Performance Web – Indicateurs de mesure

Lors du dernier billet, nous avons vu où et comment mesurer la performance de nos sites Web. Mais que faire de toutes les données obtenues ? Tour d’horizon des principaux indicateurs de mesure.

<- Partie 2 : Outils de mesure Partie 4 : L’impact de TCP ->

Après analyse d’une URL sur un des sites cités dans le billet 2, on obtient une flopée d’indicateurs. Certains doivent attirer rapidement notre attention :

Document complete - Fully loaded - Webpagetest.org

Document complete – Fully loaded – Webpagetest.org

Premier critère impactant l’expérience utilisateur : le temps de chargement. On voit ici les 2 chargements de page (first view, repeat view), et le temps nécessaire. Deux étapes principales sont évoquées ici :

  • Document complete : cette étape a lieu lorsque le navigateur lance l’événement « onLoad ». Cela intervient généralement lorsque l’ensemble du contenu statique est chargé.
  • Fully loaded : cette étape survient après le « onLoad », lorsque WebPageTest ne détecte plus d’activité réseau durant 2 secondes. La page est donc chargée entièrement, ressources dynamiques compris. À noter que les 2 secondes d’inactivité réseau ne sont pas retenues dans le chiffre affiché.
Indicateurs de mesure - WebpageTest.org

Indicateurs de mesure – WebpageTest.org

Sur cette 2e image, un peu plus d’indicateurs. On retrouve le Load Time, qui correspond à l’étape « Document complete » vue précédemment. Le « Start render » indique la durée d’attente de l’utilisateur avant de voir quelque chose s’afficher à l’écran.

« DOM éléments » et « Visually complete » parlant d’eux-mêmes, attardons-nous sur 2 indicateurs très importants : le Speed Index et le Time To First Byte.

Speed Index

La documentation WebPageTest définit le speed index ainsi :

The Speed Index is the average time at which visible parts of the page are displayed.  It is expressed in milliseconds and dependent on size of the view port.

Le speed index prend en compte la progression visuelle du chargement de la page, et calcule un score : à quelle vitesse le contenu est rendu. On obtient un graphique de la forme suivante :

Speed Index

Speed Index

Au-delà de la formule de calcul un poil barbare, le graphique est assez parlant. À gauche, on peut voir que plus de 90% du contenu est chargé en environ 1 seconde. À droite, au contraire, seuls 20% du site sont affichés lors de la 1re seconde, et il faut attendre près de 10 secondes pour obtenir un rendu visuel proche du site de gauche.

De fait, on aura une meilleure expérience utilisateur en navigant sur le site de gauche, avec une meilleure impression de vitesse. On peut considérer qu’un Speed Index entre 500 et 1000 est un bon objectif. À noter que sur l’ensemble des top 300.000 sites, le Speed Index moyen avec une connexion câble de 5Mbps est de 4493 (au 15 mai 2013, source httparchive.org)

Speed Index Distribution

Speed Index Distribution

Bien qu’assez révélateur, le Speed Index ne devrait pas s’utiliser seul. Il peut être mis en regard d’une capture vidéo, d’une étude des événements de repaint, et peut donner lieu a une analyse plus précise du CSS Critical Path (à venir dans un prochain billet)

On notera que le Speed Index est l’indicateur le plus en correlation avec un render time ou un load time élevé :

Speed Index Correlation - httparchive.org

Speed Index Correlation – httparchive.org

Time to First Byte

Le Time to First Byte (TTFB) a lui aussi un impact direct sur l’expérience utilisateur. Il indique le temps d’attente nécessaire à la réception du tout 1er byte de données. Avant cette réception, l’internaute ne voit qu’un écran blanc.

Le TTFB est souvent appellé « temps back-end », car un TTFB élévé reflète la plupart du temps des soucis serveur. Les origines peuvent être diverses, par exemple :

  • Faibles ressources RAM / CPU disponibles (merci le serveur mutualisé)
  • Matériel déficient
  • Serveur DNS peu performant
  • BDD mal configurée (indexes)

Cela peut aussi provenir d’un temps de réponse DNS important (serveur DNS mal configuré, serveurs très éloignés géographiquement…)

Le TTFB est très facilement identifiable sur les waterfalls. Avançons donc au point suivant.

Waterfall Patterns

Les waterfalls sont une symbolisation graphique du chargement dans le temps des différentes ressources d’un site internet. Ainsi on peut voir facilement quel type de ressources est chargé à quel moment, et pendant combien de temps.

Les waterfalls sont visibles sur les différents sites cités lors du dernier billet, mais aussi dans les devtools des principaux navigateurs.

C’aussi un bon indicateur, d’autant que certains patterns identifient facilement un problème :

Waterfall Pattern - TTFB important

Waterfall Pattern – TTFB important

 

Waterfall Patterns - Poids important des ressources - Source Pat Meenan

Waterfall Patterns – Poids important des ressources – Source Pat Meenan

 

Waterfall Patterns - Ressource lente et bloquante - Source Pat Meenan

Waterfall Patterns – Ressource lente et bloquante – Source Pat Meenan

 

Répartition des assets

Enfin, un dernier petit truc utile : la répartition des assets. Certains ressources sont plus « coûteuses » que d’autres et ont plus d’impact sur la performance web.

Sur l’image ci-dessous, on peut voir la répartition des images, feuilles de style, fonts… en terme de requêtes ou de poids.

Répartition des assets - webpagetest.org

Répartition des assets – webpagetest.org

Voilà pour ce 3e billet. Le prochain billet traitera de l’impact de TCP. En effet, ce protocole est complexe et son fonctionnement a une incidence directe sur la performance. Au programme, bande passante, temps de latence, congestion, etc.

<- Partie 2 : Outils de mesure Partie 4 : L’impact de TCP ->

2 comments

Laisser un commentaire

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