Core Web Vitals on large sites

The three metrics and their thresholds

The thresholds are fixed and published by Google: they apply identically to every site, and they are not negotiable.

A page passes only if it is inside the threshold on all three.

How they are actually measured

Almost everything is decided here, and it is the part most guides skip. Three things change how the numbers should be read.

1. They are field data, not lab data. The values that count come from the Chrome UX Report — real user sessions, on their devices and their connections. Lighthouse and the PageSpeed Insights score are a simulated test: they are for diagnosis, not for deciding whether a page is inside or outside the threshold.
2. They count at the 75th percentile. It is not the average user that matters: it is the value below which 75% of loads fall. Put another way, a page is fine on a metric when at least three loads in four are inside the threshold. The assessment is per page group and per metric, not per site. That is why a reassuring average can coexist with a quarter of users struggling.
3. The window is 28 days, and it rolls. The Search Console Core Web Vitals report shows, for each metric, the 75th percentile of visits over the last 28 days. A fix published today enters the data gradually, as the old sessions leave the window. Reload the report the next day and you see nothing, and conclude the work did not land.

Which tools measure what

The tools are not interchangeable: some produce lab data, some field data, and one puts them side by side.

• Search Console, Core Web Vitals report. This is the source that counts: field data, grouped by template, split between mobile and desktop. This is where you decide what to work on.
• PageSpeed Insights. It shows both on one screen: the URL's field data at the top, if there is enough of it, and the lab test below. The score out of a hundred is lab data and is not a Core Web Vital.
• Lighthouse and Chrome's Performance panel. These are for working out why a page is slow: which element is the LCP and which resource determines it, which script is holding the main thread, which block causes the shift.
• Chrome UX Report. The database behind the field data. Useful when you need comparisons across months, or across domains you do not control — competitors, for instance.

The practical rule: diagnose in the lab, verify in the field. Reverse the two and you optimise a simulated score without knowing whether users noticed.

Why the average misleads on large sites

On a site with few templates the average tells you almost everything. On a site with dozens of them the average is the sum of different behaviours, and a template that loads badly but gets little traffic disappears inside the aggregate.

Search Console makes this explicit: the report's URLs are not listed one by one but collected into groups of pages with a similar user experience, and the LCP, INP and CLS status applies to the whole group. In practice the report already thinks in templates. When a group's data is not enough, Google merges it into an origin-level group — every URL sharing protocol, host and port — and at that point the number you are reading is an average of everything, and diagnoses little. Note that subdomains and the http version count as separate origins.

So the useful question is not what the site average is. It is which templates are below the threshold and how much organic traffic they get. Those are two different lists, and the second one decides the order of the work.

How to take the number apart

1. Group URLs by template, not by site section.
2. Read the 75th percentile, not the average.
3. Separate mobile and desktop before drawing conclusions.
4. Check whether Search Console is showing you an origin group instead of page groups: if so, there is too little data for that template.

What actually moves the numbers

The three metrics break for different reasons and are repaired by different work. They are worth taking one at a time.

LCP: almost always a single resource

The LCP element is the largest block of content visible in the viewport, not the heaviest in bytes. Usually it is the main image, a video poster, a background image declared in CSS, or the opening block of text.

The reason LCP work so often goes nowhere is that the wrong part gets optimised. Google breaks LCP into four subparts, with an ideal distribution:

The two subparts that should stay under 10% are the ones that blow up in practice. Load delay is the time between the first byte of the HTML arriving and the browser actually starting to download that resource: usually because it discovers it late — when the main image is declared inside a CSS file, loaded by a script or hidden in a carousel — and sometimes because it assigns it a low priority. Render delay is the time the resource has already arrived but is not being painted, typically because a font or a script is blocking it.

Three fixes cover most cases:

1. Declare the main image's priority with fetchpriority="high", and add a preload when the resource is not discoverable straight away in the HTML.
2. Never put loading="lazy" on the LCP element. It is the most frequent mistake when lazy loading is applied to every image in the template.
3. Cut TTFB with server-side caching and a fast response, because it is one of the two heaviest subparts and the only one that falls on every page at once.

CLS: space not reserved

Layout shift has an even more concentrated cause: something takes up space after the page has already been painted, and pushes everything below it down. The causes Google lists are always the same:

• images and videos with no declared dimensions;
• fonts that load and render at a different size from the initial fallback;
• ads, widgets or third-party iframes that resize themselves;
• elements inserted into the DOM above content that is already there;
• animations built on properties that recalculate layout rather than on transform.

CLS does not add up every shift on the page: it takes the worst session window, meaning the cluster of closely spaced shifts with the highest score. A window closes after one second with no shifts, or after five seconds regardless. Which is why a single banner arriving late can determine the page's value on its own.

The fix is always the same: reserve the space first. Declared dimensions on images and iframes, a fixed-height container for blocks inserted later, and a font fallback strategy that does not change the size of the text.

INP: the main thread is busy

There is a widespread misunderstanding to correct here. INP does not measure the first interaction. That was the previous metric, FID, which INP replaced in March 2024. INP watches every click, tap and keyboard interaction in a visit, and reports the slowest one, discarding outliers.

It is a stricter and a more honest measure: a page that answers the first click well and every later one badly passed under FID and does not under INP.

Each interaction splits into three phases: input delay, the wait before the browser starts processing; processing duration, the time the event's code takes to run; and presentation delay, the time to paint the next frame. The dominant cause of a high INP is long tasks on the main thread, which keep the browser busy while the user is already clicking.

On large sites the culprit is almost always the same: third-party scripts, heavy tag managers, and the template's JavaScript all executed at once on startup.

How the work goes, template by template

The advantage of a large site is that one fix on one template applies to every page that uses it. A fix on the template carrying most of the organic traffic moves the aggregate more than ten fixes on individual pages.

So the sequence is always the same:

1. Sort the templates by organic traffic, not by how bad the problem is. A disastrous template with a hundred visits a month can wait.
2. Find the subpart that dominates, before touching any code. On LCP that means knowing whether the time sits in TTFB or in render delay: those are two different jobs.
3. Fix the template, not the pages that use it.
4. Verify in the lab immediately, so you know whether the fix did anything to that page.
5. Wait for the field data before calling the work done. In Search Console you start monitoring and validation runs for 28 days: if the problem does not reappear on any URL in the group during that time, it counts as fixed.

The last two steps are separate on purpose. The lab test tells you whether you did the work well, the field data tells you whether it helped users. Only the second one counts for Google.

How much they really weigh on ranking

It is worth being precise here, because on this point most guides overstate it in one direction or the other. Google places Core Web Vitals inside page experience, describes them as aligned with what its core ranking systems reward, and recommends that site owners have good values. But it also makes two things clear: there is no single page experience signal, and Search still shows the most relevant content even when the experience is poor. Translated: they do not make up for being less relevant. A slow but much more relevant page keeps ranking above a fast, generic one.

Where they genuinely bite is with everything else equal, and on what people do once they arrive. On an ecommerce site or a large publisher that shows up in conversions before it shows up in positions.

Core Web Vitals and AI answer engines

The link to visibility in answer engines is indirect but real, and it runs along two paths.

The first is crawling. Field metrics are not read by crawlers, but the same causes that worsen them slow crawling down: a slow server reduces the rate at which Google downloads pages, and content that only appears after JavaScript runs may not be seen at all by AI systems' crawlers, many of which do not run JavaScript.

The second is structure. Getting the main content and links into the initial HTML is the same fix that improves LCP and INP and that makes the page readable to whatever fetches it in order to cite it. Performance work and citability work overlap more than they appear to.

Common questions