In short
Fix Largest Contentful Paint by optimizing the hero image and removing render-blocking resources, fix Interaction to Next Paint by reducing long JavaScript tasks, and fix Cumulative Layout Shift by reserving space for images and dynamically-injected content before it loads.
Start with real data, not lab data alone
Google Search Console's Core Web Vitals report shows real-user field data, grouped by URL pattern — start here to see which templates are actually failing for real visitors, rather than testing a single page in a lab tool and assuming it represents the whole site.
Fixing Largest Contentful Paint (LCP)
LCP measures how long until the largest visible element renders. The most common causes: an unoptimized hero image, render-blocking CSS or JavaScript delaying the page from painting, or a slow server response time. Fixes, in order of typical impact: compress and correctly size the hero image (see how to optimize images), eliminate render-blocking resources by deferring non-critical CSS/JS, and improve server response time with caching or a faster hosting tier.
Fixing Interaction to Next Paint (INP)
INP measures how responsive the page feels when a user actually interacts with it — a click, a tap, a keypress. Poor INP is usually caused by long-running JavaScript tasks blocking the main thread when an interaction happens. Fixes: break up long tasks into smaller chunks, defer non-essential JavaScript until after initial interactivity, and audit third-party scripts (ads, analytics, chat widgets) which are a very common source of unexpected main-thread blocking.
Fixing Cumulative Layout Shift (CLS)
CLS measures how much visible content jumps around during load. The most common causes: images without explicit width/height attributes, ads or embeds injected without reserved space, and web fonts that swap in with different metrics than the fallback font. Fixes: always set explicit dimensions on images and video, reserve space for ad slots and embeds before they load, and use font-display: swap alongside a fallback font with similar metrics to the custom one.
Third-party scripts deserve special attention
Analytics tags, chat widgets, ad scripts, and embedded social widgets are collectively one of the most common sources of Core Web Vitals failures, because they're outside your direct control and often load more aggressively than necessary. Audit what's actually running, remove anything that isn't earning its cost, and load what remains asynchronously wherever possible.
Measuring progress
After making changes, verify improvement in both a lab tool (for quick iteration during development) and real-user field data (Search Console or your own analytics) over a few weeks — lab tools show whether a specific fix worked; field data confirms it's actually improving the experience for real visitors on real devices and connections.
A prioritized fix order
If all three metrics are failing, fix LCP first — it's usually the highest-impact and most visible to users. Then CLS, since layout shift fixes are often quick (adding dimension attributes) relative to their impact. INP fixes, which often require restructuring JavaScript execution, typically take longest but matter most for interaction-heavy pages.
Common questions
What's the most common cause of poor Core Web Vitals?
An unoptimized hero image is the single most common LCP problem; missing image dimensions are the most common CLS problem; and heavy or poorly-timed third-party scripts are a leading cause of poor INP.
Should I fix Core Web Vitals based on lab data or field data?
Use field data (Search Console, real-user monitoring) to prioritize which pages and metrics actually need fixing, and lab tools to quickly verify a specific fix worked during development.
Do third-party scripts really matter that much for Core Web Vitals?
Yes — ads, chat widgets, and analytics tags are collectively one of the most common causes of poor INP and CLS, since they're often loaded aggressively and outside your direct control.