Core Web Vitals for large sites: how to fix LCP, INP and CLS (2026)

Core Web Vitals are Google's three measures of real-user experience. Largest Contentful Paint (LCP) tracks loading and should land within 2.5 seconds of the page starting to load. Interaction to Next Paint (INP) covers responsiveness, with 200 milliseconds or less counted as good. Cumulative Layout Shift (CLS) measures visual stability, and a good page keeps it at 0.1 or less while it loads. Google scores each one at the 75th percentile of real Chrome visits, on mobile and desktop separately. They're a confirmed ranking signal, though a small one. On a large site, you fix them one template at a time, never one URL at a time.

I'm Brenden House, and I run Searchmaxxed, an SEO and AI SEO agency that does technical SEO for enterprise and B2B SaaS companies. On 27 October 2026 (AEST) I read Google's current documentation and the HTTP Archive's 2025 Web Almanac. The numbers below come from those.

In summary

Thresholds: Google Search Central and the 2025 Web Almanac, read 27 October 2026.

• A page passes only when all three metrics are good at the 75th percentile of real visits, per web.dev.
• Google says Core Web Vitals "are used by our ranking systems", and also that the most relevant content still wins when page experience is sub-par.
• Big sites struggle most with INP. Only 63% of the top 1,000 mobile sites had good INP in July 2025, against 77% of all mobile sites.
• Field data from real Chrome users (CrUX) is what Google uses for Search, while Lighthouse lab scores are there to help you debug the cause.
• Fix the template, ship it, then let Search Console's 28-day window confirm it. That's how we run it at Searchmaxxed.

What are Core Web Vitals?

Core Web Vitals are three metrics Google uses to describe how a page feels to a real visitor. Speed, response, stillness. Google's Search Central page lists them as LCP, INP and CLS, measured from "real-world user experience".

Each one has a plain meaning.

• Largest Contentful Paint (LCP) is the time until the largest image or text block in the viewport has rendered. On most marketing pages it's the hero image or the H1, which is why one hero component shapes LCP for every page built on it.
• Interaction to Next Paint (INP) is the delay between a user's interaction and the next frame the browser paints. It takes the slowest, or near-slowest, interaction on the page, so one sluggish filter or menu can sink it.
• Cumulative Layout Shift (CLS) scores unexpected movement. A cookie banner that pushes the article down, or an image that loads without reserved space, adds to it.

INP is the newest. It replaced First Input Delay (FID) as a Core Web Vital on 12 March 2024, according to Google's web.dev announcement. FID only measured the first interaction's delay. INP measures every interaction through the visit, which is far harder to pass on a JavaScript-heavy site. Still see FID in a guide? It's out of date.

Two more rules decide whether a page passes or fails. Google takes the 75th percentile of page loads, so a quarter of your visitors can have a worse experience and the page still passes. And it splits mobile from desktop, so a page can be good on one and poor on the other.

Do Core Web Vitals affect SEO rankings?

Yes, but modestly. Google's page experience FAQ states plainly that "Core Web Vitals are used by our ranking systems". The same page says Google "always seeks to show the most relevant content, even if the page experience is sub-par."

Google adds a warning of its own. It writes that "trying to get a perfect score just for SEO reasons may not be the best use of your time". Good scores won't lift a page to the top on their own. And there's no single "page experience signal" either, because Google's core ranking systems look at many signals that line up with a good experience.

So where does it count? In a crowded result where several pages answer the question equally well, Google's FAQ says a great page experience "can contribute to success". That's common in B2B SaaS and enterprise categories, where several vendors often publish near-identical comparison pages.

Treat them as a floor. Get every money template to "good", then stop chasing points and put the effort into pages and links. Shaving an LCP from 1.9 to 1.4 seconds is unlikely to move rankings. Lifting a pricing template from "poor" to "good" might, and it helps conversion either way.

Google also evaluates page experience mostly page by page, with "some site-wide assessments", per the same FAQ. That's why a slow template matters more than a slow page: a template is hundreds or thousands of pages failing in exactly the same way.

Why do large sites fail Core Web Vitals more often?

Large, popular sites carry more JavaScript, more third-party tags and more interactive parts, and INP punishes all three. The HTTP Archive's 2025 Web Almanac, measured in July 2025, shows the pattern.

Source: HTTP Archive Web Almanac 2025, Performance chapter, figures 7.1, 7.2, 7.13 and 7.14, read 27 October 2026.

None of the top-ranking Core Web Vitals guides I read showed this split, and it's the one that matters to a large site. The web as a whole passes INP comfortably, but popular sites don't. The Almanac puts it down to "complex functionality, heavy third-party integrations, and diverse user interaction patterns".

Two more findings from the same chapter change where you should look first:

• Home pages fail more than inner pages. 45% of mobile home pages had good Core Web Vitals, against 56% of secondary pages. Home pages tend to carry the heaviest hero, the most scripts and the most experiments.
• About 16% to 17% of pages lazy-load their LCP image. That one attribute delays the most important image on the page until layout confirms it's on screen. On a CMS where every hero shares one image component, the mistake repeats across every URL.

The Almanac also flags a measurement gap. On single-page apps, JavaScript-based navigations "are not always fully captured by current Web Vitals measurements". If your product marketing site is a React or Next.js app, part of each visit may never show up in CrUX at all.

What is the difference between field data and lab data?

Field data comes from real users visiting your site; lab data comes from one simulated load on a set device and network. Google ranks on field data. Lab data helps you find the cause.

CrUX (Chrome UX Report) is Google's public dataset of real-user performance from Chrome. Its methodology page lists what it leaves out: Chrome on iOS, Android apps using WebView, and other Chromium browsers such as Microsoft Edge. If most of your buyers browse on iPhones or Edge, CrUX sees a slice of them.

Lighthouse is Google's lab tool, the engine inside PageSpeed Insights and Chrome DevTools. Its score out of 100 is a lab score. Google doesn't rank on it.

Lab and field numbers often disagree. Google's own guide on lab and field differences says lab data can show a site performing well while field data says it needs work. When that happens, trust the field data for "are we passing?" and use the lab trace to find the slow script or late image.

Low-traffic pages have a further catch. If a URL lacks enough real visits, PageSpeed Insights shows no field data for it. Search Console still judges it, as part of a group of similar pages.

How do you read the Search Console Core Web Vitals report on a large site?

Read it by URL group. The Core Web Vitals report puts similar pages into groups, gives each group one status, and shows a sample of URLs rather than every one.

Four rules from Google's help page decide how you read it:

1. A group's status is its worst metric. Poor CLS and good INP makes the whole group "poor".
2. Only indexed URLs appear, and only groups with enough data for both LCP and CLS.
3. The numbers are 75th percentile values over the last 28 days. A fix shipped today takes a month.
4. "Start tracking" begins a 28-day monitoring session. It doesn't trigger reindexing or speed anything up; it only restarts the clock on the CrUX data Search Console reads.

On a 40,000-URL site, those groups usually map straight onto your templates: docs, blog, integrations, comparison pages. That's useful. The report is telling you which component to open, as long as you know which template each group belongs to.

A common mistake goes like this. A team opens the report, sorts by the example URLs and starts fixing pages one by one. The example URLs are a sample. Fix the template behind them and the whole group moves together.

How do you fix Core Web Vitals at the template level?

Map every template, rank them by what they earn and how badly they fail, then profile one URL per template and fix the shared component. This is how we approach Core Web Vitals work for clients at Searchmaxxed, and the order matters more than any single trick.

1. List the templates. Home, product, pricing, comparison, integration, docs, blog, landing pages.
2. Attach the data. For each template, note the Search Console group status, organic entrances from GA4 and whether it carries a conversion.
3. Rank by value times failure. A poor pricing template beats a poor tag archive every time.
4. Profile one URL per template. Run PageSpeed Insights for field values, then a Chrome DevTools performance trace to find the cause.
5. Fix the component, not the page. The hero image component, the cookie banner, the tag manager container or the hydration step.
6. Ship it as one release and record the date. Then start Search Console's 28-day tracking for the affected group, so you know when to judge it.
7. Watch real-user data per template. Google's open-source web-vitals JavaScript library can send LCP, INP and CLS from every visit to your analytics.

A worked example: a B2B SaaS site with six templates

Take a B2B SaaS company with about 40,000 indexed URLs and six templates that matter. The figures are illustrative, not a client's.

The docs carry three quarters of the URLs, so they dominate the report. But revenue sits elsewhere. The pricing page and 60 comparison pages are closest to a sale. So the pricing toggle gets fixed first, then the comparison hero component. Then the integrations grid gets a fixed width and height for each logo, which clears the whole directory out of the CLS warning.

That's four releases, not 40,000 fixes.

How do you improve LCP?

Get the largest element's bytes to the browser sooner and let it render straight away. Google's LCP guide splits the time into four parts: time to first byte, resource load delay, resource load duration and element render delay. Find the biggest part, then fix that.

Client-side rendering hurts LCP the most. If the HTML arrives empty and JavaScript builds the page, nothing can paint until the bundle downloads and runs. Our guide to JavaScript SEO for enterprise sites covers the rendering choice in depth, because it decides crawling and indexing as well as speed.

Our own site works this way. The searchmaxxed.com build renders every route to HTML before anyone visits. Only the interactive routes keep the JavaScript bundle, and the landing routes inline their stylesheet to save a round trip before the first paint.

How do you improve INP?

Keep the browser's main thread free so it can respond the moment someone clicks. Google's INP guide breaks each interaction into three parts: input delay, processing time and presentation delay. Long tasks cause most of it.

A long task is a block of script that holds the main thread for more than 50 milliseconds. While it runs, a click waits.

On enterprise and SaaS sites, the usual causes are:

• Hydration. React, Next.js and similar frameworks re-run component code in the browser after the HTML arrives. A big page hydrating all at once blocks every early click, and the visitor feels it as a dead button.
• Third-party tags. Analytics, A/B testing, chat widgets, session recording and ad pixels, often loaded through one tag manager container that grows every quarter.
• Heavy event handlers. A pricing toggle that re-renders the whole page, or a docs search that filters thousands of items on each keystroke.
• Large DOMs. Mega menus and long docs sidebars make every repaint slower.

The fixes follow from the causes. Break long tasks up and yield to the main thread between steps. Defer or remove tags nobody reads, and review the tag manager container as part of each release. Hydrate below-the-fold parts later, or not at all, where a section never changes. Debounce search inputs.

INP needs field data to judge. A lab test never clicks your pricing toggle, so Total Blocking Time in Lighthouse is only a hint. Real-user monitoring shows the slow one.

How do you improve CLS?

Reserve space for everything before it loads. CLS climbs when content appears or resizes after the page has started rendering, pushing what's already there.

The fixes are mostly in shared components:

• Set width and height (or an aspect ratio) on every image, video and embed in the component library.
• Give cookie banners, promo bars and chat widgets a fixed slot.
• Load web fonts with a fallback sized to match, so the text doesn't reflow when the real font finally arrives a second or two later.
• Keep new content below what the reader is looking at, unless they asked for it.
• Animate with transform and opacity only.

In the 2025 Almanac, 81% of mobile pages and 72% of desktop pages had good CLS. It's usually the cheapest to fix. One component change, such as a reserved banner slot, can clear an entire Search Console group of thousands of URLs in one release.

How do you stop Core Web Vitals regressing after you fix them?

Measure every release and alert when a template slips. Regressions on large sites rarely come from one big mistake. They creep in through a new tag, a hero video or a component update nobody profiled.

• Set a budget per template for LCP, INP and CLS, well inside Google's thresholds.
• Run Lighthouse in the release pipeline on one URL per template, and stop any release that breaks the budget before it reaches production.
• Collect real-user data from every visit and break it down by template, device type and country. A slip on one template then shows up within days, not a month later.
• Review the tag manager every month. Marketing teams add tags faster than anyone removes them.
• Recheck Search Console after each 28-day window closes, since that's when a fix or a regression shows up for Google.

Our technical SEO checklist lists the speed checks alongside the crawl, indexing and schema checks they sit beside, so speed doesn't get audited in isolation.

How does Searchmaxxed handle Core Web Vitals?

We treat Core Web Vitals as part of technical SEO. We profile the money-page templates, fix what drags LCP, INP and CLS, and hold the gains with monitoring and regression alerts. Speed work goes at templates because one fixed layout lifts hundreds of pages.

Searchmaxxed is an SEO and AI SEO agency for enterprise, B2B SaaS, venture-backed, manufacturing and public-sector companies. Our technical SEO covers site speed and Core Web Vitals, crawl and indexing, site structure, redirects, canonical tags, XML sitemaps, schema markup and mobile rendering. We do the speed work alongside the pages and links, so the fastest templates are also the ones built to rank.

Here's how it runs. AI agents pull your Search Console and GA4 data, read the live results and check competitors' pages. That feeds the Managed Search Loop, which ranks the next fix by what it's worth: a slow pricing template ahead of a slow careers page. We build the fix on a website you own and release it after approval. Then we check the live page and measure what changed in the next 28-day window, template by template.

Technical work doesn't reduce the page releases in a package. Want a diagnosis first? The AI SEO Audit takes five business days and ranks every fix by what it's worth, Core Web Vitals included.

Searchmaxxed's work has generated more than A$10 million in revenue through search for its clients.

Is Searchmaxxed right for you?

We fit marketing and growth teams on large sites who want Core Web Vitals fixed as part of search work that ships every week. If you only need a one-off speed fix, a performance engineer will serve you better.

Frequently asked questions

What should you do next?

Open Search Console's Core Web Vitals report, mobile first, and write each poor or needs-improvement group next to the template it belongs to. Rank those templates by what they earn, and fix the top one this sprint. If you'd like us to scope the work across your site, let's talk pricing.