Look at real data, not only a green score
If Lighthouse shows 95 but people say the site is slow, I do not trust one green score. I first look at real URL groups in Search Console, then find the culprit in PageSpeed and DevTools.
The mistake I would remove first: Lazy-loading the hero image.
What to prepare and what result to expect
- Outcome: You know which resource or script slows the page, and you can verify the fix with field data, not only a lab test.
- Open Search Console → Core Web Vitals and split Mobile/Desktop. For the problem URL, run PageSpeed Insights.
- Keep source data and access rights separate from the output so you can verify what speed and Core Web Vitals work actually did.
- Good-result targets: LCP under 2.5 s, INP under 200 ms, and CLS under 0.1. After the fix, click start validation in Search Console.
Find the main problem and fix it one at a time
- Find the problem URL
In Search Console open the issue group, then the specific URL. Paste it into PageSpeed Insights and see what the LCP element is.
Проверьте: It is clear what the user waits for the longest.
Если не сработало: Check the page in Chrome DevTools Performance with a mobile profile.
- Fix the first screen
Compress the hero image, set dimensions, and do not lazy-load the main visual. Defer secondary widgets and third-party scripts.
<img src="/hero.webp" width="1200" height="700" fetchpriority="high" alt="Technician repairing an air conditioner">Проверьте: The main visual appears without waiting for heavy JS.
Если не сработало: Replace video/animation with a static first frame for the test.
- Remove shifts and long tasks
Set width/height for images and iframes, reserve space for banners, cut heavy JavaScript, and break up long tasks.
Проверьте: On a mobile screen, elements do not jump during load.
Если не сработало: Disable third-party widgets one by one and find the culprit.
- Test a real scenario
In DevTools enable a slow CPU and mobile network, reload the page, and record Performance. Compare before and after on the same URL.
Проверьте: The fix improved the needed metric, not only the overall score.
Если не сработало: Revert the last change and test it in isolation.
I fix the LCP element first
Targets for a good result: LCP ≤ 2.5 s, INP < 200 ms, CLS < 0.1. If LCP is the hero image, do not set `loading=lazy`: set dimensions, a modern format, and `fetchpriority=high`. Images below the first screen, by contrast, should load lazily.
For CLS, reserve space for images, video, iframes, chat, and the cookie banner. For INP, open DevTools → Performance and look for long tasks: chats, maps, sliders, and several analytics widgets at once.
<img src="/assets/hero.avif" width="1440" height="900" fetchpriority="high" alt="Team working on a process">Do not confuse the lab with real users
Record URL, device, data source, LCP, INP, and CLS before the change. After the fix, recheck PageSpeed and DevTools on the same URL, then wait for Search Console field data to update. If you only fix the score but leave a slow form or a jumping button, the user will not have a better experience.
- Disable third-party widgets one by one first.
- Do not lazy-load the main visual.
- Do not treat mobile and desktop data as one metric.
One test — one culprit
First disable one third-party widget, measure again, and record the result. Then restore it and check the next one. Do not rewrite the whole frontend at once: otherwise you roll back to the old version and still do not know the cause.
For each URL group store `metric`, `device`, `source`, `before`, `after`, `change`, `owner`, and `date`. If the main problem is a heavy hero, optimize it; if it is INP, cut JavaScript. Do not fix CLS by swapping a font if an ad slot creates the shift.
LCP, INP, and CLS: what exactly to check
| Criterion | Question | Good sign |
|---|---|---|
| Input | What exactly enters speed and Core Web Vitals work? | Open Search Console → Core Web Vitals and split Mobile/Desktop. For the problem URL, run PageSpeed Insights. |
| Action | What is the system allowed to do on its own? | Only pre-listed actions, with no access to the whole account |
| Verification | How do you know the result can be accepted? | Good-result targets: LCP under 2.5 s, INP under 200 ms, and CLS under 0.1. After the fix, click start validation in Search Console. |
| Failure | Where does an unclear case go? | Compare Field data and Lab data, then fix the single heaviest resource; do not change CDN, font, and all JavaScript at once. |
What should change after setup
You know which resource or script slows the page, and you can verify the fix with field data, not only a lab test.
Which speedups accidentally hurt the first screen
Lazy-loading the hero image.
Fixing only the lab score and ignoring real data.
Forgetting image and iframe dimensions.
Adding another widget while the first screen is already overloaded.
When speed requires architecture work
You need a specialist if the slow spots involve the CMS, server rendering, a large JS bundle, or multiple external systems.
What to check after optimization
Why do PageSpeed and Search Console show different numbers?
PageSpeed combines a lab test with available field data, while Search Console uses aggregated real visits over a period.
Do you need a score of 100?
No. Stable performance of key pages and good real metrics on customer devices matter more.
What should you fix first?
What affects main content and the first screen, then layout shifts and long interactive tasks.
When will the result show up in Search Console?
Field data does not update instantly. A lab test checks the change right away, while the real report needs new visits to accumulate.
