Poor Core Web Vitals: Why They Drag Your SEO Down (and How to Fix It)

Poor Core Web Vitals: Diagnose the Metric Before Changing the Site

Core Web Vitals measure three parts of a real visitor’s experience: how quickly the main content appears, how promptly the page responds to an interaction, and how visually stable the layout remains. The metrics are Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS).

A poor result is not a diagnosis. It does not tell you which image, script, server delay, font, advert, or interface component caused the problem. It also does not mean Google has applied a standalone “Core Web Vitals penalty”. The useful response is to confirm the real-user problem, isolate the affected page type and device, reproduce the cause, make a targeted change, and then verify that the experience improved.

Quickfire Summary: Thresholds and First Actions

Google’s Core Web Vitals guidance uses the following “good” thresholds. Assessment is based on the 75th percentile of real page visits, with mobile and desktop considered separately:

• LCP: good at 2.5 seconds or less; poor above 4 seconds.
• INP: good at 200 milliseconds or less; poor above 500 milliseconds.
• CLS: good at 0.1 or less; poor above 0.25. CLS is a unitless score, not a time.

Where sufficient data exists, a page passes the Core Web Vitals assessment only when all three metrics are in the good range. Use this order of work:

1. Confirm whether the problem appears in real-user field data and whether it affects mobile, desktop, or both.
2. Identify the failing metric and the affected URL group or page template.
3. Use a lab test and browser performance trace to reproduce the underlying cause.
4. Fix the shared cause before polishing isolated pages or chasing a perfect Lighthouse score.
5. Retest immediately in the lab, then monitor the rolling field data as new visits replace the old ones.

What Poor Core Web Vitals Do — and Do Not — Mean for SEO

Core Web Vitals are used by Google’s ranking systems, but Google also states that there is no single “page experience signal” and that good scores do not guarantee top rankings. Relevance remains essential, and a highly relevant page can still appear even when its experience is weaker. Treat Core Web Vitals as one part of page quality, not as a substitute for useful content, crawlability, indexability, or search intent.

The user impact is more direct. Slow main content can delay the point at which a visitor understands the page. Poor responsiveness can make menus, filters, forms, search boxes, and checkout controls feel broken. Unexpected layout shifts can cause people to tap the wrong element or lose their place. The commercial importance depends on the page and the task, so avoid attaching invented conversion percentages to a performance score.

Prioritise a Core Web Vitals issue when:

• the affected template serves many important or high-traffic URLs;
• the status is poor rather than only just outside the good threshold;
• the failing metric interferes with a key task such as finding information, submitting a form, adding a product, or completing checkout;
• the problem repeats in field data for the device your audience actually uses; or
• one shared component, script, image pattern, or server bottleneck explains a large group of affected pages.

Do not rush into a site-wide rewrite when:

• only one synthetic test is poor but representative field data is good;
• the test used a page state or device that does not match real visitors;
• the affected URL has too little field data to support a conclusion; or
• the proposed fix risks breaking revenue, accessibility, analytics, or essential functionality without first being tested on a representative template.

Google’s page experience guidance is a useful guardrail: improve the overall experience for users rather than treating one score as the whole of SEO.

How to Diagnose Core Web Vitals: Field Data First, Lab Data Second

1. Confirm the real-user problem

Start with the Core Web Vitals report in Google Search Console. It uses Chrome User Experience Report (CrUX) field data and groups similar indexed URLs by status, metric, device type, and URL group. It is designed to reveal patterns across a site, not to provide a complete inventory or an instant reading for every individual URL.

Then test a representative page in PageSpeed Insights. When enough CrUX data exists, its field section summarises the previous 28 days of real-user experiences at the 75th percentile. If there is not enough URL-level data, the tool may show origin-level data or no field data at all. “No data” does not mean the page is fast or slow; it means the dataset cannot make a reliable assessment.

2. Use lab tools to find the cause

Field data tells you what visitors experienced. Lab tools help explain why. PageSpeed Insights also runs Lighthouse under controlled conditions, while Chrome DevTools can record the loading timeline, main-thread work, interactions, and layout shifts as you use the page.

Expect field and lab results to differ. Real users have different devices, networks, caches, locations, consent states, account states, and behaviours. A default Lighthouse navigation does not perform the full range of real interactions, so it reports Total Blocking Time (TBT) as a lab proxy rather than measuring field INP directly. TBT can expose main-thread pressure, but it is not a substitute for reproducing the slow click, tap, or key press.

3. Find the shared pattern

Compare several affected URLs from the same Search Console group. Ask what they share: the same hero component, product gallery, tag manager, cookie banner, font set, ad slot, page builder, server route, or client-side rendering path. A template-level cause is usually more valuable than a one-page symptom because one safe fix can improve many URLs.

A ScanMySEO crawl can help organise related performance and asset findings across a site. Use CrUX-backed tools such as Search Console and PageSpeed Insights to confirm the real-user Core Web Vitals status, then use the crawl findings as supporting diagnostic evidence rather than presenting a third-party score as a Google score.

When field and lab data disagree

• Field poor, lab good: reproduce real user states, scroll and interact after load, test lower-powered devices, and inspect third-party or personalised content. The 28-day field window may also still include visits from before a fix.
• Field good, lab poor: the simulated test may expose a valid worst-case weakness, but confirm its relevance before making a risky change solely to improve a score.
• One URL good, its group poor: test more representative URLs. Search Console groups similar pages, and one example does not prove that the whole template is healthy.
• CLS only appears in the field: scroll, open menus, load more content, accept or reject consent, and complete common user flows. Post-load shifts are easy for a simple page-load audit to miss.

For harder cases, use ScanMySEO’s advanced Core Web Vitals troubleshooting guide to move from a headline score to a traceable bottleneck.

Action Steps: Fix the Root Cause of the Failing Metric

Fix LCP: make the main content arrive and render sooner

First identify the actual LCP element. It may be a hero image, heading, text block, video poster, or background image. Do not assume the largest file is the LCP element. Break the result into four parts: Time to First Byte (TTFB), resource load delay, resource load duration, and element render delay. The largest avoidable part tells you where to work.

1. Reduce document delay: remove unnecessary redirects, improve backend response time, cache suitable responses, and use a content delivery network where geography is a genuine contributor.
2. Make the LCP resource discoverable: include an important image in the initial HTML where practical. Do not lazy-load an image that is likely to be the initial LCP element.
3. Give the right resource priority: use fetchpriority="high" for the likely LCP image, not for a collection of competing images. Preload only when the browser would otherwise discover the critical resource late, such as a CSS background image.
4. Reduce transfer size: serve correctly sized responsive images, compress them, and choose WebP, AVIF, JPEG, PNG, or SVG according to the content and browser support rather than treating one format as universally best.
5. Remove render delay: reduce unnecessary render-blocking CSS and synchronous JavaScript, avoid hiding the main content until a client-side script completes, and ensure web fonts do not unnecessarily delay visible text.

A suitable initial-viewport image might look like this:

<img
  src="/images/hero-1280.webp"
  srcset="/images/hero-640.webp 640w,
          /images/hero-1280.webp 1280w"
  sizes="100vw"
  width="1280"
  height="720"
  fetchpriority="high"
  alt="Descriptive alternative text">

Use that priority hint only when the image is genuinely important to the initial view. Continue to lazy-load appropriate below-the-fold images.

Fix INP: shorten the delay between an action and the next painted frame

Reproduce the slow interaction first. Test the controls people actually use: navigation, search suggestions, filters, accordions, form fields, account controls, add-to-basket actions, and checkout steps. Record the interaction in the Chrome DevTools Performance panel and separate the delay into input delay, event-handler processing, and presentation delay.

1. Reduce main-thread competition: remove unused JavaScript, load non-essential code later, and challenge third-party scripts that execute during important user flows.
2. Break up long tasks: split large units of JavaScript work so the browser can process input and render between them.
3. Simplify event handlers: do the minimum work required for the next visual response, then schedule non-critical calculations or updates afterwards.
4. Control repeated work: debounce expensive input handling where appropriate, cancel obsolete network requests, and avoid timers that repeatedly occupy the main thread.
5. Reduce rendering work: avoid very large DOM updates, layout thrashing, and components that recalculate more of the page than the interaction requires.

Immediate visual feedback can reassure a visitor, but a spinner does not itself fix INP. The next frame still needs to be painted promptly, and the underlying work still needs to be reduced or scheduled more intelligently.

Fix CLS: reserve space and stop unexpected movement

1. Set dimensions for media: include width and height attributes on images and use CSS that preserves the aspect ratio. Reserve suitable space for video, embeds, and iframes.
2. Plan dynamic regions: provide stable slots or minimum heights for adverts, recommendations, consent messages, and asynchronously loaded components.
3. Avoid inserting content above existing content: add late content below the current reading position unless the movement is an expected and immediate result of the user’s action.
4. Test font swaps: reduce unnecessary font files and weights, use a sensible fallback font, and check whether the final font materially changes line breaks or element sizes.
5. Animate safely: prefer transforms and opacity for visual movement rather than repeatedly changing layout properties such as top, left, width, or height.
6. Inspect the full page lifecycle: scroll, open components, dismiss banners, and load additional content. CLS can be created long after the initial page load.

Common Core Web Vitals Mistakes That Waste Time

• Optimising only the homepage: Search Console may be reporting a product, article, category, or service-page template instead.
• Trying to reach a perfect Lighthouse score: use lab scores to diagnose and prevent regressions, not as a ranking guarantee or a substitute for field data.
• Lazy-loading the LCP image: this delays discovery of a resource that should usually begin loading early.
• Preloading or marking everything high priority: competing priority hints can make the truly important resource less clear to the browser.
• Compressing images when TTFB is the real problem: optimise the largest LCP subpart instead of applying the most familiar fix.
• Removing third-party tools without an owner: analytics, consent, chat, personalisation, and advertising changes need business and privacy review as well as performance testing.
• Testing only the initial load: INP and CLS problems often appear when people interact, scroll, or use the page for longer.
• Applying an advanced technique before fixing basics: prerendering, Early Hints, service workers, and complex caching can be useful, but they add operational risk and may not address the measured bottleneck.

A note for single-page applications

Single-page applications can update the URL and main content without a traditional full-page navigation. Those route changes do not always map neatly to conventional page-load measurements, and browser and reporting-tool support continues to evolve. Validate important route transitions with current DevTools and real-user monitoring rather than assuming one navigation audit covers the whole application.

Worked Example: The Same Poor LCP Score Can Need Three Different Fixes

Consider three hypothetical mobile pages with a poor LCP result. The number alone is not enough to choose the fix:

1. Product page: the hero image is added by JavaScript and also marked for lazy loading. The browser discovers it late. The likely fix is to expose the image in the initial HTML, remove lazy loading from that image, and test an appropriate priority hint.
2. Article page: the LCP element is the headline, but the HTML response is slow and a large stylesheet blocks rendering. Re-encoding images will not solve the main delay. The likely work is server caching, route optimisation, and reducing render-blocking CSS.
3. Service page: the lab test looks good, but mobile field data remains poor. Real visitors receive a consent layer, a location script, and a personalised banner that the lab state did not reproduce. The next step is to test those states and collect diagnostic field data rather than repeatedly rerunning the same clean lab test.

The lesson applies to INP and CLS as well. Fix the measured cause on a representative page, then confirm whether the same component explains the wider URL group before rolling the change across the site.

Verify the Fix and Prevent the Next Regression

Record a baseline before deployment: the tested URL, device type, field status, lab settings, LCP element or slow interaction, layout-shift source, and the relevant performance trace. Without a comparable baseline, a changed score may reflect different conditions rather than a better page.

1. Retest in the same lab conditions: confirm that the targeted bottleneck improved and that the page still functions correctly.
2. Repeat the real user flow: test menus, forms, filters, consent, account states, and post-load content on representative mobile and desktop devices.
3. Check for regressions: confirm that the fix has not harmed accessibility, analytics, image quality, caching, conversion tracking, or essential scripts.
4. Deploy across the affected template: only after the representative fix is stable.
5. Monitor field data: PageSpeed Insights uses a rolling 28-day CrUX window, so old visits do not disappear immediately. Search Console groups also need enough new real-user data before their status changes.

The detailed performance verification decision guide explains how to judge a fix when lab, field, and business evidence update at different speeds.

Build prevention into normal website work

• set performance budgets for important templates and assets;
• run repeatable lab checks before releases, while remembering that field monitoring remains necessary;
• assign ownership for third-party tags and review them regularly;
• monitor representative templates rather than only the homepage;
• retain before-and-after traces for material changes; and
• investigate a regression at the component or release level before applying broad, speculative fixes.

Quick Reference: What to Check First

• Poor LCP: identify the LCP element, inspect TTFB and the LCP subparts, then fix late discovery, slow transfer, or render delay according to the trace.
• Poor INP: reproduce a real slow interaction, record the Performance panel, then reduce main-thread competition, event-handler work, and expensive rendering.
• Poor CLS: inspect layout-shift sources throughout the page lifecycle, then reserve space for media and dynamic content and stabilise font and component behaviour.
• No field data: do not infer a pass. Use representative lab tests and, where the site warrants it, real-user monitoring until enough field evidence exists.
• Field and lab disagreement: align the tested device, state, content, and user flow; use field data for the experienced outcome and lab tooling for diagnosis.

Authoritative Core Web Vitals Resources

• Google Search Central: Core Web Vitals and Search
• Google Search Console Help: Core Web Vitals report
• web.dev: Core Web Vitals workflows with Google tools
• web.dev: Optimise Largest Contentful Paint
• web.dev: Optimise Interaction to Next Paint
• web.dev: Optimise Cumulative Layout Shift

Start with the failing metric and the affected template. Fix one verified cause, re-test the user flow, deploy safely, and allow the rolling field data to show whether real visitors experienced the improvement.