La compatibilité des navigateurs n’a jamais été aussi complète, les moteurs JavaScript n’ont jamais été aussi rapides, les métriques et les outils si matures, le tree shaking tant performant, les applications si résilientes et les stratégies de cache autant sophistiquées.
Et pourtant, les sites n’ont jamais été aussi lourds à charger !
Lorsque nous sommes assis confortablement devant un ordinateur moderne, équipé d’une connexion haut débit dans notre bureau, la navigation nous semble fluide et agréable. Cependant, la majorité de nos utilisateurs sont probablement sur un appareil mobile avec une connexion hasardeuse, ou peut-être sur un smartphone ancien et nous n’avons pas d’influence là-dessus.
Notre travail consiste alors à développer et à s’assurer du bon fonctionnement du site, quel que soit l’appareil utilisé. Nous ne souhaitons pas être l’auteur d’un site qui consomme en excès la batterie ou la bande passante de nos usagers, attendant en moyenne 6.4 secondes avant que la première interaction ne soit visible. Cela peut sembler peu, mais c’est déjà 33 % de plus qu’en 2016 !
La démocratisation des frameworks front-end n’aident pas toujours les développeurs à obtenir une vision complète et réelle de ce qui est envoyé au client.
Avec l’utilisation exponentielle des smartphones, il est devenu essentiel d’améliorer et d’optimiser les performances du web. Bonne nouvelle ! Les solutions pour y parvenir n’ont jamais été aussi accessibles et efficaces.
Opportunités dans les nouveaux standards du web
Les nouveautés dans le protocole HTTP
La migration de HTTP vers HTTPS puis HTTP2 et bientôt HTTP3, modifie toute la plomberie d’internet. La façon dont nous recevons les données, la manière dont nous avons dû diviser de grandes ressources en plusieurs paquets, ou inversement avec la fusion de plusieurs images en une seule, plus volumineuse, pour avoir une feuille de sprites et ainsi optimiser les performances réseaux appartiennent dorénavant au passé. HTTP2 apporte son lot d’améliorations, principalement autour de la performance, notamment avec les streams et leur priorisation, le server push, la compression des headers et le multiplexage. HTTP3 promet également l’établissement d’une connexion plus rapide pour les appareils qui se sont déjà connectés précédemment au site, notamment grâce au 0-RTT connection resumption.
Les nouveautés dans le protocole TLS 1.3
TLS et les connexions chiffrées ont toujours ajouté un léger surcoût en termes de performances web. Avec TLS 1.2, deux allers-retours étaient nécessaires pour terminer le handshake. Avec la version 1.3, un seul est nécessaire, ce qui réduit de moitié la latence due à l’établissement du chiffrement. Cela permet aux connexions chiffrées d’être plus rapides qu’auparavant.
Mieux connaître les contraintes réseau de l’utilisateur
La récente Network Information API nous permet d’obtenir les informations réseaux auxquelles l’appareil est connecté. Elle peut par exemple nous indiquer :
- Le type de connexion : wifi, cellulaire, ethernet, etc.
- Le type de réseau mobile : 4g, 3g, 2g, etc.
- Si l’utilisateur a activé l’option “save data” sur son appareil.
Nous pouvons citer certains cas d’usage comme :
- Basculer entre la diffusion de contenu en haute et en basse définition.
- Décider de précharger ou non les ressources.
- Utiliser une version hors ligne de l’application si la qualité du réseau n’est pas suffisante.
- Avertir les utilisateurs qu’un certain usage (comme regarder une vidéo) sur une connexion mobile peut leur coûter de l’argent.
Cette nouvelle API est compatible pour 67% des internautes.
La monétisation coûte cher en performance
Une grande partie de la lenteur du web provient de nos tentatives de monétiser les visiteurs. De la publicité jusqu’au suivi de l’utilisateur, toutes ces technologies se mettent en travers de l’expérience utilisateur afin de générer des revenus. Le modèle économique du web n’est pas aussi clair que celui des grands magasins ou du marchand de journaux et nous avons encore du mal à concilier l’attente des utilisateurs d’un web libre et ouvert avec l’exigence de rentabilité commerciale.
L’amélioration de la monétisation sur le web grâce à des API intégrées telles que la Payment Request API, la Web Monetization API et même Brave Rewards devrait faciliter la monétisation des contenus sans qu’il soit nécessaire de recourir à des contenus tiers lourds et intrusifs. Ce changement pourrait entraîner une amélioration radicale de l’expérience des internautes, en particulier sur les sites d’actualités.
Les Progressive Web Apps font-elles le PWA face aux applications natives ?
Il ne s’agit pas d’un nouveau framework ou d’une nouvelle technologie. Il s’agit d’un ensemble de bonnes pratiques pour faire en sorte qu’une application web fonctionne comme une application de bureau ou mobile. L’objectif est d’avoir une expérience si uniforme et transparente que l’utilisateur ne puisse pas faire la différence entre une PWA et une application mobile native.
Pour être plus précis, les PWA peuvent offrir certaines fonctionnalités qui sont généralement associées aux applications natives :
- Chargement quasi instantané (lors de la deuxième visite)
- Installées sur l’écran d’accueil sous forme d’icône d’application
- Application en plein écran sans les bordures de la WebView
- Accès hors ligne
- Notifications push
Les droits d’accès aux fonctionnalités de l’appareil sont toutefois limités sur les PWAs. Vous pouvez consulter sur votre téléphone le site whatwebcando.today pour voir ce dont ces applications sont capables aujourd’hui.
Samsung a récemment annoncé qu’il acceptait d’inclure les PWA dans son App Store américain. Google, quant à lui, propose d’envoyer votre site web sous forme d’application dans le Play Store. Pour sa part, Apple, comme on pouvait s’y attendre, protège résolument ses revenus liés à l’App Store en ne souhaitant guère coopérer, même si Safari prend en charge certaines des fonctionnalités essentielles.
Quand devrais-je utiliser WebP ?
WebP est une méthode de compression avec ou sans perte qui peut être utilisée sur le web. Le degré de compression avec perte est réglable, de sorte qu’un utilisateur peut choisir le compromis entre la taille du fichier et la qualité de l’image. Il atteint généralement une compression supérieure de 30 % en moyenne à celle des formats JPEG a rendu équivalent.
Le format WebP vise essentiellement à créer des images plus petites et de meilleure qualité contribuant ainsi à rendre le web plus rapide.
Les navigateurs envoient un en-tête de demande « Accept », indiquant les formats de contenu qu’ils sont prêts à accepter en réponse de sorte qu’il soit possible de gérer la rétrocompatibilité. Si un navigateur indique à l’avance qu’il accepte le format d’image/webp, le serveur web sait qu’il peut envoyer des images WebP en toute sécurité, ce qui simplifie grandement la négociation du contenu.
Prioriser les ressources ?
Lorsqu’un navigateur télécharge une ressource, celle-ci se voit attribuer une priorité. Par défaut, les priorités dépendent du type de ressource (par exemple un script, une image, etc.) et de l’emplacement de la référence de la ressource dans le document. Dans la majorité des navigateurs modernes, le CSS chargé via l’élément <link> dans le <head> se verra attribuer la priorité la plus élevée, car il bloque le rendu. Les images dans la fenêtre de visualisation peuvent se voir attribuer une priorité élevée, tandis qu’on accordera aux images en dehors une priorité faible. Un <script> chargé à la fin du document peut se voir décerner une priorité moyenne ou faible, mais cela peut être influencé par defer et async.
Les indices de priorité peuvent être définis pour les ressources en HTML en spécifiant un attribut d’importance sur un élément <script>, <img> ou <link> comme suit :
<img src="/not_important.png" importance="low" alt="I'm an unimportant image!">
L’attribut d’importance peut accepter ces trois valeurs : high, low et auto.
Les modules ECMAScript
Jusqu’à récemment, JavaScript n’avait aucune notion de modules. Il n’était pas possible de référencer ou d’inclure un fichier JavaScript dans un autre sans passer par un module bundler. Et à mesure que les applications se développent en taille et en complexité, cela a rendu l’écriture du JavaScript pour le navigateur de plus en plus délicate.
L’ES6 (ES2015) s’est efforcé de remédier à cela en introduisant une norme de module unique et natif. Cette nouvelle norme permettra de se passer de module bundler tel que Webpack sur des projets ne nécessitant pas d’optimisation au build du projet.
C’est une bonne opportunité pour ceux qui veulent éviter le surplus de code injecté par Webpack dans le build pour le bon fonctionnement de l’application.
Ces modules ES6 sont compatibles pour 88% des internautes.
Performance quasi native grâce à WebAssembly
Dévoilé en 2015, WebAssembly est une cible de compilation en format binaire, pour les navigateurs modernes, qui offre de nouvelles fonctionnalités et oeuvre avec une vitesse d’exécution proche du natif. Il est conçu pour être une cible de compilation efficace pour les langages sources de bas niveau tels que C, C++, Rust, etc. WebAssembly est bien plus proche du langage machine que peut l’être JavaScript et permet un certain nombre de cas d’utilisation intensive en calcul sur le web, notamment à travers les jeux, l’édition de médias, la synthèse vocale et bien d’autres.
WebAssembly est conçu pour fonctionner avec JavaScript, ce qui signifie que vous pouvez appeler les modules WebAssembly à partir du code JavaScript. Il est utilisé pour améliorer les performances des applications et des bibliothèques JavaScript avec des applications clientes fonctionnant sur le web qui n’auraient pas été possibles auparavant.
WebAssembly est compatible pour 89% des internautes.
Lazy Loading natif des images
Les pages web contiennent souvent un grand nombre d’images, ce qui contribue grandement à l’utilisation des données et au temps de chargement d’une page web. Beaucoup de ces images sont hors du champ de visualisation, ce qui oblige l’utilisateur à scroller pour les visualiser.
Historiquement, et pour limiter l’impact des images hors écran sur le temps de chargement, les développeurs utilisaient des bibliothèques JavaScript afin de différer la récupération de ces images jusqu’à ce que l’utilisateur fasse défiler la page à proximité de l’image.
Et si le navigateur pouvait éviter de charger ces images hors écran pour vous ?
Le tout récent attribut loading répond à cette problématique en prenant en charge trois valeurs :
- Lazy : chargement retardé
- Eager : chargement immédiat
- Auto : le navigateur détermine si le chargement doit être lazy ou eager
Ce nouvel attribut est disponible pour 62% des internautes.
Opportunités dans les nouvelles tendances du web
Les générateurs de sites statiques
La JAMstack (JavaScript APIs Markup) est une architecture permettant de fournir des sites rapides en utilisant des générateurs de sites statiques (SSG pour Static Site Generator). Les SSG tels que Jekyll, Hugo et Gatsby permettent une expérience de développement agréable et une itération rapide en pré-rendant le contenu en HTML. Ces générateurs sont actuellement largement utilisés pour les blogs personnels ou les sites de petites entreprises en raison de leur faible encombrement. L’évolution vers des solutions CMS headless, des API de paiement côté client et le déploiement en un clic pourraient rendre les SSG viables pour tous, des sites d’actualités aux sites de e-commerce, en supprimant le temps de traitement serveur, facteur critique de performance, et en simplifiant le processus de déploiement.
La compilation de framework
Svelte est une approche radicalement nouvelle de la construction d’interfaces utilisateur. Alors que les frameworks traditionnels comme React et Vue font l’essentiel de leur travail dans le navigateur, Svelte transforme ce travail en une étape de compilation lorsque vous construisez votre application. Cela réduit considérablement la quantité de travail que le navigateur doit effectuer et permet aux applications web d’être beaucoup plus légères et rapides.
Les nouveaux standards de la communication mobile
La 5G frappe à la porte. Elle promet des débits théoriques 10 à 100 fois plus rapides que la 4+ tout en ayant une latence réduite. Elle permettrait de réduire les temps de chargement sur les smartphones compatibles et donc le temps d’attente nécessaire à l’affichage d’un site, sans toutefois réduire le temps d’attente de parsing du JavaScript sur le téléphone portable. Prudence toutefois, entre 2011 et 2019, la couverture de la 4G est passée de 5% à 79% dans le monde et durant cette même période, le poids médian des fichiers JavaScript sur mobile a augmenté de 52 KB à 372KB, soit une augmentation de 611% ! Espérons que cela ne se reproduira pas avec l’avènement de la 5G.
Adapter le contenu à l’utilisateur
Le chargement d’un site web peut être une expérience très différente selon les conditions du réseau. L’une des solutions pour pallier des problèmes de connectivités consiste à adapter les services que vous proposez aux utilisateurs en fonction de la qualité de leur connexion. C’est désormais possible grâce à la Network Information API, vue au début de l’article, qui permet aux applications web d’accéder à des informations sur le réseau de l’utilisateur.
De nombreuses applications font déjà quelque chose de similaire. Des exemples comme YouTube, Netflix et la plupart des autres services de vidéo (ou d’appel vidéo) ajustent automatiquement la résolution pendant la diffusion en continu. Lorsque Gmail se charge, il fournit aux utilisateurs un lien pour « charger l’affichage HTML simplifié” pour les connexions lentes.
Il existe par ailleurs des services qui peuvent héberger vos images sur un CDN puis distribuer la bonne image dans le meilleur format en fonction de la résolution, du navigateur et de la connexion utilisée par l’internaute, afin de vous abstraire de cette complexité.
Établir un budget performance
Size Limit automatise la surveillance du budget de performance que vous allouez pour le JavaScript. Il s’intègre à votre CI et vérifie à chaque commit le coût réel de votre JS pour les utilisateurs finaux et lance une erreur si le coût dépasse la limite paramétrée. Size Limit calcule également le temps qu’il faudrait à un navigateur pour télécharger et exécuter votre JavaScript. Le temps étant une mesure beaucoup plus compréhensible que la taille en octets.
L’application web performancebudget.io permet de calculer en fonction de son objectif de temps de chargement la quantité maximale d’Images, HTML, CSS, JavaScript, vidéos et polices d’écriture que l’on peut inclure dans son projet.
Le langage de requête GraphQL
La principale qualité de GraphQL est d’être moins consommatrice en bande passante que ne l’est une API REST traditionnelle. GraphQL traite la performance comme sa priorité absolue. Même si une API REST ne renvoie qu’une partie de sa base, elle transfère toujours plus de données que nécessaire, tandis qu’une API GraphQL tend à envoyer le minimum requis par le front-end. De plus, GraphQL permet d’interroger plusieurs entités et relations en une seule requête afin de réduire le nombre de requêtes émises. GraphQL met également en avant une certaine cohérence des résultats et une introspection pour faciliter le développement.
Le web continu son chemin vers la performance. Certaines entreprises encouragent d’ailleurs leurs employés à travers différentes initiatives. Shopify propose directement dans ses locaux un réseau WI-FI qui simule une connexion 3G. Quant à Facebook, il encourage ses développeurs à construire et déployer ses applications en 2G à travers le 2G tuesday. N’hésitez pas à décrire en commentaire les initiatives mises en place dans vos entreprises.
Ces nouvelles opportunités contribueront sans aucun doute à accélérer le web.
Mais gardons à l’esprit que la requête la plus rapide et optimisée sera toujours celle qui n’est pas émise.