Improve Core Web Vitals

Core Web Vitals are judged at the 75th percentile of real users: LCP good at 2.5 s or less, INP at 200 ms or less, CLS at 0.1 or less. Lighthouse is a lab test on one simulated device. It cannot measure INP (Total Blocking Time is only a proxy) and often disagrees with field data. Teams waste weeks chasing a lab score while the failing field metric is untouched, or apply a generic checklist without finding which part of the metric is slow.

Diagnose and prioritise fixes for this reportOnly if [FRAMEWORK] is given: on a [FRAMEWORK] site: [REPORT]

1. Identify whether each number is lab or field data. Prioritise metrics that fail in the field. If only lab data is given, say so and treat INP conclusions as provisional.
2. LCP: identify the LCP element, then break the time into its four parts (time to first byte, resource load delay, resource load duration, element render delay) and find the largest. Typical fixes: make the LCP image discoverable in the initial HTML, never lazy-load it, set fetchpriority="high", serve it in the right size and a modern format, reduce render-blocking CSS and JavaScript, cache HTML at the edge, and fix slow server responses.
3. INP: find the long tasks and the interactions they block. Typical fixes: break up long tasks and yield to the main thread, reduce hydration and re-render work, defer non-critical third-party scripts, avoid layout thrashing in input handlers, and show visual feedback before the expensive work.
4. CLS: find the shifting elements and their causes. Typical fixes: set width and height or aspect-ratio on images, video and embeds, reserve space for ads, banners and late content, use font fallbacks with matched metrics, and animate with transforms.
5. If a framework is given, use its own mechanisms (for example its image component, script loading strategy or streaming) rather than hand-rolled ones.
6. Rank fixes by expected improvement on a failing metric, divided by effort.

• Cite the report's own audits, elements and numbers for every root cause. Do not recommend fixes for metrics that already pass.
• Expected improvements are estimates; give a range and say what it depends on.
• If the report is missing the LCP element, the long-task breakdown or the shifting elements, list what to capture instead of guessing.
• Do only what was asked. If you notice something else worth changing, mention it in one line at the end instead of changing it.
• Keep the change as small as it can be while still being correct.

Status

A table: metric, value, lab or field, threshold, pass or fail.

Root causes

One subsection per failing metric, with the evidence from the report.

Fixes

Numbered, ranked: the change (with a code or config snippet where it helps), metric affected, expected improvement, effort (S/M/L).

Not worth doing now

Audits that look alarming but will not move a failing metric.

Measure

How to verify: which field metric to watch, for how long, and the lab check to run before release.