Six common Core Web Vitals improvements are: prioritise the actual LCP resource, reserve image dimensions, serve right-sized modern images, reduce non-critical JavaScript, configure font loading deliberately, and trim render-blocking CSS. Measure before and after using both lab diagnostics and real-user field data; the useful fix order and result vary by page.
Why CWV matters (and how much)
Core Web Vitals describe loading, visual stability, and interaction responsiveness. They are useful page-experience measures, but they do not operate as a standalone ranking guarantee. Improving them can make the site less frustrating; measure the effect on the actual audience and conversion journey.
The three metrics in plain English
- LCP (Largest Contentful Paint) — how long until the biggest above-the-fold element (usually a hero image or headline) renders. Target: < 2.5s.
- CLS (Cumulative Layout Shift) — how much the page jumps around as it loads. Target: < 0.1.
- INP (Interaction to Next Paint) — how long until the page responds when you click or tap. Target: < 200ms.
Fix 1: preload the hero image
Use performance tooling to identify the actual LCP element. If an above-fold image is the LCP resource and is discovered late, a correctly configured preload or high fetch priority may help. Do not preload every image; unnecessary preloads compete for bandwidth.
Fix 2: explicit width/height on every image
Specify correct intrinsic width and height values, or an equivalent aspect ratio, so the browser can reserve space before an image loads. Combine this with responsive CSS such as max-width: 100%; height: auto; and remeasure remaining layout shifts.
Fix 3: modern image formats, right size
Serve images close to their rendered dimensions and compare modern formats such as WebP or AVIF against the source at an acceptable visual quality. Lazy-load below-fold images, but avoid lazy-loading the LCP image. Verify MIME types and fallbacks in the deployment environment.
Fix 4: defer non-critical JavaScript
Defer, asynchronously load, delay until consent or interaction, or remove scripts that are not needed for the initial journey. Use a performance trace to find long tasks and third-party code that blocks the main thread before choosing a fix.
Fix 5: font loading
Limit font families and weights, configure font-display, and preload only critical self-hosted fonts that are used immediately. Choose compatible fallbacks to reduce layout movement, then test the loading and visual trade-offs on slower connections.
Fix 6: remove render-blocking CSS
Remove unused rules, keep critical styles small, and consider route-level splitting or carefully inlined critical CSS when measurement shows stylesheet delivery is the bottleneck. Preserve a reliable fallback and avoid introducing flashes of unstyled content.
Measure the result
Record a baseline and compare the same route, device class, network conditions, and content after each meaningful change:
- LCP: identify the element and resource discovery path
- CLS: identify the elements that move and the trigger
- INP: identify the interaction and long tasks involved
Use lab tools for diagnosis and field data for real-user assessment. Keep performance results separate from ranking claims: search visibility depends on many other factors.
What NOT to bother with
Do not optimise a checklist blindly. Prioritise the bottlenecks shown by traces and field data, verify that each change improves the real journey, and avoid trading accessibility or reliability for a small lab-score gain.