Pulseby Kraavon
Complete guide

Core Web Vitals

Core Web Vitals are the three metrics Google uses to judge how a page feels to the person using it: how long until it looks ready, how quickly it responds when touched, and whether it holds still while it loads. They are the measurable part of page experience, and unlike most SEO advice they map directly onto things a developer can change.

The three metrics

Each covers a different failure. A page can load quickly and still be unusable, or feel instant and still move a button out from under a thumb. Passing means clearing all three thresholds for 75 percent of real visits, measured over a rolling 28 day window.

How the thresholds work

Each metric has three bands. Good, needs improvement and poor. What trips people up is that the assessment uses the 75th percentile of real visits, not the average. A site where three quarters of visitors get a fast experience passes even if the slowest quarter does not, and a site with a good average can fail if its tail is bad enough.

Good

75% of visits clear it

Needs work

Between the bands

Poor

75th percentile fails

Lab data and field data

Field data comes from real Chrome users and is what Google actually judges you on. It is slow to react, aggregated over 28 days, and it cannot tell you why anything is slow. Lab data is one scripted load in a controlled browser. It is repeatable, immediate, and it can point at the exact image or script responsible.

Use field data to know whether you have a problem, and lab data to find and fix it. A common and costly mistake is optimising against a lab score until it reaches 100 while the field data never moves, usually because the fix targeted something real visitors were never affected by.

Where Pulse fits

Pulse is a lab tool and says so on every report. It runs one scripted load in a real headless Chromium instance, which makes it the right instrument for finding causes and verifying that a fix worked. It reports INP as unmeasurable rather than inventing a value, because a scripted load performs no interactions.

Supporting metrics

These are not Core Web Vitals, but each one isolates part of what the vitals measure, which is what makes them useful when a number is bad and you need to know why.

Where to start

On most sites the order below removes the majority of the problem, because the same few causes recur almost everywhere.

Fix the images first

Oversized images are the single most common cause of a poor LCP, and images without dimensions are the most common cause of layout shift. One pass over them usually improves two of the three vitals.

Then the JavaScript

Everything that blocks the main thread hurts responsiveness. Remove what is never executed, defer what is not needed for the first paint, and move third party tags off the critical path.

Then the server

If Time to First Byte is slow, it puts a floor under LCP that no front end work can lift. A CDN in front of the HTML is usually the highest return change available.

Measure again, in the field

Verify in a lab tool immediately, then watch Search Console over the following month. Field data uses a rolling 28 day window, so improvements arrive gradually rather than overnight.

Common questions

What are the three Core Web Vitals?

Largest Contentful Paint, which measures loading, Interaction to Next Paint, which measures responsiveness, and Cumulative Layout Shift, which measures visual stability. Interaction to Next Paint replaced First Input Delay in March 2024.

What thresholds do I need to pass?

LCP under 2.5 seconds, INP under 200 milliseconds and CLS under 0.1. Passing requires 75 percent of real visits to a URL to meet all three, measured over a rolling 28 day window.

Are Core Web Vitals a ranking factor?

Yes, as part of the page experience signals, though they carry less weight than relevance. In practice they act as a tiebreaker: between two pages that answer the query equally well, the faster one wins. They matter more for conversion than for position on most sites.

Why do my lab results differ from Search Console?

Search Console reports field data from the Chrome UX Report, aggregated from real Chrome users over 28 days. A lab test is one load on one device and one connection. Lab data finds causes, field data tells you where you stand. Both are useful and they will rarely agree exactly.

How long do improvements take to show up?

Field data uses a rolling 28 day window, so a fix deployed today reaches full effect in Search Console roughly a month later. Lab tools show the change immediately, which is why they are the right tool for verifying a fix.

Check your Core Web Vitals now

A free audit reports all three against their thresholds, with the measured saving behind every recommendation.