Core Web Vitals 2026: What They Are, Why They Matter and How to Improve Them

Have you ever abandoned a website because it took too long to load? Or because, just as you were about to click a button, the page shifted and you ended up clicking something else entirely? Those experiences have a technical name — and for several years now, Google has been measuring them and using them to decide where to rank your site in search results.

They are called Core Web Vitals: three metrics that capture the quality of experience a user has when visiting a web page. They do not measure whether the site looks good or whether the content is valuable — they measure whether the page actually works well in the moment a real person is using it.

They became official ranking factors in 2021. In 2026, with AI increasingly integrated into search results, the weight of user experience in Google’s overall site evaluation has grown further. Yet the majority of websites have still not properly optimised for them — something we see consistently in our analyses.

1. The Three Metrics: LCP, INP, and CLS

LCP — Largest Contentful Paint

In plain terms: how long it takes for the main content of the page to become visible.

This metric measures perceived speed from the user’s perspective. Not when the page starts loading, but when the most important part — the hero image, the headline, the central block of text — is actually visible and readable.

An LCP under 2.5 seconds is considered good by Google. Between 2.5 and 4 seconds needs improvement. Beyond 4 seconds is a serious problem.

INP — Interaction to Next Paint

In plain terms: how quickly the page responds when the user does something — clicks a button, opens a menu, fills in a field.

This metric replaced FID (First Input Delay) in March 2024, because it measures responsiveness more comprehensively: not just the first click, but all interactions during the browsing session. A site that loads quickly but responds slowly to clicks is still a poor experience.

An INP under 200 milliseconds is considered good. Between 200 and 500ms needs improvement. Beyond 500ms is problematic.

CLS — Cumulative Layout Shift

In plain terms: how much the page “jumps” while loading, shifting elements the user was looking at or was about to click.

This is the metric that captures that frustrating experience where you are about to click a link and suddenly an advertisement loads, pushing everything down — and you end up clicking the wrong thing.

A CLS below 0.1 is considered good. Between 0.1 and 0.25 needs improvement. Above 0.25 is a problem Google penalises.

2. How to Measure Core Web Vitals

Before taking action, you need to know where the problem lies. The main tools are freely available:

Google Search Console — If your site is verified in Search Console, you will find the “Page Experience” report with real user data broken down by URL. This is the mandatory starting point: it shows real problems on real traffic, not simulations.

PageSpeed Insights (pagespeed.web.dev) — Analyses a single URL and returns a score from 0 to 100, separated for mobile and desktop, with a precise breakdown of each metric and the main causes of any issues. It is the most accessible tool for a quick diagnosis.

Chrome DevTools — For those familiar with browser developer tools, the Performance panel allows granular analysis of every millisecond of page loading.

Web Vitals Extension — A Chrome extension that displays metrics in real time as you browse the site, useful for identifying issues on specific pages.

An important distinction: PageSpeed Insights shows both lab data (simulated) and field data (real). The data Google uses for ranking is the real data, collected from users via Chrome. If your site has low traffic, real data may not be available.

3. Why Your Site Is Probably Underperforming

In the analyses we regularly conduct on websites, the same recurring problems appear every time. Not because whoever built the site was incompetent, but because certain choices are made without considering their impact on performance:

Unoptimised images — Images uploaded at the original camera resolution (often 4 to 6MB) instead of properly resized and compressed versions. On their own, they can cancel out any other optimisation effort.

Too many plugins and third-party scripts — Every plugin adds code the browser must download and execute. Analytics tools, chat widgets, tracking pixels, external fonts: they accumulate quickly and slow everything down.

Poor quality hosting — Server response time (TTFB, Time To First Byte) is the foundation on which all other optimisations are built. With slow hosting, even a perfectly optimised site will have a poor LCP.

No caching system — Every page is generated from scratch on every request instead of being served from a pre-built copy. This problem is compounded on dynamically generated sites.

Web fonts loaded incorrectly — Custom fonts are one of the most common causes of CLS: the page first shows a system font, then the custom font loads and shifts the layout.

4. How to Improve LCP

LCP depends primarily on two factors: how quickly the server responds and the size of the main page element.

Optimise images — this is the absolute priority

WebP format offers equivalent visual quality to JPEG with file sizes up to 30% smaller. AVIF format, supported by all modern browsers in 2026, goes further still. Always resize images to the maximum size at which they are actually displayed — there is no benefit in loading a 3,000px wide image when the container is only 800px wide.

Use lazy loading — but with care

Lazy loading defers the loading of images not visible in the initial viewport. It is useful for anything lower on the page — but it must never be applied to the main image, the one that contributes to LCP. A common mistake is enabling global lazy loading on all images and inadvertently worsening the LCP score.

Implement server-side caching

A caching system serves the pre-built page instead of regenerating it on every request. The difference in TTFB can be an order of magnitude. On managed servers, this configuration is handled at the web server level (Nginx or Apache) or through dedicated solutions such as Varnish.

5. How to Improve INP

INP measures responsiveness to interactions, and it is almost always a problem caused by JavaScript blocking the browser’s main thread.

Identify heavy scripts

Every piece of JavaScript executed in the browser’s main thread is a potential obstacle to responsiveness. Analytics scripts, third-party widgets, heavyweight libraries imported to use 10% of their features: these are the most frequent causes of high INP.

The Performance tab in Chrome DevTools shows exactly which scripts take the most time. Often it turns out that 90% of execution time is consumed by one or two third-party scripts that could be loaded lazily or removed altogether.

Load third-party scripts deferred

Tracking pixels, chat widgets, analytics tools: in most cases they do not need to be available the instant the page opens. Loading them with the defer or async attribute, or activating them only after the user’s first interaction, improves INP without sacrificing functionality.

6. How to Improve CLS

CLS is almost always caused by elements the page does not know where to place until it has finished loading.

Always specify image and video dimensions

If the browser does not know the dimensions of an image in advance, it first shows an empty space and then inserts it once downloaded — causing other elements to shift. Adding width and height attributes to the <img> element (or using the CSS aspect-ratio property) resolves the majority of image-related CLS cases.

Reserve space for custom fonts

When a web font loads after the browser has already rendered text using a system font, the typography change can shift the layout if the two fonts have different metrics. The CSS property font-display: optional avoids the problem by only using the custom font if it is already in cache, never causing a re-layout.

Be mindful of dynamically inserted banners and elements

Advertisements, cookie banners, notifications: if they are inserted into the page after the initial load and shift already-visible content, they contribute negatively to CLS. The solution is to reserve the space they will occupy in advance, so the layout does not shift when they appear.

7. The Role of Server Infrastructure

There is one aspect frequently overlooked in the Core Web Vitals debate: all front-end optimisations have a maximum ceiling determined by the speed of the underlying server.

TTFB (Time To First Byte) — the time the browser waits before receiving the first byte of response from the server — is the floor on which all other optimisations are built. With a high TTFB, even a perfectly optimised site will never achieve an excellent LCP.

A TTFB under 200 milliseconds is the target. Achieving it requires:

A server geographically close to your users — or the use of a CDN (Content Delivery Network) that distributes content across global nodes
An optimised server configuration — updated software versions, opcode caching active, web server configuration tuned for the specific site’s load
An appropriate hosting plan — on budget shared hosting, TTFB is structurally high because resources are divided among dozens of sites

This is the point where SEO and infrastructure inevitably intersect. You can optimise every image and every line of JavaScript, but if the server responds in 800ms you are already outside the parameters of a good LCP before you have even started.

FAQ

Do Core Web Vitals really affect Google rankings?

Yes, they have been official ranking factors since 2021. They are not the dominant factor — content relevance and site authority matter more — but in competitive contexts where two sites are equivalent in content quality, Core Web Vitals can make the difference. Additionally, a site with very poor metrics can be directly penalised regardless of content quality.

What is the minimum PageSpeed score to feel comfortable?

PageSpeed Insights assigns a score from 0 to 100, but the number itself is not what Google uses for ranking — Google uses the individual metrics (LCP, INP, CLS) and their thresholds. That said, a score below 50 on mobile is almost always a signal of serious problems to address. Above 70 on mobile is a reasonable starting point. Above 90 is excellent.

Do mobile and desktop scores matter equally?

Google has been using mobile-first crawling since 2019 — it evaluates your site primarily as a smartphone user would see it. Core Web Vitals on mobile therefore carry more weight. It is common to see very different scores between mobile and desktop: mobile is generally more affected because connections are slower and phones have less processing power than computers.

Can I improve Core Web Vitals on my own or do I need a specialist?

It depends on the site’s structure. Some surface-level optimisations — compressing images, removing unnecessary scripts — are accessible to anyone with the right tools. The optimisations that produce the most significant and lasting improvements — server configuration, TTFB management, code architecture, database query optimisation — require infrastructure-level work that demands specific technical expertise. A practical rule: if PageSpeed Insights identifies server-side or JavaScript execution issues, that is not territory for a DIY approach.

How often should I check my site’s Core Web Vitals?

Google Search Console updates data with approximately a 28-day lag and shows trends over time. Checking monthly is sufficient for stable sites. After any significant change to the site — theme updates, new integrations, hosting migration — an immediate check with PageSpeed Insights is worthwhile.

My site scores well on desktop but poorly on mobile. Where do I start?

The difference is almost always caused by images not optimised for small screens, excessive JavaScript slowing down less powerful devices, or fonts and resources loaded without the correct priority. The PageSpeed Insights report for the mobile version identifies exactly which elements contribute most to the issues — it is the most efficient starting point.

Are your site’s Core Web Vitals in the good, needs improvement, or poor range? We conduct a comprehensive analysis: technical SEO, speed, server infrastructure and performance optimisation. Contact us to find out what is holding your site back.

Core Web Vitals 2026: What They Are, Why They Matter and How to Improve Them (Complete Guide)