Core Web Vitals explained: LCP, INP and CLS

Core Web Vitals are three metrics Google uses to describe real-user experience: Largest Contentful Paint (LCP) for loading, Interaction to Next Paint (INP) for responsiveness and Cumulative Layout Shift (CLS) for visual stability. A page passes when at least 75% of visits reach LCP of 2.5 seconds or less, INP of 200 milliseconds or less and CLS of 0.1 or less. This guide explains what each metric measures, how to read your scores, and which fixes usually move them.

The three metrics at a glance

Google publishes fixed thresholds for each metric and groups results into three buckets. The numbers below come from web.dev's Core Web Vitals overview.

Two details matter more than most people realize:

• The 75th percentile decides. Google does not look at your fastest or your average visit. It takes the value that 75% of page loads meet or beat, separately for mobile and desktop. A few slow phones on weak connections can therefore pull a page into "needs improvement".
• INP replaced FID in March 2024. First Input Delay only measured the delay before the first interaction was handled. INP looks at the latency of interactions across the whole visit, which is a much stricter test for JavaScript-heavy pages.

Field data versus lab data

When you test a page on corewebvitals.page, you see two kinds of results, and they often disagree.

• Field data ("Discover what your real users are experiencing") comes from the Chrome User Experience Report. It covers real Chrome users over a rolling 28-day window. This is what counts for the Core Web Vitals assessment in Search Console.
• Lab data (the Lighthouse score) is a single simulated load on a throttled device. It is great for debugging because it is repeatable, but it cannot measure INP at all, because nobody clicks during the test. Lighthouse uses Total Blocking Time as a rough stand-in.

Because field data trails by up to 28 days, a fix you ship today will show up gradually. Use lab tests to confirm the change works, then watch the field numbers settle. Our guide on how to measure website speed properly walks through a before-and-after test you can trust.

How to improve LCP

LCP is often the hardest of the three to pass, but it is usually the easiest to diagnose. Google splits it into four parts, described in the LCP article on web.dev:

1. Time to First Byte: how long the server takes to start sending HTML.
2. Resource load delay: the gap between the first byte and the moment the browser starts loading the LCP image.
3. Resource load duration: how long the LCP image itself takes to download.
4. Element render delay: the time between the image arriving and it actually being painted.

Look at which part dominates before you change anything. The Performance panel in Chrome DevTools shows the LCP element and how its time breaks down.

Slow server response

If TTFB alone eats a second or more, no amount of image tuning will get you under 2.5 seconds. Common causes are uncached pages generated by PHP and a database on every request, a server far away from most visitors, and slow plugins or extensions. Page caching, either on the server or at the edge, is the usual fix. See how to reduce TTFB for the full list.

The LCP image is discovered late

Browsers find images while parsing HTML. If your hero image is set via CSS background, injected by JavaScript or lazy-loaded, the browser learns about it late. Fixes:

• Use a normal <img> element for the hero image.
• Never add loading="lazy" to the LCP image.
• Add fetchpriority="high" or a preload hint so the browser fetches it early:

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

The LCP image is too heavy

A 3000 pixel wide JPEG shown at 1200 pixels wastes bandwidth on every visit. Serve modern formats like WebP or AVIF, size the image for the layout and use srcset for different screens. Our guide on optimizing images for the web covers this in detail.

Render-blocking CSS and fonts

Large stylesheets and synchronous scripts in the <head> delay painting even after the image is ready. Inline the critical CSS, defer non-essential scripts and keep web fonts lean.

How to improve INP

INP measures the time from a user interaction to the next frame the browser paints. It is almost always a JavaScript problem, not a network problem. The INP article on web.dev breaks it into input delay, processing time and presentation delay.

Typical causes and fixes:

• Long tasks on the main thread. Any script that runs for more than 50 ms blocks the page from responding. Break long work into smaller chunks and yield back to the browser between them.
• Too much third-party JavaScript. Chat widgets, tag managers, A/B testing tools and ad scripts all compete for the main thread. Audit what is loaded and remove what nobody uses.
• Heavy event handlers. A click that triggers a large DOM update, a re-render of a full product list or synchronous layout reads will feel sluggish. Update only what changed, and show immediate visual feedback before doing the expensive work.
• Huge DOM size. Pages with many thousands of elements take longer to re-style and re-layout after every interaction. Page builders are a frequent source.

A CDN or cache helps INP only indirectly: less time spent downloading means scripts are ready sooner, but the code still has to run on the visitor's device.

How to improve CLS

CLS scores the largest burst of unexpected layout shifts while the page is open. Shifts within 500 ms of a user interaction don't count, so an accordion opening after a click is fine. The CLS article on web.dev explains the scoring.

The usual suspects:

• Images and videos without dimensions. Without width and height attributes (or a CSS aspect-ratio), the browser reserves no space and pushes content down when the file arrives.
• Ads, embeds and banners injected above content. Reserve a fixed slot for them, or place them below the fold.
• Cookie banners that push the page. Overlay them instead of inserting them at the top of the document.
• Web fonts swapping in. When a fallback font is replaced by the web font, text can reflow. font-display: swap keeps text visible early; matching fallback metrics (for example with size-adjust) keeps the swap from moving things around.

Do Core Web Vitals affect rankings?

Core Web Vitals are part of Google's page experience signals. Google states that its ranking systems reward good page experience, but also that relevance and content quality come first. In practice, passing Core Web Vitals will not lift a weak page to the top, and failing them will not sink a page that is clearly the best answer.

The better reason to care is your visitors. Slow loading, laggy buttons and jumping layouts cost you enquiries and sales regardless of what any algorithm does. Treat the thresholds as a quality bar for users, not as an SEO trick.

How fast.site helps

fast.site sits in front of your existing hosting, so you keep your host and your CMS. You point your domain's nameservers to fast.site, and traffic then runs through an edge network with regions in North America, Europe, Asia-Pacific and South America, depending on your plan.

For LCP, the Fast Edge Cache™ serves cached pages and assets from the edge nearest to the visitor, so a cache HIT does not wait for your origin server. That targets the TTFB and download parts of LCP. Image optimization converts JPEG and PNG to WebP on the fly for browsers that support it, with AVIF available depending on your plan.

The optional HTML optimization toggle targets common LCP and CLS issues directly: it preloads the detected hero image, adds width and height to images to reduce layout shift, and adds font-display: swap to web fonts. Details are in the HTML optimization docs.

fast.site cannot fix slow JavaScript, so INP work stays in your code. Measure before and after on your own site: the fs-cache header shows HIT, MISS or BYPASS, and analytics report TTFB and cache hit ratio. You can test all of this with a free 7-day trial, no credit card needed. See plans for the details.

FAQ

What is a good Core Web Vitals score?

A page passes when, at the 75th percentile of visits, LCP is 2.5 seconds or less, INP is 200 milliseconds or less and CLS is 0.1 or less. All three must be "good" for the assessment to pass. Mobile and desktop are evaluated separately.

Why is my PageSpeed score good but Search Console says I fail?

The Lighthouse score is a single lab test on a simulated device, while Search Console uses 28 days of real Chrome user data. Real visitors use slower phones and networks than the test, and lab tests cannot measure INP. Trust the field data for the assessment and use the lab test for debugging.

How long does it take for Core Web Vitals improvements to show?

Field data is a rolling 28-day window, so improvements appear gradually over about four weeks. Search Console may take a little longer to update its reports. Lab tests show the change immediately.

Does a CDN improve Core Web Vitals?

A CDN mainly helps LCP by lowering server response time and download time for visitors far from your origin. It can reduce CLS indirectly if it offers HTML optimizations such as adding image dimensions. INP depends mostly on JavaScript running in the browser, so a CDN has little direct effect there.

What replaced First Input Delay (FID)?

Interaction to Next Paint (INP) replaced FID as a Core Web Vital in March 2024. INP considers interactions across the whole visit instead of only the first one, and it includes the time to paint the result.