Vous trouvez le Web trop lourd ? Passez au Lean Web !

Le Web est trop gros…

Oui, le Web est obèse ! C’est pas moi qui le dit : c’est Gerry McGovern dans son excellent article « Webwaste« . Selon ce concepteur d’expériences numériques (aux écrits Rock’n’Roll, ce qui n’est pas pour me déplaire), le Web s’est accru de façon exponentielle :

• En 1994, il y avait 3 000 sites Web.
• En 2019, il y en avait 1,7 milliard, soit près d’un site Web pour trois personnes sur la planète.

Non seulement le nombre de sites Web a explosé, mais le poids de chaque page a également explosé.

• Entre 2003 et 2019, le poids moyen d’une page Web est passé d’environ 100 Ko Ko (Kilooctet) est une unité de mesure informatique équivalente à 1 024 octets. Il est utilisé pour mesurer la taille des fichiers ou la quantité de données dans un système numérique. à environ 4 Mo Mo (Mégaoctet) est une unité de mesure informatique équivalente à 1 024 Ko ou 1 048 576 octets. Il est utilisé pour mesurer la taille des fichiers ou la quantité de données dans un système numérique. .

Et même trop gras !

Le Web est donc bien devenu plus gros ; on peut même dire trop gras ! En effet, si l’on compare le temps moyen nécessaire pour charger complètement une page Web en 2013 et 2019 :

• En 2013 ce temps de chargement est de 4,3 secondes sur mobile (selon une étude de Radware).
• Il est de 10,3 secondes sur ordinateur et de 27,3 secondes sur mobile en 2019 (d’après une analyse de Brian Dean pour Backlinko portant sur 5,2 millions de pages).

Le Web est plus lent ! Et pourtant nous avons grandement amélioré nos infrastructures réseaux avec le déploiement de la fibre et de la 4G.

Les images inutiles

Gerry McGovern est assez claire :

Une image vaut 1 000 mots,
mais parfois c’est 1 000 mots de merde !

Il faut bien comprendre qu’une image sera toujours plus lourde que du texte. Si vous prenez un document numérique textuel d’environ 1000 mots qui remplit deux pages au format A4, il pèsera environ 6ko. Si vous prenez un document de 4 images pour remplir le même espace sur deux pages au même format, il pèsera 160ko (si les images sont bien optimisées). On peut résumer cela par : 4 images pèsent 27 fois plus que 1000 mots ! 

Je pense qu’il est inutile de continuer la démonstration avec la vidéo…

Le Web nous étouffe d’images inutiles. Ces images clichées et stockées ne communiquent absolument rien de valeur, d’intérêt ou d’utilisation. Ils sont l’une des pires formes de gaspillage numériques, car ils provoquent un gonflement des pages et ralentissent le téléchargement des pages. Ils prennent de la place sur la page, forçant le contenu plus utile hors de vue, faisant défiler les gens sans raison valable. Pas étonnant, qu’il faille faire la chasse aux images inutiles !

Le JavaScript surdimensionné

Mais il n’y a pas que les images. L’autre cause de cette surcharge pondérale est bien évidemment le JavaScript. Sans parler de cette « merveilleuse » idée (sentez l’ironie dans le texte) qu’est Web Assembly ou même des cookies tiers qui embellissent notre vie, ce langage souffre trop souvent de démesures par rapport au sujet qu’il traite. L’interview de Chris Ferdinandi, consultant et éducateur JavaScript et auteur de « The Lean Web », publiée dernièrement sur smashingmagazine.com, nous en apprend plus sur ces mauvaises pratiques que je constate aussi tous les jours.

Même compressé reste une question de poids

Si l’on prend les frameworks Un framework est un ensemble d'outils et de bibliothèques qui fournit une structure et des fonctionnalités préétablies pour développer des applications, simplifiant ainsi le travail des développeurs en offrant des solutions prêtes à l'emploi. JS JavaScript est un langage de programmation dynamique principalement utilisé pour ajouter des fonctionnalités interactives aux pages web. Il permet de manipuler le DOM, de gérer des événements, et d'effectuer des requêtes asynchrones. tendances du moment, React ou Vue pour ne pas les nommer, ils font environ 30 ko compressés. Mais une fois que le navigateur les a décompressés, ils sont beaucoup plus gros que cela. Il faut bien comprendre que le téléchargement, le temps de décompression et de compilation de ce seul framework peuvent ajouter un peu de latence La latence est le délai entre l'envoi d'une requête et la réception d'une réponse. Elle est souvent utilisée pour mesurer le temps que met un réseau ou un système à réagir. au chargement initial sur une interface utilisateur. Cela devient encore plus prononcé si vos utilisateurs ne sont pas sur les derniers appareils d’Apple. Même un appareil Android d’il y a quelques années ou un téléphone multifonction, ou si vous avez des gens dans des pays avec des réseaux plus lent, cela rend vos pages web vraiment plus lentes !

Le DOM Virtuel

Une bonne partie de ce poids est consacrée au DOM Le DOM (Document Object Model) est une représentation en structure d'arbre d'un document HTML ou XML, permettant aux développeurs d'accéder et de manipuler dynamiquement les éléments d'une page web via des langages de programmation comme JavaScript. Virtuel . Conscient de ce problème de poids, la communauté des développeurs web a vue l’émergence d’alternatives qui utilisent des API Une API (Application Programming Interface) est un ensemble de règles permettant à différents logiciels de communiquer entre eux. Elle simplifie l'intégration et l'échange de données entre systèmes. ou des approches similaires mais sans DOM virtuel. NB : Le DOM virtuel est une représentation idéale, ou « virtuelle », d’une interface utilisateur (UI) qui est conservée en mémoire et synchronisée avec le DOM « réel » (je ne m’attarde pas sur le sujet mais je vais devoir en faire un article prochainement).

Pour React, vous avez Preact, qui fait environ 3 ko au lieu de 30 ko. Pour Vue, vous avez plutôt Alpine JS, qui fait environ 7 ko. C’est la même approche et le même type d’API dans la manière de travailler avec le code, et ils sont nettement plus petits. Il faut bien comprendre qu’interroger le DOM est coûteux en terme de performance et chaque modification déclenche un repaint.

Disposer d’un DOM Virtuel, permet donc de s’affranchir de parcourir le DOM en se référant au DOM Virtuel pour connaitre l’état de l’élément désiré (NB : ça déclenche quand même un repaint). Avec des solutions sans DOM Virtuel, chaque élément à modifier est donc parcouru et modifier directement. Mais je le rappelle : parcourir le DOM est coûteux en terme de web performance !

Mais alors, quel est l’intérêt de ces frameworks plus léger ?

Tout est une question de nombre d’éléments dans le DOM. Plus votre interface est complexe avec une arborescence très denses dans le DOM, plus parcourir le DOM sera lent. Dès lors, utiliser un DOM Virtuel prend tout son sens. A l’inverse, si une page a un nombre d’élément contenu alors vous ne devriez pas perdre trop de temps à parcourir le DOM et le modifier directement.

Pour rappel, la recommandation de Google au travers de son outil Lighthouse Lighthouse est un outil open-source de Google qui permet d'auditer la performance, l'accessibilité, le SEO et les bonnes pratiques des sites web. Il fournit des rapports détaillés et des recommandations pour améliorer les performances. est de ne pas dépasser les 1500 éléments dans le DOM. C’est 1500 éléments pour MilleCheck.ai et même 700 pour Yahoo.

Si vous avez des interfaces comme Twitter ou Facebook ou quelque chose comme ça, le DOM virtuel a probablement beaucoup de sens. Sinon pour toute interface classique, le gain promis par un DOM Virtuel ne sera tout simplement pas là.

Outre le nombre d’éléments dans le DOM, d’autres paramètres sont à prendre en compte. Il y a une recrudescence des sites web SPA ( Single Page Application Une Single Page Application (SPA) est une application web qui charge une seule page HTML et met à jour dynamiquement son contenu en réponse aux interactions utilisateur, sans recharger entièrement la page. : application d’une seule page). L’un des avantages manifeste des SPA est que seul le contenu de la page change. Vous n’avez pas besoin de retélécharger tout le JS et le CSS Le CSS (Cascading Style Sheets) est un langage utilisé pour décrire l'apparence et la mise en page des documents HTML, en définissant des styles comme les couleurs, polices, marges, et positionnements des éléments sur une page web. . Ainsi au lieu d’avoir des fichiers HTML Le HTML (HyperText Markup Language) est le langage standard utilisé pour structurer et afficher le contenu sur le web. Il définit des éléments comme les titres, paragraphes, liens, images, et autres composants d'une page web. séparés pour chaque vue de votre application, une application d’une seule page a un seul fichier HTML. C’est ce qui en fait une application d’une seule page. Ici, JavaScript gère tout :

• rendu du contenu,
• acheminement vers différents chemins d’ URL Une URL (Uniform Resource Locator) est l'adresse unique d'une ressource sur Internet, comme une page web, une image ou un fichier, permettant de la localiser et d'y accéder via un navigateur. ,
• récupération du nouveau contenu s’il le faut à partir d’une API
• et toutes autres choses du même genre.

Faire les bons choix technologiques

Le problème avec cette approche est qu’elle casse également un tas de choses que le navigateur gère nativement. Ce faisant, vous supprimez un tas de fonctionnalités du navigateur et devez ensuite les réimplémenter avec encore plus de JS. Un exemple :

1. Intercepter les clics sur les liens et les empêcher de se déclencher, avec votre JavaScript.
2. Ensuite déterminer ce que vous devez réellement afficher en fonction de cette URL, qui est normalement quelque chose qui serait géré sur le serveur ou en fonction du fichier qui accompagne ce chemin d’URL.
3. Mettre réellement à jour l’URL dans la barre d’adresse sans déclencher de rechargement de page.
4. Ecouter les clics avant et arrière sur le navigateur et mettre à jour le contenu à nouveau, comme vous le feriez avec des clics sur des liens. Vous devez mettre à jour le titre du document.

En théorie, c’est plus performant que d’avoir à recharger toute la page… Mais l’auteur de « The Lean Web » est assez claire sur le sujet :

L’idée que vous avez besoin d’une SPA pour la performance est exagérée.
Vous pouvez souvent obtenir le même niveau de performance avec différentes approches.

L’autre argument en faveur des applications Web d’une seule page est l’accès hors ligne. Mais maintenant, avec les PWAs et les services worker, cela n’est plus vraiment convaincant, d’autant plus que les services worker peuvent récupérer des fichiers HTML complets et les mettre en cache Le cache est un espace de stockage temporaire qui conserve des données fréquemment utilisées pour accélérer leur accès ultérieur, réduisant ainsi les temps de chargement et la consommation de ressources. à l’avance si nécessaire.

Lean Web

Vous pouvez traduire Lean Web par Web Léger. Il s’agit d’une approche où le choix de technologie et d’interface doit être pragmatique en fonction des besoins réels comme nous l’avons vu ci-dessus.

Même si le Web évolue, une technologie ancienne ne veut pas dire qu’elle est obsolète. Ainsi même chez Google, vous trouverez des gens pour vous recommander les sites web multi-pages. D’ailleurs avec les performances des CDN Un CDN (Content Delivery Network) est un réseau de serveurs répartis dans plusieurs emplacements géographiques qui distribue du contenu web de manière plus rapide et efficace en rapprochant les ressources des utilisateurs finaux. d’aujourd’hui, nous pouvons créer des expériences Web incroyablement rapides en utilisant des fichiers HTML individuels pour toutes les différentes pages d’un site web ou vues d’une application web (j’espère que ce site en est la preuve).

Avec une approche Lean Web, il faut envisager l’évolution de notre code de manière évolutive et sécable. L’inconvénient des solutions à base de framework c’est qu’elles sont à terme une dette technique. A chaque évolution majeure cela signifie souvent tout réécrire (Cela ne signifie pas qu’il ne faut pas les utiliser). De plus, les standards du Web évolue. Ce qui nécessitait une dizaine de lignes JavaScript comme un menu fixé en haut il y a quelques année, peut se faire en une seule ligne de CSS aujourd’hui. Il faut concevoir nos architectures de site web avec des modules que l’on peut abandonner rapidement au profit d’une technologie désormais plus pertinente comme avec le Lazy Loading natif. On peut même en fonction du support du navigateur proposer la technologie la plus adaptée.

Un Web léger pour diminuer notre impact environnemental

Au-delà, de la manière dont nous faisons les choses, il s’agit d’un enjeu écologique pour notre industrie dont la création de site web est le métier, et ce sur plusieurs aspects :

1. Le poids et le temps d’éxécution de nos pages ont certes un impact sur la web performance La Webperf désigne l'optimisation des performances d'un site web pour accélérer son chargement et améliorer l'expérience utilisateur, grâce à des techniques comme le caching, la compression, et la réduction des fichiers. ; mais surtout plus léger ils seront moins gourmands et ils auront besoin de moins d’énergie.
   En nettoyant son code JavaScript, Wikipédia a économisé 4,3 téraoctets par jour de bande passante de données pour ses visiteurs. L’équivalent de 700 arbres à planter pour faire face à la pollution annuelle qui en aurait résultée.
2. La pertinence du contenu de nos images ou de nos pages web a, de part leurs existences même, elle aussi un impact. Elles occupent un espace sur un disque dur qu’il faut alimenter. Un moteur de recherche va chercher à les indexer. Un utilisateur va peut-être même les lire. Mais seulement voilà, les informations contenues datent de 2007 et sont obsolètes. Autant de perte d’énergie pour de l’insatisfaction utilisateur. Gerry McGovern déclare à ce propos : « J’ai travaillé avec des centaines de sites Web sur lesquels nous avons dû supprimer jusqu’à 90% des pages pour commencer à voir des améliorations ».

Bref contenu et code vont de paire comme on vous l’écrivait il y a peu. Bien évidemment, le « No Fucking JS Spirit » de notre agence web basée à Rennes est en parfaite adéquation avec le Lean Web. Donc je vous recommande chaudement la lecture de l’article « Webwaste » de Gerry McGovern et l’interview de Chris Ferdinandi sur smashingmagazine.com mais aussi son livre « The Lean Web » téléchargeable sur https://leanweb.dev/ebook/.

Post-scriptum

A la relecture de cet article, l’auteur tient à signaler que l’image en haut de l’article n’est ici pas inutile. Elle sert à évoquer le sujet que l’article traite et à le différencier des autres articles dans les pages de listing. Par contre, j’ai parfaitement conscience que notre site a plusieurs pages complètement obsolètes, que je pense pouvoir supprimer dès mon retour de congés, avec l’accord de mon spécialiste SEO préféré. Sur ce je file m’acheter un nouveau slip de bain, passez un bel été !

Image par i yunmai via Unsplash.