Core Web Vitals PrestaShop 9 : corriger LCP, INP et CLS
PrestaShop

Core Web Vitals PrestaShop 9 : corriger LCP, INP et CLS

Core Web Vitals sur PrestaShop 8 et 9 : ce que font Hummingbird et Classic, réglages Performances et Images, modules lents. Méthode testable.

Mis à jour le 1er novembre 2026. Article réécrit à partir du code de PrestaShop 9.2 : comportement des thèmes Hummingbird et Classic, réglages de Paramètres avancés > Performances, régénération des miniatures en ligne de commande, menu des images corrigé (Apparence > Images).

Les Core Web Vitals mesurent le temps d’affichage du contenu principal (LCP), la réactivité aux interactions (INP) et la stabilité visuelle (CLS). Cet article traite ce qui est propre à PrestaShop : ce que le thème fait déjà, ce qu’il ne fait pas, et les réglages du back-office qui comptent.

Pour la méthode d’outillage (PageSpeed Insights, DevTools, TTFB, requêtes MySQL lentes), voir diagnostiquer un site lent. Pour la même démarche sur WordPress, voir Core Web Vitals WordPress.

Seuils et données à utiliser

Google évalue chaque indicateur au 75e percentile des visites, séparément sur mobile et sur desktop.

IndicateurBonÀ améliorerMauvais
LCP≤ 2,5 s2,5 s à 4 s> 4 s
INP≤ 200 ms200 ms à 500 ms> 500 ms
CLS≤ 0,10,1 à 0,25> 0,25

L’INP a remplacé le FID le 12 mars 2024. Dans la Search Console, le rapport « Signaux Web essentiels » regroupe les URL par modèle : accueil, catégorie, fiche produit, panier, tunnel de commande. Une correction dans un gabarit touche toutes les pages de ce type.

Les données terrain portent sur 28 jours glissants. Une fiche peu visitée n’a souvent pas de données propres : PageSpeed Insights affiche alors celles de l’origine entière.

Ce que font vraiment Hummingbird et Classic

Nous avons lu les gabarits de PrestaShop 9.2.0 (Hummingbird 2.1.2 et Classic 3.1.2). Hummingbird est le thème par défaut des nouvelles installations depuis PrestaShop 9.1.

ÉlémentHummingbird 2.1.2Classic 3.1.2
Première image de la fiche produitfetchpriority="high"loading="lazy", sans fetchpriority
Images suivantes de la ficheloading="lazy"loading="lazy"
Image de couverture de catégoriefetchpriority="high"fetchpriority="high"
Miniatures des listes de produitsloading="lazy" sur toutesloading="lazy" sur toutes
Sources AVIF/WebP en <picture>oui, avec srcset et sizesoui, une seule taille par format
width et height sur les imagesouioui

Trois conséquences pratiques :

  1. Avec Classic, l’image principale de la fiche est en chargement différé. Or web.dev recommande de ne jamais différer l’image LCP. Corrigez le template templates/catalog/_partials/product-cover-thumbnails.tpl dans un thème enfant.
  2. Sur une catégorie sans image de couverture, l’élément LCP mobile peut être la première miniature, que les deux thèmes chargent en différé.
  3. Les formats AVIF et WebP ne sont servis que s’ils sont générés. Le thème ne propose que les sources existantes.

Rendre la première image prioritaire dans Classic

Dans votre thème enfant, remplacez loading="lazy" sur l’image de couverture par :

<img
  class="js-qv-product-cover img-fluid"
  src="{$product.default_image.bySize.large_default.url}"
  alt="{$product.name}"
  fetchpriority="high"
  width="{$product.default_image.bySize.large_default.width}"
  height="{$product.default_image.bySize.large_default.height}"
>

Ne mettez fetchpriority="high" que sur une ou deux images par page. Au-delà, l’indication perd son effet.

Les premières miniatures d’une liste

Dans les deux thèmes, catalog/_partials/productlist.tpl transmet déjà la variable $position (0 pour le premier produit) à la miniature. Il suffit de l’utiliser dans miniatures/product.tpl (Classic) ou miniatures/product-image.tpl (Hummingbird), à la place de loading="lazy" sur la balise <img> :

{if isset($position) && $position < 2}fetchpriority="high"{else}loading="lazy"{/if}

Les deux premiers produits se chargent alors sans délai, les autres restent différés. Vérifiez d’abord dans le panneau Performance que l’élément LCP mobile est bien l’une de ces images. Les blocs de produits affichés par des modules (accueil, produits associés) utilisent parfois d’autres gabarits : contrôlez-les à part.

Images : réglages du back-office

Depuis PrestaShop 8.1, la génération des formats modernes se règle dans Apparence > Images, option « Formats d’image à générer ». Cochez WebP et AVIF si votre serveur les prend en charge. Les qualités de compression par défaut sont de 80 pour WebP, 90 pour AVIF et 90 pour JPEG.

Après un changement de format ou de taille, régénérez les miniatures. Le back-office le permet, mais sur un gros catalogue la ligne de commande évite les dépassements de temps d’exécution :

php bin/console prestashop:thumbnails:regenerate products
php bin/console prestashop:thumbnails:regenerate categories

La commande accepte all, categories, manufacturers, suppliers, products ou stores, un identifiant de type d’image en second argument, et l’option --delete pour effacer les anciens fichiers. Lancez-la d’abord en préproduction : elle peut durer longtemps et charger le serveur.

Vérifiez aussi que les tailles déclarées correspondent à l’affichage réel. Dans Hummingbird, l’image principale de la fiche est servie en 400 et 720 pixels de large (default_xl et product_main). Pour automatiser la conversion des fichiers, voir images WebP et AVIF sur PrestaShop.

Paramètres avancés > Performances

Réglages qui agissent sur le temps de génération (TTFB) et le poids des ressources, avec leur libellé dans PrestaShop 9.2 :

BlocRéglageValeur conseillée en production
SmartyCompilation des templates« Ne jamais recompiler les fichiers de templates »
SmartyCacheOui
Mode debugMode debugNon
Mode debugOutil de debugNon (à activer seulement pour un diagnostic)
CCC« Smart cache » pour les feuilles de styleOui, après test
CCC« Smart cache » pour le code JavaScriptOui, après test
CCCOptimisation ApacheOui sur Apache, sans effet sur Nginx
CachingUtiliser le cacheSelon le système disponible

« Recompiler les fichiers de templates s’ils ont été mis à jour » sert pendant le développement. Après tout changement de thème avec « Ne jamais recompiler », videz le cache : voir vider le cache PrestaShop 8 et 9.

Le bloc Caching propose Memcache, Memcached, APC et Xcache. Il n’y a pas de Redis natif : pour Redis ou Valkey, il faut un module. Voir Valkey ou Redis pour PrestaShop.

L’outil de debug pour trouver un module lent

L’« Outil de debug » affiche sous chaque page des informations de performance : temps et mémoire par hook et par module, liste des requêtes SQL avec leur durée et le nombre de lignes lues. Activez-le en préproduction uniquement, car ces informations s’affichent à tous les visiteurs. C’est le moyen le plus direct de relier un TTFB élevé à un module.

TTFB : le serveur avant le thème

Le LCP ne peut pas commencer avant l’arrivée du HTML. web.dev considère un TTFB comme bon jusqu’à 0,8 seconde.

Points à vérifier côté serveur :

Pour la configuration complète, voir hébergement PrestaShop : configuration serveur. Pour mesurer le TTFB, isoler la part SQL et lire un profil Xdebug, voir diagnostiquer un site lent.

INP : déclinaisons, facettes et panier

L’INP retient l’interaction la plus lente de la visite, en ignorant une valeur extrême pour 50 interactions. Seuls les clics, les touchers et les frappes au clavier comptent. Sur PrestaShop, les interactions à tester sont :

Dans le panneau Performance, activez un ralentissement du processeur, enregistrez l’interaction et cherchez les tâches de plus de 50 ms. La pile d’appels indique le fichier responsable, souvent dans modules/<nom>/views/js/.

Charger les scripts d’un module seulement où ils servent

Un module doit ajouter son JavaScript uniquement sur les pages où il est utile. Le hook actionFrontControllerSetMedia permet de filtrer par contrôleur :

public function hookActionFrontControllerSetMedia($params)
{
    if ('product' !== $this->context->controller->php_self) {
        return;
    }

    $this->context->controller->registerJavascript(
        'mon-module-produit',
        'modules/monmodule/views/js/produit.js',
        ['position' => 'bottom', 'priority' => 200]
    );
}

Le hook doit être enregistré à l’installation avec registerHook('actionFrontControllerSetMedia'). Le « Smart cache » JavaScript réduit le nombre de fichiers, mais pas le code exécuté pendant un clic. C’est ce code qui fait l’INP.

CLS : ce qui bouge sur une boutique

Les décalages qui surviennent dans les 500 ms suivant une action de l’utilisateur sont exclus du calcul. Les causes courantes sur PrestaShop :

Réservez l’espace des blocs dynamiques en CSS et affichez les bandeaux en superposition :

.bandeau-promo { min-height: 48px; }
.widget-avis   { min-height: 120px; }
#cookie-banner { position: fixed; bottom: 0; }

Les deux thèmes posent width et height sur leurs images, mais un module peut en insérer sans dimensions. Contrôlez-le dans le panneau Rendering des DevTools, option « Layout Shift Regions ».

Vérifier et suivre

Changez un seul élément à la fois, en préproduction, et comparez avec une mesure de référence sur les mêmes URL. Notez la date de chaque mise à jour de module ou de thème. Une variation des données terrain se lit avec 28 jours de décalage. Un outil d’IA peut résumer un rapport Lighthouse, mais vérifiez ses suggestions sur la page réelle. Pour le SEO technique plus large, voir le guide SEO technique PrestaShop.

Questions fréquentes

Faut-il passer de Classic à Hummingbird pour améliorer les Core Web Vitals ?

Pas forcément. Hummingbird gère mieux l’image principale de la fiche, mais changer de thème touche aussi les modules et le design. Avec Classic, corrigez d’abord l’image de couverture dans un thème enfant, puis mesurez.

Le « Smart cache » CSS et JavaScript suffit-il ?

Non. Il réduit le nombre de fichiers, pas le poids des images ni le JavaScript exécuté pendant une interaction. Testez-le en préproduction : certains modules supportent mal la concaténation.

Pourquoi mes fiches produits n’apparaissent-elles pas dans le rapport Signaux Web essentiels ?

Une URL n’est mesurée que si elle reçoit assez de visites de Chrome. Les fiches peu visitées sont regroupées avec des URL similaires ou absentes. Mesurez-les en laboratoire et suivez le gabarit.

Peut-on désactiver un module pour améliorer les scores ?

Mesurez d’abord la page avec et sans le module en préproduction, avec l’« Outil de debug » activé. Si le module reste utile, corrigez plutôt son chargement : scripts limités aux bonnes pages, blocs avec espace réservé.

Sources

Agence web PrestaShop & WordPress

Agence web spécialisée PrestaShop et WordPress : création, maintenance, sécurité, performance et référencement. Nos tutoriels sont issus de nos interventions sur de vraies boutiques.

L'agence Genisoft → LinkedIn →