Mise en cache, packing et minification [Performance web 2/6]

Après avoir vu, dans l'article précédent, les impacts de la vitesse de chargement d'un site ou d'une page web sur le business, le SEO, l'environnement...
Nous aborderons aujourd'hui la mise en place de systèmes de cache, le packing et la minification et les solutions open sources qui vous permettront d'améliorer la performance de votre site web et d'atteindre vos objectifs.

Mais avant d'aborder les actions à mener, prenons quelques minutes pour faire le point sur métriques à suivre pour mesurer les performances d'un site web.

Performances web & KPI

Dans cette vidéo de 8 minutes, Vincent Dussud, DSI du Groupe Sandaya nous partage son expérience à travers les points suivant :

• définir et mesurer les métriques essentielles : PPM et RPM
• comprendre et analyser les données
• créer un dashboard de suivi
• se familiariser avec New Relic
• utiliser des données plus visuelles avec Webpagest

Cette vidéo est extraite du webinaire intitulé : Performances Web, l'indispensable allié de votre chiffre d'affaires, réalisé en collaboration avec Ibexa DXP en juillet 2020. 

Nous connaissons désormais quelles sont les métriques des performances web, passons maintenant aux actions à mettre en place pour les optimiser.

Réduire le nombre de requêtes pour améliorer la performance d’un site : quelques rappels sur la mise en place de systèmes de cache…

Objectif de la mise en cache :

Enregistrer les résultats des requêtes afin de les restituer lors de demandes similaires et réduire le temps de traitement et d’affichage d’une page.

On retrouve des systèmes de cache au niveau :

• Applicatif
• Serveurs
• Proxys
• Client (exemple : cache de navigateur)
• Réseau Internet (FAI, accélérateurs mobiles, avions…)

Caches HTTP

• Le cache HTTP fait partie des spécifications du protocole HTTP. Les applications de cache comme Varnish, ou les navigateurs ne font qu’implémenter et respecter ce protocole.
• Ce protocole décrit comment les systèmes de caches doivent stocker et redistribuer les requêtes et leurs réponses. Il décrit aussi comment ne plus les stocker (on parle alors d’expiration et d’invalidation) : comme un système de cache classique.
• Du coté applicatif, nous configurons les réponses que nous renvoyons de manière à avoir un équilibre entre temps de traitement et stockage de réponse.

Toutes les informations relatives aux caches HTTP sont accessibles sur les liens suivants:

https://tools.ietf.org/html/rfc7234

https://developer.mozilla.org/fr/docs/Web/HTTP/Cache

Cache navigateur

Le cache navigateur permet de stocker les données directement dans le navigateur de l’utilisateur. Il s’agit ainsi de mettre en cache les éléments statiques du site, éléments qui n’ont pas besoin d’être rechargés à chaque requête. Exemples : pages, assets ou encore requêtes AJAX.

Néanmoins, en cas de changement d'asset, il se peut que les navigateurs n'aient pas la nouvelle version immédiatement, ce qui peut entraîner des comportements incohérents. C'est pourquoi il est recommandé de rajouter un élément aux noms des fichiers qui permet d'avertir les navigateurs qu'ils doivent demander la nouvelle version. On parle alors de "cache-busting".

Cache de persistance

Réaliser plusieurs requêtes sur le disque prend du temps, et les systèmes de cache répondent à ce problème.

• Un CMS, par définition, remonte du contenu, très souvent en base de données.
• La lecture/écriture sur disque sont les opérations les plus lentes qu’une machine puisse faire.
• L’optimisation de temps de réponse est donc primordiale si notre but est d’optimiser une page web.

Dans cette optique d'amélioration du temps de requête, il est recommandé de mettre en place un système de cache afin d'accélérer les demandes vers la couche de persistance.

Alléger le poids de vos requêtes grâce au Packing et à la minification

Minification JS et CSS

Un site web, pour être engageant, embarque une certaine quantité de ressources afin de mettre en page et de rendre interactif le contenu. Ces "assets" (fichiers JS, CSS, images, fonts …) impliquent un temps de téléchargement et d'interprétation qui se rajoute au chargement de la page

L’objectif:

Rendre ces fichiers les plus légers possible afin d’améliorer la rapidité.

Une première solution est de supprimer tous les caractères inutiles de ces assets : espaces, commentaires, sauts de lignes, séparateurs de bloc afin de réduire la quantité de code et donc le poids du fichier. On parle donc de minification des assets.

L’intérêt est de rendre le fichier plus léger, et donc de réduire le temps de téléchargement et d'interprétation coté navigateur. De plus, la compression de fichiers mise en place par les serveurs web (par exemple, le module gzip d'applications comme NGINX) peut se baser sur un asset plus petit pour délivrer un fichier encore plus léger.

Packing des assets pour minimiser le nombre de tunnels réseaux ouverts

Considérations valables pour HTTP /1.1

Étant donné qu’on a plusieurs fichiers JS et CSS, plutôt que d’ouvrir un tunnel réseau par fichier (qui ne peuvent pas être traités en même temps dans le cas d'un site servi en HTTP/1*), une solution est d’ouvrir un seul tunnel pour un fichier qui contient tous les assets concaténés en un seul. Conséquence:  c’est plus rapide !

Et bien évidemment, packer des fichiers qui sont minifiés est encore mieux, c’est pourquoi packing et minification fonctionnent le plus souvent ensemble.

*Complément:

• 2 tunnels peuvent être traités en même temps s’ils proviennent de 2 hosts différents (certains sites web mettent en place ce qu'on appelle le "sharding" afin de profiter de ce mécanisme).
• Avec HTTP/2, qui gère le multiplexage de requêtes, ne pas packer ses assets devient moins grave.

Les solutions (open sources) : 

• Varnish est un reverse proxy qui implémente le protocole de cache HTTP. Il se place donc en amont du serveur web et permet d'accélérer les applications.
• Redis est un système de cache clé-valeur qui permet de conserver les données demandées en RAM évitant ainsi d’interroger le disque. Quand le volume des données est trop important, Redis utilise alors de la mémoire virtuelle. Il permet également de « capturer » et d’enregistrer l'état de la base dans un fichier.
• Memcached est un système de cache similaire à Redis. Pour plus d'informations, voici un comparatif des deux solutions : https://blog.link-value.fr/redis-ae0cac58ff25
• Webpack est un "module bundler" qui permet la gestion d'assets. Cette application gère le cache-busting, le packing et la minification out-of-the-box.
• Gulp est un "task runner" qui, au même titre que Webpack, permet de gérer les assets, et d'atteindre les mêmes objectifs que ce dernier.

D'autres solutions techniques liées au chemin critique de rendu, Pattern PRPL et HTTP/2seront traitées dans nos prochains articles...