Passer au contenu principal
Spiria black logo
dans « Développement web »,
 19 août 2016

De l’obésité galopante des sites Web

Frédéric Filloux, co-chroniqueur avec Jean-Louis Gassée du blogue Monday Note, notait lundi dernier combien le code des pages Web semblait de plus en lourd. L’affichage d’une page de texte requiert de 6 à 55 pages de code HTML.

Pour illustrer ce phénomène, Filloux choisit un article du vénérable quotidien britannique The Guardian qui traite du bannissement de tous les athlètes russes des Jeux paralympiques de Rio.

To get a half page article, yout need 55 pages of html code.

Le texte contient 757 mots, soit 4 667 caractères utiles en comptant les espaces, alors que le code représente 485 527 caractères. Ainsi, le texte à lire représente moins d’un pour cent (0,96 %) de la masse de code utiliser pour l’afficher, et ce, sans compter le poids des ressources externes comme les scripts, les fichiers CSS, les polices et les images.

Ce surpoids s’explique en partie par l’abondance de liens périphériques et de code lié au marketing et à la publicité (traqueurs, statistiques, affichage). Les sites de médias ne sont pas avares en la matière : ce sont souvent des dizaines de traqueurs (code JavaScript destiné à pister et enregistrer votre activité) qu’ils vous font charger à chaque page.

À titre de point de référence, l’un des premiers textes publiés sur le Web (en 1991), le résumé du projet World Wide Web, écrit en HMTL par son inventeur, Tim Berners-Lee, comporte 4 200 caractères de texte lisible pour moins de 4 600 caractères avec le code. Certes, c’est une mise en page extrêmement dépouillée, mais le rapport “contenu/contenant” est de 90,5 %, à comparer au 0,96 % du Guardian de 2016.

The Web Pyramid. Image from Maciej Cegłowski.

L’année dernière, la “Crise de l’obésité du Web” avait été magistralement illustrée par une présentation de Maciej Cegłowski donnée lors de la conférence Web Directions à Sidney.

(Si vous travaillez dans le Web, consacrer 55 minutes à regarder cette vidéo est une quasi-obligation professionnelle.)

Maciej notait que cette tendance à l’embonpoint n’est pas nouvelle. Joshua Bixby s’alarmait en 2012 : le poids moyen de la page Web (imports inclus) atteignait alors 1 Mo (1 042 Ko pour être exact), alors que l’évolution de l’Internet faisait que les principaux périphériques de consultation étaient désormais plus lents, plus petits et aux interactions plus limitées qu’avant — on parle des téléphones mobiles bien entendu. Joshua prédisait que le poids moyen de la page en 2015 serait de 2 344 Ko.

La page du Guardian pèse au total 3 420 Ko (et 7 720 Ko si on désactive son bloqueur de publicité, soit environ 19 minutes avec un modem 56 K et 7 min 45 s en ISDN-128)…

“Les pages plus lourdes nuisent déjà à la performance pour les utilisateurs d’ordinateur bureau, mais les plus grandes victimes de la page obèse sont les utilisateurs mobiles. Non seulement une page de 1 Mo prend un siècle à se charger, mais elle peut aussi vous donner une bien mauvaise surprise quand vous recevez votre facture de téléphone. Pour vous donner un exemple, je voyageais en Europe plus tôt ce mois-ci. Avant de quitter la maison, j’avais acheté 25 Mo de données de mon fournisseur pour 100 $. En d’autres termes, je dois payer 4 $ par page.” — Joshua Bixby, 2012.

Certes, les prix du mobile ont baissé depuis… mais comme la tendance semble se maintenir, il faudra se préparer aux pages de 5 Mo d’ici 2020. Plus les pages sont lourdes, plus c’est lent, plus les utilisateurs sont malheureux et plus le Web coûte cher : il faut muscler les serveurs, élargir les câbles, faire de l’optimisation… Et du côté des avantages liés à ce surpoids, il n’y a souvent pas grand-chose, voire rien pour l’utilisateur…

De nos jours, idéalement, retenez qu’une page ne devrait pas faire plus de 2 Mo et ne devrait pas prendre plus de 2-3 secondes à se charger avec une bonne connexion. Vous lisez cet article sur une page qui fait 93 requêtes et 5 910 Ko (les photos de chats obèses comptent pour beaucoup) et j’ai dû donc attendre son affichage pendant 4,2 secondes. Peut sans doute mieux faire (on y travaille).

Pour les sites commerciaux, une mauvaise performance est synonyme d’augmentation du taux de rebond, d’une baisse du nombre de pages vues par visiteurs et surtout d’une chute du taux de conversion. Si la page prend plus de 7-8 secondes à se charger, si vous avez dépassé votre “performance poverty line”, et que vous avez des trucs à vendre, vous êtes mieux de fermer boutique.

Performance poverty line.

Songez que pour Walmart, on parle d’une augmentation de 2 % de la conversion pour chaque seconde gagnée. C’est tout de suite beaucoup de millions de dollars par seconde…

Walmart: correlation between performance and conversions.

Je crois que tout projet Web devrait se terminer, dans le cadre de l’assurance qualité, d’une étape obligatoire de “dégraissage” où l’on devrait examiner chaque ligne de code et chaque import (images, CSS, police, js, etc.) et se poser la question de leur pertinence. En outre, en amont, on devrait également s’interroger sur l’utilité de certains frameworks qui sont systématiquement dégainés alors qu’on pourrait parfois s’en passer. Une autre idée serait de brider les connexions de certains développeurs et responsables de sites… qu’ils goûtent à leur propre médecine et comprennent que tout le monde, y compris dans nos pays riches, ne dispose pas d’une mirifique connexion à Internet.

Fat Cat. Photo Ryhor Bruyeu.

 

Partager l’article :