Le , par Julien Wilhelm - Écoconception
Temps de lecture estimé : 5 minutes.
« Cela n’est pas vraiment utile de minifier un fichier sur lequel on applique déjà la compression réseau. »
C’est l’objection qui m’a été opposée il y a peu en atelier alors que je faisais le constat d’un flagrant délit d’absence de minification.
Vraiment ?
Vérifions cela ensemble.
Compression réseau ? Minification ?
Un peu de vocabulaire d’abord.
La compression réseau permet de réduire de façon impressionnante le poids des ressources HTML, CSS, JavaScript, JSON et SVG lors de leur transfert du serveur vers le client. Un algorithme de compression se taille la part du lion depuis des années : gzip. Il est de plus en plus concurrencé par brotli. Pour en savoir plus : Compression dans HTTP, mdn web docs.
Pour la minification, voici la définition donnée par la mdn web docs :
« La minification est le processus de suppression des données inutiles ou redondantes sans affecter la manière dont une ressource est traitée par le navigateur. La minification peut inclure la suppression des commentaires de code, des espaces blancs et du code inutilisé, ainsi que le raccourcissement des noms de variables et de fonctions… »
Pour aller plus loin, j’ajoute que la compression réseau est gérée par le serveur et se fait « à la volée ». À l’inverse, un fichier dit « minifié » est stocké à l’adresse cible sous cette forme. C’est la raison pour laquelle on fait la distinction entre les fichiers sources (non minifiés, lisibles par les équipes de développement, mais plus lourds) et ceux de la production (minifiés et illisibles ou presque pour l’Homme, mais plus légers).
Dans tous les cas, les deux techniques sont compatibles. Surtout, elle est automatisée pour la compression réseau, et automatisable, pour la minification.
Résultats
Retour à la question initiale : est-il vraiment utile de minifier nos fichiers s’ils sont déjà compressés par le réseau ?
Voici tout d’abord ce que j’ai pu observer sur l’évolution du poids des ressources à travers un échantillon de 4 fichiers JavaScript :
| Item | Poids initial | Poids gzippé | Poids minifié | Poids minifié et gzippé |
|---|---|---|---|---|
| Fichier JS n°1 | 675,09 Ko | 139,56 Ko | 307,35 Ko | 101,44 Ko |
| Fichier JS n°2 | 61,95 Ko | 16,38 Ko | 26,98 Ko | 10,96 Ko |
| Fichier JS n°3 | 18,2 Ko | 5,19 Ko | 7,57 Ko | 3,32 Ko |
| Fichier JS n°4 | 19,48 Ko | 4,04 Ko | 6,07 Ko | 2,78 Ko |
Note : les poids gzippés comprennent ici les en-têtes de réponse HTTP, car cela a été testé en situation de navigation réelle. On parle de 300 à 500 octets au maximum par fichier (colonnes « Poids gzippé » et « Poids minifié et gzippé » donc). Pas de quoi inverser la tendance.
Voici maintenant les gains exprimés selon le processus employé :
| Item | Gain si gzippé | Gain si minifié | Gain si minifié gzippé |
|---|---|---|---|
| Fichier JS n°1 | -79,33 % | -54,47 % | -84,97 % |
| Fichier JS n°2 | -73,56 % | -56,45 % | -82,31 % |
| Fichier JS n°3 | -71,48 % | -58,41 % | -81,76 % |
| Fichier JS n°4 | -79,26 % | -68,84 % | -85,73 % |
Sans trop de surprise, ces chiffres montrent qu’il y a un réel intérêt à cumuler compression réseau et minification. Les plus provocateurs pourront dire que l’on ne gagne ici que 5 % à 10 % de plus à faire de la minification en plus de la compression réseau.
Oui, mais :
- 5 à 10 % de 100 Ko, cela ne fait guère que 5 Ko à 10 Ko. Mais 5 % à 10 % de 1 Mo, cela fait déjà 50 Ko à 100 Ko. Avec 3 Mo de JavaScript dans une page web, c’est potentiellement 150 Ko à 300 Ko de gras facilement évitable. Pourquoi s’en priver et payer pour de la puissance serveur dont on a pas besoin ?
- Le critère 6.3 du RGESN, à savoir « Le service numérique a-t-il mis en place des techniques de compression pour les ressources transférées dont il a le contrôle ? », vérifie précisément la mise en place de la compression réseau et de la minification.
- Argument coup de poing : 5 % à 10 % en plus ou en moins sur un salaire, ça fait toujours réagir, non ? C’est que cela ne doit pas être si anodin.
Entre HTML, CSS et JavaScript, c’est clairement ce dernier qui le plus concerné par la minification. Si la suppression des commentaires et de la mise en forme reste intéressante pour CSS (pour le HTML, je suis bien moins convaincu), c’est aussi et surtout la réécriture d’instructions qui aura un impact significatif dans la réduction du poids du fichier final (nom des variables, des fonctions, etc.). Moralité : plus le code est verbeux, plus le gain à la minification peut se révéler intéressant.
Et brotli dans tout ça ?
Je vois que certains suivent, c’est parfait.
Dans cette démonstration, j’utilise effectivement l’algorithme gzip pour la compression réseau. La question peut donc se poser : ce qui est vrai pour gzip l’est-il aussi pour brotli ?
Affaire à suivre.