How to Improve Core Web Vitals

Diagnose before fixing — use field data, not just lab data

Google Search Console's Core Web Vitals report and the CrUX (Chrome User Experience Report) show real-user field data — how actual visitors experienced the site — while tools like PageSpeed Insights and Lighthouse show lab data from a single simulated test. Field data is the more accurate reflection of the ranking-relevant experience; a page can score well in a lab test while still showing poor field data due to real-world variables like actual user devices and network conditions.

Fix Largest Contentful Paint by addressing the actual LCP element

Identify which specific element is being measured as the LCP (often a hero image, a large heading, or a background image) using the PageSpeed Insights breakdown, then target that element directly: compress and properly size the image, avoid lazy-loading it if it's in the initial viewport, reduce server response time (TTFB) since LCP timing starts only after the server responds, and eliminate any render-blocking resources delaying that element's appearance.

Fix Cumulative Layout Shift by reserving space for dynamic content

CLS is almost always caused by content that loads after the initial render and pushes existing content around — ads, images without explicit dimensions, web fonts that swap in and change text size, or dynamically injected banners. The fix is consistently the same principle: reserve the correct space for these elements before they load (explicit width/height attributes on images, defined ad-slot dimensions, font-display strategies that minimize visible swapping) so nothing shifts once it does load.

Fix Interaction to Next Paint by reducing JavaScript execution burden

INP (which replaced First Input Delay) measures how responsive a page feels across all interactions throughout a visit, not just the first one — heavy, long-running JavaScript tasks are the most common cause of poor INP, since they block the browser's main thread from responding to a click or tap promptly. Breaking up large JavaScript tasks, deferring non-critical scripts, and removing unnecessary third-party scripts (each one adds its own execution burden) are the standard remediation paths.

Audit third-party scripts specifically

Chat widgets, analytics tags, ad networks, and embedded social widgets each add their own loading and execution cost, and they're frequently the largest, most overlooked contributor to poor Core Web Vitals scores precisely because they're not part of a site's own codebase and get added incrementally over time without anyone auditing their cumulative impact. A periodic audit of what's actually running on a page, and removing anything no longer providing clear value, is often the single highest-leverage fix available.

Re-test after every change, using both lab and field data

Lab data (PageSpeed Insights, Lighthouse) gives immediate feedback after a specific fix; field data (Search Console, CrUX) takes weeks to accumulate enough real-user sessions to reflect a change accurately. Use lab data to confirm a fix worked technically, then monitor field data over the following weeks to confirm it's translating into real improvement for actual visitors.

Common mistakes to avoid

• Optimizing based only on a single lab test rather than accumulated real-user field data.
• Lazy-loading the actual LCP element, which delays rather than helps that specific metric.
• Adding new third-party scripts without ever auditing whether older ones are still needed.

Related terms

• Core Web Vitals
• Largest Contentful Paint (LCP)
• Cumulative Layout Shift (CLS)
• Page Speed