Why Core Web Vitals Can Fail When PageSpeed Tests Look Good

Two Kinds of Evidence Answer Different Questions

Lab data comes from a controlled test with specified conditions. Field data records experiences from real visits. A lab result is useful for reproducing behaviour and comparing a proposed change under repeatable conditions. Field evidence tells you how the measured population experienced the site.

PageSpeed Insights contains both types of information. Its Lighthouse performance score is a diagnostic score, not the Core Web Vitals field assessment. Write down which part of the report someone is calling “green”. A screenshot containing only the large performance number is incomplete evidence for a field-performance dispute.

The current Core Web Vitals are Largest Contentful Paint (LCP), Interaction to Next Paint (INP) and Cumulative Layout Shift (CLS). They concern loading, responsiveness and visual stability respectively. Their good thresholds are LCP at or below 2.5 seconds, INP at or below 200 milliseconds and CLS at or below 0.1, assessed at the 75th percentile and separated by device category.

The 75th percentile is a position in a distribution, not an average. A good result can coexist with slower or less stable experiences for some visitors. Likewise, one fast lab run does not establish where the 75th percentile lies for actual visits.

Core Web Vitals contribute to Google’s ranking systems, but good results do not guarantee top rankings. Diagnose performance because the experience matters; do not promise a particular search position from reaching a score.

Check Scope Before Investigating Code

Create one comparison record for each discrepancy. Keep the original report date, URL and device beside the numbers. Do not combine screenshots from different runs into a single result without preserving their provenance.

PageSpeed Insights can fall back from URL-level field data to origin-level data when the page lacks sufficient observations. An origin covers the relevant scheme, host and port, not just the path being tested. Check the displayed scope before assigning its result to one product or guide.

Search Console reports groups of similar URLs. A representative example is not necessarily the only affected page, and an individual PageSpeed result can differ from its group’s result. Use the group as a starting point for investigation, then inspect the pages and components that actually vary.

Hold the diagnosis if one result is for a URL and the other is for an origin or group that has not been examined. The next task is to establish scope, not to optimise the first image visible on the example page.

Turn the Discrepancy Into a Testable Question

Start with the failing metric

If LCP is weak, ask which visible content is being measured and under what loading conditions. Different viewports or page states can change the largest visible element. Capture the relevant element and its loading behaviour before deciding that a particular image, font or server response is responsible.

If INP is weak, investigate the interaction that produces delayed visual feedback. A default load-only audit does not reproduce every later action. Total Blocking Time (TBT) is a useful lab diagnostic, but it is not an INP measurement and its good result does not prove that later interactions are responsive.

If CLS is weak, inspect when unexpected layout movement occurs. A short initial-load test can miss movement that happens later. Record the page state and the event around the shift instead of assuming that the first screen contains the cause.

Keep each proposed cause separate from its evidence. “The category filter may be expensive on mobile” is a hypothesis. “A trace recorded a long delay after this filter action on this device” is an observation. Neither alone establishes the proportion of visitors affected.

Choose a controlled comparison

Repeat the relevant journey with the same URL and a recorded baseline. If the question concerns viewport changes, hold other conditions steady while changing the viewport. If it concerns a returning visitor, compare the intended cache states without silently changing login or consent state as well.

Run enough repetitions to see whether the behaviour is reasonably reproducible, retaining the range rather than selecting the best result. There is no universal number of runs that proves a fix. Define the question and the acceptance evidence before collecting results.

Use more than one representative page when the reported issue affects a group. A product page with a large gallery and one with a single image may share a template but expose different workloads. Compare relevant differences rather than assuming that every URL needs the same intervention.

Keep manual observation and measurement together

Manual testing is useful for finding the moment when the experience changes: opening a menu, choosing a variant or returning from another page. Record a short description of the action alongside a trace or relevant measurement. A video shows what happened visually; it does not, by itself, provide the field percentile.

Use an authorised test environment or non-transactional journey where an action could submit an order or change account information. A diagnostic plan should describe the state to reproduce without requiring a live purchase or disabling a necessary control.

Worked Example: Fast Desktop, Weak Mobile Field Results

Hypothetical example: a UK retailer has a product template that achieves a desktop Lighthouse performance score of 96. Its mobile Search Console URL group shows LCP of 3.6 seconds, INP of 280 milliseconds and CLS of 0.07. These invented figures are not measurements of a client site.

The field LCP and INP values are in the needs-improvement range, while CLS is good. The desktop score does not refute either mobile issue. No root cause has been established, and the group result does not prove that every product URL has those exact values.

The sensible decision is to continue mobile loading diagnosis and open a separate responsiveness investigation. “Wait for the report to catch up” is insufficient here because the hypothetical current mobile tests still reproduce a loading weakness.

It would also be premature to remove the gallery. The release log identifies a change worth examining, but timing alone does not establish that the gallery caused the result. A useful developer handoff names the affected metric, page state, repeatable observation and evidence still missing.

Counterexample: the reporting window is the main remaining limitation

Now change the scenario. Comparable current mobile tests consistently show improved loading, and suitable recent real-user monitoring supports the same direction for the affected page family. The older field window still includes substantial pre-release experience.

That combination supports monitoring the transition while retaining the original issue record. It does not justify repeatedly changing the page to force an immediate field pass. If the current evidence later worsens, or the supposedly comparable users prove to be a different segment, reopen the diagnosis.

Record the conclusion as “current improvement supported; historical field assessment still mixed”. Avoid “fixed for all users”. The narrower statement explains both the progress and the remaining evidence requirement.

Read the Reporting Window Without Inventing a Countdown

PageSpeed Insights field reporting uses a trailing 28-day collection period. A deployment does not rewrite experiences that occurred before it. Read the displayed collection dates and maintain a separate record of when the change actually reached users.

Do not assume that a change will produce a pass exactly 28 days later. The result depends on the experiences collected, continued coverage and the performance of the deployed site. A rolling window describes the evidence period; it is not a recovery guarantee.

In the hypothetical worksheet, 24 August to 20 September is 28 calendar days inclusive. The 18 September release falls near its end. That does not tell you what percentage of measured visits used the new version: traffic varies, and rollout or caching may affect exposure.

Comparing the two dates is still useful. It prevents a developer from interpreting a mixed historical result as a clean test of the latest release. Combine that date check with present-day reproduction and any suitable monitoring, rather than treating time as the only explanation.

Missing Field Data and Population Differences

CrUX includes eligible Chrome experiences, not every browser or every visitor. Public discoverability and sufficient usage affect inclusion; the exact popularity threshold is not published. No page-level result therefore means insufficient available evidence for that report, not an automatic pass or fail.

A UK business’s report should not be described as UK-only merely because the website targets the UK. Search Console combines requests from different locations. If geography is central to the diagnosis, request an appropriate breakdown and describe its coverage instead of assigning a location to an aggregate.

Your own real-user monitoring can help investigate page families, releases and conditions when those dimensions are actually collected. Define the metric implementation, population and segmentation before comparing it with CrUX. Different coverage can produce different results without either collection being dishonest.

Check missing metrics separately. PageSpeed Insights documents an assessment exception when INP has insufficient data: good LCP and CLS can still produce a pass. If LCP or CLS lacks sufficient data, the aggregation cannot be assessed. A missing INP value must not be rewritten as zero or described as proven responsiveness.

Where coverage remains insufficient, keep the conclusion operational: the controlled tests are encouraging, but the relevant field outcome is not established. Continue useful diagnosis without manufacturing a field verdict.

Mistakes That Turn a Discrepancy Into Rework

• Optimising the score instead of the failing metric: a change may improve the lab number while leaving the reported interaction or layout problem untouched.
• Selecting only the fastest run: the retained evidence no longer describes the variability seen during testing.
• Treating origin data as a product-page measurement: responsibility is assigned before the contributing pages are understood.
• Changing several components at once: a later improvement or regression becomes harder to attribute to a specific intervention.
• Removing essential behaviour: a faster incomplete page is not an acceptable replacement for a working customer journey.
• Closing an issue on an old screenshot: the report date and deployed version may no longer match the current site.

A good investigation can finish with “not yet known”. That is a useful result when it identifies the missing comparison and avoids speculative implementation work. Name who will collect that evidence and when the decision will be reviewed.

Make Future Releases Easier to Assess

Keep a small baseline set of important page families and journeys. For each, retain the test conditions, relevant metrics, release reference and any known evidence gaps. Review the set when the site introduces a materially different template or interaction.

Separate implementation acceptance from field confirmation. Acceptance might require that the intended change is present, representative tests improve and essential journeys still work. Field confirmation concerns the subsequent measured population and reporting scope. Agree both stages before declaring the job complete.

Do not average desktop and mobile percentiles to create an invented overall pass. Preserve the separate results and prioritise work using the affected experience and business importance. If your monitoring cannot answer a segmentation question, state that limit rather than filling it with an assumption.

How to Get This Done

Send the investigator the affected report, device, metric, collection dates, example URLs and recent release history. Add the original lab report and a description of the customer action that appears slow or unstable. Request a written diagnosis that distinguishes observations, hypotheses, proposed tests and implementation dependencies.

KAP SEO Services provides technical SEO diagnosis and developer-ready recommendations. Agree any detailed performance profiling and implementation scope with the responsible developer. A useful brief asks for evidence of the cause and a validation plan, not simply a promise to deliver a green score.