Core Web Vitals: The Fixes That Actually Move LCP, INP, and CLS

Start with field data, not a lab score

Google uses real-user data from the Chrome UX Report to assess Core Web Vitals. A perfect Lighthouse score on your laptop means little if visitors on mid-range phones over mobile networks have a slow experience. Start with the Core Web Vitals report in Search Console and PageSpeed Insights field data, then group problems by page template.

The thresholds to aim for at the 75th percentile: LCP under 2.5 seconds, INP under 200 milliseconds, and CLS under 0.1.

Largest Contentful Paint (LCP)

LCP measures when the main content, usually a hero image or headline, appears. Most slow LCP comes from a late-discovered image or a slow server response.

• Serve the hero image in a modern format (WebP or AVIF) at the right size with srcset.
• Never lazy-load the LCP image; give it fetchpriority="high" instead.
• Cut server response time with full-page caching or static generation.
• Self-host critical fonts and preload only the ones used above the fold.
• Remove render-blocking CSS and scripts from the critical path.

Interaction to Next Paint (INP)

INP measures how quickly the page responds when someone taps, clicks, or types. Poor INP almost always means too much JavaScript running on the main thread.

• Audit third-party scripts: chat widgets, tag managers, and A/B tools are frequent offenders.
• Delay non-essential scripts until after interaction or idle time.
• Break long tasks into smaller chunks so the browser can respond between them.
• Avoid heavy page builders that hydrate large component trees for static content.

Cumulative Layout Shift (CLS)

CLS measures how much the page jumps around while loading. It is the easiest metric to fix and the most annoying for users when you do not.

• Set width and height (or aspect-ratio) on every image, video, and embed.
• Reserve space for ads, cookie banners, and late-loading widgets.
• Use font-display with matched fallback metrics to avoid text reflow.
• Never insert content above existing content unless the user asked for it.

Make speed a budget, not a project

Sites rarely get slow in one release. They get slow one plugin, one tracking script, and one oversized image at a time. Set a performance budget per template, check it automatically on every deploy, and review field data monthly. That turns speed from a periodic rescue project into a standing requirement.