PageSpeed Insights may show a green field assessment beside a poor Lighthouse score. The panels measure different conditions. A clean lab run can also sit beside slow taps or shifting content reported by visitors. Write down the metric, page group, and source of evidence before trying to reproduce the problem.
A TechSEO user asked which PageSpeed Insights panel to trust when the Core Web Vitals assessment passed but lab LCP was poor. Another site owner saw field CLS fail while a lab test looked good. Those are useful questions, but the replies cannot trace the affected pages. The steps below connect field evidence to a repeatable test and a specific fix.
Which Core Web Vital Actually Needs Work?
Core Web Vitals describe loading, responsiveness, and visual stability. Largest Contentful Paint, or LCP, times the largest visible content element during loading. Interaction to Next Paint, or INP, measures response to qualifying interactions across a visit. Cumulative Layout Shift, or CLS, scores unexpected visual movement. Google’s Web Vitals reference defines the metrics and the field-data approach.
At the 75th percentile of page visits, the good thresholds are LCP at or below 2.5 seconds, INP at or below 200 milliseconds, and CLS at or below 0.1. Those are experience thresholds, not a promise of better rankings. A page can meet them and still fail to answer its search task. A useful page can exceed one and still need a specific performance fix. Google’s Search guidance on Core Web Vitals recommends good page experience without treating a score as the whole ranking system.
Write down which metric fails and whether the report describes one URL, a URL group, or an origin. PageSpeed Insights can show URL-level Chrome UX Report data when enough eligible visits exist, or origin-level data when the URL lacks its own sample. The Search Console Core Web Vitals report groups similar URLs. A group can identify a template problem, but it does not prove that every URL in the group has an identical cause.
Why Do Field and Lab Results Disagree?
Field data records eligible real visits with their devices, networks, and behavior. Lab data runs a page under controlled conditions. A lab run is useful for finding what to change, while field data tells you what people have experienced. Google’s guide to lab and field differences explains how navigation paths, device capacity, and interactions create gaps between them.
Check the label above the number before comparing it. Is it URL data or origin data? Mobile or desktop? A recent lab run or a trailing field window? Did the lab test scroll, open a menu, or submit a form? A Lighthouse load-only run cannot measure INP because it has no user interaction. Its Total Blocking Time can hint at main-thread trouble, but it is not a substitute for field INP. A load-only run can also miss layout shifts that happen after a visitor scrolls.
The field window moves as new visits arrive, so a fix shipped yesterday will not instantly replace older observations. Chrome UX Report commonly presents a rolling 28-day view. Record the deployment date and the report window. A lab improvement is an early check. A later field change is a separate observation, with traffic mix and other releases still capable of affecting it.
How Do You Pick a Representative URL and Test Setup?
Choose a URL from the failing group that has the same template and main content shape as other affected pages. If the issue seems limited to product pages, do not diagnose it on the homepage. Save the exact URL, viewport, device, network profile, browser version, test date, and whether the cache was warm. Repeat the lab run enough to see whether the symptom is stable. One unusually fast or slow result should not become the baseline.
Open PageSpeed Insights for field context and Lighthouse opportunities, then use Chrome DevTools Performance to inspect the relevant page behavior. For LCP, capture a load trace. For INP, record the interaction that feels slow, such as opening a filter or switching tabs. For CLS, record long enough to include the scroll, ad load, font swap, or modal that causes movement. The point is to observe the same event the field metric represents.
Compare mobile and desktop separately. A desktop trace with ample CPU does not explain a mobile INP problem. A local fast network may hide late image loading. Also confirm that the URL redirects to the same final page in both tests. The image size guide helps when the trace identifies image delivery as the bottleneck, but image compression is not the answer to every slow page.
How Do You Trace a Slow LCP?
Identify the LCP element first. It might be a hero image, a large heading, or another text block. The element can differ by viewport or visit. A common mistake is to compress the largest image file without confirming that it is the element responsible for LCP. In DevTools, inspect the LCP marker and the network waterfall for the same run.
Google’s LCP optimization guide divides the delay into time to first byte, resource load delay, resource load duration, and element render delay. Those parts suggest different fixes. A slow HTML response points toward server or cache work. A hero image discovered late because JavaScript inserts it points toward earlier discovery in the initial HTML. A long download may need a better source size or encoding. A resource that finishes early but renders late points toward blocking CSS, scripts, or main-thread work.
Do not lazy-load the image that becomes the visible LCP element. Give it a discoverable src or srcset in the HTML and consider priority only when the trace shows that the browser schedules it too late. If the LCP element is text, investigate the font and render path instead of changing image settings. A shorter download can fail to improve LCP if the saved time merely becomes render delay. Measure the subpart that moved.
| Trace observation | Likely area to inspect | First test |
|---|---|---|
| HTML response starts late | Redirects, cache, origin response | Compare final URL and time to first byte |
| LCP image request starts late | HTML discovery and request priority | Confirm source is present in initial HTML |
| Image download dominates | Dimensions, format, transfer size | Compare responsive variants at the rendered slot |
| Resource is ready but element appears late | CSS, font, script, main thread | Inspect render-blocking work in the trace |
A page can have several delays. Use the trace to find the largest measured part, fix it, and record another trace.
How Do You Find the Interaction Behind Poor INP?
INP concerns what happens when a visitor interacts, not how quickly the page first looks complete. Find the actual interaction in field attribution or a session recording if available, then reproduce it in DevTools. Open a menu, type into a search field, change a filter, or submit the form while recording. If you cannot identify the exact field interaction, test the likely high-use controls and label that work as exploratory.
Google’s INP guide splits an interaction into input delay, processing duration, and presentation delay. Input delay means the browser was busy before the handler ran. Processing duration points toward work inside the handler. Presentation delay means the next frame took time to render. A long script task during startup may block a tap even when the tap handler itself is short. A large DOM update can delay presentation even after the handler finishes.
Use the trace to choose a fix. Remove unnecessary client code, split long work, reduce synchronous work in the event handler, or simplify the layout update. A button that merely waits for a network response can still need a prompt visual response so the user knows the action registered. Do not hide a slow interaction by moving work behind a loading spinner unless the underlying response path is also understood. Re-test the same control under comparable conditions.
Where Can CLS Happen After the Initial Load?
CLS can accumulate during a visit. A page may look stable in a load-only lab test and shift when an image, embed, ad, or consent banner appears later. The CLS optimization guide identifies missing image dimensions, unreserved embeds, dynamic content, and font changes as common causes. Inspect the layout-shift events in a Performance recording and watch which elements move.
Reserve space for images and embeds with dimensions or an aspect ratio. Give an ad slot a sensible reserved area when its size can be predicted. Avoid inserting a banner above text a reader has begun reading. For fonts, compare the fallback and final font metrics and test whether the swap changes line breaks. A visual shift in one video or one scrolled section can affect the field metric even if the first screen is stable.
Do not assume the element that moved caused the shift. A paragraph may slide because an image above it gained height. The trace’s shift attribution and a replay help identify the source. Check the page at a narrow viewport, since a small width can turn a font change into several extra lines. Fix the source of the movement and record the same interaction again.
What Should a Fix Record Contain?
Keep one record per issue: URL or template group, affected metric, field source and window, lab setup, observed element or interaction, suspected cause, change shipped, and verification date. This is a diagnostic template, not a GIndexa performance claim. We have not measured a GIndexa URL for this article, so it reports no site score or improvement.
The first verification is a comparable lab trace. Did the LCP request start earlier, did the slow tap respond sooner, or did the shift disappear? The second is the later field view after the rolling window contains enough visits after the change. If field data is unavailable, say so and keep a small repeatable lab record. Do not present a single Lighthouse score as a real-user outcome.
Prioritize fixes by affected users and page purpose. A slow form interaction on a heavily used tool may deserve attention before a minor layout shift on an archive page. A critical text page with poor LCP may need a template fix that helps many URLs. The technical SEO audit workflow can hold the issue owner and release check. Rankings may move for many reasons, so report experience improvements separately from search traffic changes.
Frequently Asked Questions About Core Web Vitals Diagnosis
Does a Green Lighthouse Score Mean Real Users Pass?
No. Lighthouse is a controlled lab run. Compare the relevant URL or origin field data and inspect the metric that fails. A green score can miss interactions, later shifts, or network conditions that appear during real visits.
Why Does PageSpeed Insights Show Origin Data for My URL?
The URL may not have enough eligible Chrome UX Report visits for a separate field result. Origin data can give context, but it mixes pages. Use it to choose a template to inspect, then label any URL-specific lab work as a diagnostic test rather than URL-level field proof.
Can Lighthouse Measure INP Without a User Action?
No. A load-only Lighthouse run does not create the interaction that INP measures. Total Blocking Time is a useful lab clue for main-thread work. Record the actual interaction in DevTools and compare it with field INP when that data exists.
Will Passing Core Web Vitals Guarantee Higher Rankings?
No. Better loading, response, and stability help users, and Google considers page experience, but a pass is not a ranking contract. Confirm the experience change first. Evaluate search performance in its own report and avoid crediting one metric for every later movement.