Core Web Vitals Fixes: Pass LCP, INP and CLS for Real Users

The three metrics and their thresholds

Each Core Web Vital answers one question a visitor would ask. Largest Contentful Paint asks "when can I see the thing I came for?" It records the moment the biggest image, video poster or block of text in the viewport finishes rendering. Interaction to Next Paint asks "does the page respond when I use it?" It watches clicks, taps and key presses across the whole visit and reports one of the slowest delays between the input and the next frame the browser draws. Cumulative Layout Shift asks "does the page stay still?" It scores unexpected movement of content that was already on screen.

A page passes only when all three are in the good band at the 75th percentile of visits. In plain terms, at least three out of every four page loads must meet each threshold. Mobile and desktop are assessed separately, so a page can pass on one and fail on the other.

INP became a Core Web Vital in March 2024, replacing First Input Delay. FID only measured the wait before the browser started handling the very first interaction, which most pages passed easily. INP covers every interaction and includes the time spent running your event handlers and painting the result, so sites that looked fine under FID sometimes fail now.

Field data and lab data: why the numbers disagree

The checker shows two kinds of result, and understanding the difference saves a lot of wasted effort.

Field data comes from the Chrome UX Report, known as CrUX. Chrome collects anonymous timings from real users who have opted in, and Google publishes them per URL and per origin once there is enough traffic. The figures are a rolling 28-day window, reported at the 75th percentile. This is the data Google uses when it assesses your pages, and it is what the Core Web Vitals report in Search Console is built on.

Lab data comes from a single Lighthouse run on a simulated device and connection. It is repeatable and gives detailed diagnostics, which makes it ideal for testing a change before and after. But it is one visit, with an empty cache, no logged-in state, no cookie banner choice and no real interactions. Lighthouse cannot measure INP at all because nobody clicks anything during the test; it reports Total Blocking Time as a stand-in.

Common reasons the two disagree

• Timing. You fixed something last week, the lab test passes, but CrUX still shows three weeks of the old behaviour.
• Devices. Your visitors may use older phones than the device Lighthouse simulates, or much faster ones.
• Journeys. Real people scroll, open menus, accept cookies and add to basket. Layout shifts and slow interactions that happen after load never appear in a load-only lab test.
• Traffic mix. Low-traffic URLs may have no field data of their own, so Search Console groups them with similar pages or falls back to origin-level data.

When the numbers conflict, trust the field data for deciding whether you have a problem, and use lab data for working out why. Adding your own real-user monitoring, for example with Google's open-source web-vitals JavaScript library sending results to your analytics, closes the gap and shows results within days instead of weeks.

The fix guides

Each guide takes one finding from the checker and walks through the causes, how to confirm which applies to you, and the fix, with code where it helps.

The three Core Web Vitals

Fixing slow Largest Contentful Paint covers finding your LCP element, why it should never be lazy-loaded, preloading it, using fetchpriority="high", and removing the render-blocking CSS and slow server responses that hold it back. Fixing poor Interaction to Next Paint covers event handlers that monopolise the main thread, breaking long tasks into smaller pieces, deferring non-urgent work until after the next paint, moving heavy computation into a Web Worker and virtualising very long lists. Fixing layout shift covers images and embeds without reserved space, web fonts that swap late, ads and banners that push content down, and components that render after the rest of the page.

Supporting measurements

Fixing slow Time to First Byte deals with the server end: hosting location, caching whole pages at the edge, slow database queries and serving pre-rendered HTML. Fixing slow First Contentful Paint covers the first thing a visitor sees, which depends on a fast response and a short list of blocking files in the <head>. Fixing high Total Blocking Time covers the long JavaScript tasks during load that make a page unresponsive, including third-party tags and tracking that could wait for consent.

Devices and data sources

Fixing mobile-only failures explains why a page that feels fast on your laptop can fail for phone users on mid-range hardware and patchy connections, and how to test under realistic conditions. Fixing a CrUX vs lab mismatch explains how to read the 28-day window, when to expect Search Console to update, and how to set up real-user monitoring.

By platform

The platform guides apply the same principles where you have less control over the code. WordPress covers hosting, caching and optimisation plugins, page-builder weight and lighter themes. Shopify covers theme weight and the scripts that installed apps inject into every page. Next.js and Nuxt covers choosing static, server or incremental rendering per route, the image and font components, and hydration cost.

Which metric to fix first

Start with whichever metric is failing in the field for the pages that matter most to your business, usually the home page, key category or service pages and your best-performing landing pages. If more than one metric fails, this order tends to give the most benefit for the least effort:

1. CLS, if it is poor. Layout shift fixes are often small changes to templates: dimensions on images, reserved space for an ad slot or banner, a better font-loading setting. They are quick to ship and the improvement shows in field data as soon as the old visits age out.
2. LCP. This is the metric most sites fail. Check TTFB first, because no front-end work can rescue a page whose HTML takes two seconds to arrive. Then look at how the LCP element is discovered and prioritised.
3. INP. Responsiveness problems usually trace back to JavaScript: too much of it, handlers that do too much work, or third-party scripts competing for the main thread. The fixes are real engineering work, so measure carefully before you start and target the interactions people actually use.

Within each metric, fix the template rather than the page. If every product page shares one layout, one change to that layout fixes all of them, and Search Console groups similar URLs together for exactly this reason.

If your site has very little traffic and no field data, you cannot pass or fail in Google's eyes. Use lab results to build good habits, but put more of your effort into content and crawlability until traffic grows.

Order of work

1. Run the checker. Test your key pages with the Core Web Vitals checker and note, for each, the field result on mobile and desktop and the lab diagnostics.
2. Confirm in Search Console. Open the Core Web Vitals report and see which URL groups are poor or need improvement. This tells you how widespread each problem is.
3. Pick one metric and one template. Changing several things at once makes it impossible to tell what worked.
4. Diagnose with lab tools. Use the checker's diagnostics, Lighthouse and the Performance panel in Chrome DevTools to find the element, script or request responsible. Test with CPU and network throttling switched on.
5. Fix and verify in the lab. Re-run the lab test and confirm the diagnostic has cleared.
6. Deploy and watch the field data. With your own real-user monitoring you will see a change within days. CrUX and Search Console take up to 28 days to fully reflect it. In Search Console you can start validation on the issue once the fix is live.
7. Move to the next metric or template. Keep a short log of what you changed and when, so that a later regression is easy to trace.

For background on how each metric is measured, see the Core Web Vitals Guide or the example report. If your problems are mainly about heavy files and slow servers, the page speed fixes go deeper into assets, and the CLS Debugger fixes focus on tracking down individual shifting elements.

What Core Web Vitals do and do not do for rankings

Google uses Core Web Vitals as part of its page experience signals, and its guidance is consistent: good scores are rewarded, but they are not a substitute for relevant, helpful content. A page that answers the query well will usually outrank a faster page that does not. Where several results are similarly useful, page experience can make a difference.

That makes Core Web Vitals worth fixing for two reasons. The first is search: failing pages give up a possible tie-breaker, and very slow or unstable pages are also more likely to lose visitors who click through. The second, often bigger, reason is people. A button that moves just as someone taps it, a menu that takes half a second to open or a hero image that appears after the visitor has given up all cost enquiries and sales whether or not search is involved.

There are also things Core Web Vitals do not cover. They say nothing about whether a page can be crawled, whether its content matches search intent, whether its structured data is valid or whether it is accessible to disabled visitors. Passing all three metrics is one box ticked, not a clean bill of health.