Why does Lighthouse pass while Search Console reports a problem?
Choose the problem by the actual task and device. A delayed hero image, slow filter and shifting form need different fixes; one aggregate score does not identify their causes.
If a product photograph is the LCP element, inspect its dimensions and loading in the image SEO guide. If the main text arrives after scripts, start with JavaScript. Recheck accessibility after each change. A deferred menu still needs to work with a keyboard.
What to do step by step
- Separate field data from lab diagnostics in PageSpeed Insights.
- Identify the element and loading chain behind LCP.
- Reproduce slow interactions when investigating INP.
- Find unreserved space or late content behind CLS.
- Repeat comparable tests and monitor subsequent real-user data.
A practical example
Reserving the aspect ratio of a hero image addresses layout movement. Reducing its transfer size addresses delivery. These are different fixes with different verification.
A common mistake
One passing desktop test does not establish a good mobile experience. HTML size and a static scan are not Core Web Vitals measurements.
Try the report before checking your site.
Explore the sample report, then enter your own URL to see findings, HTML evidence and a repair plan for your page.
Run your audit
How Lighthouse differs from real-user performance data
Field data describes real visits; Lighthouse is a controlled diagnostic run. A score from one mobile test cannot describe every customer’s experience.
- Good thresholds are LCP ≤ 2.5 s, INP ≤ 200 ms and CLS ≤ 0.1, evaluated at the 75th percentile.
- Separate mobile and desktop results.
- Missing field data means insufficient evidence, not a passing result.
Source web.dev — Core Web Vitals ↗
How to find the cause of a slow LCP
First identify the measured element. It may be an image or text. Then inspect the path from the server response to its first useful rendering.
- Check slow HTML delivery before compressing the hero image.
- Do not lazy-load an image identified as the above-the-fold LCP resource.
- Inspect discovery delay, image transfer and render-blocking dependencies separately.
Source web.dev — optimize LCP ↗
How to investigate slow interactions and layout shifts
INP and CLS need different repairs. A slow filter suggests interaction work; a jumping product image suggests space was not reserved before loading.
- Record the actual slow click or key interaction when investigating INP.
- Use width, height or aspect ratio to reserve image space.
- Do not present Lighthouse Total Blocking Time as a measured INP value.
How to verify a Core Web Vitals improvement
Keep the URL, device and test conditions comparable. A faster repeat may reflect cache or network variation rather than the code you changed.
- Repeat the same scenario and compare the specific metric you targeted.
- Check that the image, menu or purchase interaction still works.
- PageSpeed field data covers a rolling 28-day period, so it will not instantly reflect a deployment.
How to verify the result
In Fukamo, compare mobile and desktop Google Lighthouse results. Do not present lab LCP and CLS as the experience of all visitors. Use available field data or your own interaction measurements for INP and longer-term evaluation.
Primary documentation web.dev ↗
Frequently asked questions
Why does Lighthouse pass while Search Console reports a problem?
Lab tests and real-user data describe different conditions. Distinguish mobile from desktop and URL data from origin-level data. LCP concerns main-content loading, INP interaction responsiveness, and CLS layout movement. Improving one test run does not establish a better experience for every visitor.
Is a Lighthouse score the same as Core Web Vitals?
No. Lighthouse measures a page in a specific laboratory run. Core Web Vitals describe real visitors’ experience through LCP, INP and CLS. Distinguish lab measurements from available field data and the period those data cover.
Why do mobile and desktop results differ?
The runs use different conditions, and the mobile page may have a different content layout. Compare the same device and conditions. Repeat measurements after a repair; one slow run may not describe visitors’ usual experience.
When the task is complete
Repeat a comparable test and retain a trace of the specific bottleneck. Then monitor subsequent field data. Missing field data should remain an uncertainty rather than an automatic pass or failure.
Related SEO guides
Check a specific page.
Fukamo shows findings, evidence and the next step.
679 rules + SEO, AI readability, performance and accessibility measurements for free.