Il est l'heure de prendre du recul sur le Speed Index

Le speed index est un indicateur de référence pour juger l'expérience utilisateur sur un site web. Différentes méthodes de calcul et nombreuses variables à prendre en compte...

Toute société ayant une activité digitale (transactionnelle ou non) doit se soucier de l’expérience de navigation de ses internautes. Cette notion d’expérience utilisateur bien qu’abstraite, a une place centrale dans une activité et représente un véritable enjeu stratégique pour une enseigne et son site internet. La réputation de la marque, le positionnement du site dans les moteurs de recherches et - dans le cas de site e-commerce- la conversion sont en jeu.

Afin de juger de cette qualité d’expérience, il est indispensable de sélectionner des indicateurs webperf et d’en faire des KPI à suivre dans le temps. Le speed index en fait partie.

Le speed index établit pour une page donnée un score en fonction de la vitesse d’affichage des éléments situés au-dessus de la ligne de flottaison. « La ligne de flottaison est une ligne virtuelle en dessous de laquelle le contenu d’une page Internet n’apparait plus à l’écran ». (Source : definitions-marketing.com).

Indicateur webperf de référence, il est aujourd’hui nécessaire de prendre du recul sur le Speed Index, sur sa méthode de calcul, son contexte d’utilisation et son usage dans le cas de classement par exemple.

Des scores speed index qui attisent la curiosité

Il est indispensable de replacer cet article dans son contexte.

Fin 2017 début 2018 nous avions publié deux études webperf sur le Black Friday et les soldes d’hiver. Celles-ci ont consisté à mesurer et classer 25 sites e-commerce selon les temps de chargement ressentis par les internautes (DOMContentLoaded) et leur vitesse d’affichage (Speed Index). Là où les temps de chargement semblaient cohérents avec les résultats d’autres études similaires, le score speed index obtenu pour certains sites semblait nettement inférieurs.

En parallèle, le site de Oui.sncf clôturait de nombreux panels à cause de scores trop élevés. Les équipes opérationnelles (utilisatrices de nos solutions) ont entrepris un plan d’optimisation de la webperformance visant à améliorer l’expérience de leurs utilisateurs. Nous avons donc accompagné les équipes opérationnelles pour comprendre et analyser les différentes méthodes de calcul. 

Speed index : un score multiplié par 18 selon la méthode de calcul

Il existe différentes méthodes de calcul du Speed Index. Comment choisir l’une plutôt que l’autre ? Cela dépend de votre vision de l’expérience utilisateur. En effet, le calcul du speed index n’est pas une science exacte, il repose sur des convictions et des partis pris en termes d’UX. Toutefois, toutes les méthodes de calcul aboutissent à la même conclusion : plus le score est bas, plus la page est performante en termes de vitesse d’affichage.

Le recours aux webservices

Une première méthode consiste à établir le score Speed Index d’une page via les webservices de WebpageTest. Cette méthode de calcul repose sur une analyse du remplissage visuel de la page.

Pour les plus téméraires, la formule de calcul est la suivante : 


Dans les faits :
Pour une URL testée, un maximum de screenshots de la page est fait, depuis le début jusqu’à la fin de son chargement. L’ensemble des screens forment ce que l’on appelle un filmstrip. On va attribuer un score en fonction du remplissage de la page à chacun des screenshots. La somme de tous ces scores donnera le score speed index de la page. Le speed index est bien un score et non un indicateur temps !

Lors du test de l’URL, 3 indicateurs temps vont être déterminés :

  • Le Start Render : il correspond au 1er élément visible sur la page. C’est lui qui détermine le début du calcul du speed index. Il ne faut pas le confondre avec l’obtention du 1er octet qui lui a trait aux flux de données sur la page. 
  • Le Visually Complete : c’est le temps écoulé jusqu’à ce que la page soit 100% chargée sur le plan visuel (au-dessus de la ligne de flottaison). 
  • Le temps de chargement total : il est indispensable car permet de définir quand la page est complètement chargée (y compris les éléments non visibles). C’est en effet grâce au temps de chargement total que la progression de remplissage (en %) peut être établie pour chacun des screens. Sans lui, il est impossible d’établir le Visually Complete. Le 1er screen à 100% détermine de ce fait le Visually Complete. 

Plus précisément, pour calculer le score de remplissage de la page, la formule du speed index se focalise sur l’aire au-dessus de la courbe de progression (cf schéma plus bas).

Cela revient donc à calculer la somme de :

Elapsed x(1-progress/100)
Sachant que :
- Elapsed = l’écart entre deux screenshot
- Progress = le taux de remplissage de la page
Ce graphique est le résultat du tableau ci-dessous.


Le recours au Javascript
Au chargement de la page, chaque élément appelé est analysé selon :

  • Son positionnement sur la page (selon la ligne de flottaison)
  • Sa taille (en pixel)
  • Sa place (le % qu’il représente par rapport à l’intégralité de la page)
  • Sa position dans la cascade
Dès lors un algorithme avancé va permettre d’établir le score speed index de la page.

Cette seconde méthode de calcul repose également sur l’aspect visuel de la page mais se base ici sur la cascade de chargement.

 

Pourquoi ces deux méthodes génèrent-elles des scores différents ? Explication avec la Home Page du site d’Intersport.

Nous avons testé la home page d’Intersport avec ces deux méthodes de calcul afin d’en comparer les résultats. Avec la méthode des webservices, le site d’Intersport obtient un Speed Index de 3919. Avec la méthode utilisant du JavaScript, le score est de 217 soit 18 fois moins.

Ces écarts de scores proviennent essentiellement d’une différence d’interprétation des images entre les 2 méthodes de calculs.

1er Constat : La Home Page d’Intersport dispose d’un carrousel d’image. A chaque rotation du carrousel, un nouveau visuel apparait. Cela semble pénaliser la méthode de calcul via webservices.

2ème constat : On constate grâce aux frames et à l’affichage en cascade qu’Intersport a vraiment fait des efforts concernant l’optimisation de ses images. Au chargement d’un visuel, une première version dégradée de l’image, donc très légère (12 Ko) est très rapidement appelée. On a constaté les paramètres suivant dans l’URL de l’image : « ?wid=50&qlt=85 » .

Puis ils ont audacieusement recours à un Javascript permettant de flouter les visuels. Cet effet fait office de transition et permet d’arriver à la version définitive du visuel (plus lourde :180Ko) de venir se superposer et de remplacer la version dégradée de l’image (paramètres de l’image « ?wid=1380&qlt=85 »  .

Des scores différents : Explication

La méthode de calcul via JavaScript ne revient jamais « en arrière » là où les webservices vont parfois revoir la progression de chargement à la baisse.

Nous pouvons affirmer que la méthode via Javascript ne prend pas en compte le changement de visuel. En cas de rotation du carrousel, le score n’est pas impacté car ce mode de calcul considère que cette zone de la page a déjà été chargée. Il en est de même pour la superposition de visuels. Qu’importe le chargement d’une seconde version du visuel, cette zone a déjà été chargée et donc le speed index attribué. En revanche, la méthode de calcul par webservices va interpréter la rotation du carrousel ou encore cette superposition de visuels comme un chargement non abouti de la zone en question. Cela génère donc une baisse du pourcentage de remplissage de la page et donc un nouveau calcul du Speed Index pour ce screenshot. D’ailleurs, lorsque l’on regarde les différents frames du chargement, on constate des régressions du pourcentage de remplissage (Cf visuel 1). 



Certains diront que la rotation du carrousel ne doit pas être synonyme de régression, d’autres qu’une version dégradée de l’image peut impacter la qualité perçue par l’internaute. Une fois encore, il n’y a pas de meilleure méthode de calcul ! Pour autant, combien de sites ont été mal notés lors de panels du fait de dispositifs marketing ou d’actions d’optimisations non appréciées à leur juste valeur ?

Calcul du speed index : d'autres variables à prendre en compte

En plus des différentes méthodes de calcul, le Speed Index repose sur une multitude de paramètres, liés notamment au contexte de navigation de l’internaute:

  • La bande passante : les performances des pages sont impactées en cas de bande passante faible ou dégradée.
  • La localisation de l’internaute : suivant le lieu d’hébergement du site et la localisation de l’internaute les performances d’une page sont différentes et ce malgré le recours à un CDN.
  • La résolution de l’écran : un écran 4K est plus exigeant en termes de qualité de visuels. Le poids des images en haute définition a un impact sur les indicateurs webperf tels que le Speed Index.
  • Le device : desktop, mobile, tablette … il y a autant de lignes de flottaison que de modèles de device.
  • Le trafic du site internet : un trop grand nombre d’internautes sollicite la plateforme la rendant plus lente en termes de performance.
Les points clés à retenir

Le speed index est un indicateur fiable toutes choses égales par ailleurs. WebPageTest, Javascript ou encore Google Speedline, qu’importe la méthode de calcul, l’objectif est de suivre les indicateurs sélectionnés dans le temps afin d’avoir une réelle visibilité sur les améliorations et régressions du site internet.

Comme tous les indicateurs, le Speed Index n’est pas une fin en soi mais un moyen de piloter la webperformance et l’expérience utilisateur. Il est primordial de le contextualiser et de le mettre en parallèle d’autres indicateurs clefs tels que le DomContentLoaded ou le Start Render afin de constituer la boîte à outil du parfait webperformer. 

Annonces Google