Sites plus rapides : au-delà de PageSpeed Insights
PageSpeed Insights de Google est un outil facile à utiliser qui teste si une page Web peut être plus lente que nécessaire. Il donne un score pour quantifier les performances de la page. Parce que ce score est concret, le score PageSpeed Insights est souvent utilisé comme mesure des performances du site. Comme pour PageRank il y a des années, les gens veulent optimiser ce nombre simplement parce qu’il existe. En fait, Moz a un article populaire sur ce sujet : Comment atteindre 100/100 avec l’outil de test de vitesse de page Google.
Pour les petits sites sur des CMS courants (pensez à Wordpress), cela peut être accompli. Si c’est vous, PageSpeed Insights est un excellent point de départ. Pour la plupart des sites, un score parfait n’est pas réaliste. Alors, par où commencer ?
C’est de cela qu’il s’agit. Je veux faire trois remarques :
- La latence peut affecter les temps de chargement plus que la bande passante
- Les scores de PageSpeed Insights ne doivent pas être pris au pied de la lettre
- L’amélioration commence par la mesure, la définition d’objectifs et la priorisation
J’écris avec les praticiens SEO à l’esprit. Je vais sauter quelques-uns des éléments les plus techniques. Vous devriez repartir avec suffisamment de recul pour commencer à poser les bonnes questions. Et vous pouvez faire de meilleures recommandations en conséquence.
| Clause de non-responsabilité: HTTP2 améliore certains des problèmes abordés dans cet article. Plus précisément, plusieurs requêtes au même serveur sont moins problématiques. Ce n’est pas une panacée. |
La latence peut affecter les temps de chargement plus que la bande passante
Un premier regard sur les règles de PageSpeed Insights pourrait vous faire penser qu’il s’agit de servir moins d’octets à l’utilisateur. Minifier, optimiser, compresser. La taille n’est que la moitié de l’histoire. Il faut également du temps pour que votre demande atteigne simplement un serveur. Et puis le serveur met du temps à vous répondre !
Que se passe-t-il lorsque vous faites une demande ?
Si un utilisateur saisit une URL dans la barre d’adresse d’un navigateur et appuie sur Entrée, une demande est effectuée. Beaucoup de choses se passent lorsque cette demande est faite. La toute dernière partie consiste à transférer le contenu demandé. C’est seulement ce dernier bit qui est affecté par la bande passante et la taille du contenu.
Répondre à une demande nécessite (plus ou moins) ces étapes :
- Trouver le serveur
- Connectez-vous au serveur
- Attendez une réponse
- Recevoir une réponse
Chaque de ces étapes prend du temps, pas seulement la dernière. Les trois premiers sont indépendants de la taille du fichier ; ce sont effectivement des coûts constants. Ces coûts sont encourus à chaque demande, que la charge utile soit un petit fichier CSS minifié ou une énorme image non compressée.
Pourquoi faut-il du temps pour obtenir une réponse ?
Le facteur que nous ne pouvons pas éviter est que les signaux du réseau ne peuvent pas voyager plus vite que la vitesse de la lumière. C’est un maximum théorique; en réalité, le transfert des données prendra plus de temps que cela. Par exemple, il faut environ 40 ms de lumière pour un aller-retour entre Paris et New York. S’il faut deux fois plus de temps pour que les données traversent réellement l’Atlantique, alors le temps minimum qu’il faudra pour obtenir une réponse d’un serveur est de 80 ms.
C’est pourquoi les CDN sont couramment utilisés. Les CDN rapprochent physiquement les serveurs des utilisateurs, ce qui est le seul moyen de réduire le temps nécessaire pour atteindre le serveur.
Combien cela importe-t-il ?
Consultez ce tableau (à partir des DevTools de Chrome):
La durée de vie d’une requête, mesurée par Chrome Dev Tools.
Toutes les valeurs dans la case rouge correspondent à ce que je considère comme une “latence”. Ils totalisent environ 220ms. Le transfert réel du contenu a pris 0,7 ms. Aucune compression ou réduction de la taille du fichier ne pourrait aider cela ; la seule façon de réduire le temps pris par la requête est de réduire la latence.
N’avons-nous pas besoin de faire beaucoup de requêtes pour charger une page ?
Il faudra plus d’une requête pour charger tout le contenu nécessaire au rendu d’une page. Si cette URL correspondait à une page Web, le navigateur découvrira généralement qu’il doit charger plus de ressources pour afficher la page. Il peut s’agir de fichiers CSS, JavaScript ou de polices. Il doit suivre de manière récursive les mêmes étapes répertoriées ci-dessus pour charger chacun de ces fichiers.
Heureusement, une fois qu’un serveur a été trouvé (“DNS Lookup” dans l’image ci-dessus), le navigateur n’aura pas besoin de le rechercher à nouveau. Il devra encore se connecter, et nous devrons attendre une réponse.
Une lecture sceptique des tests de PageSpeed Insights
Toutes les évaluations de PageSpeed Insights couvrent des éléments qui peuvent avoir un impact sur la vitesse du site. Pour les grands sites, certains d’entre eux ne sont pas si faciles à mettre en œuvre. Et selon la façon dont votre site est conçu, certains peuvent avoir plus d’impact que d’autres. Cela ne veut pas dire que vous avez une excuse pour ne pas faire ces choses – ce sont toutes les meilleures pratiques et elles aident toutes. Mais ils ne représentent pas l’ensemble de la vitesse du site.
Dans cet esprit, voici une “lecture sceptique” de chacune des règles de PageSpeed Insights.
Tests axés sur la réduction de l’utilisation de la bande passante
| Régner | Lecture sceptique |
|---|---|
| Optimiser les images | À moins que vous n’ayez d’énormes images, cela pourrait ne pas être un gros problème. Il s’agit uniquement de mesurer si les images peuvent être davantage compressées, et non si vous en chargez trop. |
| Activer la compression | La compression est facile. Vous devriez l’utiliser. Cela peut également ne pas faire beaucoup de différence à moins que vous n’ayez (par exemple) d’énormes fichiers JavaScript en cours de chargement. |
| Réduire le HTML | Ne réduira probablement les frais généraux que de dizaines de Ko. La latence aura un impact plus important que la taille de la réponse. |
| Minifier le CSS | Ne réduira probablement les frais généraux que de dizaines de Ko. La latence aura un impact plus important que la taille de la réponse. |
| Minifier JS | Probablement pas aussi important que de consolider JS en un seul fichier pour réduire le nombre de demandes à faire. |
Tests axés sur la réduction de la latence
| Régner | Lecture sceptique |
|---|---|
| Tirez parti de la mise en cache du navigateur | Mettons définitivement en cache nos propres fichiers. De nombreux fichiers qui pourraient bénéficier de la mise en cache sont probablement hébergés sur des serveurs tiers. Vous devrez les héberger vous-même pour modifier les heures de cache. |
| Réduire le temps de réponse du serveur | Le seuil du PSI est trop élevé. Il essaie également d’exclure la latence physique du serveur, au lieu de ne regarder que le temps qu’il faut au serveur pour répondre une fois qu’il a reçu une demande. |
| Évitez les redirections de page de destination | Oui. |
| Éliminer JavaScript et CSS bloquant le rendu dans le contenu au-dessus de la ligne de flottaison | Une préoccupation valable, mais peut être extrêmement difficile. Il n’est pas nécessaire d’avoir zéro requête en plus du chargement initial de la page pour afficher le contenu au-dessus de la ligne de flottaison pour atteindre la plupart des objectifs de performances. |
| Privilégier le contenu visible | En fait assez important. |
Ne les considérez pas comme le dernier mot sur les performances du site ! Indépendamment de ces tests, voici quelques éléments de réflexion. Certains ne sont pas couverts du tout par PageSpeed Insights, et certains ne sont couverts qu’à moitié :
- Mise en cache du contenu tu contrôler.
- Réduire la quantité de contenu que vous chargez à partir de domaines tiers.
- Réduire le temps de réponse du serveur au-delà du minimum requis pour réussir le test de PageSpeed Insights.
- Rapprocher le serveur de l’utilisateur final. Fondamentalement, utilisez un CDN.
- Réduction des demandes de blocage. S’assurer que vous utilisez HTTP2 vous aidera ici.
Comment commencer à s’améliorer
La mesure
Les captures d’écran de cet article ont été créées avec Chrome DevTools. Il est intégré au navigateur et vous permet d’inspecter exactement ce qui se passe lorsqu’une page se charge.
Au lieu de faire confiance à l’outil Pagespeed Insights, continuez et chargez votre page dans Chrome. Découvrez comment il fonctionne. Regardez quelles demandes réellement semblent prendre plus de temps. Souvent, la réponse sera évidente : trop de temps sera consacré au chargement des publicités, par exemple.
Établissement d’objectifs
Si un score PageSpeed Insights parfait n’est pas votre objectif, vous devez savoir quel sera votre objectif. Ceci est important, car cela vous permet de comparer les performances actuelles à cet objectif. Vous pouvez voir si la réduction des besoins en bande passante répondra réellement à votre objectif, ou si vous devez également faire quelque chose pour réduire la latence (utilisez un CDN, gérez moins de requêtes, chargez d’abord le contenu hautement prioritaire).
Prioriser
Il est important de prioriser les “correctifs” de vitesse de page – ce n’est pas le seul type de priorisation. Il y a aussi la question de ce qui doit réellement être chargé. PageSpeed Insights essaie de déterminer si vous accordez la priorité au contenu au-dessus de la ligne de flottaison. C’est une excellente cible. Ce n’est pas non plus une évaluation parfaite; il pourrait être plus facile de diviser le contenu en chemins “critiques” et “non critiques”, indépendamment de ce qui est ostensiblement au-dessus du pli.
Par exemple : si votre site dépend des revenus publicitaires, vous pouvez charger tout le contenu de la page et commencer ensuite à charger les annonces. Trouver comment servir moins est un défi que vous et votre équipe devez relever au mieux. Après tout, PageSpeed Insights est une solution unique.
Conclusion
Jusqu’à présent, l’histoire a été que PageSpeed Insights peut être utile, mais il existe des moyens plus intelligents d’évaluer et d’améliorer la vitesse du site. Un score parfait ne garantit pas un site rapide.
Si vous souhaitez en savoir plus, je vous recommande fortement de consulter le site d’Ilya Grigorik et plus particulièrement ce jeu d’introduction ancien mais bon. Grigorik est ingénieur en performance Web chez Google et un très bon communicateur sur les problèmes de vitesse des sites.
