Core Web Vitals Explained: What to Measure and Fix First

A page can load quickly and still feel broken. Its headline appears, but the pricing button ignores a tap. Or a late-loading banner pushes the form down just as someone tries to submit it.

Core Web Vitals measure three different parts of that experience: loading, responsiveness and visual stability. Your job is not to chase a perfect performance score. It is to identify which experience is failing, fix the cause and verify that real visitors benefit.

What are the three Core Web Vitals?

Google defines these metrics and thresholds in its Core Web Vitals documentation on web.dev:

LCP is not the time until everything finishes downloading. On a founder's homepage, the measured element might be the hero image. On a text-heavy pricing page, it might be the main heading or introductory paragraph.

INP is not simply the runtime of a click handler. It includes waiting before the handler runs, the handler's work and the delay before the browser can paint the response. Background JavaScript can therefore make an otherwise simple button feel slow.

CLS is a unitless score, not a duration. It reflects how much visible content moves and how far. It can capture instability after initial loading, such as an embedded widget expanding while someone reads.

Google's guidance assesses each metric at the 75th percentile, separately for mobile and desktop. In plain English, at least three-quarters of measured experiences must meet a metric's good threshold. Passing the overall assessment requires all three metrics to be good.

Do Core Web Vitals affect Google rankings?

Yes. Google's Search Central documentation says Core Web Vitals are used by its ranking systems. Their introduction into page experience signals began in 2021; Google's web.dev documentation records INP replacing the older First Input Delay metric in March 2024.

That does not make performance a shortcut past relevance, useful content or crawlability. A fast page that misses the searcher's intent does not become the best answer because its metrics are green.

Google does not publish a fixed ranking boost for passing. Avoid plans built around claims such as “improve LCP and gain a specific percentage of traffic.” There is no universal result to promise.

Use performance work to remove friction from pages that already matter: your main landing page, pricing page, product pages and signup flow. A responsive purchase button matters even when there is no measurable ranking change.

How do you check your site's real performance?

Start with Google PageSpeed Insights. Test representative URLs rather than only your homepage: different templates often load different images, scripts and widgets.

Read the real-user section before the diagnostic score. Its data comes from the Chrome User Experience Report, or CrUX, where enough eligible traffic exists. Google's CrUX documentation describes the results as a rolling 28-day view of real Chrome experiences.

Then use the lab results to investigate causes.

Check whether PageSpeed Insights is showing this URL or origin-level data. An origin result summarizes eligible experiences across the origin; it does not prove that the specific page you entered passes.

No field data does not mean good performance or failure. It means the public dataset cannot provide that assessment. Use lab testing and, where useful, your own monitoring instead.

A standard Lighthouse navigation test also does not establish real-user INP. Its Total Blocking Time metric can flag main-thread blocking, but you still need to test interactions.

What should you fix when LCP is slow?

First identify the LCP element in your performance trace. Do not compress every image and hope you found the right one.

Next, determine where the time goes: waiting for the server, discovering the resource, downloading it or rendering it. Each delay needs a different fix.

Is the server slow to return the page?

If the browser waits a long time for the initial HTML, image optimization alone cannot solve the problem. Investigate hosting, redirects, uncached database work and server-side rendering.

Cache public pages where appropriate and use a CDN when it reduces delivery latency. Keep personalized or account-specific responses out of shared caches unless the configuration safely handles them.

Is the main image discovered or downloaded too late?

Do not lazy-load an above-the-fold LCP image. Lazy-loading is useful for images farther down the page, not the image visitors are waiting to see first.

Make important images discoverable in the initial HTML where possible. For an identified hero image, the fetchpriority attribute set to high can help the browser prioritize it. Preloading can help a late-discovered resource, but unnecessary preloads compete with resources the page actually needs.

Serve an appropriately sized image using responsive image markup. WebP or AVIF often reduces transfer size compared with older formats, but compare file size and visual quality rather than assuming a format switch is enough. The image optimization guide covers that workflow in more detail.

Is the element ready but waiting to appear?

Large stylesheets, JavaScript-driven rendering and hidden-until-initialized components can delay the paint even after resources arrive. Prefer delivering the main content in HTML rather than making its appearance depend on a carousel or application bundle.

If text is the LCP element, inspect font loading. Reduce unnecessary font families and weights. Use a fallback strategy that shows readable text without introducing large layout changes later.

Preconnect can help when a critical resource comes from another origin. Add it selectively for origins actually needed early, not every analytics provider or third-party service.

What should you fix when INP is poor?

Test the actions visitors actually take: opening navigation, choosing a product variant, typing into a search box, accepting a consent notice and submitting a form.

Record these actions in Chrome DevTools. Look for long main-thread tasks around the slow interaction. The browser may be busy parsing scripts, recalculating layout or updating a large component tree before it can respond.

Start with unnecessary work. Remove unused plugins and duplicate tracking. Load a chat widget when it is needed rather than letting it compete with every early interaction.

Then reduce work inside the interaction itself. A pricing toggle should not rebuild unrelated sections of the page. A search field should not repeatedly filter a huge dataset synchronously on every keystroke.

Break lengthy operations into smaller tasks that yield to the browser, or move suitable computation into a web worker. Keep immediate feedback lightweight: show that the button responded before beginning expensive nonessential work.

Deferring non-critical JavaScript helps initial loading, but deferred code still has to execute. If it runs just as a visitor opens the menu, responsiveness can still suffer.

Test on a representative phone as well as your development laptop. CPU-heavy code may look harmless on your machine while causing obvious delays elsewhere.

What should you fix when CLS is high?

Reserve space before content arrives. Give images explicit width and height attributes, or establish an appropriate aspect ratio in CSS, so the browser can calculate their layout early.

Apply the same principle to video embeds, booking widgets, ads and recommendations. A placeholder only prevents movement if its dimensions reasonably match the final content.

Do not inspect only the first screen immediately after navigation. Scroll, wait for third-party content and exercise the page. Some shifts appear only after a widget loads or a recommendation panel refreshes.

Not every visible movement counts toward CLS; expected changes closely associated with certain user inputs can be excluded. But “not counted” is not the same as “good UX.” A confusing form remains a problem even with a green score. A broader DIY UX audit helps catch those issues.

Which performance fixes should you prioritize first?

Prioritize a demonstrated problem on an important template over a generic optimization suggestion.

A hero image fix may benefit every product page that shares the template. Removing one expensive third-party script may improve interactions across the entire site. Conversely, shaving bytes from a rarely visited legal page is unlikely to be your best first move.

Use this order:

1. Find the failing metric and affected templates. Separate mobile and desktop, and distinguish URL data from origin data.
2. Reproduce the cause. Identify the actual image, task or moving element rather than treating the score as a diagnosis.
3. Choose the smallest meaningful fix. Assign an owner and state the expected effect before changing code.
4. Test functionality alongside performance. Check navigation, forms, payments, consent controls and analytics after the change.
5. Verify in production. Confirm the deployed fix, then monitor real-user results as new visits enter the dataset.

SiteScoper's free website audit can help prioritize performance alongside UX, SEO and conversion issues. Use dedicated performance tools to inspect traces and confirm Core Web Vitals field results.

How do you know a fix worked and keep it working?

Compare before-and-after lab tests under similar conditions. Repeat tests rather than treating one unusually fast run as proof. For INP, repeat the interaction that was slow, not just the initial page load.

Field results will move more gradually because CrUX uses a rolling reporting window. Do not expect yesterday's deployment to erase older visits immediately. Search Console's validation process can track progress, but starting validation does not change the underlying measurements.

Document what changed and watch for regressions when you add a tag, replace the hero, install a plugin or update a shared component. Test shared templates after releases, not only when someone reports a slow page.

Stop optimizing when the remaining work offers little practical benefit compared with your other site problems. Good Core Web Vitals support a usable website; they do not replace clear pricing, accessible controls or a working checkout.