Perceptual Speed Index : définition et axes d’amélioration

Introduction

Le Perceptual Speed Index est un indice de performance de chargement de page qui indique à quelle vitesse le contenu d’une page commence à être visible. Plus le score est est proche de zéro, mieux c’est. L’outil d’audit Lighthouse utilise SpeedLine pour tester cet indice.

Pourquoi améliorer cet indice me demandez-vous ?

"Une étude Google montre la corrélation évidente entre le temps de chargement et le taux de rebond : pour un temps de chargement mobile qui passe de 1 seconde à 10 secondes, le taux de rebond augmente de 123%. Plus encore, 1 visite sur 2 est abandonnée au-delà de 3 secondes de chargement sur un site mobile en 3G." - source

Si vous en déduisez la même chose que moi, réduire la perception du temps de chargement fait baisser le taux de rebond et donc aide à l’amélioration du taux de conversion.

Le Speed Index a été initialement introduit par WebPageTest.org. Cet outil est encore utilisé aujourd’hui par Google pour son outil Test My Website. Google teste un site web mobile sous différents types de connexion comme la 3G ainsi que les éléments qui peuvent impacter la vitesse de chargement comme le code source, JS, images etc. Vous obtenez alors un rapport assez light avec une comparaison par rapport à d’autres sites de la même thématique (ou industrie comme l’appelle Google).

 

C’était une parenthèse pour vous présenter le principe de fonctionnement et l’utilisation « grand public » qui en est faite par Google pour démocratiser le test Page Speed. Notre sujet du jour est bien d’améliorer notre score Perceptual Speed Index.

Comment améliorer le Perceptual Speed Index ?

Pour améliorer votre score, vous devez optimiser votre page pour charger plus rapidement (en tout cas visuellement). Deux axes principaux sont immédiatement évidents :

  • optimisation des contenus
  • optimisation du chemin critique du rendu (critical rendering path)

L’optimisation des contenus est évident : poids des images et éléments de page. L’optimisation du chemin critique du rendu l’est moins. Il s’agit, pour simplifier, de comprendre comment les navigateurs en arrive au rendu d’une page. Comment ils convertissent le HTML, CSS et Javascript en pixels visibles sur nos écrans. Comprendre le chemin critique du rendu permet ensuite d’avoir les bons réflexes pour créer des pages ou sites qui offrent de bonnes performances.

Concrètement, voici comment un navigateur procède lorsqu’il reçoit les donnés d’une page :

  1. Traiter le balisage HTML et créer l’arborescence du modèle DOM.
  2. Traiter le balisage CSS et créer l’arborescence du modèle CSSOM.
  3. Combiner les modèles DOM et CSSOM pour créer une arborescence d’affichage.
  4. Exécuter la mise en page sur l’arborescence d’affichage pour calculer la géométrie de chaque nœud.
  5. Afficher chaque nœud sur l’écran
L'optimisation du chemin critique du rendu est le fait de réduire la durée totale des étapes mentionnées dans la séquence ci-dessus.

Par défaut, le code CSS est interprété comme une ressource qui empêche l’affichage. Ceci signifie que le navigateur interrompt l’affichage de tout contenu traité jusqu’à ce que le modèle CSSOM soit construit. Pour être optimal, il faut donc conserver un code CSS simple et le transmettre le plus rapidement possible au navigateur. Splitter le code CSS en type de média permet en partie de gagner en performance :

<link href="style.css"    rel="stylesheet">
<link href="style.css"    rel="stylesheet" media="all">
<link href="portrait.css" rel="stylesheet" media="orientation:portrait">
<link href="print.css"    rel="stylesheet" media="print">

Lorsque vous déclarez vos feuilles de style, soyez très attentif au type et aux requêtes de média, car ils ont un réel impact sur les performances du chemin critique du rendu.

  • La première déclaration empêche l’affichage car elle respecte toutes les conditions.
  • La seconde déclaration du style empêche également l’affichage : ‘all’ est le type par défaut, et si vous ne précisez pas le type, il sera implicitement défini sur ‘all’. De fait, la première et la seconde déclaration sont donc des équivalences.
  • La troisième déclaration a une requête média dynamique qui sera évaluée lors du chargement de la page. Selon l’orientation de l’appareil utilisé, portrait.css peut empêcher ou non l’affichage.
  • La dernière déclaration n’est prise en compte que lorsque la page est imprimée. Elle n’empêchera donc pas l’affichage de la page lors du premier chargement.

Qu’il y ai affichage ou non, toutes les ressources CSS seront dans tous les cas téléchargées.

Un script JS peut également bloquer la construction DOM d’une page et retarder son affichage. Pour une performance optimale, il faut utiliser un fichier JS asynchrone et éliminer tout fichier inutile au chemin critique du rendu.

Important : un script JavaScript bloque systématiquement la construction du DOM sauf s'il est indiqué comme asynchrone.

Lorsque l’analyseur HTML rencontre une balise de script, il suspend le processus de construction du DOM, puis cède le contrôle au moteur JavaScript. Lorsque celui-ci a fini de s’exécuter, le navigateur reprend sa tâche au point où il l’a laissée, puis reprend la construction du DOM. Cela retarde donc l’affichage initial de la page.

Le JavaScript permettant de modifier le CSSOM, si un script demande un modifier un CSS alors que le CSSOM n’est pas terminé de construire, le DOM est également bloqué. On entre en « concurrence ». L’emplacement des JS dans la page est donc important. un fichier JavaScript intégré ou en fichier externe bloquent dans tous les cas l’analyseur du navigateur. Néanmoins, utiliser le mot-clé async dans un fichier externe débloque l’analyseur.

<script async src="exemple.js"></script>

Notez que Google Analytics mesure parfaitement la construction d’un document DOM et permet donc de déterminer quelle page peut bénéficier d’une optimisation.

Conclusion

Afin de réduire le chemin critique de rendu, il faut réduire les éléments externes critiques.

Pour ceci, ayez toujours la démarche suivante :

  1. Analysez le chemin critique : nombre de ressources et octets à télécharger.
  2. Réduisez le nombre de ressources critiques : supprimez les ou définissez les comme asynchrones
  3. Optimisez l’ordre de chargement des ressources critiques restantes : téléchargez en priorité tous les éléments critiques pour réduire la longueur du chemin critique. Prioriser dans le code les éléments.

 

Vous avez aimé ? Partagez 🙂

3 commentaires sur “Perceptual Speed Index : définition et axes d’amélioration

  1. Marc Répondre

    Très instructif merci, et pas seulement pour le SEO ! Est-ce qu’on peut aussi en déduire qu’un document dont le code HTML est valide fait partie des axes d’amélioration ? Par exemple un code avec des balises mal fermées (une section ouverte et pas fermée) peut-elle ralentir la représentation du DOM ? Sinon je pense aussi aux bonnes pratiques d’accessibilité, comme toujours fournir les attributs width et height d’une image pour que le navigateur lui réserve l’espace lors de l’affichage de la page…

    • admin Auteur d'articleRépondre

      Bonjour Marc,

      En effet, ce n’est pas que lié au référencement naturel mais ça touche également l’expérience utilisateur. Tout ce qui n’est pas dans les normes est globalement à éviter. Un code HTML non valide va ralentir la construction du DOM mais ça sera à peine mesurable. Ce n’est pas à mon sens là dessus qu’on va énormément gagner en performance. Dans tous les cas, un code propre, que ce soit HTML ou CSS est toujours à préconiser 🙂

  2. Antoine Tissier Répondre

    Super article, merci 🙂
    A noter que Google Analytics ne mesure pas lui même le temps de construction du DOM. Il passe par une API mise à disposition par les navigateurs.

    De mémoire GA passe par le navigation timing API qui met à disposition les métriques dans cet objet :
    window.performance.timing

    Il est déjà arrivé que les métriques renseignées ici soit fantaisistes (un bug sur une ancienne version de Firefox), et certains navigateurs ne mettent pas à disposition ces informations (de mémoire Safari notamment).

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *