Three metrics decide whether Google considers a page a good experience. Most guides list them, quote the thresholds and stop, which leaves you knowing you failed without knowing which part failed.
Each of the three breaks into phases, and the fix depends entirely on which phase is slow. A page failing Largest Contentful Paint because the server took 900 milliseconds to respond needs nothing done to its images.
This guide goes metric by metric. The service itself, how the work is sequenced and what it cannot fix, is covered in site speed optimization.
What Are Core Web Vitals?
Core Web Vitals are three metrics Google uses to measure page experience: Largest Contentful Paint for loading, Interaction to Next Paint for responsiveness, and Cumulative Layout Shift for visual stability. Each has a published good threshold, assessed at the 75th percentile of real page loads.
- Largest Contentful Paint should occur within 2.5 seconds.
- Interaction to Next Paint should be 200 milliseconds or less.
- Cumulative Layout Shift should be 0.1 or less.
The 75th percentile matters more than people expect. Passing means three quarters of real visits met the threshold, so a fast experience for most users still fails if a quarter of your traffic is on slower devices or connections.
Interaction to Next Paint replaced First Input Delay and became a stable metric in 2024. Any audit still reporting FID is working from a retired metric.
Does Fixing Core Web Vitals Improve Rankings?
Google states that Core Web Vitals are used by its ranking systems. Google also states there is no single page experience signal, describing instead a variety of signals its core ranking systems consider, and adds that beyond Core Web Vitals, other page experience aspects do not directly help a page rank higher.
Read plainly, that makes speed one input among many rather than the deciding one. A fast page with weak content does not outrank a slow page that answers the question better.
Ranking is also the smaller half of the argument. Core Web Vitals sit underneath everything else, the way foundations sit underneath a building. A page that takes four seconds to show anything, shifts under the reader's thumb, or ignores a tap has lost the visitor before the content, the keywords or the structured data get a chance to work. None of that other work becomes wrong. It simply cannot be collected on.
That is the honest case for doing this work. Not that Google rewards a fast page, but that a slow one quietly wastes everything built on top of it.
Note - Treat a failing page as a cracked foundation rather than a missing feature. Once all three thresholds pass, further effort buys a better score and little else, so the work has a clear finish line.
Largest Contentful Paint
LCP measures how long the largest visible element takes to render. Usually a hero image, sometimes a block of text or a video poster frame.
The four phases of LCP
LCP breaks into four parts that add up to the total, and web.dev publishes rough guidelines for how the time should distribute:
- Time to First Byte, roughly 40 percent. Measured from when the user starts loading the page to when the browser receives the first byte.
- Resource load delay, under 10 percent. Covers the gap between that first byte and the browser starting to load the LCP resource.
- Resource load duration, roughly 40 percent. The download time of the image or font itself.
- Element render delay, under 10 percent. Covers the gap between the resource finishing its download and the element appearing.
Those are guidelines rather than strict rules, and the point of knowing them is diagnostic. A page where render delay is 50 percent of LCP has a main-thread problem, not an image problem, and compressing the image will change nothing.
Why LCP is slow
- High Time to First Byte, caused by server redirects, visitors far from the server, poor networks or uncacheable URL parameters.
- Late discovery of the LCP resource, which happens when the image is injected by JavaScript, hidden in a data attribute or set as a CSS background image.
- Lazy-loading the LCP image. Never do this, since it guarantees the browser finds the most important image last.
- Render-blocking resources, meaning large stylesheets or synchronous scripts in the document head.
- Main-thread blocking, where long JavaScript tasks delay rendering even after the image has finished downloading.
- Oversized resources or network contention from too many competing high-priority requests.
How to fix LCP
Fix in phase order, because the phases are sequential and an early one puts a floor under everything after it.
- Cut TTFB first through caching, a content delivery network and removing redirect chains. Nothing on the front end compensates for a slow first byte.
- Make the LCP resource discoverable in the HTML itself, then preload it so the browser finds it immediately.
- Serve the image at the dimensions it actually displays at, in a modern format, compressed.
- Defer scripts and stylesheets that the first screen does not need, and inline only the small amount of CSS it does.
Load duration tends not to be the real bottleneck on most sites, which is worth knowing before spending a day on image compression.
Interaction to Next Paint
INP measures how long the page takes to respond visibly after a user interacts with it. A click, a tap or a key press, measured through to the frame that shows the result.
The three phases of an interaction
- Input delay, which starts when the user initiates the interaction and ends when the event callbacks begin to run.
- Processing duration, which is how long those event callbacks take to run to completion.
- Presentation delay, which is how long the browser then takes to present the next frame containing the visual result.
Google does not publish which phase usually dominates, so measure rather than assume. All three add to total interaction latency.
Why INP is poor
- Main-thread activity during input delay, from script loading, parsing and compiling, plus fetch handling, timers and overlapping interactions.
- Heavy event callbacks, where complex interaction logic runs long and one long task blocks every other interaction.
- Layout thrashing, caused by updating styles and then reading them back in the same task, which forces synchronous layout.
- Large DOMs, which make rendering updates very expensive.
- Client-side HTML rendering, where generating large amounts of markup in JavaScript delays the next frame.
How to fix INP
- Reduce long tasks during page load, particularly script evaluation, since that is what holds up input delay.
- Keep event callbacks light and yield to the main thread to break up work.
- Run only the work needed for the next visual update inside the callback, and defer the rest.
- Stop reading styles immediately after changing them, which removes the forced synchronous layout.
- Reduce DOM size, and use content-visibility so off-screen elements render lazily.
Third-party scripts deserve special mention here. Chat widgets, heat maps and tracking pixels each run code you did not write on the main thread, and they are the most frequent cause of a failing INP on otherwise well-built sites. The honest fix is usually removal, which makes it a commercial decision rather than a technical one.
Cumulative Layout Shift
CLS measures how much visible content moves around unexpectedly while the page loads. Unlike the other two it is not a time, it is a score, and 0.1 or less passes.
What causes layout shift
- Images and video without width and height attributes, so the browser cannot reserve space before the file arrives.
- Ads, embeds and iframes injected into a space nobody reserved.
- Web fonts that swap after load, reflowing every line of text around them.
- Content inserted above existing content, such as a cookie banner or a promotional bar that appears late.
How to fix CLS
- Set explicit width and height, or a CSS aspect ratio, on every image and video. This single change fixes most CLS problems.
- Reserve a fixed container for anything injected later, including ads and embeds, so late arrival changes nothing.
- Preload the fonts used on the first screen and set a sensible font-display behavior.
- Render banners and notification bars in reserved space, or overlay them rather than pushing content down.
CLS is usually the cheapest of the three to fix and the most commonly left broken, because it costs nothing in page weight and shows up in no bandwidth report.
Where to Measure
Two kinds of data exist and they routinely disagree.
- Lab data, from Lighthouse and the score in PageSpeed Insights, simulates one load under fixed conditions. Useful for diagnosis because it is repeatable and names specific causes.
- Field data, from the Chrome User Experience Report, comes from real Chrome users on real devices. Slower to update because it reflects a rolling window, and far more honest.
Search Console reports field data. A fix that improves your Lighthouse score while field data stays flat has not worked, and that outcome is common enough to check for rather than assume away.
Note - Field data lags the work by weeks. Expect the engineering to finish well before Search Console confirms it, and do not re-fix something that is already fixed because the report has not caught up.
The Bottom Line
Core Web Vitals optimization is worth doing when a page fails the thresholds, because a failing page undermines every other thing you have built on it, and carries a smaller ranking handicap on top. Worth much less once a page passes.
Diagnose by phase before changing anything. The three metrics fail for different reasons, and within each metric the phases fail for different reasons again, which is why generic recommendation lists produce so little movement. An SEO audit finds which phase is at fault across a whole site, and technical SEO covers the implementation work itself.
