Core Web Vitals: why speed has become SEO

The quiet change of 2021

In May 2021, Google officially built the Core Web Vitals into its ranking algorithm. For 18 months before that date, the search engine had been communicating step by step so that developers could prepare. Many did not take it seriously. Five years on, in 2026, the ranking gap between the sites that optimised and those that did not is massive.

On competitive queries, Core Web Vitals have become a technical sorting factor on a par with content relevance. On keywords with strong transactional intent (“SEO agency Geneva”, “website design Switzerland”), a site with a Lighthouse score of 70 does not rank, even with content objectively better than that of the Lighthouse 95 site in first position.

A site targeting these queries therefore needs to know what Core Web Vitals really measure and how to meet them in 2026.

The three metrics that count

Google publishes around ten performance metrics through Lighthouse. Only three of them are part of the official Core Web Vitals in 2026.

Largest Contentful Paint (LCP) measures the loading time of the largest element visible on screen when the page first displays. It is usually a hero image, an H1 heading or a video. Google’s target: under 2.5 seconds. Beyond 4 seconds, the experience is rated poor.

Interaction to Next Paint (INP) replaced the former First Input Delay (FID) in 2024. INP measures the delay between a user interaction (click, tap, keystroke) and the moment the page responds visually. Target: under 200 ms. Beyond 500 ms: poor.

Cumulative Layout Shift (CLS) measures the visual shifts in the layout during loading. You have all seen it: you are about to click a button, an advertising banner loads at the top, the button moves and you click on something else. Target: a score below 0.1.

Together, the three Core Web Vitals measure the user’s real experience during loading and interaction: the time they spend waiting.

Why Google gives these metrics so much weight

Google has three reasons, in order of importance.

Mobile has crushed desktop. In 2026, 65% of Google searches come from smartphones. On mobile, the slightest slowness has a massive impact on the user experience: a variable 4G or 5G connection, a less powerful processor, a short attention span. Google cannot afford to push slow results into position 1, or people will use Google less.

Competition from social networks and AI. When you look for information, you can choose between Google, TikTok (45% of under-30s), ChatGPT and other LLMs with web search. Google no longer has a monopoly. If its experience becomes frustrating, its users leave. Pushing slow sites into position 1 degrades its product.

Measurement has become precise and anonymous. Since the Chrome User Experience Report (CrUX) arrived, Google has been measuring real experience times across tens of millions of real sessions, without any individual cookie. This data feeds the algorithm in real time. A site whose Core Web Vitals deteriorate sees its traffic fall in the weeks that follow.

What hurts LCP

LCP is the metric most closely tied to the site’s technical stack. Five main causes.

Images that are too heavy or not optimised. A 2 MB hero image on mobile = at least 2 seconds of loading on average 4G. The solution: WebP or AVIF compression (modern formats 30 to 50% lighter than JPEG), responsive images with a srcset suited to each viewport, and lazy loading for everything below the fold.

Blocking web fonts. A custom font loaded synchronously blocks rendering until it arrives. With font-display: swap, a fallback font shows immediately; you can also serve the fonts locally to avoid a third party’s latency.

Render-blocking CSS and JavaScript. Any file in the <head> without async or defer blocks rendering. Inline the critical CSS in the HTML, load the rest without blocking, and split JavaScript bundles into logical chunks.

High response time. A server that responds in 500 ms (high TTFB) automatically adds 500 ms to the LCP. HTTP/2 or HTTP/3 and Brotli compression reduce that delay.

An unsuitable technical stack. WordPress with 30 plugins, or a React SPA that hydrates an editorial page on the client side, inevitably drag the LCP down. It is better to choose a modern stack suited to the type of page (Astro for editorial, Next.js for interactive, Remix for transactional).

What hurts INP

INP depends on the amount of JavaScript running at the moment the user interacts with the page.

Over-engineered JavaScript. Many sites load 500 KB of JavaScript for a page that could work with 50 KB. Every additional KB has to be downloaded, parsed, compiled and executed. On a mid-range phone, the effect is dramatic.

Blocking long tasks. A JavaScript function that runs for more than 50 ms blocks the main thread. If the user clicks during that time, the interaction is delayed. Break up long tasks (setTimeout, requestIdleCallback, Web Workers for heavy calculations).

Misused SPA frameworks. React, Vue and Svelte are excellent for applications. For a business website, they are oversized. If you use React for an “About” page, you are paying 200 KB of JS for nothing.

What hurts CLS

CLS is the least technical of the three, but the most visible to the user.

Images without declared dimensions. An <img> without a defined width and height causes a shift during loading. Always declare the dimensions, either as HTML attributes or with CSS aspect-ratio.

Web fonts that change the layout. The swap from a fallback font to the custom font can shift all the text. Choose a fallback font with similar metrics, or use size-adjust in @font-face to specify the dimensions.

Content injected with JavaScript after the first render. Cookie banners, pop-ups, chat widgets. Reserve the space with a placeholder of the right size, or delay the injection until the user interacts.

Ads and third-party embeds. YouTube iframes, Twitter widgets, advertising banners. Here too, reserve the space with aspect-ratio or a fixed minimum height.

How to test your site

Three tools to know.

PageSpeed Insights (https://pagespeed.web.dev) gives the mobile and desktop Lighthouse score, with detailed recommendations. It is Google’s official tool. The test is a one-off, with no tracking over time.

Search Console (Core Web Vitals report) gives your site’s real data aggregated over 28 days, by group of URLs. This is what Google actually uses to rank you. Keep a constant eye on it.

WebPageTest (https://webpagetest.org) gives a detailed analysis of the loading waterfall. Excellent for identifying specific bottlenecks.

The 2026 target: mobile Lighthouse > 90 on PageSpeed Insights, and 75% of URLs rated “good” in the Search Console Core Web Vitals report. Below that, your site is handicapped on competitive queries.

What we do at Voren

Every Voren site is designed with Core Web Vitals as an architectural constraint, built in from the design stage.

A stack suited to the type of page. Astro for editorial and corporate sites (static HTML with partial hydration), Next.js for highly interactive sites, Remix for transactional applications. We never deliver an SPA for a site that does not need one.

Images optimised by default. Automatic WebP or AVIF compression, responsive images with srcset, lazy loading below the fold.

Fonts served locally with font-display: swap. Google Fonts is never loaded synchronously, which avoids FOIT (Flash of Invisible Text) and any visible FOUT.

Critical CSS inlined. The CSS for the first view sits in the <head>, and the rest loads without blocking.

Lighthouse > 95 targeted on every business website package, measured at go-live.

The real reason that makes the difference

Many agencies treat Core Web Vitals as an end-of-project optimisation: you build the site, launch it, look at Lighthouse, patch. It partly works, but it always leaves 10 to 20 points on the table.

The difference is made at the design stage. Choosing Astro rather than WordPress at the start of the project gains you 30 Lighthouse points without any optimisation effort. Choosing compressed WebP images rather than PNGs gains you 10 points.

When these choices are made at the start of the project, your site reaches production with a Lighthouse score of 95, without laborious optimisation. When they are not, you then spend weeks optimising after the fact, for marginal gains.

Going further

If your site has a mobile Lighthouse score below 75, that is probably the number one cause of your stalled SEO. Before investing in content or backlinks, you need to fix the technical foundation.

Request a free SEO audit: we look at your Lighthouse score, your Core Web Vitals and your stack, and tell you what to prioritise, within 7 days.

Discover our website design packages: all our sites are delivered with a Lighthouse score measured at go-live (> 95 for a business website).