Le LCP (Largest Contentful Paint) mesure le temps avant l'affichage du plus gros élément visible de votre page. Sur Magento 2, c'est presque toujours la métrique Core Web Vitals la plus difficile à corriger — parce que ses causes sont empilées : serveur, rendu, images, JavaScript. Optimiser au hasard ne donne rien. Voici l'ordre dans lequel je l'attaque en audit.

1. Identifier le vrai élément LCP

Avant toute optimisation : sachez quel élément est mesuré. Sur une page produit, c'est souvent l'image principale ; sur la home, le visuel de hero ou un bloc de texte. Utilisez le panneau Performance de Chrome DevTools (section « Timings » → LCP) ou l'API PerformanceObserver. Optimiser une image qui n'est pas l'élément LCP ne déplacera pas la métrique.

2. Le TTFB : le plafond invisible

Le LCP ne peut pas être plus rapide que votre Time To First Byte. Sur Magento, le TTFB se joue sur trois leviers :

  • Full Page Cache (FPC) : vérifiez le taux de HIT. Un FPC contourné par des blocs non-cachables (mini-panier, prix dynamiques mal gérés) ruine le TTFB.
  • Varnish / Fastly : un cache HTTP en amont sert la page en quelques millisecondes. Sans lui, chaque requête repart vers PHP.
  • ESI : les blocs personnalisés (panier, « bonjour {client} ») doivent passer par ESI, pas par un contournement du cache.

Tant que le TTFB n'est pas sous contrôle, le reste est cosmétique.

3. L'image LCP

Quand l'élément LCP est une image, trois réglages comptent :

  • Format moderne : servez du WebP ou de l'AVIF, pas du JPEG non compressé.
  • Dimensions explicites : width/height (ou aspect-ratio) pour éviter le reflow — et au passage le CLS.
  • Préchargement : un <link rel="preload" as="image"> sur l'image de hero la sort de la file d'attente du navigateur.

Et surtout : ne mettez jamais l'image LCP en lazy-load. C'est l'erreur la plus fréquente — le lazy-loading générique appliqué à tout retarde précisément l'élément qu'on veut afficher en premier.

4. Le JavaScript qui bloque

Sur Luma, RequireJS charge un graphe de dépendances JS avant que la page ne soit interactive. Deux chantiers :

  • Modules tiers : chaque extension qui injecte du JS non-critique en <head> pousse le LCP. Auditez requirejs-config.js et les mixins.
  • Bundling : un bundle monolithique force le navigateur à tout télécharger. Le découpage (code splitting) ou le passage à un build moderne change la donne.

C'est précisément là que Hyvä (Alpine.js + Tailwind, sans RequireJS) fait gagner le plus : il supprime la dette JS structurelle de Luma.

5. Polices et CSS critique

  • font-display: swap pour éviter le texte invisible (FOIT) pendant le chargement des polices.
  • Préchargez la police utilisée par l'élément LCP s'il s'agit de texte.
  • Inlinez le CSS critique « above the fold » pour éviter un aller-retour bloquant.

Mesurer, toujours

Chaque correction doit être validée par une mesure avant/après, en labo (Lighthouse, WebPageTest) et en conditions réelles (RUM / CrUX). Une optimisation qui « devrait » aider mais qu'on ne mesure pas n'est pas une optimisation — c'est un pari.

C'est exactement la méthode de mon audit performance Magento : identifier le vrai goulot, le corriger, prouver le gain par les chiffres. Si votre boutique rame et que vous ne savez pas par où commencer, parlons-en.