Core Web Vitals on Magento 2: where to start

28 October 2026 · Oussama Chebbi

Core Web Vitals are three measures of your visitors’ real experience. On a Magento 2 store, they often degrade for the same reasons. Here is how to measure them without being misled, then in what order to act.

The three measures and their thresholds

Google considers that a page offers a good experience when, for 75% of visits, these thresholds are met:

  • LCP (Largest Contentful Paint): the main element of the page is displayed in 2.5 seconds or less;
  • INP (Interaction to Next Paint): the page responds to an interaction in 200 milliseconds or less;
  • CLS (Cumulative Layout Shift): the layout does not move, with a score of 0.1 or less.

Measure first, in the right place

A Lighthouse score obtained on your own computer is a lab measurement: useful for diagnosing, insufficient for judging. What matters for search ranking is field data, collected from real visitors: the Core Web Vitals report in Search Console and CrUX data.

Measure by page type, not just the home page: home page, category, product page, cart and checkout have neither the same content nor the same problems. Note the starting state of each: without a starting point, no gain can be demonstrated.

LCP: start with the server, then the image

A slow LCP almost always comes from one of these three points:

  1. A server response time that is too long. Check that page caching is active on public pages (Varnish or built-in cache), that a CDN serves the static assets, and that pages are not continuously invalidated by scheduled tasks or imports.
  2. A main image loaded too late. The above-the-fold image must not be lazy-loaded (loading="lazy"): it should be specified in the HTML, sized, in a modern format, and preloaded if necessary.
  3. Resources that block rendering. CSS and JavaScript loaded before the first paint, heavy fonts or fonts requested late.

INP: JavaScript is almost always to blame

INP degrades when the browser is busy at the moment the user clicks. On an e-commerce site, the usual culprits are third-party scripts (tag manager, chat, reviews, A/B testing tools) and long JavaScript tasks in the theme. Start by listing the third-party scripts, measuring their cost and removing those that no longer pay for themselves. Load the others later, or only on the pages where they are useful.

CLS: reserve the space before the content arrives

A layout shift appears when an element is inserted after the first paint and pushes the rest of the page down. Look for:

  • images and banners without declared dimensions;
  • fonts that change the size of the text as they load;
  • blocks filled in by the browser after the fact (mini-cart, customer account information, banners) whose space is not reserved;
  • promotional or consent banners that appear at the top of the page.

In what order to act

  1. Measure each page type, in the field and in the lab.
  2. Fix the server and the cache: this benefits every page.
  3. Deal with the main image and the blocking resources on high-traffic pages.
  4. Take an inventory of third-party scripts and remove or defer some of them.
  5. Reserve the space for elements that are inserted late.
  6. Re-measure after every release: field data takes several weeks to reflect a change, so check in the lab first.

One last piece of advice: test the effect of each setting (minification, bundling of JavaScript files, for example) rather than enabling it on principle. On some configurations, a setting meant to speed up the site slows it down.

Discover our web performance audit →

Let's see where your site is losing speed, visibility or time.

Start a free diagnostic