Dans un article publié le 11 novembre, les équipes de Chrome affichent leur volonté de poursuivre leurs efforts pour un web toujours plus rapide, cette fois en annonçant le signalement des pages lentes aux internautes. Comment comptent-ils s’y prendre ? Ce projet sera-t-il mené à terme ? Le suspense est pour le moment intense.
Le “badge de la honte”
Certaines des réactions à cette nouvelle n’ont pas manqué de relever le côté stigmatisant de cette démarche, évoquant un “badge de la honte” :
Bientôt un "badge de la honte" pour les sites trop lents sur #Chrome
En savoir plus
👇👇👇https://t.co/uzsdUmLU8C pic.twitter.com/vM2IayhVzV— Clubic (@Clubic) November 12, 2019
Si on remonte à 2015, des expérimentation semblables ont été menées par Google qui affichait alors un “Slow to Load Warning” - le fameux “Red Slow Label”. Elles ont été de courte durée, et consistaient à ajouter un picto (petit mais bien visible) ou un texte à côté des résultats de recherche pour signaler les pages susceptibles d’être lentes. Ce signalement tenait a priori compte du contexte de navigation puisqu’un site comme Youtube était signalé comme potentiellement lent. Lorsque Google a été interrogé sur l’apparition de ce label, la réponse a été pour le moins laconique : “We're always experimenting".
A l’époque, comme souvent quand Google fait des annonces, tout le petit monde du SEO a tremblé. Pourtant l’initiative n’a finalement jamais vu le jour à grande échelle.
Des questions pour le moment sans réponses
Revenons en 2019, en ce lundi 11 novembre au cours duquel les équipes de Chrome ont dévoilé leur projet. Est-ce encore un effet d’annonce ? Ce qui change par rapport à 2015, c’est que cette fois l'information émane des équipes Chrome, et non d’utilisateurs qui rapportent ce qu’ils ont observé.
La communication semble plus officielle, mais rien ne permet de prédire si elle sera suivie d’effets ni dans quels termes - bien que les équipes Chrome soient autonomes et que leur engagement pour rendre les sites rapides ne soit plus à prouver.
D’après ce que révèle l’article, il s’agirait de proposer un avertissement dans le navigateur et non plus dans les SERPs, et pour l’instant, la “surface” reste à définir. C’est-à-dire qu’à l’heure actuelle, il n’y a pas d’emplacement défini pour apposer ce label : est-ce sur une page intermédiaire après avoir cliqué sur un lien dans les SERPs ? En surimpression sur la page ? Sur une ligne discrète quelque part sur la page ? Tout est envisageable.
Par ailleurs, l'affichage de cette alerte serait-elle systématique, ou fonction du contexte de navigation de l’internaute ?
Il va sans dire que si on navigue en Edge, tous les sites sont lents, a priori personne n’a besoin de recevoir d’alerte dans ce cas.
Enfin, la question est aussi de savoir selon quelle(s) métrique(s) la vitesse des pages sera évaluée. Est-ce que ce sera un algorithme “à la Google”, avec une multitude de paramètres qui pourront évoluer autant que nous échapper (cf. le score Lighthouse dont le mode de calcul vient de changer pour donner moins d’importance au TTI, par exemple) ? Ce point reste là aussi assez obscur pour le moment.
Ce que nous pressentons en tant qu’expert.e.s webperf
On attend des performances d'un site qu'il s’affiche rapidement mais aussi qu’il soit rapidement interactif. Cependant, prévenir du manque d’interactivité nous semble compliqué auprès du grand public, c’est pourquoi nous supposons que les métriques plébiscitées seront celles qui mesurent l’affichage, plutôt que l’interactivité. En effet, en cliquant sur un lien la perception de vitesse repose avant tout sur le temps d’affichage de la page, avant le fait de pouvoir interagir avec.
Aussi, nous ne pouvons pas nous empêcher de supposer une volonté de Google de soulager son infrastructure.
Pourquoi vouloir à tout prix rendre un site rapide ? Pas seulement par souci UX ou par amour de son.a prochain.e, mais aussi parce que Google passe du temps à crawler un volume immense de pages.
Or le crawl peut se faire de deux façons :
- par le téléchargement de la page HTML (ce qui permet de voir les données Page Speed de la Search Console) ;
- ou en observant le rendering de la page, autrement dit, en chargeant la page comme le fait un navigateur, en exécutant les JS... et ce rendering a un coût ! Alors, plus le site est rapide, moins il aura besoin de temps pour le parcourir.
Dans tous les cas, c’est une affaire à suivre, et nous sommes évidemment curieux.ses de connaître l’issue de ce projet.
Vous aussi ? Pour suivre l'actu webperf, abonnez-vous à notre newsletter mensuelle :
