Core Web Vitals in 2026: what they actually measure and why your agency probably isn't fixing the right things

If your SEO agency's Core Web Vitals strategy involves compressing images and installing a caching plugin, you're not fixing the problem. You're treating the symptoms while the underlying condition gets worse.

Core Web Vitals are Google's framework for measuring real-world page experience. They became a confirmed ranking signal in 2021, and they've been updated since — most significantly in 2024 when Interaction to Next Paint (INP) replaced First Input Delay (FID) as the interactivity metric. Understanding what these metrics actually measure tells you a great deal about how a website was built.

Largest Contentful Paint (LCP)

LCP measures the time from when the page starts loading to when the largest visible content element — typically a hero image, a heading, or a large text block — finishes rendering.

Google's thresholds: under 2.5 seconds is "good", 2.5–4.0 seconds needs improvement, over 4 seconds is poor.

What LCP actually reveals about your site:

• Server response time (TTFB). If your server takes 1.5 seconds to respond, your LCP cannot be below 1.5 seconds regardless of anything else. LCP starts from the first navigation request — server latency is baked directly into it.
• Render-blocking resources. If your site loads a 400KB CSS file before rendering anything, the browser waits for that file before painting. Every render-blocking stylesheet or script delays LCP. Page builders are notorious for loading all their CSS on every page, whether it's used or not.
• Image delivery. Yes — image optimisation does matter here, specifically for the LCP element if it's an image. Serving the right format (WebP, AVIF), the right size for the viewport, and with correct preload hints will improve LCP for image-heavy pages.
• Font loading. Web fonts loaded from external servers (Google Fonts, Adobe Fonts) can block LCP if not handled carefully. Self-hosting fonts with correct font-display settings is a meaningful fix.

Cumulative Layout Shift (CLS)

CLS measures visual stability — how much the layout unexpectedly shifts as the page loads. A score of 0 means nothing moved. A score of 0.1 or below is "good". Above 0.25 is poor.

CLS reveals how carefully the CSS and HTML were written:

• Images without dimensions. If an image loads and pushes content down because no width and height attributes were set in the HTML, that's a CLS hit. This is a basic development discipline issue — it's easy to get right and easy to get wrong.
• Dynamically injected content. Cookie banners, chat widgets, newsletter popups, and ad units that load after the initial paint and shift content are a common CLS culprit. Many third-party scripts do this without warning.
• Web font FOUT/FOIT. Flash of Unstyled Text or Flash of Invisible Text occurs when a web font loads and the fallback font is replaced. If the two fonts have different metrics, the layout shifts. Correct font loading strategy, combined with font-display: optional or size-adjust CSS, prevents this.
• CSS animations that affect layout. Animations that change properties like height, margin, or padding (rather than transform and opacity) cause layout recalculations and contribute to CLS.

Interaction to Next Paint (INP)

INP replaced First Input Delay (FID) in March 2024. This is the metric most agencies are least prepared for, and it's the one that most directly reflects JavaScript quality.

INP measures the time between a user interaction (click, tap, keyboard input) and the next visual update — across all interactions during a page session, not just the first one. A score under 200ms is "good". Over 500ms is poor.

FID only measured the delay before the browser could start processing the first interaction. It didn't measure how long that processing took. INP measures the full response time, including the JavaScript execution that follows the interaction. This makes it much harder to fake.

What a poor INP score reveals:

• Long JavaScript tasks blocking the main thread. If a user clicks a button and the browser is busy running a 300ms JavaScript task from an analytics script or a page builder framework, the interaction response is delayed. The browser can only do one thing at a time on the main thread.
• Excessive third-party scripts. Every third-party script — chat widgets, tag managers, ad trackers, social embeds — competes for main thread time. A site with eight third-party scripts loaded synchronously will struggle to achieve a good INP score regardless of how well the first-party code is written.
• Inefficient event handlers. JavaScript event handlers that do heavy work synchronously — DOM manipulation, complex state recalculations, synchronous storage reads — will delay paint after interaction. Proper code design defers or batches this work.

Why most SEO fixes don't work

The image compression checklist — WebP conversion, lazy loading, compression ratios — addresses one input into LCP on image-heavy pages. It does nothing for TTFB, render-blocking resources, JavaScript execution time, or layout stability.

Most "SEO agencies" don't have front-end developers on staff. They have content writers, link builders, and analysts. When Core Web Vitals fail, they reach for the tools they know: image optimisation plugins, caching plugins, and PageSpeed Insights screenshots to show the client something is happening.

Real Core Web Vitals improvements require development work: restructuring how CSS is loaded, auditing and removing third-party scripts, fixing layout instability at the CSS level, profiling JavaScript execution, and — fundamentally — building sites that don't have these problems in the first place.

A site built by developers who understand browser rendering, server response times, and JavaScript performance will pass Core Web Vitals naturally. A site built in a page builder with 15 plugins will not — no matter how many images are compressed.

If your site is failing Core Web Vitals and your current agency's answer involves a plugin, talk to us. We'll look at the actual data from your CrUX report and tell you what's really going on. If you want to understand what a properly built site looks like under the hood, we're happy to walk you through it.