Module 6 · 6.1
Français
Qu'est-ce qui rend un site lent, et comment le mesurer ?
Module 6: Vitesse · Temps de lecture : 9 minutes
Objectif pédagogique : après cette leçon, vous saurez mesurer où se situe le temps perdu et faire la différence entre une lenteur côté serveur et une lenteur côté navigateur.
Notions clés : TTFB, Core Web Vitals (LCP, INP, CLS), données de laboratoire, données de terrain, PageSpeed Insights, onglet réseau, compression, scripts externes, limites de la formule d'hébergement, 503
D'abord mesurer, ensuite seulement ajuster
"Le site est lent" peut avoir dix causes différentes. Qui installe sans mesurer une extension de cache, une extension d'optimisation d'images et une formule plus grande en même temps, ne sait plus ensuite ce qui a aidé, et se retrouve avec trois choses de plus à suivre. Commencez donc toujours par trois questions (les mêmes que dans la documentation de votre hébergeur) :
- Tout est lent, ou seulement l'administration ? Une administration lente avec une partie publique rapide indique des extensions qui font beaucoup de choses dans l'administration, ou des robots qui s'acharnent sur la page de connexion.
- Toujours, ou à certains moments ? Seulement aux heures de forte affluence ou quand une tâche planifiée s'exécute : alors votre formule atteint ses limites.
- Chez tout le monde, ou seulement chez vous ? Essayez depuis votre téléphone en 4G ou 5G, ou demandez à quelqu'un d'autre. Si c'est lent uniquement chez vous, cela vient de votre connexion ou de votre VPN.
Deux moitiés : serveur et navigateur
Le temps d'attente d'un visiteur se compose de deux parties (leçon 1.2) :
- Le serveur génère le HTML : serveur web, PHP, extensions, base de données. Cela se mesure en TTFB (time to first byte), le temps jusqu'au premier octet de la réponse. web.dev recommande comme règle générale que la plupart des sites visent un TTFB de 0,8 seconde ou moins.
- Le navigateur lit ce HTML puis récupère tout ce qui y est référencé : feuilles de style, scripts, polices, images, vidéos, codes de mesure, widgets de chat. Ce n'est que lorsqu'une partie suffisante de tout cela est arrivée que le visiteur voit quelque chose.
Un TTFB élevé se résout du côté du serveur : mise en cache (leçon 6.2), moins d'extensions ou des extensions plus légères, une version de PHP plus récente, une base de données nettoyée (leçon 6.3) ou plus de puissance de calcul. Un TTFB bas avec pourtant une page lente oriente vers le côté navigateur : images trop grandes, trop de scripts, éléments externes.
Core Web Vitals
Google mesure l'expérience des visiteurs avec trois chiffres, les Core Web Vitals :
| Mesure | Ce qu'elle mesure | Bon si |
|---|---|---|
| LCP (Largest Contentful Paint) | La rapidité avec laquelle le plus grand élément de contenu (souvent la grande photo ou le titre) devient visible | 2,5 secondes ou moins |
| INP (Interaction to Next Paint) | La rapidité avec laquelle la page réagit quand vous cliquez, touchez ou tapez | 200 millisecondes ou moins |
| CLS (Cumulative Layout Shift) | Dans quelle mesure la page bouge pendant le chargement | 0,1 ou moins |
INP a remplacé en mars 2024 l'ancienne mesure FID. Google utilise ces chiffres notamment pour classer les résultats de recherche, mais la principale raison de les améliorer est simple : les visiteurs quittent une page lente ou instable.
Données de laboratoire et données de terrain
Il existe deux types de mesures, et elles donnent des chiffres différents :
- Données de laboratoire : un test à un moment donné, depuis un seul endroit, avec un téléphone et une connexion simulés. Pratique pour comparer (avant et après une modification), mais ce n'est pas un vrai visiteur.
- Données de terrain : des mesures réalisées chez de vrais visiteurs utilisant Chrome, sur les 28 derniers jours. C'est ce que les visiteurs vivent réellement. Les petits sites ont souvent trop peu de visiteurs pour avoir des données de terrain.
PageSpeed Insights (pagespeed.web.dev) affiche les deux : en haut les données de terrain (si elles existent), en dessous un test de laboratoire avec un score et des conseils concrets. Ne vous fiez pas aveuglément au score de 0 à 100. Regardez les détails : le LCP est-il mauvais parce que le serveur est lent (TTFB) ou parce que la grande photo fait 3 Mo ?
Testez toujours plusieurs fois (les chiffres varient) et testez aussi une page ordinaire, pas seulement la page d'accueil.
Observer par vous-même avec le navigateur
Les outils de développement de votre navigateur (F12) montrent ce qui se passe réellement :
- Onglet Réseau : actualisez la page avec le cache désactivé (case "Désactiver le cache"). Vous voyez chaque fichier chargé, sa taille et le temps qu'il a pris. Triez par taille : les fichiers les plus gros sont souvent des images. Triez par domaine : quelle part provient d'autres parties (polices, codes de mesure, vidéos) ?
- La première requête (le HTML lui-même) : cliquez dessus, onglet Timing. "Waiting for server response" correspond au TTFB.
- Les en-têtes de cette première requête : y a-t-il compression (
content-encoding: brougzip), et la page provenait-elle d'un cache (leçon 6.2) ?
Les responsables habituels
En pratique, la lenteur sur WordPress vient le plus souvent de l'un de ces éléments :
- Absence de cache de page : chaque page est régénérée à chaque visite (leçon 6.2).
- Trop d'extensions ou des extensions trop lourdes, en particulier celles qui appellent des services externes à chaque requête ou effectuent des requêtes lourdes (leçon 5.3).
- Des images volumineuses : une photo de 5 Mo prise avec un téléphone sur la page d'accueil (leçons 4.4 et 6.3).
- Un thème lourd ou un créateur de page qui charge beaucoup de scripts et de feuilles de style sur chaque page (leçon 5.1).
- Des éléments externes : polices, vidéos, widgets de chat, codes de mesure, boutons de réseaux sociaux appartenant à d'autres parties. Chacun est une connexion vers un autre serveur qui peut être lent.
- Une version de PHP ancienne (leçon 8.4).
- Une base de données mal entretenue : des milliers de révisions, du spam, des tables de journalisation d'extensions (leçon 6.3).
- Des robots : les robots d'indexation, les robots d'IA et les tentatives de connexion occupent votre formule (leçon 7.3).
- La formule atteint ses limites : pas assez de puissance de calcul (CPU), de processus ou de mémoire pour le trafic.
Les limites de votre formule
Avec l'hébergement mutualisé, chaque formule reçoit une part fixe du serveur : puissance de calcul, mémoire, vitesse de disque et un certain nombre de processus simultanés. Si votre site consomme davantage, il est ralenti, ou les visiteurs reçoivent une erreur 503 (Service Unavailable, chez certains hébergeurs "Resource Limit Is Reached"). Sous DirectAdmin avec CloudLinux, vous voyez cela dans Resource Usage (avec des "faults" si votre site a été ralenti) et avec X-Ray vous voyez, page par page, quelle extension ou quelle requête consomme du temps. D'autres hébergeurs disposent d'aperçus comparables, parfois uniquement sur demande.
Une formule plus grande aide si votre site en a réellement besoin (une boutique en ligne très fréquentée). Cela ne résout pas un site mal configuré : le problème revient alors plus tard. Cherchez d'abord la cause.
Résumé
- Mesurez d'abord : tout ou seulement l'administration, toujours ou parfois, tout le monde ou seulement vous.
- Le TTFB est le côté serveur (visez 0,8 seconde ou moins) ; le reste est ce que le navigateur charge.
- Core Web Vitals : LCP (2,5 s), INP (200 ms) et CLS (0,1) ; INP a remplacé le FID en 2024.
- PageSpeed Insights affiche les données de terrain et les données de laboratoire ; l'onglet réseau montre ce qui se charge réellement.
- La plupart des lenteurs viennent de l'absence de cache, d'extensions lourdes, d'images volumineuses et d'éléments externes ; une formule plus grande n'est que la dernière étape.
Quiz
Exercice
Exercice A6.1 : Mesurez votre TTFB et votre compression. Indiquez l'adresse de votre site et, si vous le souhaitez, une page ordinaire (par exemple votre page de contact). Le programme interroge chaque page trois fois sans cookies et affiche le TTFB médian, la taille du HTML, et si le serveur envoie le HTML compressé (content-encoding gzip ou br). Comparez le résultat avec un test dans PageSpeed Insights et notez ce qui vous frappe.
Pour aller plus loin
Ces articles décrivent les étapes dans les panneaux de WebOké ; dans d'autres panneaux, cela fonctionne de manière comparable.
- Guide DirectAdmin 18.3: Mon site web est lent
- Guide DirectAdmin 17.3: Resource Usage : CPU, mémoire et processus
- Guide DirectAdmin 17.4: X-Ray : repérer les pages lentes
- Guide DirectAdmin 17.5: 503 ou « Resource Limit Is Reached » : que faire ?
- Mon site est lent ou utilise trop de CPU : comment le rendre plus rapide
- Core Web Vitals (web.dev, en anglais) : https://web.dev/articles/vitals
- PageSpeed Insights : https://pagespeed.web.dev/
