Core Web Vitals: what they are and how to fix them - Zephyra Studio

Core Web Vitals are three measurable metrics Google uses to judge how good your site's experience actually is: LCP (how fast the main content appears), CLS (how much the layout shifts while loading) and INP (how fast the site responds to a click or tap). A poor score does not automatically tank rankings, but it is one factor, and it directly affects whether a visitor stays or leaves within three seconds. Here is what each metric actually measures, typical causes of a poor score, and what genuinely fixes each one.

LCP (Largest Contentful Paint): how fast the main content appears

LCP measures the time from a visitor clicking a link to the moment the largest visible element on screen (usually a large image or heading) has fully loaded. Google considers a result under 2.5 seconds "good". Anything over 4 seconds is treated as poor.

The most common causes: unoptimised images (large full-resolution photos instead of compressed WebP/AVIF versions), a slow server (hosting that responds slowly to the first request), and render-blocking resources (CSS/JavaScript files that must fully load before the browser starts painting the page).

• Compress and convert images to WebP or AVIF, and lazy-load anything except the most important image above the fold
• Use a CDN (content delivery network) so content is served from a server physically closer to the visitor
• Remove or defer JavaScript that is not necessary for the first render of the page
• Check your hosting - cheap shared hosting with a slow server response is a common, hard-to-spot cause of poor LCP

CLS (Cumulative Layout Shift): how much the layout shifts

CLS measures how much elements on the page unexpectedly move while loading, the classic example being when you try to tap a button and right at that moment an ad or image pops in above it, so you tap the wrong thing. Google considers a result under 0.1 "good".

The most common cause: images and video without a predefined width and height, so the browser does not know how much space to reserve until the file has fully loaded. The same applies to ads, embeds, and fonts that load late and change text size.

• Always set width and height (or aspect-ratio) on every image and video element
• Reserve space for ads and embeds in advance, do not let them "pop in" after loading
• Use font-display: optional or swap carefully, and preload key fonts to avoid a text "jump"
• Avoid inserting new content above existing content except as a direct response to a user action

INP (Interaction to Next Paint): how fast the site responds

INP measures the time from a click or tap to the moment the browser visually responds to that action. It replaced the older FID (First Input Delay) metric in 2024 because it measures responsiveness across the ENTIRE visit, not just the first interaction. Google considers a result under 200 milliseconds "good".

The most common cause: too much JavaScript executing on the main thread, blocking the browser from responding to user actions until it finishes its work. Third-party scripts (chat widgets, analytics, ads) are a common, often overlooked culprit.

• Split large JavaScript bundles into smaller chunks (code splitting) so not everything executes at once
• Defer loading third-party scripts (chat, analytics) until the page becomes interactive
• Avoid heavy operations (complex calculations, large DOM manipulations) directly in response to a click - defer them if they can wait

How to check your score

Google PageSpeed Insights (a free, publicly available tool) gives both lab data (simulated testing) and, if the site has enough traffic, real-world data from actual visitors (Chrome UX Report). Real-world data is more reliable since a lab test measures one simulated condition, while real visitors have varying devices and connections.

Search Console also has a Core Web Vitals report that groups pages by type and shows which groups have an issue, which is more useful than checking one page at a time when a site has hundreds or thousands of pages of the same type.

Source

Key takeaways

• LCP (main content load speed) is most often fixed by compressed images, a CDN, and removing unnecessary JavaScript.
• CLS (layout shift) is almost always solved by setting width/height on images and reserving space for ads/embeds.
• INP (click responsiveness) needs less JavaScript work on the main thread, especially from third-party scripts.
• Google PageSpeed Insights and Search Console's Core Web Vitals report are free, sufficient tools to check with.
• Real visitor data (when available) is more reliable than a simulated lab test.

Conclusion

Core Web Vitals are not a one-time fix - a new feature or third-party script can quietly worsen the score months after the first optimisation. If you have checked your site and the score is poor but you are not sure where to start fixing it, our redesign ROI calculator can show you a conservative estimate of what a faster site could realistically be worth, before you invest in a technical redesign.