Core Web Vitals in 2026: how to read LCP, INP and CLS and what actually moves the numbers

Core Web Vitals are the three metrics Google uses to describe a page experience: how quickly the main content appears, how quickly the interface responds to an action, and how much the layout moves while the page loads.

Since March 2024, the set has consisted of LCP, INP and CLS. FID was retired, and INP took its place because it measures the full duration of an interaction rather than just the delay before the first response. For a brochure site or an online store, these thresholds are not a reporting formality: they describe whether someone presses the button or closes the tab.

01. What Core Web Vitals measure in 2026

Google scores real user experience in Chrome through the Chrome UX Report (CrUX). Data is collected continuously, aggregated over the last 28 days and evaluated at the 75th percentile. In other words, a metric is good only when 75% of real visits fall within the threshold, not when the average looks fine.

A fourth number is useful but is not an official Core Web Vital: TTFB. It shows how long the browser waits for the first byte from the server. When TTFB is high, even a perfectly compressed image cannot rescue LCP.

Two data sources are often confused. Field data comes from real browsers and reflects real phones, networks and habits. Lab data comes from a controlled test, usually on a stable server, and is useful for reproducing a problem, not for deciding whether the site is fast.

02. LCP: first impressions are decided on the server

LCP breaks into four stages, and each has a different culprit: TTFB, the delay before the resource starts downloading, the download duration and the delay before the element renders. Once you know which stage is losing time, you stop optimizing at random.

Common causes

• A slow server or no cache: heavy queries on every visit, PHP without OPcache, databases without indexes.
• Render-blocking CSS and JavaScript: oversized files in the <head>, loaded synchronously.
• An unoptimized hero image: several megabytes sent to mobile, with no width, height or srcset.
• Web fonts: text waits for the font file, and the fallback is not prepared.
• Client-side rendering: the HTML arrives almost empty and content appears only after JavaScript runs.
• Lazy loading in the wrong place: the main image is deferred as if it were far below the fold.

What actually works

• Response caching and a CDN: HTML cached at the edge, not just images.
• Modern compression: Brotli for HTML, CSS and JavaScript.
• Responsive images: AVIF or WebP, correct dimensions, srcset and fetchpriority="high" on the LCP element.
• Preload only what matters: the hero image and the primary font, not dozens of speculative resources.
• Inline critical CSS: the remaining stylesheets load without blocking the first render.
• Server-side rendering: complete HTML in the first response, regardless of framework.

Before changing anything, open DevTools, run a performance profile with mobile throttling and identify the actual LCP element. Sometimes it is not the image at all, but a large heading waiting on a font or a text block rendered only after hydration.

03. INP: responsiveness lives on the main thread

INP does not ask how fast the page loads. It asks how fast the page reacts after the user does something. It includes the time until the browser can begin processing the event, the execution time of the handler and the time until the next visible frame. A single click that blocks the main thread for 600 milliseconds ruins the metric for the entire session.

Where the time goes

• Long tasks: any chunk of JavaScript that keeps the main thread busy for more than 50 milliseconds.
• Bloated JavaScript bundles: entire libraries loaded for a single function.
• Third-party scripts: chat, heatmaps, A/B testing, consent banners and pixels that run before the content.
• Expensive hydration: large components that re-run logic on the client on every load.
• Costly handlers: layout recalculations, filters applied synchronously on every keystroke, huge lists re-rendered from scratch.

What actually improves INP

The first move is to remove anything unnecessary from the path of an interaction. The second is to split the code so the page downloads only what it uses. The third is to hand control back to the browser between heavy chunks of work so it can paint a frame.

button.addEventListener('click', async () => {
    // yield before a heavy operation
    if ('scheduler' in window && 'yield' in scheduler) {
        await scheduler.yield();
    }

    renderResults();
});

The rest of the measures are just as concrete: load third-party scripts after the first interaction or after consent, use defer and dynamic imports, move heavy computation into Web Workers and avoid reading layout inside scroll handlers. For forms and long lists, debouncing and event delegation reduce the number of executions, not only their duration.

04. CLS: reserved space beats any animation

CLS does not measure how long loading takes. It measures how aggressively elements move under the user's finger. A button that jumps 80 pixels down exactly when someone tries to press it is a conversion problem, not just a score problem.

Common causes

• Images without dimensions: the browser cannot reserve space until the file arrives.
• Fonts that change metrics: text reflows when the custom font appears.
• Ads and embeds: iframes without a fixed height, slots filled late.
• Injected banners: consent notices or promotions that push content down.
• Content added above: error messages, alerts or asynchronously loaded components over the visible area.

What actually works

• Explicit dimensions: width and height on images, aspect-ratio on containers.
• Reserved space: a minimum height for ads, embeds, cards and areas that load asynchronously.
• Disciplined fonts: font-display: swap or optional, plus a fallback with close metrics via size-adjust.
• Banners as overlays: a cookie banner should sit above the layout, not push it down.
• Transform-based animation: transform and opacity do not trigger reflow, unlike top or height.

A useful audit trick: load the page with a throttled network and an empty cache, then watch the filmstrip. Shifts that happen in the first seconds are the ones that count for CLS, even if a user on a fast laptop never notices them.

05. How to measure without fooling yourself

The right order is simple: field data first, then segmentation, then the lab to reproduce. If you start with Lighthouse, you risk fixing a symptom that real users never see while ignoring the problem that actually affects them.

When you compare results, keep the context constant: same device class, same network, same page version. Otherwise the gap between two reports may come from the test conditions rather than from your code.

06. Platform notes: Laravel and WordPress

The principles are the same everywhere, but the tools differ. In Laravel you control the delivery chain directly. In WordPress you often inherit decisions made by plugins you do not control.

Laravel

Start with the server response: OPcache enabled, indexed queries, eager loading for relationships and a cache layer for pages that do not depend on the session. Then look at Vite. The manifest and dynamic imports let you ship only the JavaScript a page needs, and modules load natively with defer. Do not bundle the entire front end into one package just because it feels simpler.

For images, generate AVIF and WebP variants on upload in a queued job, and store the real dimensions in the database. The template should output a proper srcset, not a single 3000-pixel image resized with CSS. Put a CDN in front of the application and add cache headers for hashed assets.

Pay attention to interactive components above the fold: if hydrating them blocks the main thread, LCP and INP suffer together. Isolate them and load them after the main content is visible.

WordPress

The problem is not WordPress itself, but the layer of plugins and page builders added on top. Every plugin that loads CSS and JavaScript globally on every page raises the cost for the visitor, even when its feature is used on a single page.

• Remove duplicate plugins and those that load assets across the whole site.
• Check which fonts and icon sets the theme and the builder load.
• Enable page caching and, for authenticated traffic, an object cache.
• Use a CDN and server-level compression, not just an optimization plugin.
• Test every change on staging, because a caching plugin can hide a code problem.

07. A practical checklist

Order matters. Do not optimize images before you know whether the server responds in two seconds, or you will measure the same problem again.

08. What to do on Monday morning

If you do not have time for the whole process, start with the three changes that usually matter most: caching and a CDN for TTFB, a correctly sized hero image, and removing third-party scripts from the path of the first interaction. Then measure again, in the field, on mobile.

Do not look for a single miracle fix. Core Web Vitals are the result of small decisions made consistently: every image has dimensions, every script has a reason to exist, every component loads when it is needed. That is how a site stays fast even after new features ship.

If you want a code-level assessment with clear priorities and no inflated reports, we can start with speed optimization for your site, or with a direct conversation about what can be fixed in your current architecture.