Comment vérifier la vitesse d'un site web

La méthode rapide : lancer un test en vrai navigateur

Entrez l'URL dans un test de vitesse de page et laissez-le charger la page dans un vrai navigateur plutôt que d'estimer. Un bon rapport vous donne une capture d'écran de ce qui s'est affiché, les temps globaux, et une décomposition par requête montrant quelle image, quel script ou quel appel tiers était lent. Cette décomposition est ce qui transforme « la page est lente » en « ce fichier de police bloque le rendu pendant 1,8 seconde ».

Lancez-le juste après un déploiement, après une mise à jour de plugin ou de thème, et avant de vous engager dans un changement d'hébergement ou de CDN. Ce sont les moments où la vitesse change et où personne ne le remarque.

Le mesurer vous-même en ligne de commande

Pour la partie serveur de l'histoire, vous n'avez besoin d'aucun navigateur du tout. curl peut afficher sa propre décomposition des temps :

curl -o /dev/null -sS -w   "dns:%{time_namelookup}s connect:%{time_connect}s tls:%{time_appconnect}s ttfb:%{time_starttransfer}s total:%{time_total}s\n"   https://example.com/

Cela mesure une seule requête pour le document HTML uniquement, donc cela paraîtra toujours plus rapide que la vraie page. C'est exactement pourquoi c'est utile : cela isole le serveur du navigateur. Si ttfb est élevé ici, aucune optimisation d'image n'aidera. Si ttfb est bas et que la page paraît quand même lente, le problème se trouve dans ce que le navigateur doit faire après l'arrivée du HTML.

Ce que signifient TTFB, LCP et le chargement complet

• Temps jusqu'au premier octet (TTFB). Le temps que le serveur a mis à commencer à répondre, incluant le DNS, l'établissement de la connexion, le TLS et le traitement propre du serveur. Un TTFB élevé pointe vers l'hébergement, les requêtes de base de données ou le code backend, pas vers les ressources de la page.
• Largest contentful paint (LCP). Le moment où le plus grand élément visible dans la fenêtre a fini de s'afficher, généralement une image d'en-tête, une affiche de vidéo ou un gros bloc de texte. C'est le chiffre le plus proche de ce qu'un visiteur appelle « quand la page est apparue ». Google considère 2,5 secondes ou moins comme bon.
• Temps de chargement / chargement complet. Le moment où le navigateur a fini de charger le document et ses ressources bloquantes. Tout ce que le visiteur peut voir est normalement terminé bien avant cela.
• Temps total de stabilisation. Le temps de chargement plus tout ce qui continue à s'exécuter ensuite, comme des scripts qui récupèrent des données une fois que la page paraît terminée. Une page peut paraître finie et être quand même occupée, et ce travail entre en concurrence avec le premier défilement ou le premier clic du visiteur.
• Requêtes et octets transférés. Combien de fichiers la page a chargés et combien de données ont été téléchargées. Ce sont les leviers derrière presque tous les chiffres ci-dessus.

Lisez-les ensemble. Un TTFB bas avec un LCP élevé signifie que le navigateur fait trop de choses : trop de requêtes, des scripts bloquant le rendu, ou une énorme image d'en-tête. Un TTFB élevé avec tout le reste normal signifie que le serveur est le goulot d'étranglement, avant même que le navigateur soit impliqué.

Pourquoi un seul test depuis un seul endroit induit en erreur

Il est normal de tester la même URL deux fois et d'obtenir deux résultats différents, et aucun n'est faux. Trois éléments expliquent la majeure partie de l'écart :

• La distance. Un test lancé près du serveur a un chemin réseau plus court qu'un test lancé sur un autre continent. Si vos visiteurs sont en Europe et que vous testez depuis la même ville que votre serveur, vous mesurez le meilleur cas, pas le cas typique.
• Le profil de l'appareil. Un test peut émuler un appareil mobile avec une fenêtre plus petite, un user agent différent et une connexion bridée. Une page optimisée pour ordinateur de bureau obtient un score très différent sous émulation mobile, volontairement.
• La mise en cache et l'échauffement. La première requête peut tomber sur un cache froid au niveau du CDN ou de l'application ; la seconde est servie à chaud. Testez une page deux ou trois fois et utilisez la tendance, pas la seule exécution la plus rapide.

Un seul test vaut quand même la peine d'être lancé. Cela signifie simplement qu'un chiffre n'a de sens qu'accompagné des conditions dans lesquelles il a été mesuré.

Comment lire un waterfall

Le waterfall est la chronologie par requête, une barre par fichier, ordonnée par heure de début. Quatre formes reviennent sans cesse :

1. Une longue première barre avant que quoi que ce soit d'autre ne commence. C'est le TTFB sur le HTML, et tout le reste attend derrière.
2. Un escalier où chaque requête ne commence que quand la précédente se termine. C'est une chaîne de dépendances, généralement un script qui charge un autre script qui charge le vrai contenu. Les chaînes sont la forme la plus coûteuse du graphique.
3. Une barre large au milieu venant d'un domaine tiers. Les publicités, widgets de discussion, outils d'analyse et polices se trouvent ici, et un tiers lent retarde votre propre page s'il est chargé de façon synchrone.
4. Un amas dense de petites barres. Des dizaines de petits fichiers, chacun avec sa propre surcharge de connexion. Moins de fichiers, plus gros et mis en cache, valent généralement mieux que beaucoup de petits fichiers.

Les barres en rouge ou avec des codes 4xx et 5xx méritent de l'attention même quand la page paraît normale, car une requête qui échoue coûte quand même du temps avant d'échouer.

Détecter un ralentissement que personne n'a cherché

Un seul test vous dit comment la page s'est comportée une fois, depuis un endroit, sur un profil d'appareil. C'est ce que vous voulez quand vous déboguez quelque chose de précis. Ce n'est pas ce que vous voulez quand le but est simplement de remarquer un ralentissement : les pages s'alourdissent une mise à jour à la fois, et personne ne lance un test manuel un mardi tranquille. La surveillance programmée de vitesse de page exécute le même test depuis les mêmes emplacements selon un intervalle, conserve l'historique, et alerte quand les chiffres dépassent un seuil. Lancez-en un maintenant avec le test de vitesse de page, et consultez temps de réponse du serveur si la partie lente s'avère être le serveur.