Website performance optimisation is the work of making pages load, respond and stay visually stable faster. Google measures the result with three Core Web Vitals: LCP within 2.5 seconds, INP of 200 milliseconds or less and CLS of 0.1 or less. According to the HTTP Archive Web Almanac 2025, only 48% of mobile websites passed all three, so most sites have room to improve. In 2026, seven steps fix most slow websites. Step 1 is images, because 76% of mobile pages have an image as the LCP element. Step 2 is JavaScript. The remaining steps cover rendering, caching, fonts, blocking files and monitoring. For example, a site built with Next.js gets image resizing and font self-hosting out of the box. Finally, measure with field data from real users, not only with a Lighthouse lab score.
Why does website performance matter in 2026?
Website performance is a ranking factor and a user experience factor at the same time. According to Google Search Central, "Core Web Vitals are used by our ranking systems". Google also states that Search shows the most relevant content first, even when the page experience is weak. Speed is therefore a tiebreaker in search, not a shortcut past good content. For visitors, a slow product page on a mobile connection loses attention before the first image appears. The HTTP Archive Web Almanac 2025 shows how common slow pages still are: only 48% of mobile websites passed all three Core Web Vitals in 2025. On mobile, 62% of pages reached a good LCP score, against 74% on desktop. In practice, the mobile score deserves the most attention. Google reports mobile and desktop separately, and mobile is usually the weaker of the two.
What are the Core Web Vitals thresholds?
Google judges each metric at the 75th percentile of real page loads.
Step 1: How do you optimise images for a faster LCP?
Image optimisation is the first step, because the largest element on most pages is an image. According to the HTTP Archive Web Almanac 2025, 76% of mobile pages have an image as the LCP element. The same report found that about 16% to 17% of pages lazy-load the LCP image, a share unchanged since 2024. Lazy loading delays the most important pixel on the screen. First, serve modern formats: the Next.js documentation notes that AVIF files are about 20% smaller than WebP, but take about 50% longer to encode. Second, set width and height, so CLS stays low. Third, use srcset, so phones never download desktop images. Finally, load the hero image eagerly with a high fetch priority, and lazy-load images below the fold. For example, a site built with Next.js gets resizing, modern formats and lazy loading from the Image component.
Step 2: How do you reduce JavaScript to improve INP?
JavaScript reduction is the main lever for INP, the responsiveness metric. INP replaced First Input Delay as a Core Web Vital on 12 March 2024. According to Google, an INP above 500 milliseconds counts as poor. Every script competes for the main thread, so heavy bundles make clicks and taps feel slow. First, split code per route, so a visitor only downloads the JavaScript for the current page. Second, remove unused libraries; a bundle analyser shows the heaviest dependencies. Third, delay non-essential third-party scripts, such as chat widgets and tag managers, until after the first interaction. Additionally, break long tasks into smaller pieces, so the browser can respond to input in between. In practice, a site built with Next.js and React Server Components renders on the server, so Server Component code stays out of the browser bundle.
Step 3: Which rendering strategy is fastest: SSG, SSR or ISR?
Static site generation (SSG) is usually the fastest rendering strategy, because the HTML exists before a visitor arrives. A CDN serves a static page without any database query. Server-side rendering (SSR) builds the HTML per request, which suits pages with personal or constantly changing data. Incremental static regeneration (ISR) sits in between: pages stay static, but refresh after an interval or a content change. One project built with Next.js can mix all three strategies per route. For example, a marketing page can be static, a blog can revalidate after publishing, and a customer dashboard can render per request. A client-side single page application is often the slowest option for public pages, because content appears only after JavaScript runs. Additionally, pre-rendered HTML helps Google and other crawlers read the content. In 2026, the fastest setup still renders most HTML ahead of time, which makes step 3 a choice per route rather than per site.
Step 4: How should you set up caching and a CDN?
Caching means storing a ready-made response, so server and network do less work next time. Step 4 builds on step 3, because a static page is easy to cache. First, give static files such as CSS, JavaScript and images a long browser cache. Files with a content hash in the name can stay cached for one year, because each new version gets a new name. Second, put a CDN in front of the website, so visitors download files from Amsterdam or Frankfurt, not one distant server. Third, cache expensive work on the server: database queries, API responses and rendered pages. A slow server response delays every other metric, including LCP. In practice, in 2026 server response time is still often the hidden problem on WordPress sites with many plugins. A site built with Next.js can cache rendered pages and data fetches instead. Finally, check the cache headers in Chrome DevTools, because one wrong header disables caching site-wide.
Step 5: How do you load web fonts without layout shifts?
Font optimisation is step 5, the step to stop text from jumping when the final typeface arrives. Layout shifts, according to Google's web.dev documentation, often come from fonts that render larger or smaller than the fallback font. First, limit the number of font files. For example, two families with two or three weights each is usually enough. Second, use the WOFF2 format and a subset with only the characters the website needs. Third, preload the one or two fonts used at the top of the page. Additionally, set font-display to swap or optional, so visitors read text immediately instead of waiting for a download. A variable font can replace several weight files with a single file. A site built with Next.js can use next/font, which self-hosts fonts and removes external network requests. The result is stable text and one fewer third-party connection.
Step 6: How do you remove render-blocking resources?
A render-blocking resource is a CSS or JavaScript file the browser must download before the first paint. After step 5 handles fonts, step 6 targets the remaining CSS and scripts. Every blocking file adds a network round trip, and on mobile connections each round trip costs noticeable time. First, inline the small amount of critical CSS for the top of the page, and load the rest without blocking. Second, add defer or async to scripts that do not need to run before the first paint. Third, use preconnect for the few external domains the page truly needs, such as a payment provider or an image CDN. Additionally, replace heavy embeds with a lightweight facade. For example, a YouTube embed from Google can show a static thumbnail and load the full player only after a click. A quick check with Lighthouse in Chrome DevTools lists the blocking files and the time saved per file.
Step 7: How do you monitor website performance continuously?
Continuous monitoring is step 7, the last step, because a fast website slows down again as features, plugins and tracking scripts pile up. Google offers three free tools for the job. First, PageSpeed Insights combines lab data from Lighthouse with field data from real Chrome users over the previous 28 days. Second, teams using Google Search Console get a Core Web Vitals report that groups slow URLs by problem type. Third, the open-source web-vitals library measures real user data in the browser, ready to send to any analytics tool. PageSpeed Insights, according to Google, reports the 75th percentile for field metrics, the same percentile used for the Core Web Vitals assessment. In practice, a short performance check before every release in 2026 prevents most regressions. A performance budget, for example a maximum JavaScript size per page, makes the check objective.
Frequently asked questions
Do you need a Lighthouse score of 100?
No, a Lighthouse score of 100 is not necessary. Core Web Vitals are measured with field data from real users, not with a lab score. Lighthouse is a lab test on one simulated device and one simulated connection. For example, compare a page with a lab score of 85 and good field values against a page with 100 in the lab. When the second page has a poor INP for real users, the first page is in the better position. Step 1 is therefore checking the field data with PageSpeed Insights or the Core Web Vitals report in Google Search Console. In practice, aim for good field values for LCP, INP and CLS first, measured at the 75th percentile of page loads. Relevance, according to Google Search Central, still outweighs page experience in 2026, so content quality remains the first priority. A lab score remains useful as a quick test before each release.
Is Next.js faster than WordPress?
Next.js is not automatically faster than WordPress, but the framework makes a fast result easier to reach. WordPress speed depends on hosting, theme and plugins, and according to W3Techs, WordPress runs 39.7% of all websites in October 2026. First, a lean WordPress theme on good hosting with page caching can pass all three Core Web Vitals. Second, a heavy page builder with many plugins can struggle with INP or LCP. A React framework such as Next.js starts from pre-rendered HTML, automatic code splitting and built-in image and font optimisation, so many fixes are part of the foundation. For example, the VirtuoLab website itself runs on Next.js with React Server Components. The trade-off is content editing, because a Next.js site usually needs a headless CMS, while WordPress offers an editor out of the box. Step 1 in any fair comparison is measuring field data for real pages, not for a demo page.
Should you optimise an existing website or rebuild it?
Optimising an existing website is the right choice when the foundation is sound and the problems are specific. Typical examples are large images, missing caching or too many scripts. A rebuild is the better investment when an old theme, a heavy page builder or outdated hosting blocks every improvement. First, check the field data in PageSpeed Insights for the 5 pages with the most visitors. Second, estimate the effort per cause Lighthouse reports. When the fixes touch almost every template, a rebuild is usually the more predictable route. For example, a site with 8 pages on a modern theme may need only image and caching fixes. A heavy page builder on every template points towards a rebuild. VirtuoLab gives an indication of €2,000 to €8,000 for a business website in 2026. Step 1 is a free introductory call with VirtuoLab, after which the exact price follows.