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 Google has measured them as part of its page-experience signals.

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 have formed part of Google’s page-experience signals since 2021. AI features in search do not change the documented thresholds or prove an automatic increase in weight; these metrics matter primarily because they describe real user problems.

Table of Contents

1. The three metrics: LCP, INP, and CLS
2. How to measure Core Web Vitals
3. Why your site is probably underperforming
4. How to improve LCP
5. How to improve INP
6. How to improve CLS
7. The role of server infrastructure
8. FAQ

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 in the poor range and calls for diagnosis.

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, the Core Web Vitals report groups URLs using the available field data. It is a useful starting point for observing real-world issues; URLs with insufficient traffic also need consistent lab or RUM measurements.

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 — The Performance panel provides real-time metrics and detailed loading analysis. These features have replaced the role of the Web Vitals Extension, whose support ended in 2025.

An important distinction: PageSpeed Insights shows both simulated lab data and field data aggregated in the Chrome UX Report. Lab data supports diagnosis; field data describes observed experience over time and may be unavailable for low-traffic URLs.

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 — Multi-megabyte files uploaded at their original dimensions instead of versions resized and compressed for their context. They can consume a large part of the page’s loading budget.

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 should be broken down across the full loading path: initial response, discovery and loading of the main resource, and the element’s render delay. The bottleneck varies by page.

Optimise the LCP resource when measurement shows it is the bottleneck

WebP and AVIF can reduce weight compared with traditional formats, but results depend on the image and compression settings. Format, dimensions and fallbacks should be selected and measured in the site’s real context.

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 can serve a prepared response instead of regenerating it for every request. The benefit depends on the application, content and invalidation strategy and should be measured rather than assumed.

5. How to Improve INP

INP measures responsiveness to interactions. JavaScript and long main-thread tasks are common causes, but input delay, processing and presentation of the next frame should all be measured.

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.

Chrome DevTools’ Performance panel shows which work occupies the main thread. Priorities should follow measured bottlenecks while separating first-party code, libraries and third-party services.

Load third-party scripts deferred

Tracking pixels, chat widgets and analytics tools can often use defer or async, or be activated later. The choice depends on consent, dependencies and purpose, and should be measured and tested to avoid regressions or the loss of required data.

6. How to Improve CLS

CLS comes from unexpected layout shifts: images without reserved space, dynamically inserted content, fonts and other changes can contribute in different ways.

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. font-display: optional can reduce the risk by avoiding a late swap, while size-adjust can calibrate the fallback. The result should be checked with the actual fonts and browsers.

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.

TTFB should be assessed by geography, page type and infrastructure. A high value requires separating network, cache, application and database causes before acting:

• 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 where SEO and infrastructure intersect. A slow initial response consumes a meaningful part of the time available to render the main content; its impact must be measured alongside network, caching, rendering and page resources.

FAQ

Do Core Web Vitals really affect Google rankings?

They form part of page-experience signals and can contribute to the overall assessment. There is no automatic penalty independent of content and no guarantee that improving one value will raise rankings.

What is the minimum PageSpeed score to feel comfortable?

PageSpeed Insights assigns a laboratory score from 0 to 100, which is useful for comparing tests run under consistent conditions. There is no minimum score that guarantees rankings or conversions: LCP, INP and CLS, field data, diagnostics and actual user behaviour must be evaluated separately.

Do mobile and desktop scores matter equally?

Google uses mobile-first crawling, but mobile and desktop performance should be assessed separately. Mobile often reveals more network and device constraints; that makes it an operational priority, not a universal rule about a metric’s “weight”.

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?

The CrUX data used for Core Web Vitals aggregates a rolling 28-day window; this does not mean every update takes 28 days to appear. For stable sites, review the trend periodically. After a significant change, test immediately in the lab and then follow the field-data trend.

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.