What are Core Web Vitals and why should you care?
Core Web Vitals are a set of three specific metrics that Google uses to measure how real people experience your website. They are not theoretical scores or abstract numbers. They represent actual user experiences collected from Chrome browsers around the world.
The three metrics measure three distinct things: how quickly the main content loads (LCP), how stable the page is while it loads (CLS), and how responsive the page is when someone interacts with it (INP). Together, they paint a picture of whether your website feels fast, stable, and responsive, or slow, jumpy, and frustrating.
Here is why this matters for your business. Google has explicitly stated that Core Web Vitals are a ranking signal. If your website fails these metrics, you are at a disadvantage in search results compared to competitors who pass. We have worked with clients who saw measurable ranking improvements within 6 to 8 weeks of fixing their Core Web Vitals, particularly on competitive commercial keywords where multiple sites had similar content quality.
Beyond rankings, poor Core Web Vitals directly affect your conversion rate. Research from Google shows that as page load time increases from 1 second to 3 seconds, the probability of a visitor bouncing increases by 32%. At 5 seconds, that jumps to 90%. We have seen this play out on client sites. One ecommerce client saw a 23% increase in enquiry form completions after we reduced their LCP from 4.8 seconds to 1.9 seconds.
The good news is that Core Web Vitals are fixable. They are not arbitrary or mysterious. Each metric has specific causes and specific solutions. This guide will explain exactly what each metric measures, what causes poor scores, and what you can do about it.
LCP: Largest contentful paint explained
Largest Contentful Paint measures how long it takes for the biggest visible element on your page to finish loading. This is usually a hero image, a large heading, or a banner. It is the metric that most closely represents how quickly your page appears "ready" to a visitor.
What counts as "good":
- Good: Under 2.5 seconds
- Needs improvement: 2.5 to 4 seconds
- Poor: Over 4 seconds
LCP is the metric we see failing most often on business websites. The typical culprits are large, unoptimised images and slow server response times. In our experience working on website design projects, we find that roughly 70% of LCP failures are caused by one of five issues.
The five most common causes of poor LCP
1. Unoptimised hero images. This is the single most common issue. A 3MB PNG hero image that could be a 150KB WebP is the difference between a 1.5 second LCP and a 5 second one. We audit every image on every site we build, and we typically reduce total image weight by 60% to 80% without any visible quality loss.
2. Slow server response time (TTFB). If your server takes 2 seconds just to start sending the page, your LCP cannot possibly be under 2.5 seconds. This is a hosting problem. Cheap shared hosting often has TTFB over 1 second. A good managed hosting setup should deliver a TTFB under 200 milliseconds.
3. Render-blocking JavaScript and CSS. When the browser encounters a JavaScript or CSS file in the head of your document, it stops rendering the page until that file has downloaded and processed. If you have 15 plugin scripts loading before your content, your LCP will suffer. The fix involves deferring non-critical scripts and inlining critical CSS.
4. Web font loading delays. If your heading uses a custom font that takes time to download, the browser may show invisible text (FOIT) or a fallback font that then swaps (FOUT). Both delay the moment when your LCP element is considered "painted". Preloading your primary font file solves this.
5. No caching strategy. Without proper browser caching and server-side caching, every page visit requires a full round trip to the server. A returning visitor should see your page almost instantly from cached resources. We configure multi-layer caching on all our managed hosting plans specifically to address this.
How to fix LCP: A practical approach
Start with the biggest impact items first. Convert all images to WebP format and set appropriate dimensions. Implement lazy loading for images below the fold, but make sure your hero image is NOT lazy loaded, as that will make LCP worse. Check your hosting and upgrade if your TTFB is consistently above 400 milliseconds. Then address render-blocking resources by deferring non-critical scripts.
CLS: Cumulative layout shift explained
Cumulative Layout Shift measures how much elements on your page move around unexpectedly while the page loads. If you have ever tried to click a button and the page suddenly shifted, causing you to click something else, that is exactly what CLS captures.
What counts as "good":
- Good: Under 0.1
- Needs improvement: 0.1 to 0.25
- Poor: Over 0.25
CLS is measured as a score rather than a time. The score reflects how much content shifts and how far it moves. A CLS of 0 means nothing shifted at all. A CLS of 0.5 means half the viewport's worth of content moved unexpectedly.
What causes layout shift
Images without dimensions. This is the most common cause we encounter. When an image tag does not have width and height attributes, the browser does not know how much space to reserve. The page renders, the image loads, and everything below it gets pushed down. The fix is simple: always include width and height attributes on every image element.
Fonts loading and swapping. When a web font loads and replaces a fallback font, the text often takes up a different amount of space, causing elements below to shift. Using font-display: swap combined with matching your fallback font metrics to your web font minimises this.
Dynamically injected content. Cookie consent banners, newsletter popups, and ad units that load after the initial page render push content around. If you must use these elements, reserve space for them in your CSS or load them in a way that overlays content rather than displacing it.
Embeds and iframes without reserved space. YouTube embeds, Google Maps, and social media widgets have a specific aspect ratio. If you embed them without setting explicit dimensions, the page will shift when they load. Use CSS aspect-ratio or padding-based containers to reserve the correct amount of space.
How to fix CLS: Step by step
Run PageSpeed Insights on your page and look for the "Avoid large layout shifts" section. It will highlight exactly which elements are causing the shifts. In our experience, fixing CLS usually takes less time than fixing LCP because the solutions are more straightforward. Add dimensions to images, reserve space for dynamic content, and handle font loading properly. Most sites can go from a failing CLS score to a perfect one in a single development sprint.
INP: Interaction to next paint, the newest metric
Interaction to Next Paint replaced First Input Delay (FID) in March 2024 as the official Core Web Vital for responsiveness. While FID only measured the delay before the browser could start processing your first interaction, INP measures the full latency of every interaction throughout the entire page visit, then reports the worst one (roughly).
What counts as "good":
- Good: Under 200 milliseconds
- Needs improvement: 200 to 500 milliseconds
- Poor: Over 500 milliseconds
INP is a more demanding metric than FID was. Many sites that passed FID comfortably are failing INP. This is because FID only looked at the first click, while INP evaluates clicks, taps, and keyboard interactions throughout the entire session. If your site has a heavy JavaScript framework or complex interactive elements, INP is where you are most likely to see problems.
Why INP fails and what to do about it
Heavy JavaScript execution. When a user clicks a button, the browser needs to run the associated JavaScript and then update the display. If the main thread is busy processing a large script bundle, the user's click has to wait. This is the primary cause of poor INP scores. The solution is to break up long JavaScript tasks into smaller chunks, defer non-essential scripts, and remove unused code.
Third-party scripts. Analytics tools, chat widgets, marketing pixels, and social media embeds all compete for main thread time. We regularly audit client sites and find 15 to 20 third-party scripts loading on every page. Each one adds to the processing burden. Audit your scripts and remove anything that is not providing genuine value.
Complex DOM structures. Pages with thousands of DOM elements take longer to update after an interaction. If your page has deeply nested elements or unnecessarily complex markup, simplifying the structure can improve INP. We aim for under 1,500 DOM elements on most business pages.
For most business websites, the practical fix for INP is to reduce the amount of JavaScript running on the page. Remove plugins you are not using, defer scripts that are not needed immediately, and consider whether you genuinely need that chat widget on every single page.
How to check your Core Web Vitals scores
There are two types of Core Web Vitals data: lab data and field data. Understanding the difference is important because they can tell you very different things.
Field data (real-user metrics) comes from the Chrome User Experience Report (CrUX). This is what Google actually uses for rankings. It reflects how real visitors experience your site over a 28-day rolling window. You can see field data in:
- Google Search Console: The Core Web Vitals report shows which pages pass or fail based on real-user data. This should be your primary monitoring tool.
- PageSpeed Insights: Enter any URL and the "Field Data" section at the top shows CrUX data if available. Not all pages have enough traffic to generate field data.
Lab data (simulated metrics) is generated by tools running tests in controlled conditions. It is useful for diagnosing issues but does not represent real-user experience. Lab tools include:
- Google Lighthouse: Built into Chrome DevTools. Press F12, go to the Lighthouse tab, and run an audit.
- PageSpeed Insights: The "Lab Data" section below the field data.
- WebPageTest: More advanced tool that lets you test from different locations and connection speeds.
We recommend checking Search Console weekly for the overall picture and using PageSpeed Insights for diagnosing specific pages. If you are on one of our website maintenance plans, we monitor your Core Web Vitals automatically and flag any regressions before they affect your rankings.
Understanding your results
When you run a PageSpeed Insights test, focus on the field data first. If your field data shows green for all three metrics, you are in good shape regardless of what the lab score says. The performance score out of 100 is a lab metric and can vary significantly between tests. Do not obsess over getting a perfect 100. Focus on passing the three Core Web Vitals in field data.
If your page does not have field data (common for low-traffic pages), the lab data is your best proxy. Aim for green across all three metrics in the lab, knowing that real-world performance may be slightly different depending on your visitors' devices and connection speeds.
What to do if your scores are poor
If your Core Web Vitals scores are in the red, do not panic, but do take action. Here is a prioritised approach based on what we have found makes the biggest difference across hundreds of client sites.
Priority 1: Quick wins (1 to 3 days)
Optimise images. Convert to WebP, resize to the actual display dimensions, and compress. This alone often moves LCP from red to green. Use a tool like ShortPixel or Imagify if you are on WordPress.
Add image dimensions. Go through your templates and make sure every img tag has width and height attributes. This is the fastest way to fix CLS.
Enable caching. If you do not have browser caching and server-side caching configured, set it up. On WordPress, a plugin like WP Super Cache or W3 Total Cache handles the basics. On our managed hosting, this is pre-configured.
Priority 2: Medium effort (1 to 2 weeks)
Audit and defer JavaScript. Review every script loading on your page. Remove anything unnecessary. Defer the rest so it loads after the main content. This improves both LCP and INP.
Upgrade hosting. If your TTFB is consistently above 400 milliseconds, your hosting is holding you back. Moving from shared hosting to a managed solution typically reduces TTFB by 50% to 70%.
Preload critical resources. Preload your hero image and primary font file so the browser fetches them immediately rather than discovering them partway through the page load.
Priority 3: Deeper fixes (2 to 4 weeks)
Inline critical CSS. Extract the CSS needed to render above-the-fold content and inline it in the HTML. Load the rest asynchronously. This eliminates render-blocking CSS as an LCP bottleneck.
Implement a CDN. A Content Delivery Network serves your static assets from servers geographically close to your visitors, reducing latency.
Refactor JavaScript. If your INP is poor due to heavy framework code, you may need to refactor how your interactive elements work. This could mean switching from a heavy framework to lighter alternatives, or breaking up long tasks with techniques like requestIdleCallback.
When to get professional help
If your scores are borderline (amber), you can likely fix them yourself with the quick wins above. If they are in the red across multiple metrics, or if you have tried the basics and nothing has improved, it is worth getting professional help. The root cause might be in your theme code, your hosting architecture, or a combination of factors that require technical diagnosis.
We offer website design and performance optimisation services specifically focused on achieving and maintaining good Core Web Vitals. Every site we build is tested against these metrics before launch, and we include ongoing monitoring with our maintenance plans.
Core Web Vitals and mobile vs desktop
Google assesses Core Web Vitals separately for mobile and desktop. With mobile-first indexing, the mobile scores are what matter most for search rankings. This is important because mobile scores are almost always worse than desktop scores for the same page.
Mobile devices have less processing power, less memory, and often slower connections. A page that loads in 1.5 seconds on your office computer might take 4 seconds on a mid-range Android phone on a 4G connection. When optimising, always test on mobile first and use Chrome DevTools throttling to simulate real mobile conditions.
We have seen clients who were ecstatic about their desktop Lighthouse score of 95, only to discover their mobile score was 38. The mobile score is the one that counts. Make it your primary target.
The ongoing nature of performance
Core Web Vitals are not a fix-once-and-forget situation. Every time you add a new plugin, upload an unoptimised image, or embed a third-party widget, you risk degrading your scores. We have seen sites go from all green to all red in a single month after a developer added a heavy JavaScript library or a content editor uploaded a batch of uncompressed images.
This is why ongoing website maintenance matters. Performance monitoring should be part of your regular website management, not a one-off project. Set up alerts in Search Console so you are notified if any pages start failing, and check your PageSpeed scores after any significant content or code changes.