Core Web Vitals PrestaShop : passer les trois seuils de Google sur mobile

Une boutique passe les Core Web Vitals quand 75 % des visites réelles obtiennent un bon résultat sur trois mesures. Il faut un LCP de 2,5 secondes ou moins, un INP de 200 millisecondes ou moins, un CLS de 0,1 ou moins. Google les évalue sur mobile et sur ordinateur. Une alerte de la Search Console désigne un groupe d’URL, c’est-à-dire des pages à l’expérience semblable.

• Les trois seuils des Core Web Vitals se lisent au 75e centile, sur mobile comme sur ordinateur
• Le rapport Core Web Vitals de la Search Console classe les groupes d’URL selon leur pire mesure
• Le terrain et le laboratoire répondent à deux questions différentes
• Dans une boutique PrestaShop, chaque indicateur a ses causes probables, à confirmer
• Le laboratoire bouge tout de suite, le terrain met 28 jours à suivre
• Confiez la mission quand la cause dépasse la boutique ou résiste à un réglage
• Sources consultées
• Foire aux questions

Les trois seuils des Core Web Vitals se lisent au 75e centile, sur mobile comme sur ordinateur

Le LCP mesure le chargement du plus grand élément affiché, l’INP la réaction aux clics et aux touches, le CLS la stabilité de la mise en page. Le 75e centile est la valeur que 75 % des visites atteignent ou améliorent. Les mêmes seuils servent aux deux appareils, mais chacun a son propre rapport.

Ces parts viennent d’HTTP Archive, qui compte des origines, c’est-à-dire des sites où il détecte PrestaShop, dans le monde entier, parmi celles qui ont assez de données pour l’indicateur ; le rapport porte sur août 2026. Sur mobile, le LCP est la mesure la plus faible ; sur ordinateur, c’est le CLS. Pour l’INP, 41 592 origines sont mesurées sur mobile, contre 49 558 pour le LCP : l’indicateur n’est pas évalué partout.

Le rapport Core Web Vitals de la Search Console classe les groupes d’URL selon leur pire mesure

Le rapport s’appuie sur les données du rapport d’expérience utilisateur de Chrome (CrUX). Il regroupe les URL à l’expérience semblable et retient pour chaque groupe sa pire mesure : un seul indicateur mauvais classe tout le groupe en mauvais. Une boutique y retrouve en général ses gabarits, fiches produit d’un côté, catégories de l’autre ; c’est une déduction, la documentation parlant de pages à l’expérience similaire.

Ouvrez le rapport mobile et le rapport ordinateur : la Search Console les sépare. Chaque rapport liste les URL en défaut dans un tableau. Un groupe sans assez de données pour le LCP et le CLS disparaît du rapport. Quand les données d’une URL manquent, PageSpeed Insights se replie sur l’origine entière.

Le terrain et le laboratoire répondent à deux questions différentes

Le laboratoire (Lighthouse, dans PageSpeed Insights) simule un appareil, un réseau et un cache vide. web.dev en relève deux limites. Il rate souvent les décalages qui surviennent quand le visiteur fait défiler la page, car il ne retient que ceux du haut de page pendant le chargement. Il ne mesure pas l’INP, faute d’interaction ; l’indicateur de substitution proposé est le Total Blocking Time (temps de blocage total).

Le terrain a ses propres angles morts. CrUX ne collecte que Chrome sur ordinateur et sur Android, auprès d’utilisateurs qui ont activé les statistiques d’usage et la synchronisation de l’historique. Chrome sur iOS, les vues web des applications et Edge n’y contribuent pas. Le seuil de popularité exigé d’une page ou d’une origine n’est pas publié.

Dernier piège de lecture : PageSpeed Insights juge une page sur le LCP et le CLS quand l’INP manque de données, et ne la juge pas du tout quand l’un des deux manque. Un « réussi » obtenu sans INP laisse un indicateur non évalué.

Décrire mon besoin →

Dans une boutique PrestaShop, chaque indicateur a ses causes probables, à confirmer

web.dev découpe le LCP en quatre temps. La réponse du serveur en pèse environ 40 % du total visé, le délai avant que la ressource démarre moins de 10 %, la durée de son chargement environ 40 %, le délai avant son affichage moins de 10 %. Ces parts sont des repères. Le temps serveur renvoie à la mission serveur et cache.

• LCP : le plus grand élément est probablement une bannière ou la photo d’une fiche produit. web.dev recommande de la rendre visible dès le HTML initial et de ne pas la charger en différé. Le bloc CCC (« Combine, Compress and Cache » : combiner, compresser, mettre en cache) de Paramètres avancés > Performances (« Advanced parameters > Performance » dans la documentation) combine les fichiers CSS et JavaScript. La documentation de la version 8 avertit que combiner le JavaScript peut poser problème et demande de tester avec soin.
• INP : web.dev distingue le délai avant la réaction, l’exécution du code et le dessin de l’image suivante. Un module branché ou activé sur trop de pages, défaut que cite la documentation d’optimisation, pèse probablement sur le premier. Une page de catégorie au code HTML très volumineux peut peser sur le dernier.
• CLS : images sans dimensions déclarées, contenu injecté après le chargement, polices web qui changent la mise en page. Un bandeau de cookies ou de promotion inséré tardivement entre dans la deuxième catégorie.

Le laboratoire bouge tout de suite, le terrain met 28 jours à suivre

Une correction se vérifie en deux temps : un test de laboratoire le jour même, puis le rapport de terrain, dont la fenêtre couvre 28 jours. Dans la Search Console, la validation d’un correctif ouvre elle aussi une surveillance de 28 jours, qui ne déclenche aucune réindexation.

Corrigez par groupe d’URL : un défaut venu du gabarit de fiche produit se règle une fois pour tout le groupe, un défaut propre à une page se règle page par page.

Confiez la mission quand la cause dépasse la boutique ou résiste à un réglage

Trois situations justifient de confier le sujet.

Le temps serveur domine le LCP : le réglage relève de l’hébergement et du cache et suppose un accès au serveur.

Le défaut vient du thème, périmètre d’une refonte du thème : un décalage de mise en page ou une image principale mal déclarée s’y corrigent dans les gabarits.

La cause reste introuvable après avoir coupé les modules un à un : un audit de performance la localise, mesure à l’appui.

Exigez en retour des mesures de terrain avant et après, par groupe d’URL et par appareil, relevées une fois la fenêtre de 28 jours écoulée ; un score de laboratoire ne les remplace pas. Faites écrire qui paie la remise en état quand un correctif de thème casse une page.

Dans le message du formulaire de cette page, reportez l’indicateur en défaut, l’appareil, le groupe d’URL et la date de l’alerte.

Décrire mon besoin →

Sources consultées

• Google, « Web Vitals » et « Defining the Core Web Vitals metrics thresholds », web.dev, consulté le 14 octobre 2026.
• Google, « Why lab and field data can be different (and what to do about it) », web.dev, consulté le 14 octobre 2026.
• Google, « Optimize Largest Contentful Paint », « Optimize Interaction to Next Paint » et « Optimize Cumulative Layout Shift », web.dev, consulté le 14 octobre 2026.
• Google, « Interaction to Next Paint is officially a Core Web Vital », web.dev, consulté le 14 octobre 2026.
• Google, « Core Web Vitals report », aide de la Search Console, consulté le 14 octobre 2026.
• Google, « Understanding page experience in Google Search results », Search Central, consulté le 14 octobre 2026.
• Google, « About PageSpeed Insights », consulté le 14 octobre 2026.
• Google, « Chrome UX Report » et « CrUX methodology », Chrome for Developers, consulté le 14 octobre 2026.
• HTTP Archive, « Core Web Vitals Technology Report » et sa présentation sur le forum d’HTTP Archive, données PrestaShop d’août 2026, consulté le 14 octobre 2026.
• PrestaShop, documentation utilisateur de la version 8, « Performance », section CCC, consulté le 14 octobre 2026.
• PrestaShop, documentation développeur de PrestaShop 9, « Optimize your PrestaShop performance », section Modules optimization, consulté le 14 octobre 2026.

Foire aux questions

Les Core Web Vitals comptent-ils pour le référencement ?

La documentation de CrUX indique que Google Search s’en sert pour alimenter le facteur de classement « expérience de page ». La page de Google sur l’expérience de page dit que ses systèmes de classement utilisent les Core Web Vitals, sans en chiffrer le poids. Les seuils décrivent une bonne expérience pour vos visiteurs, sans promesse de classement.

Pourquoi la Search Console n’affiche-t-elle aucune donnée pour une boutique ?

CrUX n’inclut que les pages et les origines assez visitées, sans publier le minimum. Une propriété Search Console tout juste ajoutée met quelques jours à afficher des données CrUX déjà existantes. Un rapport vide ne dit pas que les seuils sont tenus : faites mesurer la boutique par un test de laboratoire en attendant, en gardant en tête ses limites.

Faut-il commencer par le mobile ou par l’ordinateur ?

Par l’appareil dont le rapport compte le plus d’URL en défaut. La Search Console présente un tableau d’URL distinct pour chaque appareil, avec les mêmes seuils. Un groupe peut être bon sur ordinateur et mauvais sur mobile : corriger l’un ne valide pas l’autre.

Le FID figure dans un rapport ou un guide : faut-il le suivre ?

Non. L’INP a remplacé le FID comme Core Web Vital le 12 mars 2024. Google laissait jusqu’au 9 septembre 2024 aux développeurs pour passer du FID à l’INP. Un guide qui présente encore le FID comme un indicateur actuel est périmé.