Performance : le retour du fils de la vengeance

Où l’on reparle de questions qui ont quinze ans et où l’on arrive presque aux mêmes conclusions.

In this post, I’ll outline some recent observations […]

Page weight isn’t the only measure ; focus on perceived performance

Nous revoilà en 2000. Vous vous rappelez de l’excellent Art & Science
of Web Design de Jeff Veen ?

Il y parlait du « sleight of hand » (le « tour de main » du magicien) pour expliquer comment un site [1] utilisait un mélange de CSS et de mise en page pour donner l’illusion de vitesse.

Rien de récent donc sur les constatations, un petit manque de recul historique dans nos métiers, dû en partie à la jeunesse des gens qui les pratiquent [2].

Ce qui a changé aujourd’hui ? Le poids pharaonique des pages, qui chargent un tas de trucs dont on n’a pas besoin [3], surtout maintenant que le Web mobile est devenu un tel enjeu (et qu’il dépasse le « Web de bureau » en temps d’usage), ce qu’Élie résume tellement bien en les nombreuses dégradations actuelles de l’expérience utilisateur (lire Publicité Web : y’a des limites ? - Blog Temesis).

Un petit bémol donc, sur tous les articles liés à la performance : quand on dit « le poids n’est pas la seule mesure », on finit par s’habituer à entendre « la mesure est ailleurs » [4], alors qu’il faut quand même toujours et encore limiter le poids des pages, quoi qu’on fasse en parallèle [5]. Il faut donc continuer à dire que ce n’est pas la seule mesure, mais elle est et doit rester cruciale dans votre processus de validation : posez des objectifs de performance liés au poids de la page, pas seulement à ce qui s’affiche rapidement au-dessus du légendaire pli.

Notes

[1] De mémoire c’était le moteur de recherche de Wired, mais je peux me tromper, ça date.

[2] Oui je suis un vieux con.

[3] J’ai entendu quelqu’un dire il y a quelques jours « sur mobile on ne va charger que tel et tel truc, le reste est inutile ». Je suis fatigué de répéter que si c’est inutile pour mobile, il faut se demander à quel point c’est du bruit sur desktop.

[4] Attention, un jeu de mots involontaire s’est caché dans cette phrase.

[5] Attention, une référence involontaire à HTTP/2 s’est glissée dans cette phrase.

Commentaires

  • Damien (12 février 2016)

    Hello Stéphane,

    Je suis intrigué par ce point de vue !

    Mon quotidien est la performance (derrière le service DareBoost.com), j’ai lu beaucoup et écrit un peu sur la notion de budget (https://medium.com/@DamienJubeau/budget-de-performance-indispensable-rapidite-sites-web-a771922e89e8), et je te rejoins totalement sur l’intérêt de maîtriser le poids !

    Par contre, je n’irais pas jusqu’à le placer au niveau de "crucial" de manière si absolue. On entend parfois « la mesure est ailleurs » certes, et je trouve cela justifié car le "régime" n’est pas la réponse absolue. Et cela ouvre sur d’autres techniques.
    Mais je ne trouve pas l’indicateur abandonné pour autant (whatdoesmysitecost.com, etc) !

    Je suis donc intrigué : un déclencheur particulier pour lui faire une telle apologie ?

    Damien
    * jeune con :)

    PS : mon premier site ayant été mis en ligne via une connexion 56k, je me souviens...
    des "tas de trucs dont on n’a pas besoin", ça fait un moment qu’on en a (les jolies bannières 468*60 en GIF, la surcharge de jolis boutons en flash, etc).

    Mon avis : Les connexions ont évolué donc on se permet davantage...
    à la différence qu’aujourd’hui, les connexions sont de plus en plus hétérogènes, et les métiers du web sont logiquement parmi les mieux équipés, et ont sans doute tendance à l’oublier !

    Répondre à Damien

  • Stéphane (18 février 2016)

    Damien : Je vois qu’on est complètement d’accord, c’est très rassurant :)

    Même avec nos connexions ADSL, les sites mettent de plus en plus de temps à charger, même avec des bloqueurs de pub et de mouchards (qui eux-mêmes entraînent parfois des effets de bord liés à la mauvaise gestion de l’asynchrone du site visité).

    Tu sais comme moi que tout le monde y va de ses deux ou trois widgets de réseaux sociaux (dont l’efficacité est vivement discutable), trois ou quatre outils de statistiques et de régie publicitaire au minimum (allez, arrondissons à quinze pour plein d’organes de presse en ligne).

    Je pense de plus en plus à tous les endroits où la consommation de données est coûteuse sur mobile, et je me dis qu’on va dans le mur sans aucun respect pour l’usager.

    Ce n’est pas en chargeant les 3/4 du bazar qu’on trouvera sur la page après l’affichage critique « au-dessus du pli » qu’on règle le problème. On gagne en rapidité perçue, certes (et donc là rien de nouveau sur le principe, en 2000 on y avait déjà réfléchi), mais on continue à payer de la bande passante pour une tonne de trucs non critiques (s’ils étaient réellement critiques, on les chargerait en dur dans la page pour éviter les mauvaises surprises liées aux risques de casse du JS, des dépendances au réseau, etc. — ou alors c’est que l’architecte du site fait mal son métier, et là, retour case départ).

    Ça reste donc crucial pour :

    • limiter le taux d’abandon
    • respecter l’utilisateur dans ses usages, notamment en tethering — dans ce dernier cas, il est en condition de mobilité pour la qualité de la connexion (légère), mais en conditions de desktop pour les aménagements que le site a mis en place (et bam, prends des méga-octets et apprends la patience).

    Comme dit Maciej Cegłowski : 1. assurez-vous de charger et d’afficher les éléments les plus importants de la page, et 2. arrêtez-vous là. C’est assez provoc évidemment, mais ça devrait quand même être écrit en première page de tous les projets web pour ne pas l’oublier.

    Il n’y a pas de déclencheur particulier, mais ça fait un moment que ça me traîne dans la tête et que ça monte doucement :)

    Répondre à Stéphane

Qui êtes-vous ?
Votre message

Ce formulaire accepte les raccourcis SPIP [->url] {{gras}} {italique} <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Lien hypertexte

(Si votre message se réfère à un article publié sur le Web, ou à une page fournissant plus d’informations, vous pouvez indiquer ci-après le titre de la page et son adresse.)