Core Web Vitals in practice: fixing LCP, INP and CLS
INP replaced FID and broke a lot of previously passing sites. Here is how to diagnose each metric with field data and what actually moves them.
By Digiloom engineering team · Published · Updated
Lab scores are a diagnostic, not the target
Search engines use field data from real users, aggregated over 28 days. A perfect Lighthouse score on a desktop connection tells you very little about a customer on a mid-range Android phone on 4G.
Start from the Chrome UX Report and your own real user monitoring, segmented by device. Fix what is slow for the segment that generates your revenue.
LCP: it is almost always the image or the server
Largest Contentful Paint is dominated by four things: server response time, render-blocking resources, resource load time and client-side rendering delay.
The fixes, in order of usual impact: serve the hero image at the right size in AVIF or WebP with a preload hint, remove render-blocking CSS and fonts from the critical path, cache HTML at the edge, and stop rendering above-the-fold content client-side.
INP: main thread congestion, not network
Interaction to Next Paint measures how long the page takes to visibly respond after a tap or click. It fails when the main thread is busy with long tasks — hydration, third-party tags, heavy event handlers.
Break long tasks into chunks, yield to the main thread, defer non-critical scripts until interaction, and audit third-party tags ruthlessly. A single chat widget or heatmap script is often the entire problem.
CLS: reserve the space
Cumulative Layout Shift is usually images without dimensions, ads and embeds without reserved containers, fonts swapping to different metrics, or content injected above existing content.
Set width and height or aspect-ratio on every image, reserve space for anything injected, and use font-display with a metric-matched fallback.
Keeping it fixed
Performance regressions arrive through the marketing team, not the engineering team. A new tag, a new hero video, a new pop-up.
Put a performance budget in CI that fails the build, and monitor field data monthly. Fixing it once and walking away means doing it again in eight months.