# Core Web Vitals PrestaShop : suivi CrUX et diagnostic par module (dfcoreweb) > DataFirefly Core Web Vitals rapatrie dans votre back-office les mesures de performance réellement vécues par vos visiteurs Chrome (rapport CrUX de Google), séparément pour chaque type de page : accueil,… - Page: - Langue: fr - Mis à jour le: 2026-10-16 - Autres langues: [en](https://www.datafirefly.com/en/documentation/dfcoreweb/index.md), [es](https://www.datafirefly.com/es/documentation/dfcoreweb/index.md), [de](https://www.datafirefly.com/de/documentation/dfcoreweb/index.md), [it](https://www.datafirefly.com/it/documentation/dfcoreweb/index.md), [pl](https://www.datafirefly.com/pl/documentation/dfcoreweb/index.md), [nl](https://www.datafirefly.com/nl/documentation/dfcoreweb/index.md), [pt](https://www.datafirefly.com/pt/documentation/dfcoreweb/index.md) - Index: DataFirefly Core Web Vitals rapatrie dans votre back-office les mesures de performance réellement vécues par vos visiteurs Chrome (rapport CrUX de Google), séparément pour chaque type de page : accueil, catégorie, fiche produit, panier, page CMS et domaine entier. Il conserve l'historique, prévient par e-mail quand une métrique se dégrade, compare votre boutique à vos concurrents et explique, avec un diagnostic PageSpeed Insights, quel module, fichier du thème ou service tiers ralentit une page. Cette documentation couvre la version **1.2.0**, compatible PrestaShop **8.0 à 9.x** et PHP **8.1+** avec l'extension cURL. Module strictement back-office : aucun hook front-office, aucun script côté visiteur, aucune dépendance Composer. ## Prérequis : la clé API Google Le module utilise deux API gratuites de Google avec la même clé : Chrome UX Report (mesures réelles) et PageSpeed Insights (onglet Diagnostic). 1. Ouvrez la **Google Cloud Console** et créez un projet, ou choisissez-en un. 2. Dans **API et services > Bibliothèque**, activez **Chrome UX Report API**. 3. Toujours dans la bibliothèque, activez **PageSpeed Insights API**. 4. Dans **API et services > Identifiants**, cliquez sur **Créer des identifiants > Clé API** et copiez la clé (elle commence par `AIzaSy`). N'appliquez pas de restriction par référent HTTP à cette clé : les appels partent du serveur de la boutique, pas d'un navigateur. Une restriction par API (Chrome UX Report et PageSpeed Insights) est en revanche possible. Aucune carte bancaire n'est demandée. Le quota CrUX est de 150 requêtes par minute ; une synchronisation en consomme une vingtaine, plus une par concurrent et par appareil suivi. ## Installation et mise à jour 1. Ouvrez **Modules > Gestionnaire de modules** et cliquez sur **Installer un module**. 2. Déposez le fichier `dfcoreweb.zip`. 3. Cliquez sur **Configurer** : vous arrivez sur le tableau de bord du module. L'installation crée 5 tables et un menu **Core Web Vitals** sous **Améliorer**, avec 5 pages : Tableau de bord, Recommandations, Historique, Diagnostic et Configuration. ### Mise à jour depuis la version 1.0.0 Installez le nouveau ZIP par-dessus l'ancien, sans désinstaller. La mise à jour réorganise le menu, répare les mesures enregistrées par la 1.0.0 (des métriques absentes y étaient stockées à 0), ajoute les nouvelles tables et supprime les anciens fichiers. La mise à jour crée un jeton de tâche planifiée aléatoire : l'ancienne URL de cron cesse de fonctionner. Copiez la nouvelle depuis l'onglet **Configuration** dans votre planificateur. ## Configuration ### Clé API Collez la clé et cliquez sur **Enregistrer et tester**. Le module interroge CrUX pour le domaine de la boutique et affiche l'un de ces résultats : - **Clé valide, CrUX renvoie des données** : tout est prêt. - **Clé valide, pas encore assez de trafic Chrome** pour le domaine : la clé fonctionne, certaines pages très visitées peuvent quand même remonter des mesures, et le Diagnostic reste disponible. - **Clé refusée** : vérifiez la clé et l'activation de Chrome UX Report API sur le projet. - **Le serveur n'arrive pas à joindre Google** : voir le dépannage en fin de page. ### Appareils suivis - **Mobile** : activé par défaut, c'est celui que Google utilise pour évaluer l'expérience de page. - **Ordinateur** : activé par défaut. - **Tablette** : désactivé par défaut, CrUX a rarement assez de données sur ce segment. Au moins un appareil reste toujours actif : si vous décochez tout, Mobile est réactivé. ### Pages mesurées L'accueil, le panier et le domaine entier sont toujours mesurés. Pour les autres types, laissez le champ vide pour la sélection automatique ou saisissez des identifiants séparés par des virgules : - **ID produits** : vide = les 3 meilleures ventes des 90 derniers jours (commandes validées de la boutique), à défaut les 3 produits les plus récents. - **ID catégories** : vide = les 3 catégories qui contiennent le plus de produits actifs, hors catégories racine et accueil. - **ID pages CMS** : vide = aucune page CMS mesurée. Choisissez des pages très visitées. CrUX ne publie rien sous un certain volume de visites Chrome : une page confidentielle restera en « Pas assez de trafic Chrome », mais vous pourrez toujours l'analyser dans l'onglet Diagnostic. ### Concurrents Saisissez jusqu'à 5 domaines, un par ligne (`concurrent.fr` ou `https://www.concurrent.com`). Les mesures CrUX étant publiques, le module mesure le domaine entier de chaque concurrent sans rien installer chez eux. Les concurrents n'entrent ni dans les alertes ni dans les recommandations. ### Synchronisation automatique - **Autoriser l'URL de synchronisation** : active la tâche planifiée décrite plus bas. - **Importer l'historique hebdomadaire CrUX** : récupère jusqu'à 40 semaines de mesures passées pour chaque page, puis les rafraîchit une fois par semaine. - **Analyse labo automatique** : la tâche planifiée analyse une page par jour avec PageSpeed Insights (mobile), si bien que chaque page est revue environ une fois par semaine. - **Conservation de l'historique** : 365 jours par défaut, de 30 à 3650. Les mesures, analyses et événements plus anciens sont supprimés à chaque synchronisation. ### Alertes de régression - **Envoyer un e-mail quand une métrique se dégrade** : active les alertes. - **Destinataire** : vide = adresse e-mail de la boutique. - **Seuil de dégradation** : 15 % par défaut, de 5 à 100 %. À chaque synchronisation, LCP, INP, CLS et TTFB de chaque page et appareil sont comparés à leur moyenne des 7 jours précédents (au moins 3 mesures). Une alerte part quand la hausse dépasse le seuil **et** que la valeur n'est plus dans la zone verte de Google. Toutes les régressions d'une synchronisation tiennent dans un seul e-mail, et la même page ne déclenche pas d'alerte pour la même métrique avant 7 jours. Le bouton **Envoyer un e-mail de test** vérifie l'adresse et la configuration e-mail de la boutique. ### Tableau de bord PrestaShop L'option **Afficher un résumé mobile** ajoute sur la page d'accueil du back-office un bloc avec LCP, INP et CLS mobiles par type de page et leur statut. ## La tâche planifiée L'onglet Configuration affiche l'URL à appeler une fois par jour et une ligne crontab prête à copier : ``` 17 6 * * * curl -fsS "https://votre-boutique.com/module/dfcoreweb/cron?token=VOTRE_JETON" > /dev/null ``` Sur un hébergement mutualisé, utilisez le planificateur de votre panneau d'administration ou un service comme cron-job.org. Chaque appel : 1. met à jour la liste des pages suivies (meilleures ventes, catégories) ; 2. interroge CrUX pour chaque page, appareil et concurrent ; 3. envoie l'e-mail d'alerte si nécessaire ; 4. importe l'historique hebdomadaire quand il est dû ; 5. lance l'analyse labo du jour ; 6. supprime les données plus anciennes que la durée de conservation. L'URL répond en JSON avec un code **200** quand tout s'est bien passé et **502** en cas d'échec, pour que votre service de cron puisse vous prévenir. Un mauvais jeton reçoit un code 403. La tâche fonctionne même boutique en maintenance et refuse de tourner deux fois en même temps pour une boutique (verrou de 15 minutes). Une exécution par jour suffit : CrUX agrège 28 jours et ne se met à jour qu'une fois par jour. Le bouton **Nouveau jeton** invalide l'URL actuelle ; en multiboutique, chaque boutique a sa propre URL. Le tableau de bord vous prévient si la tâche n'a jamais été appelée, ou si aucune synchronisation n'a eu lieu depuis plus de 3 jours. Le bouton **Synchroniser maintenant** lance une collecte immédiate, utile juste après l'installation. ## Le tableau de bord Une tuile par type de page affiche, pour chaque appareil, les cinq métriques au **75e centile** sur 28 jours glissants, avec les couleurs des seuils de Google : - **LCP** (affichage du contenu principal) : bon jusqu'à 2,5 s, mauvais au-delà de 4 s. - **INP** (réactivité aux interactions) : bon jusqu'à 200 ms, mauvais au-delà de 500 ms. - **CLS** (stabilité visuelle) : bon jusqu'à 0,1, mauvais au-delà de 0,25. - **FCP** (premier affichage) : bon jusqu'à 1,8 s, mauvais au-delà de 3 s. - **TTFB** (temps de réponse du serveur) : bon jusqu'à 0,8 s, mauvais au-delà de 1,8 s. Le badge **Réussi** ou **Échoué** suit la règle de Google : LCP, INP et CLS dans la zone verte (l'INP est ignoré quand CrUX n'en publie pas, ce qui est fréquent sur le panier). Sous chaque valeur, une flèche indique l'évolution par rapport à il y a 4 semaines : rouge quand la métrique se dégrade, verte quand elle s'améliore. Quand un type de page regroupe plusieurs URL, la tuile affiche leur moyenne. Plus bas, la **comparaison avec vos concurrents** classe votre domaine et ceux de vos concurrents par LCP, pour chaque appareil. Le tableau **URLs suivies** détaille chaque page avec ses mesures, son dernier score PageSpeed (colonne Labo) et deux raccourcis : son historique et son diagnostic. ## Recommandations Chaque métrique hors de la zone verte produit une recommandation. Les recommandations qui ont la même cause sont regroupées en une seule carte, qui liste les pages concernées avec leur valeur (par exemple le TTFB sur l'accueil, les catégories et les fiches produit). Chaque carte indique : - la sévérité : **Critique** (zone rouge), **À traiter** (zone orange) ou **Conseil** ; - la cause probable sur ce type de page PrestaShop et les étapes de correction ; - un ordre de grandeur de l'impact, tiré d'études publiques, présenté comme une estimation ; - des liens vers les écrans concernés (Performances, Paramètres des images, Positions des modules, Règles panier) et vers le Diagnostic. **Ignorer 30 jours** masque la carte pour toutes ses pages. Elle revient si une nouvelle page est touchée, et un lien en haut de page affiche les recommandations ignorées pour les réafficher. ## Historique Choisissez le type de page, l'URL (ou la moyenne de toutes les URL du type), l'appareil et la période (30, 90, 180 ou 365 jours). Six courbes s'affichent : LCP, INP, CLS, TTFB, FCP et la part des URL qui réussissent l'évaluation, avec les seuils de Google en pointillés. Avant la première synchronisation, chaque point correspond à une semaine importée de l'historique CrUX ; ensuite, un point par synchronisation. Chaque point couvre les 28 jours qui le précèdent : un changement met environ 4 semaines à apparaître en entier. ### Événements Les installations et désinstallations de modules sont notées automatiquement et apparaissent en pointillés sur les courbes. Ajoutez vos propres repères avec une date et une description (mise à jour du thème, changement d'hébergeur, campagne) pour relier une variation à sa cause. Le survol d'un point affiche les événements proches. Le bouton **Export CSV** télécharge la sélection affichée, avec la source de chaque point (hebdomadaire ou quotidien). ## Diagnostic d'une page Choisissez une page suivie et l'appareil (Mobile ou Ordinateur), puis cliquez sur **Lancer l'analyse**. Google charge la page depuis ses serveurs et le résultat arrive en 20 à 60 secondes. Il reste enregistré : changer de page ou d'appareil affiche la dernière analyse sans en relancer une. Le score et les valeurs de laboratoire varient de quelques points d'une analyse à l'autre. Google classe les pages avec les mesures réelles, pas avec ce score. Le **TBT** est l'équivalent labo de l'INP. Les mesures réelles de la page sont rappelées sous les valeurs labo quand elles existent. ### Score et capture Le score de performance (sur 100), les valeurs LCP, TBT, CLS, FCP, Speed Index et TTFB, le poids total, le nombre de requêtes et la capture de ce que Google a affiché. ### Élément LCP L'élément qui fixe le LCP (image, bannière, titre) avec son code HTML, et la répartition de son temps en quatre étapes : réponse du serveur, attente avant le téléchargement, téléchargement de la ressource et délai d'affichage. Un conseil correspond à l'étape la plus longue, par exemple précharger l'image quand elle est découverte tard, ou retirer `loading="lazy"` quand l'image LCP est chargée en différé. ### Ce qui pèse sur la page Chaque fichier chargé est attribué à son origine d'après son chemin : - **Module** : fichiers sous `/modules/nom_du_module/`, affichés avec le nom du module ; - **Thème** : fichiers sous `/themes/nom/` ; - **Boutique** : fichiers du cœur de PrestaShop, images de la boutique, et la page HTML avec les scripts écrits directement dedans ; - **Service tiers** : tout autre domaine, nommé par Google quand il le reconnaît (Google Tag Manager, Facebook, outils de chat...). Pour chaque origine : temps CPU (exécution du JavaScript pendant le chargement, première cause d'un INP élevé), poids JS, CSS et autres fichiers, JavaScript inutilisé et nombre de requêtes. Le tableau est trié par temps CPU. Si le cache intelligent (CCC) est activé, PrestaShop regroupe les fichiers des modules dans ceux du thème et le détail par module disparaît. Le Diagnostic le signale : désactivez le CCC le temps d'une analyse dans **Paramètres avancés > Performances**, relancez, puis réactivez-le. ### Fichiers bloquants et points relevés La liste des fichiers qui bloquent l'affichage, chacun avec son module ou son origine, et les points relevés par Google (cache, format des images, JavaScript inutilisé...), classés par gain estimé, avec une piste PrestaShop pour chacun. Les intitulés de Google sont dans la langue du back-office. ### Analyses précédentes Le tableau des dernières analyses de la page (score, LCP, TBT, CLS, poids, ou l'erreur rencontrée) permet de vérifier l'effet d'une correction. ### Analyse automatique Avec l'option **Analyse labo automatique**, la tâche planifiée analyse chaque jour la page dont la dernière analyse mobile est la plus ancienne, si elle date de plus de 7 jours. Pour une boutique sans mesures CrUX par page, c'est la seule mesure qui évolue dans le temps. Si la boutique est en maintenance, Google analyse la page de maintenance. Le Diagnostic l'indique au-dessus du bouton. ## Le statut « Pas assez de trafic Chrome » CrUX ne publie une mesure que si suffisamment de visiteurs Chrome ont chargé l'URL sur 28 jours. Sinon, le module enregistre ce statut sans erreur et la synchronisation continue. Appuyez-vous alors sur le **domaine entier**, qui atteint plus facilement le seuil, et sur l'onglet **Diagnostic** pour les pages concernées. ## Vie privée Seules les URL publiques suivies, et les domaines concurrents que vous saisissez, sont envoyés à Google. Aucune donnée client ne sort de la boutique. Toutes les mesures, analyses et événements restent dans votre base PrestaShop ; chaque analyse conserve un résumé et la capture de la page (environ 50 Ko) selon la même durée de conservation. Chart.js est embarqué dans le module : aucun CDN, aucune télémétrie. ## Dépannage - **« Google a refusé la clé API »** : clé mal recopiée, Chrome UX Report API non activée sur le projet, ou restriction par référent HTTP sur la clé. - **« L'API PageSpeed Insights n'est pas activée »** (onglet Diagnostic) : activez **PageSpeed Insights API** dans la bibliothèque du même projet Google Cloud. - **« Le serveur de la boutique n'arrive pas à joindre les serveurs de Google »** : l'hébergeur bloque les connexions sortantes. Demandez-lui d'autoriser le HTTPS sortant vers `googleapis.com`. La synchronisation s'arrête après deux échecs au lieu d'attendre sur chaque page. - **« Quota dépassé »** : la synchronisation reprendra au prochain passage de la tâche. Pour PageSpeed, réessayez une minute plus tard. - **« Une synchronisation est déjà en cours »** : une synchronisation tourne déjà pour cette boutique ; réessayez quelques minutes plus tard. - **L'URL de cron répond 403** : le jeton n'est plus valide (nouveau jeton ou mise à jour depuis la 1.0.0). Recopiez l'URL de l'onglet Configuration. - **L'e-mail de test n'arrive pas** : vérifiez l'adresse et **Paramètres avancés > E-mail**. - **Le Diagnostic ne détaille pas les modules** : désactivez le CCC le temps d'une analyse (voir plus haut). - **Le menu n'apparaît pas** : videz le cache dans **Paramètres avancés > Performances** et vérifiez les permissions du profil employé sur les onglets du module. ## Désinstallation La désinstallation supprime les 5 tables du module, sa configuration et ses onglets après confirmation. L'historique est définitivement perdu : exportez-le en CSV depuis l'onglet Historique si vous voulez le garder.