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

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. 

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

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 ?