Website speed and Core Web Vitals: what matters for selling

Why speed is paid for in sales

On Google France, “Core Web Vitals” is searched 1,000 times a month, “temps de chargement” (loading time) 210 times, “vitesse site internet” (website speed) 170 times. The question behind these searches is always the same: is my site losing customers because it is slow?

A study commissioned by Google from Deloitte in 2020 (“Milliseconds Make Millions”, 37 brands across Europe and the US, not peer reviewed) observed on retail sites a rise of 8.4% in conversions and 9.2% in average order value for every tenth of a second gained on mobile. Take these figures for what they are: a correlation measured by an interested party. The direction, however, is not in doubt.

Mobile is where it is decided: on our own selling sites, 61% of measured visits happen on a phone, often on 4G, with one thumb and little patience.

The three Core Web Vitals, in plain English

Google measures three signals on real visitors (Chrome data), and considers a page good when the 75th percentile of its page loads passes the threshold.

1. 1
   LCP (Largest Contentful Paint): the time to display the largest visible element, often the product photo or the heading. Good threshold: 2.5 s.
2. 2
   INP (Interaction to Next Paint): the delay between a gesture (tapping a button, opening a menu, choosing a size) and the response on screen. Good threshold: 200 ms.
3. 3
   CLS (Cumulative Layout Shift): elements moving during loading, the kind that makes you tap the wrong button. Good threshold: 0.1 or less.

Measure without fooling yourself

There are two kinds of measurement, and mixing them up wastes time.

• Field data: what your real visitors experience, over 28 days. It appears in the Core Web Vitals report of Google Search Console and at the top of PageSpeed Insights when the site has enough traffic. This is the data Google uses.
• Lab data: a simulated test, run when you launch it (the score out of 100 in PageSpeed Insights, Lighthouse). Useful to find causes, misleading to judge: a lab score of 60 can hide green field data, and vice versa.
• Test from a realistic network and device: a mid-range phone on 4G, not the office computer on fibre.
• Measure the pages that sell (product page, service page, checkout), not just the home page.

Fix first: images

In a shop, the product photo is almost always the LCP element, and often the heaviest on the page. The WebP format saves weight with no visible loss: according to Google, a lossy WebP image is 25 to 34% smaller than a JPEG of comparable quality, and a lossless WebP image 26% smaller than a PNG.

1. 1
   The right format: WebP (or AVIF) for photos, SVG for logos and icons.
2. 2
   The right size: an image displayed 600 pixels wide does not need to be 4,000. Serve several sizes with srcset and let the browser choose.
3. 3
   Declared dimensions: width and height on every image, so the page reserves the space and does not shift (CLS).
4. 4
   Lazy loading for images below the fold (loading=“lazy”), never for the main image at the top of the page, which on the contrary must get priority (fetchpriority=“high”).

Next: scripts and plugins

After images, third-party scripts are what slows a site down: chat widgets, pop-ups, carousels, advertising pixels, theme plugins stacked up over the years. Each one adds code to download and run, and mostly degrades INP.

1. 1
   Take stock: list every third-party script and what it brings in. A tool nobody looks at gets removed.
2. 2
   Defer: load everything not needed for the purchase (chat, videos, review widgets) after the page has displayed.
3. 3
   Lighten the theme: a theme that loads a slider, three fonts and an animation library on every page weighs on the whole site.
4. 4
   Fonts: two families at most, in WOFF2, with font-display: swap.
5. 5
   Cache and CDN: static files cached for a long time, served from a network close to the visitor.

The buying journey, where every second costs

Home page speed gets measured everywhere; the speed of the buying journey is often forgotten. Yet that is where the decided buyer waits: adding to cart, opening the cart, the payment page. A button that takes a second to respond creates doubt, and a buyer in doubt taps twice or leaves.

Three reflexes. The buy button responds at once, even if processing takes a moment (a visible “in progress” state). Payment goes through a page hosted by the payment provider, fast and already familiar to buyers, rather than a home-made form loaded with scripts. And nothing gets in the way: no newsletter pop-up between the cart and the payment.

The plan in one week

1. 1
   Day 1: read the Core Web Vitals report in Google Search Console, mobile first, and list the URL groups in orange or red.
2. 2
   Day 2: run three typical pages (home, product or service page, checkout) through PageSpeed Insights and note the LCP element of each.
3. 3
   Day 3: convert and resize the images of these templates, declare their dimensions.
4. 4
   Day 4: remove or defer the unnecessary third-party scripts.
5. 5
   Day 5: retest in the lab, then wait for the field data to update (it covers 28 days) before judging.