Core Web Vitals optimisation
Google measures three specific performance metrics on your site and uses them to influence your rankings. If your Core Web Vitals are failing, we identify exactly why and fix the root causes.
What are Core Web Vitals and why do they matter?
Core Web Vitals are a set of three metrics that Google introduced in 2020 and began using as a ranking signal in 2021. They measure real user experience on your website: how fast the main content loads, how quickly the page responds to interaction, and how stable the layout is while loading.
Unlike older speed metrics that relied purely on lab tests, Core Web Vitals are based on real user data collected from Chrome browsers visiting your site. This data is aggregated in the Chrome User Experience Report (CrUX) and visible in Google Search Console. If your real visitors are experiencing slow loads or janky interactions, Google knows about it.
Failing Core Web Vitals does not instantly tank your rankings, but it puts you at a disadvantage compared to competitors who pass them. For a deeper look at how page speed affects SEO rankings, see our blog. For competitive search terms where multiple sites offer similar content quality, page experience can be the deciding factor between page one and page two. You can check your current scores with our instant speed test.
The three Core Web Vitals metrics
Each metric measures a different aspect of user experience. Each has specific technical causes and specific fixes.
Largest Contentful Paint (LCP)
What it measures: The time it takes for the largest visible element on the page to finish rendering. This is usually a hero image, a large heading, or a prominent block of text.
Thresholds: Good = 2.5 seconds or less. Needs improvement = 2.5 to 4 seconds. Poor = over 4 seconds.
Common causes of poor LCP:
- Oversized, uncompressed hero images (the single most common cause)
- Slow server response time (high TTFB) delaying everything
- Render-blocking CSS and JavaScript in the document head
- Web fonts that block text rendering until they download
- Client-side rendering that delays content visibility
How we fix it: We identify your LCP element, optimise its loading path (compression, format, preloading, priority hints), remove or defer render-blocking resources, and reduce server response time where possible.
Interaction to Next Paint (INP)
What it measures: The time between a user interaction (click, tap, or key press) and the next visual update on screen. INP replaced First Input Delay (FID) as a Core Web Vital in March 2024 and is a stricter, more comprehensive measure of responsiveness.
Thresholds: Good = 200 milliseconds or less. Needs improvement = 200 to 500 milliseconds. Poor = over 500 milliseconds.
Common causes of poor INP:
- Heavy JavaScript execution blocking the main thread
- Long-running tasks from analytics, chat, or marketing scripts
- Excessive DOM size making style recalculations slow
- Event handlers that trigger synchronous layout work
- Unoptimised third-party scripts competing for processing time
How we fix it: We identify which scripts are blocking the main thread, break up long tasks, defer non-critical JavaScript, reduce DOM complexity where possible, and optimise event handlers for faster visual feedback.
Cumulative Layout Shift (CLS)
What it measures: How much the visible content shifts around while the page loads and during the user's session. If text jumps, buttons move, or images push content down unexpectedly, that counts as layout shift.
Thresholds: Good = 0.1 or less. Needs improvement = 0.1 to 0.25. Poor = over 0.25.
Common causes of poor CLS:
- Images and iframes without explicit width and height attributes
- Web fonts causing a flash of unstyled text (FOUT) that reflows layout
- Dynamically injected content (ads, cookie banners, pop-ups)
- Late-loading components that push content down after initial paint
- Responsive images that do not reserve their space correctly
How we fix it: We add explicit dimensions to all media elements, configure font loading to minimise layout shift, reserve space for dynamic content, and audit third-party injections that cause unexpected movement.
Lab data versus field data
One of the most common points of confusion with Core Web Vitals is the difference between lab data and field data. Google PageSpeed Insights shows both, and they often tell different stories.
Lab data is generated by running your page through a simulated environment with controlled conditions (a specific device, connection speed, and location). It is useful for diagnosing issues and testing changes but does not reflect what real users experience.
Field data comes from real Chrome users visiting your site over a 28-day period. This is what Google actually uses for ranking purposes. A site can score 95 in lab testing but fail Core Web Vitals in field data because real users are on slower devices and connections.
We use both. Lab data tells us what to fix. Field data tells us whether it worked. Our optimisation targets real-world performance, not just lab scores.
Our Core Web Vitals process
Systematic, data-driven improvement for all three metrics.
Measure your current scores
We pull your real-world Core Web Vitals data from the Chrome User Experience Report (CrUX) and combine it with lab testing from PageSpeed Insights and WebPageTest. You get both field data and lab data.
Identify root causes
Each failing metric has specific technical causes. We trace every poor score back to its source: which image, which script, which layout element is responsible. No guessing.
Fix and verify
We implement targeted fixes for each metric, test across devices, and monitor the results. CrUX data updates over a 28-day rolling window, so we track improvement over time.
Core Web Vitals across different platforms
Every platform has its own Core Web Vitals challenges. The approach to fixing them varies based on what the platform allows you to control.
- WordPress: Full control over server, code, and assets. The widest range of optimisation options. Theme and plugin choices are the primary drivers of poor scores.
- WooCommerce: WordPress plus e-commerce overhead. Product pages, cart scripts, and checkout complexity add specific LCP and INP challenges.
- Shopify: Limited server control. Optimisation focuses on theme code, apps, and script management. App bloat is the most common cause of failing INP on Shopify.
- Custom and static sites: Usually the easiest to optimise. Most issues come from unoptimised images, unminified assets, or poor hosting.
Regardless of platform, meaningful Core Web Vitals improvement is possible. Start with a free speed check and we will tell you exactly where your site stands and what it will take to get your scores into the green. For more background, read our guide on what makes a good website speed score.
Core Web Vitals questions
Core Web Vitals are three specific metrics Google uses to measure user experience on web pages. They are Largest Contentful Paint (loading speed), Interaction to Next Paint (responsiveness), and Cumulative Layout Shift (visual stability). Google uses these metrics as ranking signals.
You can check your scores in Google Search Console under the Core Web Vitals report, Google PageSpeed Insights for individual page scores, or the Chrome User Experience Report for field data. PageSpeed Insights shows both lab data and real-user field data when available.
Core Web Vitals are part of Google's page experience ranking signal. Sites that pass all three thresholds have an advantage over sites that fail them, all else being equal. It is not the biggest ranking factor, but it can be the difference between page one and page two for competitive terms.
Google considers an LCP of 2.5 seconds or less to be good. Between 2.5 and 4 seconds needs improvement. Over 4 seconds is poor. Most unoptimised sites score between 4 and 8 seconds on mobile. The most common causes are oversized images, slow servers, and render-blocking scripts.
Google considers an INP of 200 milliseconds or less to be good. Between 200 and 500 milliseconds needs improvement. Over 500 milliseconds is poor. INP measures how quickly your site responds to user interactions like clicks, taps, and key presses.
Google considers a CLS score of 0.1 or less to be good. Between 0.1 and 0.25 needs improvement. Over 0.25 is poor. CLS measures how much content shifts around while the page loads. Images without dimensions, late-loading fonts, and dynamically injected ads are common causes.
Core Web Vitals data in Google Search Console is based on a 28-day rolling average of real user data from Chrome browsers. After implementing fixes, you will typically see CrUX data improve within 4 to 6 weeks. Ranking changes based on improved page experience may take longer to materialise.
Yes. The techniques vary by platform, but Core Web Vitals can be improved on WordPress, WooCommerce, Shopify, Squarespace, and custom-built sites. Some platforms give you more control than others, but there are meaningful improvements available on all of them.
Fix your Core Web Vitals
Request a free speed check. We will measure your current scores and show you exactly what is causing failures.