Core Web Vitals went from “important signal” to “ranking factor” between 2021 and 2024. In 2026, an e-commerce site with poor Core Web Vitals loses both organic traffic (SEO) and conversion (visitors who give up because the page is slow). This guide covers the three current metrics, how to measure them, and the concrete levers to bring them into the green on PrestaShop and WooCommerce.
The 3 Core Web Vitals metrics in 2026
Google has refined its set of vitals over the years. As of 2026, three metrics matter:
- LCP (Largest Contentful Paint) — time before the largest visible element appears. Target: under 2.5 seconds. Above 4 seconds, you’re “poor”.
- CLS (Cumulative Layout Shift) — visual stability during loading. Target: under 0.1. Above 0.25, the page jumps too much.
- INP (Interaction to Next Paint) — response time to user interactions. Target: under 200 ms. INP replaced FID in March 2024.
Important note: Google measures these metrics on real users (CrUX field data), not in a lab. A simulated PageSpeed test gives you an indication, but the score that counts for SEO is the one based on the previous 28 days of real visits.
How to measure your Core Web Vitals
Three free tools to start:
PageSpeed Insights
Free Google tool at pagespeed.web.dev. Tests one page, displays both lab data and field data (real users) when available. Granular optimisation suggestions. Handy for spot-checking a specific page.
Search Console — Core Web Vitals report
In Google Search Console, the Experience > Core Web Vitals report aggregates field data on every page Google has crawled. Identifies “URL groups” with similar problems. The first place to check the actual state of your site.
Web Vitals JavaScript library
For ongoing monitoring, the web-vitals library (Google) lets you send your real users’ Core Web Vitals to Google Analytics 4. Install in 5 minutes, RUM (Real User Monitoring) data accessible in your GA4. Indispensable for a serious site.
Optimising the LCP (Largest Contentful Paint)
The LCP is almost always an image on an e-commerce site: the homepage hero, the main product photo, or the first banner of a category page. Five winning levers:
1. Convert images to WebP/AVIF
WebP shaves 25-35% off weight at equal quality, AVIF goes further (-50%). Both formats are supported by every modern browser (95%+). Use ImageMagick, Squoosh or a dedicated module to batch-convert your library.
2. Properly size images
An image displayed at 800×600px doesn’t need to weigh 2400×1800px. Generate multiple sizes via srcset and sizes attributes — the browser picks the right one automatically.
3. Lazy loading except for the LCP
Lazy loading (loading="lazy") delays loading off-screen images. Critical rule: never lazy-load the LCP image. The browser then takes too long to identify it. The first image of the homepage and the main product photo always have loading="eager" + fetchpriority="high".
4. Preload the LCP image
Add <link rel="preload" as="image" href="hero.webp" fetchpriority="high"> in the page header. The browser starts downloading it in parallel with the HTML, gain of 200-500 ms on LCP.
5. Inline critical CSS
The CSS needed to render the above-the-fold should be embedded directly in the <head>, not loaded via an external file. The remaining CSS loads asynchronously. Critical-CSS generation tools (Penthouse, Critical, dedicated PrestaShop module) automate this.
Optimising the CLS (Cumulative Layout Shift)
The CLS measures visual jumps during loading. The five most common causes:
1. Images without specified dimensions
Always include width and height attributes on your <img> tags. The browser reserves the right amount of space before the image arrives, no jump.
2. Web fonts loaded late
Web fonts (Google Fonts, Adobe Fonts) cause “FOUT” (Flash of Unstyled Text) — the page first renders with the system font, then jumps when the web font loads. Solution: font-display: swap + preload on the main font.
3. Lazy-loaded ads
Ad placements that appear after page render push existing content. Reserve space upfront with a fixed-height container.
4. Cookie banners that push content
An anti-pattern: a cookie banner that lands at the top of the page after 500 ms and pushes everything down. Either it appears at position: fixed overlay, or it’s reserved at the start of the page.
5. Buttons that change size
“Add to cart” buttons that change size when their text loads (translation, dynamic price) cause CLS. Reserve a fixed minimum size with min-width and min-height.
Optimising the INP (Interaction to Next Paint)
The INP measures how quickly your site responds to a click, tap or keypress. Most common causes of poor INP:
1. Heavy or unoptimised JavaScript
JavaScript that blocks the main thread for more than 50 ms degrades the INP. Solution: split your JS into smaller chunks, defer non-critical loading, use async and defer.
2. Third-party scripts
Google Analytics, Facebook Pixel, chat widgets, A/B testing tools — each script costs INP. Defer them with Tag Manager and load only on user interaction when possible.
3. Heavy DOM
A page with 3000+ DOM elements struggles to react quickly. Reduce nesting, use virtualisation for long lists (search results, large catalogues).
PrestaShop-specific optimisations
PrestaShop has known weaknesses on Core Web Vitals: heavy default theme, jQuery used everywhere, sometimes badly cached. Concrete actions:
- Enable Smarty cache and CCC (Combine, Compress, Cache) in Advanced Parameters → Performance
- Switch to a modern theme (Hummingbird, Warehouse, Wojo) which has been Core-Web-Vitals optimised
- Install a critical CSS generator — see our Administration & Productivity category
- Convert all images to WebP via dedicated module
- Activate OPcache and Redis on your server
WordPress / WooCommerce-specific optimisations
WooCommerce shares the same issues amplified by jQuery dependency. Best practices:
- Install a serious cache plugin: WP Rocket, LiteSpeed Cache or W3 Total Cache
- WebP/AVIF conversion plugin — see our Media & Image Optimisation category
- Image CDN (Cloudflare R2, Bunny CDN, KeyCDN)
- Disable unused plugins (each plugin = JS/CSS loaded)
- Move to a “modern” theme based on Gutenberg blocks rather than a heavy page builder
Common mistakes to avoid
- Optimising for the lab score, not the field score. PageSpeed at 95 in a simulator means nothing if real users on slow 4G are getting 50.
- Forgetting mobile. Google’s Core Web Vitals primarily look at the mobile score, not desktop.
- Sacrificing visual quality. Compressing your images to 30% WebP quality saves bytes but kills the experience.
- Stacking optimisation plugins. Three caching plugins active at once = chaos. One serious plugin, well configured.
Going further
Core Web Vitals optimisation is iterative work. Browse our Performance and Core Web Vitals category for monthly deep dives. For dedicated modules covering critical CSS, image conversion, and global performance optimisation, see our PrestaShop Administration & Productivity and WordPress SEO & Performance categories.