Your site fails Core Web Vitals: what to fix first and what to ignore

A failing Core Web Vitals assessment is about what real visitors experienced on your pages over the last 28 days, not about the 0–100 score PageSpeed Insights shows underneath it. That score comes from a simulated test, and it is a hint about what to fix. So start with the assessment: find which of the three metrics fails, on which device, and identify what is contributing to that metric on the affected pages. A high lab score and a passing field assessment are not the same thing: chasing "90+ on mobile" can still leave the assessment red.

The three metrics, in plain words

Google's Web Vitals guidance sets a "good" threshold for each, measured at the 75th percentile of page loads, separately for mobile and desktop. For a metric to be rated good, at least 75% of measured page loads need to meet its threshold.

INP replaced First Input Delay (FID) as a Core Web Vital on 12 March 2024. If a guide or tool still talks about FID, it is out of date.

Field data versus the score

PageSpeed Insights shows two different things on one screen, and they are easy to mix up.

• Field data, at the top: real Chrome users' experience of your page over the previous 28 days. The Core Web Vitals assessment comes from this. It passes only if all three metrics are good at the 75th percentile. If your page doesn't have enough visitors, PageSpeed Insights falls back to data for the whole site.
• Lab data, below it: one simulated page load on one device and network, run by Lighthouse. The Performance score belongs here. It is not part of the assessment.

The two disagree for ordinary reasons. Google's article on lab and field differences lists several: real visitors use many devices and connections, often have files cached already, and actually scroll and tap. A lab test can't tap, so it can't measure INP at all; it reports Total Blocking Time as a rough stand-in. Google's advice is to prioritise field data when you have both.

So a page can score 45 in the lab and pass the assessment, or score 92 and fail it. When they conflict, the field data is the one describing your customers.

Search Console's Core Web Vitals report shows the same kind of field data across your site, grouped by similar pages. A group's status is set by its worst metric, which is useful: it tells you whether the problem is one template (all product pages) or one page.

What to check for each failing metric

Work on the metric that fails, on the device where it fails. A store whose mobile LCP is 3.4 seconds and whose CLS and INP are fine has one problem, not three.

LCP too slow. Check which element is the LCP element. If it's a hero image or banner, look at these causes:

• the image is large, uncompressed or in an old format;
• the image is lazy-loaded. Google's LCP guidance says never to lazy-load the LCP image;
• a slider or app loads the banner with JavaScript, so the browser finds it late;
• the server is slow to send the first byte. If that's the case, it is a hosting question, and a separate diagnosis from this one.

PageSpeed Insights shows which element is the LCP element; fix that one first.

INP too slow. The page is busy running scripts when someone taps. On Shopify and WordPress sites, the usual sources are apps and plugins that add their own JavaScript to every page: chat widgets, review widgets, pop-ups, upsell tools, trackers. List what loads on a failing page and remove what you don't use. Google's INP guidance recommends starting from field data to find which interactions are slow, because the lab can't reproduce them.

CLS too high. Something appears late and pushes content down. Typical causes, from Google's CLS guidance:

• images and videos without width and height set;
• cookie banners, announcement bars or pop-ups inserted at the top after the page has loaded;
• embeds and ads without reserved space;
• web fonts that swap in and change text size.

Load a failing page on your phone and watch it. CLS can be visible: the "Add to cart" button moves as a banner drops in.

Fix order, and waiting for the data

1. Open Search Console's Core Web Vitals report. Note which metric fails, on mobile or desktop, and for which group of pages.
2. Pick the template with the most traffic among the failing groups. On a store that may be product pages.
3. Fix the most likely cause of that one metric on that template.
4. Check the change in the lab (PageSpeed Insights lab data, or Lighthouse in Chrome) to confirm the fix works technically.
5. Tell Search Console you've fixed the issue from the Core Web Vitals report, then wait. Field data covers 28 days, and Google says it monitors the fix for 28 days, so the assessment changes gradually.

Don't stack five changes in the same week. If the metric improves, you won't know which change helped; if something breaks, you won't know which to undo.

What to ignore: the Performance score as a target, lab-only warnings on pages with few visitors, and differences of a few points between test runs.

What this does and doesn't do for search

Keep two questions apart. Faster, steadier pages are better for the people using them, and that is reason enough to fix a red LCP on your product pages. The search question is narrower.

Google's page experience documentation says Core Web Vitals are used by its ranking systems, but also that Google Search always tries to show the most relevant content even if page experience is poor, and that good results in Search Console or third-party tools don't guarantee top rankings. It adds that chasing a perfect score just for SEO may not be the best use of your time.

So don't plan on a traffic increase after the assessment turns green. If you lost search traffic, don't treat a failing assessment as the explanation before checking timing, indexing and what changed on the site.

Tools: free first

The free Google tools cover the basics: Search Console's Core Web Vitals report for field data across the site, and PageSpeed Insights for one page at a time, with both field and lab data.

Semrush adds a lab check across several pages in one place. Its Site Audit includes a Core Web Vitals report that tests a set of 10 pages with Lighthouse and reports LCP, CLS and Total Blocking Time. That has one practical use: after a theme change, you can see whether the fix worked on your main templates without waiting 28 days for field data. Its limits matter. It is lab data only, from Semrush's servers in the US, it doesn't measure INP, and Semrush itself notes its numbers can differ from Search Console. It complements the Google reports; it can't tell you whether you pass the assessment.