Lab vs field data: start with field
Lighthouse gives you a lab score from a single synthetic test run. Search Console gives you field data — what real users actually experience. Always start with field data. If field data passes, the lab score doesn't matter. If field data fails, identify which metric is failing for which device class, then dig in with lab tools.
Setting up the audit environment
Run Lighthouse from an incognito browser window with no extensions. Use the mobile preset with simulated 4G throttling — this matches the conditions Google uses for ranking signals. Run each audit three times and take the median; single runs are noisy and can mislead.
Reading the LCP element
Lighthouse identifies the LCP element in the report. Usually it's the hero image, sometimes it's a heading. Whatever it is, optimise for it specifically — don't generically optimise the page. If the LCP element is an image, preload it. If it's text, ensure the font is preloaded. The targeted fix is 10x more effective than the generic one.
Diagnosing slow LCP
Slow LCP usually has one of four causes: slow server response (TTFB > 600ms), render-blocking resources, large LCP asset, or client-side rendering of the LCP element. Lighthouse points to the cause in the diagnostics. Address the diagnosed cause, not the symptom.
INP: the chrome trace
Lighthouse reports INP but doesn't tell you why. Open Chrome DevTools, record a performance trace while interacting with the page, look for long tasks. Long tasks over 200ms are INP killers. The fix depends on the task source — hydration, third-party script, your own code. Each requires a different remedy.
CLS: visual regression
Lighthouse shows the elements that shifted and by how much. Each shifting element needs explicit dimensions or aspect-ratio. Banners injected after load, lazy-loaded images without width/height, ads loading into reserved-but-empty space — all are common CLS causes with simple fixes.
The opportunities section
Lighthouse lists 'Opportunities' — specific changes that would improve metrics. Read them all. The estimated savings are conservative; real improvements often exceed the estimate. Prioritise opportunities by estimated impact vs implementation effort. Some wins are 5-minute changes that save 500ms.
The diagnostics section
The Diagnostics section flags issues that don't directly tank metrics but are worth fixing — image sizing, unused JavaScript, large network payloads. Each is a small win. Together they add up. Address them in a 'performance polish' sprint after the high-impact fixes.
Building the action plan
Translate the audit into a prioritised list: fixes that improve a failing metric (P0), fixes that improve a passing metric closer to the green zone (P1), polish (P2). Ship P0 immediately, P1 in the next sprint, P2 ongoing. Re-run the audit after each batch to verify improvements and catch regressions.
The continuous audit
Run audits weekly on your top 10 templates. Track scores in a dashboard. Set alerts for regressions. Performance optimisation is not a one-time project — it's a habit. The teams that sustain great Core Web Vitals are the ones that audit relentlessly.