The Complete Guide to Core Web Vitals

Key takeaways

• Core web vitals cover three things: Largest Contentful Paint for load, Interaction to Next Paint for responsiveness, and Cumulative Layout Shift for visual stability. Each has a good, needs-improvement, and poor band.
• Field data from real users is what Google grades, so fix for the 75th percentile phone on a mid-tier network, not for your own device.
• Most LCP problems trace back to a slow server response, render-blocking resources, or an unoptimized hero image, and each has a direct fix.
• Reserve space for images, ads, and embeds with width and height attributes to keep Cumulative Layout Shift low without guesswork.

What core web vitals measure and where the numbers come from

Core web vitals are three metrics that describe a page from the visitor’s point of view rather than the developer’s. Largest Contentful Paint records when the biggest visible element, usually a hero image or a headline block, finishes rendering. Interaction to Next Paint measures how long the page takes to visually respond after a tap, click, or key press. Cumulative Layout Shift adds up how much content moves around unexpectedly while the page loads. Together they answer three plain questions a user is already asking: did it load, did it react, and did it hold still.

The scores that count toward ranking come from the Chrome User Experience Report, which is anonymized field data from real Chrome visitors over a rolling 28-day window. That distinction matters. A synthetic test in a lab tells you what is possible on one machine, but core web vitals grade what happened across every device that loaded your page, including the three-year-old Android phone on a train.

The thresholds you are actually being graded against

Each metric has three bands, and Google evaluates them at the 75th percentile of your traffic. That means three out of four page loads need to hit the target for the metric to pass. Largest Contentful Paint is good at 2.5 seconds or under, and poor past 4 seconds. Interaction to Next Paint is good at 200 milliseconds or under, and poor past 500. Cumulative Layout Shift is good at 0.1 or under, and poor past 0.25.

The 75th percentile rule is why an average is misleading. You can have a fast median and still fail if the slow quarter of your visitors are stuck at 5 seconds. When you audit core web vitals, always look at the distribution, not the mean, because the tail is where the failures hide and where the ranking impact sits.

Fixing largest contentful paint

LCP breaks down into four stages: time to first byte, resource load delay, resource load time, and render delay. Work them in order. A slow server response inflates every other stage, so start by checking time to first byte and adding server-side caching or a CDN if it sits above 600 milliseconds. Next, find the LCP element in the field data and make sure it is discoverable early in the HTML rather than pulled in by a script.

For a hero image, three moves do most of the work. Serve it in a modern format like WebP or AVIF, size it to the container instead of shipping a 4000-pixel original, and add a preload hint so the browser fetches it without waiting. Remove render-blocking CSS and defer non-critical JavaScript so the main content is not stuck behind code the first paint does not need.

Fixing interaction to next paint

Interaction to Next Paint replaced First Input Delay in 2024 because it measures the full response to an interaction, not only the initial delay. Most INP problems come from long JavaScript tasks that block the main thread while the browser is trying to respond to a tap. When a single task runs for 200 milliseconds, every interaction that lands during it has to wait.

The fixes are concrete. Break long tasks into smaller chunks so the browser can respond between them. Move heavy work such as parsing, filtering, or analytics off the main thread with a web worker or by deferring it until after the interaction paints. Audit third-party scripts, since chat widgets, tag managers, and A/B testing tools are frequent culprits. Reducing the amount of JavaScript that runs on load is often the single biggest lever for this part of core web vitals.

Fixing cumulative layout shift

Cumulative Layout Shift punishes content that moves after a user has started reading. The classic cause is an image or ad with no reserved space, so the text below it jumps down when the media finally loads. The fix is to always set width and height attributes, or a CSS aspect-ratio, on images, videos, iframes, and ad slots so the browser reserves the box before the content arrives.

Other common triggers include web fonts that swap and reflow text, banners injected at the top of the page, and content inserted above what the user is already looking at. Use font-display settings that avoid a jarring swap, reserve height for any dynamic banner, and never insert content above existing content unless it is in direct response to a user action. Small, disciplined habits keep this metric green without constant firefighting.

Measuring core web vitals with the right tools

Use two categories of tool and keep their jobs separate. Field tools report what real users experienced: the Core Web Vitals report in Google Search Console, the CrUX dashboard, and the web-vitals JavaScript library you can wire into your own analytics. These are the numbers that affect ranking. Lab tools such as Lighthouse and WebPageTest simulate a load in a controlled setting and are for diagnosis, since they let you reproduce and fix an issue before it shows up in the field.

The workflow that works: watch the field data to know whether you have a real problem, then reach for a lab tool to reproduce it and test fixes. A common mistake is chasing a perfect Lighthouse score while the field data still fails, because the lab device and network do not match your real audience. Trust the field, diagnose in the lab.

Why lab scores and field scores disagree

Teams get confused when Lighthouse shows a 95 and Search Console still flags the page as poor. The two are measuring different populations. Lighthouse runs one load on a simulated mid-tier device with throttled network settings that you control. Field data blends thousands of real loads across every device, connection, and cache state your visitors bring. If most of your traffic is on older phones or slow connections, the field will always be harsher than a clean lab run.

Cache state is another source of disagreement. A lab test usually runs cold, while returning visitors hit warm caches that make their loads faster. When core web vitals disagree between lab and field, treat the field as the source of truth and use the lab to figure out which slice of users is dragging the 75th percentile down.

How core web vitals fit into ranking and business goals

Core web vitals are a ranking signal, but they are a tiebreaker rather than a primary one. Relevance and content quality still decide most of the ordering. Where the vitals earn their keep is on competitive queries where several pages answer the query equally well, and on the business side, where a faster, steadier page reduces bounces and lifts conversion regardless of ranking. Speed is a user-experience win first and a ranking nudge second.

Treat the metrics as a floor, not a finish line. Passing all three means you are no longer losing users or ranking to a slow, jumpy experience. Beyond that, keep an eye on the numbers as you add features, because a new video embed or marketing tag can quietly push a passing page back into the needs-improvement band within a single release.

Building a monitoring habit that keeps the numbers green

Performance regresses the moment nobody is watching. A theme update, a new hero video, or an extra analytics tag can undo months of work in one deploy. The teams that stay green treat core web vitals as a standing check rather than a one-time project. Wire the web-vitals library into your analytics so you see real-user numbers segmented by page template and device, and set a budget in your build so a pull request that adds 300 kilobytes of JavaScript gets flagged before it ships.

If you want a partner to run the audit, fix the LCP, INP, and CLS issues, and set up ongoing monitoring so the numbers stay passing after launch, our team can help. Start with a look at our pricing to see how a performance engagement is scoped.

More web design & development guides