Guide · Updated October 2026

Core Web Vitals Explained: LCP, INP and CLS for Business Websites

A technical but readable guide to Core Web Vitals in 2026: what LCP, INP and CLS measure, the thresholds Google uses, and the exact fixes that move a site into the green.

Core Web Vitals are the three performance signals Google uses to judge how a page feels to a real visitor. They feed into the page experience part of ranking, and more importantly they track closely with whether people stay or bounce. If your site feels slow or jumpy on a phone, these numbers will tell you why.

This guide explains what each metric measures, the thresholds that count as "good", how the data is collected, and the specific engineering fixes we use to get sites into the green.

The three metrics at a glance

LCP (Largest Contentful Paint): how long until the biggest visible element, usually the hero heading or hero image, is painted. Good is 2.5 seconds or less.
INP (Interaction to Next Paint): how quickly the page responds visually after a tap, click or key press, measured across the whole visit. Good is 200 milliseconds or less. INP replaced the older FID metric in 2024.
CLS (Cumulative Layout Shift): how much content jumps around unexpectedly while loading. Good is 0.1 or less.

Google assesses each metric at the 75th percentile of real visits. In plain terms, three out of four visitors need a good experience for the page to pass.

Lab data versus field data

This is the part most people miss. PageSpeed Insights shows two different things. The top section, when available, is field data from the Chrome User Experience Report: real visitors on real devices over the last 28 days. The lower section is lab data from Lighthouse, a single simulated load on an emulated mid-range phone over throttled 4G.

Lab data is perfect for debugging because it is repeatable. Field data is what Google actually uses. A fix you deploy today shows in lab results instantly but can take up to four weeks to fully appear in the field report and in Search Console.

How to fix LCP

LCP breaks down into four parts: time to first byte, resource load delay, resource load time and element render delay. Find which one dominates, then attack it.

Cut time to first byte

Serve pages from a CDN edge close to the visitor rather than a single shared server. Static HTML on an edge network typically answers in tens of milliseconds. Dynamic platforms that build each page on request often take several hundred.

Remove render blocking resources

Every external stylesheet in the head stops the browser painting until it downloads. Inline the critical CSS needed for the first screen, and load the rest without blocking. Third party fonts are a frequent culprit: the browser must connect to another domain, fetch a stylesheet, then fetch the font file. Self host fonts or use a well chosen system font stack.

Prioritise the hero image

If your LCP element is an image, never lazy load it. Add fetchpriority="high", serve it in AVIF or WebP, size it for the viewport with srcset, and preload it if it is referenced from CSS.

Avoid entrance animations on the LCP element

A headline that fades or slides in counts as painted only when the animation finishes. That can add a full second to LCP with no other change. Animate secondary elements, not the main one.

How to fix INP

INP is about the main thread. When JavaScript runs a long task, the browser cannot respond to the visitor until it finishes.

Ship less JavaScript. Most small business sites need very little. Every framework, slider and tracking tag adds parse and execution time.
Break up long tasks. Anything over 50 milliseconds is a long task. Yield back to the browser with scheduler.yield() or setTimeout between chunks of work.
Defer third parties. Chat widgets, heatmaps and ad scripts can load after consent or after the first interaction rather than on page load.
Keep the DOM lean. Very large pages with thousands of nodes make every style recalculation slower.

How to fix CLS

Reserve space for media. Always set width and height attributes, or use the CSS aspect-ratio property, so the browser holds the slot before the file arrives.
Tame web fonts. When a web font swaps in, text can reflow. Use size-adjust and related descriptors on the fallback font, or skip web fonts on headings entirely.
Never inject content above existing content. Cookie banners and promo bars should overlay the page or have space reserved for them.
Animate with transform and opacity only. Animating top, left, width or height triggers layout. Transforms run on the compositor and do not shift anything.

A real example

On our own homepage, a mobile Lighthouse run showed First Contentful Paint and LCP both at 3.2 seconds, with a small layout shift caused by a Google Font swapping in on the main heading. We removed the external font, dropped the slide-in animation on the headline and stopped two decorative background animations. The next run showed LCP at 1.0 second and CLS at zero. No redesign, no new hosting, just removing work the browser did not need to do.

The bottom line

Core Web Vitals reward simple, well built pages. Serve from the edge, inline what matters, prioritise the hero, ship less JavaScript and reserve space for everything. Do that and passing all three becomes the default rather than a project.

Frequently asked questions

Do Core Web Vitals affect Google rankings?

Yes, as part of Google's page experience signals. Relevance and content quality still matter more, but when pages are otherwise similar, a faster and more stable page has an advantage, and it converts visitors better regardless of ranking.

Why is my PageSpeed score different every time I test?

Lab tests vary with network conditions, server response and third party scripts. Run three tests and look at the median, and rely on field data for the real picture.

What replaced First Input Delay?

Interaction to Next Paint (INP) replaced FID as a Core Web Vital in March 2024. INP measures responsiveness across all interactions in a visit, not just the first one.

How long until Search Console shows my improvements?

Field data covers a rolling 28 day window, so expect gradual improvement over about four weeks after a fix goes live.

Want a website that brings you customers?

Tell us what you do on WhatsApp and we will send a fixed quote and a free mockup.

Get my free mockup

Our products

Starter website$99 setup, $15 a month Business website$249 setup, $29 a month Premium website$499 setup, $59 a month Website RescueFix a slow, broken or hacked site Free speed testCheck your site in seconds Sample websitesSee designs for your industry

Website design near you

Website design in London Website design in New York Website design in Sydney Website design in Adelaide Website design in Aberdeen Website design in San Diego Website design in Cork Website design in Luxembourg City Website design in Philadelphia Website design in Helsinki All cities →

SiteDrum home · All guides · Sitemap · Contact us