Pourquoi et comment travailler la webperf des sites ?

Le temps de chargement est un sujet à la mode en SEO. Il est élu "sujet tech" de l'année 2018, et le sera encore en 2019. Le 17 janvier 2018, Google annonçait l'arrivée prochaine du "Speed update" : la vitesse d'affichage d'une page deviendrait officiellement un critère de classement. Le 9 juillet 2018, Google déployait sa mise à jour... qui a fait autant de bruit dans les SERP que le "mobileggedon" en avril 2015 (c'est-à-dire un silence quasi complet). La Speed Update a-t-il fait pschiit ? Est-ce plutot abracadabrantesque ? Faut-il mettre un pognon de dingue dans la "web performance" ? Est-ce une révolution qui n'en a pas l'air ? Réponse dans cet article...

Par Madeline Pinthon

Pourquoi s'intéresser à la vitesse des sites ? Comment le faire ? Que mesurent les outils mis en avant par Google et que valent les recommandations présentes ? Voici les questions auxquelles tentera de répondre cet article.

Un contexte qui évolue : des sites plus lourds, des connexions inégales

Un constat est aujourd'hui évident : les sites web sont devenus de plus en plus lourds. Ils font appel à de plus en plus de ressources, le poids a augmenté, le nombre de requêtes a augmenté, les JavaScript sont eux aussi de plus en plus lourds.

Fig 1. Poids des JavaScript internes et externes depuis 2011. Source : https://httparchive.org

En parallèle, les connexions ADSL se sont stabilisées, la fibre n'est pas encore généralisée, les réseaux 3G sont souvent saturés. Et nou utilisons de plus en plus nos téléphones pour aller sur Internet...

Fig 2. Evolution des modes de connexion à Internet selon le baromètre du numérique en 2017.

Les téléphones sont certes plus performants... mais sont aussi très inégaux.

Fig 3. Délai pour parser et compiler 1Mo de fichier javaScript non compressé par appareil . Source : Addy Osmani, le coût du JavaScript en 2018.

Travailler la web performance est un réel challenge technique pour améliorer l'expérience utilisateur. Si vous allez sur une page qui pèse plus de 5 Mo avec un smartphone entrée de gamme en zone rurale, vous aurez intérêt à être patient...

Fig 4. Pourcentage des sites affichés en moins de 10 secondes par opérateur et strate de populations.

Nous ne pouvons pas agir sur la qualité du réseau, ni sur la qualité des smartphones mais cela n'empêche pas d'essayer d'offrir la meilleure expérience utilisateur possible en travaillant sur les pages web.

Avoir un site rapide : un intérêt pour le marketing, la technique et le SEO

La web performance (ou "webperf") dépasse largement le cadre du SEO. C'est un métier technique, un chantier complexe. Toutes les études s'accordent à le dire : un site rapide améliore l'expérience utilisateur. Qui dit site rapide dit généralement augmentation du chiffre d'affaire. On observe une meilleure rétention des utilisateurs : baisse du taux de rebond, augmentation de la durée de la visite, du nombre de pages vues, etc.

Un travail sur les web performances sous-entend également un travail sur l'infrastructure du site. Avoir un site rapide est souvent synonyme de soulager le serveur… donc d'être en mesure d'accueillir plus de visiteurs. Mathématiquement, c'est un calcul gagnant. Si le taux de conversion reste similaire mais que le nombre d'utilisateurs augmente, le chiffre d'affaire s'accroît.

Le SEO est également un bon moyen d'augmenter le nombre de visiteurs. Et comme nous sommes dans un monde bien fait, avoir un site rapide est un critère de positionnement pour Google. S'il est encore difficile de voir une corrélation directe entre la vitesse du site et l'évolution des positions sur un mot clé, il est néanmoins évident qu'un site rapide permet d'économiser de la bande passante pour Google… Sur un site rapide, Google pourra visiter plus de pages. Cela permet de gérer le budget de crawl et peut donc avoir un impact sur le référencement (même si, aujourd'hui, l'impact sur le positionnement est quasi nul).

Il est donc important d'effectuer un suivi des performances d'un site. Cela tombe bien, Google propose de nombreux outils pour le faire. Il existe également de nombreux outils sur le marché. Nous nous intéresserons principalement aux outils proposés par la société de Mountain View, car ils ont l'avantage d'être gratuits, et les SEO en ont déjà entendu parlé.

Comment mesurer la vitesse des sites : les indicateurs techniques sur le chargement

Il existe de nombreux outils et de nombreux indicateurs pour mesurer la vitesse d'un site. "Une page doit se charger en moins de 2 secondes". Qu'entend-on exactement par cela ? Qu'es-ce que le temps de chargement ? Historiquement, le temps de chargement correspondait à l'événement onload.

Lorsqu'une page est appelée, il existe de nombreuses étapes intermédiaires avant de la voir affichée à l'écran.

Fig 5. Les différentes étapes pour charger une page.

L'API Navigation.timing permet de récupérer toutes ces informations. Elle a l'avantage d'être compatible avec de nombreux navigateurs. Il est donc possible de collecter facilement ces informations, qui permettent également de cerner certains problèmes :

Votre serveur est-il lent à répondre ?
Ou bien est-ce plutôt l'affichage qui est en cause ?

Les indicateurs importants sont donc :

Response start : ou time to first byte, c'est le premier octet reçu ;
Response end : le document html est chargé, le navigateur a toutes les ressources pour commencer l'affichage de la page ;
Domcontentloaded : le document html a été chargé et analysé (mais pas certaines ressources comme les feuilles de styles, images, etc.) ;
Load : toutes les ressources sont chargées.

L'inconvénient de ces données chiffrées est qu'elles restent très techniques. Le Web a évolué, les technologies aussi et certaines informations sont devenues obsolètes. L'événement load, qui correspond donc au chargement de la page, n'est parfois que le point de départ si le site utilise un framework JavaScript.Une page peut avoir techniquement fini de charger, sans être utilisable pour l'utilisateur.

Par conséquent, si ces mesures ont le mérite d'exister et donnent une première idée des performances du site, elles ne sont plus suffisantes.

Il est plus pertinent de parler d'affichage de page que de chargement. Cela tombe bien, une nouvelle API permet d'obtenir des informations sur l'affichage d'une page. A noter que l'API n'est pas abandonnée, qu'il existe une 2e version encore en test :

Fig 6. Les éléments collections par la 2e version de l'API navigation timing.

Du chargement à l'affichage : les nouveaux indicateurs

L'API Paint Timing permet d'avoir des indicateurs concernant l'affichage ou le rendu d'une page. Les principaux sont :

First paint : le premier pixel affiché ;
First Contentful Paint : la navigation est visible ;

L’API est encore récente, tous les navigateurs ne la supportent pas. Elle n’est donc pas totalement déployable pour des tests RUM (Real User Monitoring).

Fig 7. Peu de navigateurs prennent aujourd'hui en compte l'API Paint timing.

Comme Chrome est un des rares navigateurs à le mesurer, l'information est disponible dans le CrUX, Chrome User Experience report. Il est par conséquent accessible dans Page Speed Insights.

De l’affichage à l’interaction

Il existe d’autres indicateurs assez prometteurs, qui prennent en considération la consommation de la batterie ou du processeur du téléphone, comme le First CPU Idle, le Time To Interactive ou le First Input Delay.

La plupart de ces chiffres sont visibles dans LightHouse.

Ces métriques ont le mérite se baser sur les indicateurs visuels, mais également de prendre en compte l’activité du CPU et du réseau...Or, nous l’avons vu tout au début, en plus des ressources appelées, le processeur et le réseau font partie des facteurs qui influencent le temps d’affichage d’un site. Ces mesures se rapprochent donc fortement de l’expérience utilisateur.

Le principal désavantage de ces statistiques est qu’elles sont encore difficiles à récupérer ou calculer, seul chrome est capable de le faire car ce sont des ingénieurs Google qui en sont à l'initiative. Leur définition et mode de calcul sont encore en phase de test et peuvent être modifiés.

Fig 8. Illustration des nouveaux indicateurs liés à l'affichage de la page.

Quels sont les meilleurs indicateurs ?

Il existe différents outils pour aider à optimiser la vitesse des sites. Les outils peuvent parfois donner des notes, et d'un outil à l'autre, un site peut être considéré comme rapide ou lent. Comme les outils n'utilisent pas les mêmes indicateurs, les notes seront différentes. On peut avoir un site rapide à afficher mais très long à charger complètement. Si un outil se base sur le début d'affichage, il sera rapide, si l'autre préfère le chargement complet, il sera lent.

Il est donc préférable d'utiliser différents indicateurs pour mesurer les performances :

TTFB : pour détecter les problèmes de serveur ;
FCP : pour mesurer le début d'affichage de la page ;
DomContentLoaded ou FirstMeaningfulPaint : la page est en partie chargée (pour les sites utilisant JQuery, le DCL est utile, pour ceux réalisés avec certains Framework JavaScript, le FMP est plus significatif) ;
Speed Index : nous n'en avons pas parlé jusqu'à maintenant, mais le SpeedIndex était le premier indicateur qui permettait de mixer les données de temps de chargement et l'affichage de la page.

Le SpeedIndex est présent sur l'outil Webpagetest, et repris par d'autres outils. Cet indicateur est abstrait. C'est un chiffre théorique dont voici la formule :

Fig 9. Illustration du calcul du speedindex : en abscisse : le temps passé, en ordonnée : le pourcentage du contenu affiché.

Dans un monde idéal, les pages devraient avoir un speed index inférieur à 1000. Cet objectif semble aussi ambitieux que le plan très haut débit en France (la fibre doit être entièrement déployée en France d'ici 2022).

Pourquoi sélectionner le SpeedIndex comme indicateur plutôt que le Time To Interactive ? Le SpeedIndex a fait ses preuves. Il existe depuis 2012, il est donc possible d’utiliser cet indicateur dans le temps et de voir l’évolution. Le TTI est, selon moi, encore trop récent. Cela dit, les meilleurs indicateurs sont ceux qui vous sont le plus utiles et qui vous parlent le plus. Chacun est donc libre de choisir ce qui lui convient mieux.

Outils lab ou outils RUM ?

Il existe deux types d'outils pour mesurer la vitesse des sites : les outils lab, ou synthétiques, et les outils RUM, pour Real User Monitoring. Les outils RUM permettent de collecter les informations des utilisateurs : ce sont donc les conditions réelles.

Les outils lab permettent de paramétrer et contrôler les conditions du tests : quelle vitesse de connexion, quel type d'appareil, quel pays... Il est possible de reproduire un test dans les mêmes conditions, ce qui permet un suivi dans le temps. Ils permettent également d'avoir des indicateurs spécifiques, comme le Speed Index.

Les outils RUM et lab sont donc complémentaires. Avant de lancer un médicament sur le marché, il est nécessaire de le tester en laboratoire. Avant de lancer des optimisations en production, il vaut mieux les tester avec des outils lab. De plus, ceux-ci sont largement moins coûteux que des outils RUM.

Il existe cependant un outil RUM disponible à moindre coût : Google Analytics. Grâce à lui, vous pouvez, sur un échantillon de page vues, connaître tous les indicateurs présents dans l'API Navigation.timing.

En couplant cela avec les autres dimensions disponibles dans l'outil, il est facile de :

Comparer les indicateurs par catégorie d'appareil ;
Identifier les pages les plus lentes ;
Regarder si certains pays ont des performances détériorées.

Mais également : connaître les modèles de téléphones utilisés par vos utilisateurs, les fournisseurs d'accès, les navigateurs,.. Comme tous ces facteurs ont un impact sur la vitesse d'affichage des sites, cela permet d'identifier les problèmes et de les prioriser.

Google Analytics a également le mérite de donner des répartitions, et pas seulement des moyennes. Google Analytics permet donc d'avoir une vision plus proche de la réalité.

Le point sur les outils et les indicateurs

Fig 10. Tableau récapitulatif des différents indicateurs de la webperf.

Les outils pour développeurs de Chrome dépendent du navigateur. Nous avons vu que les API Navigation Timing et Paint Timing étaient compatibles avec Chrome. Par conséquent, il est possible de récupérer toutes les mesures en utilisant la console.

Par exemple : performance.getEntriesByType('paint')

Si les informations sont récupérables en JavaScript, il est possible de les récupérer massivement, auprès de tous les utilisateurs, donc de les utiliser avec les outils RUM.

Par défaut, Google Analytics se limite principalement aux indicateurs de temps de chargement. Cependant, il est possible de le paramétrer pour obtenir des informations supplémentaires liées à l’affichage (FP, FCP,...) et aux utilisateurs. Les chrome dev tools font appel à LightHouse dans la partie audit.

Décryptage de PageSpeedInsights

PageSpeedInsights mélange des indicateurs en provenance de LightHouse, mais également du CrUX, rapport d'expérience utilisateur de Chrome (donc les chrome dev tools). C'est donc un mélange de données lab et de données RUM. PSI avait intégré les données du Chrome UX Report en janvier 2018. L'outil fournit donc aujourd'hui des chiffres réels en provenance des utilisateurs de Chrome. L'avantage de PSI sur le Chrome UX report est la fraîcheur des données : elles sont mises jour quotidiennement sur PSI, alors que les data set sont mis à jour mensuellement pour le CrUX.

Début novembre 2018, PageSpeedInsights (PSI) a fait peau neuve. Google a décidé de modifier les indicateurs mis en avant : ce ne sont plus le FCP et le DCL, mais le FCP et le FID.

Que mesure le First Input Delay (FID) ? Le temps écoulé entre une interaction avec le site (clic, scroll, etc.) et le temps de réponse du navigateur. L'information ne peut donc être collectée que par des utilisateurs (jusqu'à maintenant, notamment en JavaScript, les robots de Google ne faisaient pas d'interaction…). Elle est également très volatile : si l'utilisateur clique lorsque son processeur est déjà en pleine activité, le temps de réponse sera plus lent. Si l'utilisateur clique lorsque la consommation de CPU est faible, la réaction sera rapide. Le Time To Interactive peut donc devenir un indicateur essentiel.

PageSpeedInsights affiche donc plusieurs informations :

Celles de la page ;
Celles du site (Origin Summary)

L'information est présentée via un histogramme et un chiffre. Ce chiffre correspond au 90e centile pour le FCP : combien faut-il de temps pour que 90% des utilisateurs ait vu le contenu commencer à s'afficher ? (en simplifiant l'indicateur). Pour le FID, Google affiche le 95e centile.

Un FCP rapide est compris entre 0 et 1 seconde. Il sera moyen s'il est compris entre 1 et 2.5 secondes, et lent au delà de 2 secondes. Un FID rapide est compris entre 0 et 50 millisecondes, moyen entre 50 et 250 millisecondes et lent au-delà.

La page, ou le site, sera considéré comme rapide si les deux indicateurs sont rapides. Il sera considéré comme lent si un des deux indicateurs est lent. Il sera moyen dans les autres cas.

Viennent ensuite les données lab, mesurées par LightHouse. On retrouve donc des indicateurs similaires mais cette fois-ci mesurées par un robot. Les données peuvent donc varier fortement. LightHouse utilise le user agent du motorola GA, le téléphone qui a un temps "moyen" d'exécution du JavaScript, sur un réseau mobile équivalent à un réseau 3G rapide.

Le score total est une pondération des différents indicateurs proposés par LightHouse :

Fig 11. Pondération des différents indicateurs proposés par LightHouse.

Pour LightHouse, les indicateurs les plus importants sont :

le Consistently Interactive (ou Time To Tnteractive) ;
le SpeedIndex ;
le First Contentful Paint.

Il est fort probable de constater des écarts entre les données proposées par LightHouse et celles venant du CrUX : les conditions pour afficher la page ne sont pas les mêmes. Il existe donc de multiples raisons pour expliquer les écarts. Le plus important est de conserver les chiffres pour détecter des tendances.

Que valent les optimisations données par les sites ?

Certains outils, en plus de fournir des indicateurs, proposent des optimisations et fournissent un score en fonction des optimisations mises en places.
Cependant, la webperformance est un métier à part entière. Il est similaire au SEO. Lorsque tous les voyants sont au vert dans Yoast, considérez-vous que votre page est optimisée ? On peut faire le même raisonnement avec la vitesse des sites. Si tous les voyants sont au vert, votre page est optimisée pour l'outil, pas forcément pour l'utilisateur. De plus, une optimisation qui fonctionne sur un site n'aura pas forcément le même résultat sur un autre.

Si certaines recommandations sont des fondamentaux, d'autres pourront être au mieux inutiles, au pire contre productives. Enfin, certains outils fournissent également des informations contradictoires. Par exemple, un outil peut vous dire sans sourciller d'externaliser vos fichiers JavaScript, mais également de réduire le nombre de requêtes externes. Or, en externalisant, on augmente le nombre de requêtes. Google est également le spécialiste pour conseiller d'exploiter la mise en cache du navigateur et les principales ressources incriminées sont les tag Google Analytics et Google Tag Manager.

Conclusion

Cet article n’est qu’une longue introduction sur le sujet. S’il ne fallait retenir qu’une chose, c’est qu’il n'existe pas d’indicateur miracle pour mesurer la vitesse d’un site. Il est important de comprendre les différents indicateurs présentés par les différents outils. Tous les indicateurs n’ont pas la même importance selon les sites. Il est même possible de créer des indicateurs personnalisés pour mesurer exactement ce dont vous avez besoin. Les outils les plus adaptés sont parfois ceux que l'on se fabrique. Si améliorer la vitesse de vos pages est un chantier complexe à mettre en place, cela apporte également une réelle valeur ajoutée. Mais il s'agit clairement d'un métier à part entière...