Core Web Vitals 2026: How to Achieve a Perfect Lighthouse Score

By Eoin Villarin, 2026-03-08, updated 2026-10-28

Only about half of mobile sites pass Core Web Vitals. This 2026 guide explains LCP, INP and CLS, how Lighthouse scores really work, and the fixes that move real-user data.

Core Web Vitals feed into how Google evaluates page experience, but the bigger reason to care is that the metrics track things users genuinely feel: how long until the page looks ready, how quickly it answers a tap, and whether the layout stops moving. A fast site keeps visitors, and a janky one quietly loses them before they reach your contact form.

This guide covers the three metrics and their thresholds in 2026, how the Lighthouse score is actually calculated, what usually causes each metric to fail, and the fixes that move real-user numbers rather than the ones that only sound right.

There is plenty of room to stand out. The 2025 Web Almanac performance chapter found that only 48 percent of mobile websites and 56 percent of desktop websites pass all three metrics.

What are the Core Web Vitals in 2026?

The set has not changed since Interaction to Next Paint replaced First Input Delay in March 2024. Google's Web Vitals documentation lists three stable metrics, assessed at the 75th percentile of real page loads, separately for mobile and desktop.

Lab data is not field data

This trips up almost everyone. Lighthouse runs a simulated load on one machine. Search Console and PageSpeed Insights report what real Chrome users experienced on their own devices and connections over the previous 28 days, and that field data is what Google uses.

A perfect Lighthouse score with failing field data is common and usually means your users have slower phones and networks than you do. Always confirm against real-user data before declaring victory.

What changed: LCP and INP work in every major browser

Until recently only Chromium browsers exposed the APIs behind LCP and INP, so iPhone users were invisible in most monitoring. With Safari 26.2 in December 2025, both metrics became Baseline Newly available. Your own monitoring can now cover Safari and Firefox, although the Chrome UX Report, and therefore Search Console, still only includes Chrome users.

Treat early Safari numbers with some care. Segment your data by browser rather than blending everything into one score, so an implementation quirk does not send you chasing a problem that is not there.

How is the Lighthouse performance score calculated?

A "perfect Lighthouse score" means 100 in the performance category, and it helps to know what feeds it. According to Chrome's Lighthouse scoring documentation, the score is a weighted blend of five lab metrics, each scored against a curve built from real website data.

Two things follow. Lighthouse cannot measure INP, because nobody interacts with the page during a lab run, so Total Blocking Time stands in for it. And 90 to 100 is already the green band, so chasing the last few points rarely changes anything a user notices. Scores also vary between runs, so test several times and use the median.

How to fix Largest Contentful Paint (LCP)

LCP is the metric sites fail most often: the Web Almanac found only 62 percent of mobile sites achieve a good LCP. The LCP element is usually a hero image or a headline, and the time breaks down into four parts. Find out which part is slow before optimising anything.

Time to first byte

If the server takes a second to respond, the other three phases are already fighting a deficit. Full-page caching and serving from the edge are the biggest levers here, which is one reason running code at the edge is worth understanding.

Resource load delay

This is the gap between the HTML arriving and the browser starting to fetch the LCP resource, and it is where most avoidable time hides.

• Do not lazy-load the hero. loading="lazy" on the LCP image reliably makes LCP worse, yet the Web Almanac found 16 to 17 percent of pages still do it.
• Raise its priority. fetchpriority="high" tells the browser this image matters more than the others.
• Preload late-discovered images. If the hero is a CSS background or chosen by JavaScript, a preload hint lets the browser start before it finds the reference.

<img src="/images/hero-1600.avif"
     srcset="/images/hero-800.avif 800w, /images/hero-1600.avif 1600w"
     sizes="100vw" width="1600" height="900"
     fetchpriority="high" alt="Mechanic servicing a car in a workshop">

<link rel="preload" as="image" href="/images/hero-bg.avif" fetchpriority="high">

Resource load duration and render delay

Modern formats and correct sizing do most of the work. Serve AVIF or WebP, size images to their container with srcset rather than shipping a 3000px original, and make sure render-blocking CSS and fonts are not holding up paint. font-display: swap prevents invisible text while a web font loads, and inlining critical CSS removes a round trip on first visits.

How to improve Interaction to Next Paint (INP)

INP replaced First Input Delay because FID only measured the first interaction and only the delay before handling started. INP looks at the full duration of interactions across the whole visit and reports one of the slowest, which is much harder to game. The full playbook is in the INP guide; these are the essentials.

What usually causes poor INP

1. Long tasks blocking the main thread. Anything over 50ms means an interaction landing in that window has to wait.
2. Expensive event handlers. Synchronous work on every keystroke, click or scroll.
3. Large re-renders. A state change high in the tree re-rendering hundreds of components. The techniques in React performance apply directly.
4. Third-party scripts. Chat widgets, tag managers and analytics are often the largest single contributor, and the easiest to fix by deferring or removing them.

Yield to the main thread

Breaking a long task into smaller chunks lets the browser paint a response between them. It does not reduce total work, but it dramatically improves how responsive the page feels, and INP measures exactly that. scheduler.yield() is the cleanest way to do it, but MDN still lists it as limited availability, so keep a fallback.

function yieldToMain() {
  if (globalThis.scheduler?.yield) {
    return scheduler.yield();
  }
  return new Promise((resolve) => setTimeout(resolve, 0));
}

async function handleFilterChange(filters) {
  updateCheckboxes(filters); // visible feedback first
  await yieldToMain();       // let the browser paint
  const results = applyFilters(filters);
  await yieldToMain();
  renderResults(results);
}

How to eliminate Cumulative Layout Shift (CLS)

CLS is the most fixable of the three because the causes are a short, well-known list. It is also the one most sites already pass, at 81 percent of mobile sites in the Web Almanac data.

• Images without dimensions. Set width and height, or an aspect-ratio, so space is reserved before the file arrives.
• Ads and embeds. Reserve the slot with a min-height even when it is empty.
• Late-injected banners. Consent bars and promo strips that push content down after paint. Overlay them instead.
• Web font swaps. A fallback with very different metrics shifts the text when the real font loads. size-adjust and matched fallback fonts reduce this.
• Animations that move layout. Animate transform and opacity, not top, height or margin.

Almost all layout shift comes from content arriving into space that was never reserved for it.

How to measure Core Web Vitals in the field

Lab tools find problems; field data tells you whether you fixed them. Use both, roughly in this order.

1. Search Console's Core Web Vitals report groups similar URLs, so you can see which templates fail.
2. PageSpeed Insights shows the same field data for a single URL alongside a Lighthouse run.
3. Your own real-user monitoring captures every browser, including Safari and Firefox, and can point at the slow element or interaction.
4. Lighthouse CI in your deployment pipeline catches regressions before they reach users.

The open-source web-vitals library is the simplest way to start collecting your own data:

import { onCLS, onINP, onLCP } from 'web-vitals';

function sendToAnalytics(metric) {
  const body = JSON.stringify({
    name: metric.name,
    value: metric.value,
    rating: metric.rating,
    page: location.pathname,
  });
  navigator.sendBeacon('/api/vitals', body);
}

onCLS(sendToAnalytics);
onINP(sendToAnalytics);
onLCP(sendToAnalytics);

What is the best order to fix performance problems?

1. Pull field data first, so you fix what real users hit rather than what the lab flags.
2. Fix CLS. It is usually the quickest win and the most visible.
3. Attack LCP by phase, starting with whichever phase dominates.
4. Audit third-party scripts before optimising your own code for INP.
5. Re-measure in the field once the 28-day window has rolled over, not the next morning.

On hosted platforms the levers differ: you cannot tune the server, but you control apps, theme code and media. The Shopify speed optimisation checklist covers that side in detail.

Frequently asked questions

Do Core Web Vitals affect Google rankings?

Yes, but modestly. They are part of the page experience signals Google uses, and they behave more like a tiebreaker than a trump card, because relevant, helpful content still wins. Their bigger effect is on people. Faster and more stable pages keep visitors engaged, which matters for enquiries and sales whether or not rankings move.

Do I need a Lighthouse score of 100?

No. Anything from 90 to 100 is in the green band, and the score varies between runs anyway. What matters for Google and for users is passing all three metrics in field data at the 75th percentile. A site scoring 92 with good field data is in better shape than one scoring 100 in the lab while failing in the field.

Why do PageSpeed Insights and Lighthouse show different numbers?

Because they measure different things. The top of PageSpeed Insights shows field data from real Chrome users over 28 days, while the Lighthouse section below it is a single simulated lab run on throttled settings. Field data reflects real devices and networks, and lab data is reproducible and good for debugging. When they disagree, set priorities from the field data.

How long do fixes take to show in Search Console?

Expect around four weeks. Field data is aggregated over a rolling 28-day window, so a fix deployed today only gradually displaces older, slower page loads. After deploying, start validation in the Search Console report and watch your own real-user data in the meantime, which confirms the improvement within days rather than weeks.

Next steps: get your site passing

Optimise against real-user data, reserve space for everything that loads late, prioritise the hero image and never lazy-load it, break up long tasks, and treat third-party scripts as the prime suspect for poor responsiveness.

If your site is failing these metrics and you want it looked at properly, send me the URL through the contact form, or browse the case studies for the WordPress, Shopify and custom builds I work on.