What Are Core Web Vitals?
They focus on speed, interactivity, and visual stability, which all have a major impact on user experience.
As of 2026, these metrics include:
Largest Contentful Paint (LCP) – this refers to how quickly the main content on the page loads. Google deems under 2.5 seconds ‘good’.
Interaction to Next Paint (INP) – how fast the page responds to user actions like clicks or taps. This replaced an older metric, known as First Input Delay (FID). ‘Good’ is below 200 milliseconds.
Cumulative Layout Shift (CLS) – this measures the stability of the layout as it loads. You need to stay under 0.1s to achieve a ‘good’ standard.
Why Do Core Web Vitals Matter?
Core Web Vitals are still vital in the age of LLMs, because the metrics relate to the user experience i.e. what people visiting your ecommerce website actually observe as they load, scroll, click and navigate around your pages.
Well-performing core web vitals, then, mean that your site visitor is going to have a better experience. Not only that, but it also helps from an SEO perspective - CWV are a Google Page Experience Signal, which means Google takes them into account when assessing page ranking, to determine what to show to users in search results. While they do not outweigh high-quality content, they act as a ‘tie-breaker’ for ranking pages of similar relevance, and directly boost SEO by minimising bounce rates and improving crawl efficiency.
So in summary, striving to achieve a good score across your Core Web Vitals metrics will help your Shopify store rank better, while ensuring that your visitors have a better experience - both of which ultimately contribute to helping improve conversion and sales on your Shopify store.
How To Measure Core Web Vitals
You can find the Core Web Vitals report in Search Console. It shows you how your pages perform, based on real world usage data - also known as field data. The report gathers anonymised metrics about performance times from actual users visiting your website.
The Core Web Vitals report shows URL performance grouped by status (‘Poor’, ‘Need improvement’, ‘Good’), metric type (the 3 outlined above: CLS, INP, and LCP), and URL group (groups of similar web pages).
Once a URL group has a threshold amount of data for both LCP and CLS, the URL group's status is its most poorly performing metric. So, for example, if a URL group has poor CLS but good INP, the URL status is ‘poor.’
If a URL group does not have a minimum amount of reporting data for both LCP and CLS, the URL is omitted from the report.
Only indexed URLs can appear in this report. The other thing to bear in mind is that the report isn't a comprehensive list of all indexed URLs. It shows a sample of pages to help you assess your site's performance based on Core Web Vitals, so you won’t see the status of a specific URL, but rather your site’s performance as a whole.
Remember that data is combined for all requests from all locations. If you have a substantial amount of traffic from a country with slow internet connections, for example, then your performance in general will go down. (You can break down your performance by country using BigQuery if you suspect this might be a cause for low performance.)
The report shows a table of URLs that have ‘Poor’ or ‘Need improvement’ issues, and another table of URLs with all ‘Good’ scores for LCP, INP, and CLS.
How To Improve Core Web Vitals
Improve Largest Contentful Paint
Prioritise LCP resource and make discoverable from the HTML source
This metric refers to how quickly the main content on the page loads, and therefore a typical problem is images on the page, with the loading of them taking enough time to impact the experience - and the score.
If you ensure the image is discoverable from the HTML source and prioritised, this will help.
Take advantage of the ‘fetchpriority’ HTML attribute. This gives higher priority to the resources, which could improve the page’s LCP with minimum effort.
(If the problem is the resource load delay, it may be too late to improve the LCP if a page needs to wait for CSS or Javascript to load before images can start loading.)
Load the image using an <img> element with the src or srcset attribute. Don’tt use non-standard attributes like data-src. This requires JavaScript in order to render, and is slower.
Use server-side rendering (SSR) instead of client-side (CSR). With SSR, your server generates fully formed HTML and sends it straight to the browser, meaning users see content instantly.
If your image needs to be referenced from an external CSS or Javascript file, you can still include it in the HTML source using a <link rel="preload"> tag.
While lazy loading improves performance in many cases, it can negatively impact LCP when applied incorrectly. The LCP element (often the hero image or main product image) should not be delayed, as this would slow down the user’s perceived page speed.
To optimize for LCP, images that are likely to be the largest visible content should not use lazy loading. Instead, they should be explicitly set to eager loading to ensure they load as soon as possible.
Allow for ‘instant navigation’
Instant navigations try to load and render the page before the user starts to navigate there. This way, the prerendered page can be displayed immediately with a very low LCP. When a user navigates back or forward to a previously visited page, it can be quickly restored from an in-memory cache, appearing exactly as the user left it.
As well as caching, you can also preemptively load the next page the user will visit through speculations. Using analytics, you can see the next page the user is likely to visit and prerender that page so it loads instantly when they arrive there. You need a fairly high degree of confidence about the user journey though, as prerendering the wrong page wastes resources and can damage performance.
Use a CDN to optimise TTFB
Using a CDN (content delivery network) improves LCP by reducing the Time to First Byte (TTFB). Because TTFB starts the clock for all page rendering, minimizing it via edge caching and reduced network distance buys the browser extra time to discover, download, and render your site's largest visual element.
Improve Interaction to Next Paint
This refers to how fast the page responds to user actions like clicks or taps. Some ways to improve the performance here are:
Remove unused JavaScript and break long tasks into smaller chunks
This includes comments, whitespaces, line breaks, and other unnecessary elements. The reason for minification is to reduce your JavaScript file size so the browser can execute tasks faster. The smaller the file size, the faster the download and the faster your website loads.
Defer or async non-critical scripts
Deferring or using async attributes on non-critical scripts prevents them from blocking the main thread while HTML is parsed and the initial page is rendering. By letting the browser process JavaScript in the background or after page load, you keep the main thread free, directly lowering INP (Interaction to Next Paint)
Optimise event handlers: debounce inputs and streamline click actions
Optimising event handlers directly improves Interaction to Next Paint by reducing processing duration and presentation delays. By stopping the main thread from being flooded with rapid, overlapping calculations, the browser can execute essential event callbacks immediately and paint visual updates.
Reduce layout thrashing and excessive DOM updates
Write your JavaScript in such a way that the number of times the page has to be reflowed is minimised.
Improve Cumulative Layout Shift
You know when you open a website and 3 seconds later, the content is still jumping around and shifting as new elements load? That annoying situation is what this metric refers to.
Make sure you utilise bfcache
This is the technique we referenced in the ‘instant navigation’ section above, about improving LCP. It’s where you’re able to preload a page a visitor has already been to on their return, or pre-emptively load one that you predict they’ll go to next. This also helps minimise the layout shift.
In order to do this you need to make sure your pages are eligible for bfcache. You can use Chrome DevTools to check and fix this.
Avoid animations that require the browser to update the page layout
Some animations on web pages can be handled completely in the compositor stage of the rendering pipeline.
Non-composited animations require more work and can appear to be jerky on low-end phones or when performance-heavy tasks are running on the main thread.
Non-composited animations can also increase the Cumulative Layout Shift (CLS) of your page as they result in actual movement of elements that the CLS algorithm measures, which may cause knock-on shifts to other elements. Composited animations won't result in other elements shifting and so are excluded from CLS.
Set sizes on content loaded from the page
Setting rules around sizes for content on pages helps minimise CLS. Because the browser already reserved the necessary dimensions for the content, it seamlessly paints the loaded elements inside the allocated area without disrupting the rest of the page layout.
Explicitly stating width and height properties in image and video tags so the browser can calculate the aspect ratio.
Employing the CSS aspect-ratio property to automatically calculate the correct height even when the width is responsive
Setting a min-height on third-party widgets and ad units so the page reserves space even if a specific ad takes longer to load.
Monitoring Core Web Vitals
When you've fixed a specific issue in all of your URLs, you can confirm whether you fixed the issue for all URLs. Click ‘Start Tracking’ to start a 28-day monitoring session to check for instances of this issue in your site. If this issue is not present in any URLs on your site during the 28-day window, the issue is considered fixed. The presence of that issue in any URL is enough to mark the issue as not fixed; however the status of individual URLs continue to be evaluated for the entire 28 days, regardless of issue status.
The following validation statuses are possible:
Not started: There are one or more URLs with an instance of this issue that have never been in a validation request.
Started: You have begun a validation attempt and no remaining instances of the issue have been found yet.
Looking good: You started a validation attempt, and all issue instances that have been checked so far have been fixed.
Passed: All URLs are in Passed state. You must have clicked Validate fix to get to this state (if instances disappeared without you requesting validation, state would change to N/A)
N/A: Google found that the issue was fixed on all URLs, even though you never started a validation attempt.
Failed: One or more URLs are in Failed state after a validation attempt.
How Often Should You Check Core Web Vitals?
You should check your overall score trends monthly at first, particularly if you are making changes to improve the scores. The report in Search Console updates weekly with the field data updating on a rolling 28 day window.
Once you’ve made changes and seen improvements on your Shopify store, we’d recommend keeping an eye on the report on a quarterly basis to make sure the scores remain stable.
If you make any major site changes, check the scores after you’ve deployed them to check if there’s been a negative impact, so you can take the appropriate remedial action.
Conclusion
Understanding and managing Core Web Vitals is essential for both SEO and user experience.
By understanding LCP, INP, and CLS and applying defined strategies, you can build a Shopify store that loads quickly, responds smoothly, and remains visually stable. Not only this, but it also gives your site the best chance of repeat visits and sales from visitors who are happy with your products - and the journey they need to go on to take them to the checkout.
