Site lent : diagnostic avec DevTools, PageSpeed et MySQL

Mis à jour le 1er novembre 2026. Ajouts : panneau Performance de Chrome, audits de Lighthouse 13, décomposition du TTFB, Server-Timing, Xdebug 3, journal MySQL et statuts de cache Cloudflare. Les libellés incertains ont été vérifiés ou retirés.

Un site lent l’est à cause du navigateur (images, scripts, CSS), du serveur, de la base de données ou du réseau. Chaque outil n’éclaire qu’une couche : l’ordre d’utilisation compte autant que les outils. Cette méthode vaut pour tout site. Les corrections propres à chaque CMS sont dans Core Web Vitals WordPress et Core Web Vitals PrestaShop.

L’ordre de diagnostic

Refaites la mesure après chaque modification, dans les mêmes conditions.

Étape 1 : PageSpeed Insights

PageSpeed Insights (PSI) affiche deux types de données. Lisez d’abord la partie haute.

• Données terrain : les visites réelles de Chrome, sur les 28 derniers jours, issues du Chrome UX Report (CrUX). Si l’URL n’a pas assez de visites, PSI affiche les données de l’origine entière. Si l’origine n’en a pas non plus, il n’y a aucune donnée terrain.
• Données de laboratoire : un test Lighthouse sur un appareil et un réseau simulés. Le score est jugé bon à partir de 90, à améliorer de 50 à 89, mauvais en dessous de 50.

Les seuils des Core Web Vitals, évalués au 75e percentile :

CrUX ne collecte ni Chrome sur iOS, ni les autres navigateurs comme Edge. Une page n’y figure que si elle est indexable (code 200, pas de noindex) et assez visitée. Le rapport « Signaux Web essentiels » de la Search Console utilise les mêmes données : voir le guide Google Search Console 2026.

Étape 2 : le panneau Performance des DevTools

Le panneau Performance de Chrome affiche dès son ouverture le LCP et le CLS locaux, puis l’INP si vous interagissez. Il peut charger les données terrain de CrUX pour comparaison.

Réglages à faire avant de mesurer :

• Ralentissement du processeur : votre poste est plus rapide que le téléphone de vos visiteurs.
• Ralentissement du réseau : choisissez un profil mobile, par exemple « Fast 4G ».
• Cache désactivé (« Disable cache », onglet Réseau) et navigation privée.

Pour le LCP, enregistrez un chargement de la page : le panneau désigne l’élément LCP et décompose son délai. web.dev donne une répartition indicative pour les quatre parties :

Pour l’INP, enregistrez une interaction (menu, filtre, ajout au panier) et cherchez les tâches de plus de 50 ms. La pile d’appels indique le fichier responsable.

Lighthouse 13 : lire les nouveaux audits

Lighthouse 13, publié le 10 octobre 2025, a remplacé de nombreux audits par des « insights », comme dans le panneau Performance. Le calcul du score n’a pas changé. Si vous exploitez le JSON, utilisez les nouveaux identifiants :

Lighthouse ne mesure pas l’INP : il utilise le Total Blocking Time (TBT) comme indicateur de substitution. En ligne de commande, Lighthouse 13 demande Node 22.19 ou plus récent :

npx lighthouse https://www.exemple.fr/ --only-categories=performance --output=json --output-path=./rapport.json

Le score varie d’un passage à l’autre : comparez plusieurs exécutions.

Étape 3 : le TTFB

Le TTFB (Time To First Byte) est le délai entre la requête et le premier octet de la réponse. web.dev le juge bon jusqu’à 0,8 s et mauvais au-delà de 1,8 s. Ce n’est pas un Core Web Vital, mais il fait partie du LCP.

curl permet de le décomposer :

curl -o /dev/null -s -w "DNS : %{time_namelookup}\nTCP : %{time_connect}\nTLS : %{time_appconnect}\nTTFB : %{time_starttransfer}\nTotal : %{time_total}\n" https://www.exemple.fr/

Sous Windows PowerShell, appelez curl.exe pour éviter l’alias vers Invoke-WebRequest. Les valeurs sont cumulées. L’écart entre TTFB et TLS correspond surtout au temps de génération côté serveur.

Faites plusieurs mesures, page en cache et hors cache. Les journaux du serveur aident à repérer les pics : voir analyser les logs Nginx avec un script. Sans terminal, utilisez notre vérificateur d’état du serveur et un vérificateur de taille de page.

Étape 4 : Server-Timing et profileur PHP

Server-Timing

L’en-tête Server-Timing envoie au navigateur des durées mesurées par le serveur. Chrome les affiche dans l’onglet Réseau, sous « Timing ». Il indique si le temps se perd en base ou dans le code :

<?php
$debut = hrtime(true);

$t0 = hrtime(true);
// ... requêtes SQL de la page ...
$db = (hrtime(true) - $t0) / 1e6;

// ... reste du traitement, avant tout envoi de HTML ...
$total = (hrtime(true) - $debut) / 1e6;

header(sprintf('Server-Timing: db;dur=%.1f;desc="Base", app;dur=%.1f', $db, $total));

Les durées sont en millisecondes, et l’en-tête doit partir avant le HTML. Il expose votre infrastructure : réservez-le à la préproduction ou aux administrateurs.

Xdebug 3 en mode profilage

Xdebug enregistre le temps passé dans chaque fonction PHP. Réservez-le à la préproduction : il ralentit l’exécution. Configuration dans php.ini :

xdebug.mode=profile
xdebug.output_dir=/tmp/xdebug
xdebug.start_with_request=trigger

Avec trigger, le profil n’est produit que si la requête porte XDEBUG_TRIGGER (paramètre GET, POST ou cookie) :

curl -s -o /dev/null "https://preprod.exemple.fr/?XDEBUG_TRIGGER=1"

Les fichiers commencent par cachegrind.out.. Ouvrez-les avec KCacheGrind (Linux), QCacheGrind (Windows et macOS) ou Webgrind. QCacheGrind ne lit pas les fichiers compressés : ajoutez xdebug.use_compression=false.

Pour lire le profil :

• Temps inclusif : la fonction et ses appels, pour descendre dans l’arbre.
• Temps exclusif : le temps propre de la fonction, qui désigne un coupable direct.
• Nombre d’appels : très élevé, il signale souvent une requête répétée dans une boucle.

Les hooks des plugins et des modules apparaissent dans ces appels. PrestaShop a aussi son propre outil de debug.

Étape 5 : le journal des requêtes lentes MySQL

Si le temps se perd en base, le journal des requêtes lentes est le point de départ le plus direct. Variables utiles, d’après la documentation de MySQL 8.4 :

SET GLOBAL slow_query_log = 1;
SET GLOBAL long_query_time = 0.5;
SHOW VARIABLES LIKE 'slow_query_log_file';

Ces commandes demandent des droits d’administration et sont perdues au redémarrage. Sur un mutualisé, passez par l’interface de l’hébergeur.

Pour synthétiser le journal :

mysqldumpslow -s t -t 10 /var/lib/mysql/serveur-slow.log

pt-query-digest, de Percona Toolkit, produit une analyse plus détaillée. Placez ensuite EXPLAIN devant la requête suspecte. Une valeur ALL dans la colonne type signale un parcours complet de la table. Comparez le plan avant et après un index, qui ralentit aussi les écritures. Si la requête vient d’un plugin ou d’un module, ne modifiez pas le cœur du CMS. Sur PrestaShop, voir aussi configurer PHP, MySQL et MariaDB.

Étape 6 : le CDN

Un CDN sert des copies de vos fichiers depuis des serveurs proches du visiteur. Il aide quand la distance est en cause. Il ne règle rien pour :

• les pages dynamiques non mises en cache (panier, compte, back-office) ;
• le code PHP ou les requêtes SQL lentes, exécutés à l’origine ;
• le JavaScript bloquant et les décalages de mise en page.

Pour vérifier le cache, lisez l’en-tête de statut deux fois de suite :

curl -sI https://www.exemple.fr/wp-content/uploads/image.webp | grep -i cf-cache-status

Chez Cloudflare, les valeurs principales sont :

Cloudflare ne met pas le HTML en cache par défaut : elle renvoie DYNAMIC sans règle de cache. Si vous en créez une, excluez les pages personnalisées.

Questions fréquentes

Ces outils conviennent-ils à WordPress et PrestaShop ?

Oui. Les outils du navigateur analysent n’importe quelle page. Server-Timing, Xdebug et le journal MySQL demandent un accès au serveur ou à une préproduction.

Pourquoi PageSpeed Insights n’affiche-t-il pas de données terrain ?

L’URL et l’origine n’ont pas assez de visites éligibles, ou la page n’est pas indexable. Mesurez alors vos visiteurs avec la bibliothèque JavaScript web-vitals (onLCP, onINP, onCLS).

Faut-il être développeur pour faire ce diagnostic ?

Pour les étapes 1 à 3, non : elles suffisent à situer la couche en cause. Pour le profilage PHP et l’analyse SQL, transmettez vos mesures à un développeur ou à votre hébergeur.

La vitesse a-t-elle un impact sur le référencement ?

Google indique que les Core Web Vitals sont utilisés par ses systèmes de classement, sans garantie de position. La pertinence du contenu reste déterminante.

Sources

• Google, « À propos de PageSpeed Insights » : https://developers.google.com/speed/docs/insights/v5/about
• Chrome for Developers, « CrUX methodology » : https://developer.chrome.com/docs/crux/methodology
• Chrome for Developers, « Performance panel » : https://developer.chrome.com/docs/devtools/performance/overview
• Chrome for Developers, « Lighthouse 13.0 » (10 octobre 2025) : https://developer.chrome.com/blog/lighthouse-13-0
• Chrome for Developers, « Lighthouse is moving to performance insight audits » : https://developer.chrome.com/blog/moving-lighthouse-to-insights
• web.dev, « Core Web Vitals » : https://web.dev/articles/vitals
• web.dev, « Optimize Largest Contentful Paint » : https://web.dev/articles/optimize-lcp
• web.dev, « Time to First Byte (TTFB) » : https://web.dev/articles/ttfb
• web.dev, « Optimize long tasks » : https://web.dev/articles/optimize-long-tasks
• Google Search Central, « Expérience sur la page » : https://developers.google.com/search/docs/appearance/page-experience
• MDN, « Server-Timing » : https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Server-Timing
• curl, page de manuel (--write-out) : https://curl.se/docs/manpage.html
• Xdebug, « Profiling » : https://xdebug.org/docs/profiler
• MySQL 8.4 Reference Manual, « The Slow Query Log » : https://dev.mysql.com/doc/refman/8.4/en/slow-query-log.html
• Cloudflare, « Cloudflare cache responses » : https://developers.cloudflare.com/cache/concepts/cache-responses/

L'équipe Genisoft 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 →