Sites plus rapides : au-delà de la vitesse des pages

Sites plus rapides : au-delà de la vitesse des pages

Sites plus rapides : au-delà de la vitesse des pages

PageSpeed Insights de Google est un outil facile à utiliser qui permet de tester si une page web peut être plus lente qu’elle ne devrait l’être. Il donne un score pour quantifier la performance de la page. Comme ce score est concret, le score de PageSpeed Insights est souvent utilisé comme mesure de la performance du site. Comme pour le PageRank il y a quelques années, les gens veulent optimiser ce chiffre simplement parce qu’il existe. En fait, Websterdata a un article populaire sur ce sujet : How to Achieve 100/100 with the Google Page Speed Test Tool.

Pour les petits sites sur des CMS courants (pensez à WordPress), cela peut être réalisé. Si c’est votre cas, 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 l’objet de ce billet. Je voudrais faire trois remarques :

La latence peut nuire à la charge plus que la bande passante
Les résultats de PageSpeed Insights ne doivent pas être pris au pied de la lettre
L’amélioration commence par la mesure, la fixation d’objectifs et l’établissement de priorités

J’écris en pensant aux praticiens du référencement. Je vais passer sur les éléments les plus techniques. Vous devriez partir avec suffisamment de recul pour commencer à poser les bonnes questions. Et vous pourrez ainsi faire de meilleures recommandations.

Avertissement : HTTP2 améliore certaines des questions abordées dans ce billet. En particulier, les requêtes multiples vers le même serveur sont moins problématiques. Ce n’est pas une panacée.

La latence peut nuire davantage aux temps de chargement qu’à la bande passante

Un premier coup d’œil aux règles de PageSpeed Insights pourrait vous faire penser qu’il s’agit de servir moins d’octets à l’utilisateur. Minimiser, optimiser, compresser. La taille n’est qu’une partie de l’histoire. Il faut aussi du temps pour que votre requête atteigne simplement un serveur. Et puis il faut du temps pour que le serveur vous réponde !

Que se passe-t-il lorsque vous faites une demande ?

Si un utilisateur tape une URL dans la barre d’adresse d’un navigateur et appuie sur la touche Entrée, une demande est faite. Beaucoup de choses se passent lorsque cette demande est faite. La toute dernière partie de ce processus consiste à transférer le contenu demandé. Seule cette dernière partie est affectée par la largeur de bande et la taille du contenu.

Pour répondre à une demande, il faut suivre (plus ou moins) ces étapes :

Trouver le serveur
Se connecter au serveur
Attendre une réponse
Recevoir une réponse

Chacune de ces étapes prend du temps, et pas seulement la dernière. Les trois premières sont indépendantes de la taille du fichier ; il s’agit en fait de coûts constants. Ces coûts sont encourus à chaque demande, que la charge utile soit un minuscule 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é, il faudra plus de temps que cela pour transférer les données. 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 nécessaire 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 la seule façon de réduire le temps nécessaire pour atteindre le serveur.

Quelle est l’importance de cette mesure ?

Consultez ce tableau (tiré de Chrome’s DevTools) :

La durée de vie d’une requête, mesurée par Chrome Dev Tools.

Toutes les valeurs dans l’encadré rouge sont ce que je considère comme « latence ». Elles totalisent environ 220ms. Le transfert réel du contenu a pris 0,7 ms. Aucune compression ou réduction de la taille des fichiers ne pourrait y remédier ; la seule façon de réduire le temps pris par la requête est de réduire la latence.

Ne faut-il pas 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 correspond à une page web, le navigateur découvrira généralement qu’il doit charger plus de ressources pour rendre la page. Il peut s’agir de CSS, de JavaScript ou de fichiers de police. Il doit suivre de manière récursive les mêmes étapes que celles énuméré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 toujours 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, certaines d’entre elles 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 des bonnes pratiques, et elles sont toutes utiles. Mais elles ne représentent pas l’ensemble de la vitesse du site.

Dans cette optique, 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ègle

Lecture sceptique

Optimiser les images

A moins d’avoir des images géantes, ce n’est pas un problème. Il s’agit seulement de mesurer si les images pourraient être davantage compressées – et non pas si vous en chargez trop.

Activer la compression

La compression est facile. Vous devriez l’utiliser. Elle ne fera pas non plus une grande différence, sauf si vous avez (par exemple) d’énormes fichiers JavaScript à charger.

Minifier le HTML

Ne réduira probablement les frais généraux que de quelques dizaines de KB. La latence aura un impact plus important que la taille de la réponse.

Réduire le CSS

Ne réduira probablement les frais généraux que de quelques dizaines de KB. La latence aura un impact plus important que la taille de la réponse.

Minimiser le JS

Probablement pas aussi important que de regrouper le SJ en un seul dossier pour réduire le nombre de demandes qui doivent être faites.

Tests axés sur la réduction de la latence

Règle

Lecture sceptique

Exploiter la mise en cache du navigateur

Il faut absolument mettre en cache nos propres fichiers. Beaucoup de fichiers qui pourraient bénéficier d’une mise en cache sont probablement hébergés sur des serveurs tiers. Il faudrait les héberger soi-même pour modifier les heures de mise en cache.

Réduire le temps de réponse des serveurs

Le seuil de l’ISP est trop élevé. Il tente également d’exclure la latence physique du serveur, en ne tenant compte que du temps de réponse du serveur lorsqu’il reçoit une requête.

Éviter les redirections de pages d’atterrissage

Oui.

Éliminer les JavaScript et CSS qui bloquent le rendu dans les contenus au-dessus du pli

Une préoccupation valable, mais qui peut être frustrante et difficile. Il n’est pas nécessaire d’avoir zéro demande en plus du chargement initial de la page pour rendre un contenu supérieur à la moyenne pour atteindre la plupart des objectifs de performance.

Prioriser le contenu visible

En fait, c’est assez important.

Ne les considérez pas comme le dernier mot sur la performance du site ! Indépendamment de ces tests, voici quelques éléments de réflexion. Certains ne sont pas du tout couverts par PageSpeed Insights, et d’autres ne le sont qu’à moitié :

La mise en cache du contenu que vous contrôlez.
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 passer le test de PageSpeed Insights.
Rapprocher le serveur de l’utilisateur final. Fondamentalement, utilisez un CDN.
Réduire les demandes de blocage. S’assurer que vous utilisez HTTP2 vous aidera ici.
Comment commencer à s’améliorer
Mesure

Les captures d’écran de ce billet 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, allez-y et chargez votre page dans Chrome. Découvrez comment il fonctionne. Examinez les demandes qui semblent prendre plus de temps. La réponse est souvent évidente : le chargement des annonces, par exemple, prend trop de temps.

Définition d’objectifs

Si un score parfait de PageSpeed Insights n’est pas votre objectif, vous devez savoir quel sera votre but. C’est important, car cela vous permet de comparer vos performances actuelles à cet objectif. Vous pouvez voir si la réduction des besoins en bande passante vous permettra réellement d’atteindre votre objectif, ou si vous devez également faire quelque chose pour réduire la latence (utiliser un CDN, traiter moins de demandes, charger d’abord le contenu hautement prioritaire).

Priorités

Il est important de donner la priorité aux « corrections » de la vitesse des pages – ce n’est pas le seul type de priorité. Il y a aussi la question de ce qui doit être chargé. PageSpeed Insights essaie de déterminer si vous accordez la priorité à un contenu supérieur à celui de la page précédente. C’est un objectif très intéressant. Ce n’est pas non plus une évaluation parfaite ; il pourrait être plus facile de diviser le contenu en deux catégories, « critique » et « non critique », indépendamment de ce qui se trouve ostensiblement au-dessus du pli.

Par exemple : Si votre site repose sur les recettes publicitaires, vous pouvez charger tout le contenu de la page et ne commencer à charger les publicités qu’ensuite. La meilleure façon de relever le défi est de trouver un moyen de servir moins de clients. Après tout, PageSpeed Insights est une solution universelle.

Conclusion

Jusqu’à présent, l’histoire a montré 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 vivement de consulter le site d’Ilya Grigorik, et plus particulièrement ce vieux mais bon jeu d’introduction. Grigorik est un ingénieur en performance web chez Google et un très bon communicateur sur les questions de vitesse des sites.

À propos de BenjaminEstes –

Ben est un consultant principal qui a rejoint Distilled en 2010. Il se concentre maintenant sur le renforcement de notre équipe. Grâce à des formations de groupe et à des consultations internes, il guide les membres de l’équipe dans leurs changements pour nos clients.

52
29