Skip to content

Core Web Vitals 2026: The Metrics That Matter and the Targets That Hold

Three numbers. Hit them and you’re competing on content; miss them and you’re competing one hand tied.

John Cravey with AIFounder4 min readUpdated Jul 6, 2026

Core Web Vitals are Google’s headline performance metrics. They’re a ranking signal, they correlate strongly with conversion rate, and most SMB sites still miss the targets. Through 2024-2026 the metric set has shifted — Interaction to Next Paint (INP) replaced First Input Delay, the thresholds have stayed stable, and the diagnostic tools have gotten better. Here’s the 2026 state of the art and the targets we ship to on every FH client site.

Free estimate · 2 minutes

Slow pages lose rankings and leads. Price the fix.

Build the estimate to see what a fast rebuild would look like for your site and what we would ship in the first thirty days.

The three metrics

  • LCP (Largest Contentful Paint): time until the largest visible element renders. Target: under 2.5s.
  • INP (Interaction to Next Paint): worst-case delay between user input and the next render. Target: under 200ms.
  • CLS (Cumulative Layout Shift): unexpected visual movement during page load. Target: under 0.1.

All three measured at the 75th percentile of field data over a 28-day window. Lab data (Lighthouse) is a starting point but the field data from real users is what Google ranks on.

LCP: the headline number

LCP is the time until the largest visible element renders — typically the hero image or the main headline. The under-2.5s target is met by ~55% of SMB sites in our audit data. The bottom 25% are over 4 seconds, which is a ranking liability and a conversion catastrophe.

The four biggest LCP killers we see in audits: unoptimized hero images (often 1-3MB JPEGs served raw), render-blocking JS (often a CMS theme), web fonts blocking the hero text, and slow origin servers (cheap shared hosting). The SMB speed post covers the canonical fixes.

INP: the interaction metric

INP replaced FID (First Input Delay) in March 2024. INP measures the worst interaction latency over the user’s session — not just the first one. It’s a much harder bar than FID was. Sites that passed FID often fail INP.

The under-200ms target is missed by sites that ship too much JavaScript or that block the main thread on long tasks. Common culprits: heavy third-party scripts (chat widgets, tag managers), inefficient React re-renders, lack of debouncing on search inputs. We measure with PageSpeed Insights and the Performance tab in Chrome DevTools.

CLS: the layout-stability metric

CLS measures unexpected movement of visible elements during load. Common causes: images without width/height attributes, fonts swapping in and pushing text around, ads or embeds loading into spaces that weren’t reserved, sticky elements appearing without proper anchoring.

Hitting under 0.1 is mostly a discipline thing: always specify image dimensions (next/image forces this), use font-display: optional or swap with size-adjust, reserve space for embeds in CSS.

Where to measure (lab vs field)

Lab data: PageSpeed Insights’ Lighthouse score, Chrome DevTools’ Performance panel, web.dev/measure. Synthetic; runs on a controlled environment; useful for debugging.

Field data: PageSpeed Insights’ ‘Discover what your real users are experiencing’ section, Chrome User Experience Report (CrUX), Search Console’s Core Web Vitals report. Real user data; what Google actually ranks on.

Always optimize for field data. Lab data can show ‘good’ while field data shows ‘poor’ if your tests miss real user conditions (slow mobile networks, low-end devices, geographic distance from your origin).

The diagnostic flow we run on every audit

  1. Pull current field data from Search Console’s Core Web Vitals report. Note: which URLs are poor/needs-improvement, by which metric.
  2. Run Lighthouse against the top URLs. Note the specific issues (unoptimized images, render-blocking JS, etc.).
  3. Open Chrome DevTools Performance panel, record a slow-3G page load. Identify long tasks blocking the main thread.
  4. Pull the network waterfall. Identify any single request taking over 1s.
  5. Build a remediation list, prioritized by user-visible impact.

The typical first-pass remediation list

  • Replace unoptimized hero images with next/image at the right resolution + format.
  • Defer or async every non-critical third-party script.
  • Preload web fonts; use font-display: swap with size-adjust to prevent layout shift.
  • Add width/height to every image.
  • Defer below-fold images via loading="lazy".
  • Remove unused JavaScript (often 100-300KB on SMB sites that have accumulated dead code).

What ‘good’ looks like on FH client sites

  • LCP: 1.5-2.0s on mobile, 0.8-1.2s on desktop.
  • INP: 80-150ms.
  • CLS: 0.00-0.05.
  • Lighthouse score: 95+ on every page.

When the target is hard to hit

Two cases we hit regularly. Heavy interactive features (video players, chatbots, embedded forms from third parties) drive INP up. Solution: lazy-load them and accept that their loaded state has higher INP than the initial state. Heavy image content (portfolio sites, photography sites) drive LCP up. Solution: aggressive optimization, AVIF format, careful priority management on the hero image only.

The 28-day lag

Search Console field data is a 28-day moving average. A perf improvement you ship today doesn’t fully reflect in CWV scoring for 28 days. We tell clients: expect ranking improvements to compound over 60-90 days post-fix, not immediately. The fix is real; the credit just takes time.

Performance budgets

Set a budget at build time. JS bundle ≤ 200KB. CSS ≤ 60KB. Hero image ≤ 200KB. Total page weight ≤ 1MB. Run a CI check that fails the build if any budget is exceeded. Without a budget, regressions accumulate silently across every PR.

How this lands across FH client work

Every FH client site has a CWV-monitoring routine: weekly Search Console check, monthly Lighthouse audit, quarterly deep performance review. New builds ship with a perf budget enforced in CI. The combined effect is that every FH client site stays in ‘good’ on Core Web Vitals over time — drift doesn’t accumulate. If your site’s CWV is in the ‘poor’ or ‘needs improvement’ bucket and you want to fix it, book a consultation — the remediation engagement is usually a 1-2 sprint project with measurable ranking and conversion impact.

Answers

Frequently asked questions

What do the three Core Web Vitals measure?

Loading, interactivity, and visual stability. Largest Contentful Paint is when the main content appears, Interaction to Next Paint is how quickly the page responds when someone acts, and Cumulative Layout Shift is how much the page moves under them while loading.

What are the targets?

Largest Contentful Paint under 2.5 seconds, Interaction to Next Paint under 200 milliseconds, and Cumulative Layout Shift under 0.1, each measured at the 75th percentile of real visits. The percentile matters: passing on average while failing for a quarter of visitors is failing.

What is the difference between lab and field data?

Lab is a simulated load on a machine you control; field is what real visitors experienced on their devices and connections. Google uses field data. A perfect lab score with failing field data means your test conditions are nothing like your audience's.

Which metric usually needs fixing first?

Largest Contentful Paint on marketing sites, because the largest element is normally a hero image that has not been sized or optimized. It is also the easiest to move, which makes it the right starting point even when other metrics are also failing.

What is the usual first-pass fix list?

Optimize and correctly size images, defer non-critical third-party scripts, limit and preload fonts, reserve space for anything that loads late, and move off slow hosting. That list covers most failing business sites and needs no architectural change.

Why did my score not change after fixing things?

Because field data is a rolling 28-day window, so a fix takes weeks to show fully. Checking the day after a deploy shows almost nothing. Verify the fix in lab data immediately, then watch the field number over the following month.

Is Cumulative Layout Shift really a ranking factor?

It is part of the page experience signals, and more importantly it is a conversion factor. A page that moves under someone's finger as they tap costs you the tap. The ranking effect is modest; the usability effect is not.

What if the target is genuinely hard to hit?

Decide whether the constraint is architectural or content-level. A heavy page builder with thirty plugins has an architectural ceiling that no optimization pass clears, and at that point the honest answer is a rebuild rather than another round of tuning.

What is a performance budget?

A stated limit on page weight or a metric, checked automatically, so a regression fails a build rather than being discovered in a quarterly audit. Without one, performance is fixed in bursts and degrades continuously between them.

Should I chase a perfect score?

No. Passing the thresholds is the goal; the last few points typically cost more than they return and often make the code harder to maintain. Spend the effort on the pages your visitors actually land on rather than on a number.

How do these metrics relate to conversion?

Directly, and usually more strongly than to rankings. Faster pages convert better because fewer people leave before the page is usable. That is why performance work is worth doing even for sites that rank fine already.

What is the diagnostic flow?

Read field data first to see what real visitors experience, then reproduce in lab to find the cause, then fix, then verify in lab immediately and in field over the following month. Starting in the lab produces fixes for problems your visitors do not have.

Question we did not answer? Ask us directly and we will answer it here.

John Cravey, Founder
Written by
John Cravey
Founder

Founder of Frontend Horizon. Writes most of the long-form work on the FH blog.

Newer post
Google Search Console: From Zero to Actionable in an Afternoon
Older post
App Router Patterns That Actually Scale in 2026
Keep reading

More from the blog

SEO·10 min

Automated Technical SEO Audits: Crawl, Score, and Fix With AI

A once-a-year audit finds problems a year too late. The point of automating it is that it never stops looking.

Next.js·10 min

Speed Is a Ranking Factor: The Next.js Performance Checklist by Business Size

Google measures your speed with real users and ranks you on it. Next.js hands you the tools to win. Most sites leave them switched off.

Performance·4 min

Optimizing INP: The Five Patterns That Fix Interaction Latency

INP is the hardest of the three Core Web Vitals to hit. Five patterns cover most of what we ship to fix it.