Core Web Vitals are often treated as a marketing metric: a score to push up before a launch, then forget. That misses the point. They measure how real people experience your pages, they feed into how search engines evaluate them, and when they are poor, the cause is almost always architectural. Fixing them properly means fixing how the site is built.
What is measured, and how
There are three Core Web Vitals:
| Metric | Measures | Good |
|---|---|---|
| Largest Contentful Paint (LCP) | How quickly the main content appears | 2.5 seconds or less |
| Interaction to Next Paint (INP) | How quickly the page responds to input | 200 milliseconds or less |
| Cumulative Layout Shift (CLS) | How much content moves unexpectedly | 0.1 or less |
Two details matter more than most teams realise.
First, these are field metrics. Search engines use data from real Chrome users, published in the Chrome UX Report, not your Lighthouse run on a fast laptop. Lighthouse is a diagnostic tool; real-user data is the scoreboard.
Second, a page passes at the 75th percentile. Three quarters of visits must meet the threshold. Slow phones and weak networks are not edge cases; they are a quarter of your score.
LCP: get the main content to the screen
LCP measures when the largest image or text block in the viewport finishes rendering. It breaks down into four parts, and each has its own fixes.
Time to first byte. Serve HTML from the edge. Static or pre-rendered pages on a CDN routinely return in tens of milliseconds. Server-rendered pages need caching that actually hits.
Resource load delay. The browser must discover the LCP resource early. Do not lazy-load the hero image, do not inject it with JavaScript, and add fetchpriority="high" to it. If it is a background image in CSS, preload it.
Resource load time. Serve modern formats such as AVIF or WebP, sized for the device with srcset. A 2,000-pixel image on a 400-pixel phone screen is the most common LCP problem we see.
Render delay. Render-blocking CSS and fonts hold everything back. Inline the critical CSS, keep stylesheets small, and use font-display: swap with a size-adjusted fallback font so text appears immediately.
INP: keep the main thread free
INP replaced First Input Delay in 2024 and is far stricter: it considers the latency of interactions throughout the visit, not only the first. When INP is poor, the cause is nearly always long tasks on the main thread.
- Ship less JavaScript. Every kilobyte must be parsed, compiled and executed. Static HTML with small islands of interactivity beats hydrating an entire page.
- Break up long tasks. Yield to the main thread between chunks of work so the browser can respond to input.
- Audit third-party scripts. Tag managers, chat widgets and analytics often dominate main-thread time. Load them late, or not at all.
- Keep the DOM small and avoid layout thrashing. Reading layout properties immediately after writing styles forces synchronous layout work.
CLS: reserve space for everything
Layout shift happens when content arrives without space reserved for it.
- Always set
widthandheight(oraspect-ratio) on images, videos and iframes. - Reserve space for ads, embeds and banners before they load.
- Use metric-matched fallback fonts so the swap to the web font does not reflow text.
- Never insert content above existing content unless the user asked for it.
- Prefer CSS
transformfor animations, which do not trigger layout.
Performance, SEO and accessibility are one discipline
The engineering that produces good Core Web Vitals also produces pages that search engines and AI assistants can read: semantic HTML, a single clear heading structure, server-rendered content that does not depend on JavaScript, descriptive links and structured data that states what the page is about. The same discipline produces accessible pages. On large estates, we track accessibility against WCAG 2.2 AA with the same rigour as performance, because both are measures of whether people can actually use the site.
Measuring at scale
For a single site, Search Console and the Chrome UX Report are a good start. For an estate of many sites across markets, you need more: scheduled audits of every page template, field data joined to the architecture each site runs on, and dashboards that tell each team what to fix. Two lessons from building that kind of platform:
- Store metrics at the precision they are defined. CLS is a decimal. Store it as an integer and 0.05 becomes 0, and every site looks perfect.
- Never let an unmeasured metric look like a pass. Show it as pending, so nobody mistakes a gap in data for a good result.
Where we can help
This website is built the way this article describes: pre-rendered HTML on a global edge network, one small inlined stylesheet, a single preloaded font, almost no JavaScript and structured data on every page. If your site or estate needs the same, see our technical SEO and web performance service or get in touch.