Réduire et compresser les charges utiles du réseau avec gzip

Houssein Djirdeh

Cet atelier de programmation explique comment la minification et la compression du bundle JavaScript de l'application suivante améliorent les performances des pages en réduisant la taille de la requête de l'application.

Mesurer

Avant de vous lancer dans l'ajout d'optimisations, il est toujours judicieux d'analyser d'abord l'état actuel de l'application.

• Pour prévisualiser le site, appuyez sur Afficher l'application, puis sur Plein écran .

Cette application, également abordée dans l'atelier de programmation Supprimer le code inutilisé, vous permet de voter pour votre chaton préféré. 🐈

Voyons maintenant la taille de cette application:

1. Appuyez sur Ctrl+Maj+J (ou Cmd+Option+J sur Mac) pour ouvrir DevTools.
2. Cliquez sur l'onglet Réseau.
3. Cochez la case Disable cache (Désactiver le cache).
4. Actualisez l'application.

Bien que de nombreux progrès aient été réalisés dans l'atelier de programmation Supprimer le code inutilisé pour réduire la taille de ce bundle, 225 ko reste une taille assez importante.

Minimisation

Prenons le bloc de code suivant.

function soNice() {
  let counter = 0;

  while (counter < 100) {
    console.log('nice');
    counter++;
  }
}

Si cette fonction est enregistrée dans un fichier propre, sa taille est d'environ 112 octets.

Si tous les espaces sont supprimés, le code obtenu se présente comme suit:

function soNice(){let counter=0;while(counter<100){console.log("nice");counter++;}}

La taille du fichier est maintenant d'environ 83 octets. S'il s'allonge encore davantage en réduisant la longueur du nom de la variable et en modifiant certaines expressions, le code final peut ressembler à ceci:

function soNice(){for(let i=0;i<100;)console.log("nice"),i++}

La taille du fichier atteint désormais 62 octets.

À chaque étape, le code devient plus difficile à lire. Cependant, le moteur JavaScript du navigateur interprète chacun d'eux exactement de la même manière. L'avantage de l'obscurcissement du code de cette manière peut aider à réduire la taille des fichiers. 112 B n'était pas vraiment beaucoup au départ, mais la taille a tout de même été réduite de 50 %.

Dans cette application, la version 4 de webpack est utilisée comme outil de regroupement de modules. La version spécifique est visible dans package.json.

"devDependencies": {
  //...
  "webpack": "^4.16.4",
  //...
}

La version 4 minimise déjà le bundle par défaut en mode production. Il utilise TerserWebpackPlugin, un plug-in pour Terser. Terser est un outil populaire utilisé pour compresser le code JavaScript.

Pour vous faire une idée de l'apparence du code minifié, cliquez sur main.bundle.js dans le panneau Network (Réseau) des outils de développement. Cliquez maintenant sur l'onglet Response (Réponse).

Le code sous sa forme finale, minifié et tronqué, est affiché dans le corps de la réponse. Pour connaître la taille que le bundle aurait pu atteindre s'il n'a pas été réduit, ouvrez webpack.config.js et mettez à jour la configuration mode.

module.exports = {
  mode: 'production',
  mode: 'none',
  //...

Rechargez l'application et examinez à nouveau la taille du bundle via le panneau Network (Réseau) des outils de développement.

C'est une différence assez importante ! 😅

Assurez-vous d'annuler les modifications ici avant de continuer.

module.exports = {
  mode: 'production',
  mode: 'none',
  //...

L'inclusion d'un processus de minification du code dans votre application dépend des outils que vous utilisez:

• Si vous utilisez webpack v4 ou une version ultérieure, aucune tâche supplémentaire n'est requise, car le code est minifié par défaut en mode production. 👍
• Si vous utilisez une ancienne version de webpack, installez et incluez TerserWebpackPlugin dans le processus de compilation webpack. La documentation explique cela en détail.
• D'autres plug-ins de minimisation existent également et peuvent être utilisés à la place, tels que BabelMinifyWebpackPlugin et ClosureCompilerPlugin.
• Si aucun outil de regroupement de modules n'est utilisé, utilisez Terser comme outil de ligne de commande ou incluez-le directement en tant que dépendance.

Compression

Bien que le terme "compression" soit parfois utilisé de manière vague pour expliquer comment le code est réduit lors du processus de minimisation, il n'est pas réellement compressé au sens littéral.

La compression fait généralement référence au code qui a été modifié à l'aide d'un algorithme de compression de données. Contrairement à la minification, qui fournit un code parfaitement valide, le code compressé doit être décompressé avant d'être utilisé.

Pour chaque requête et réponse HTTP, les navigateurs et les serveurs Web peuvent ajouter des en-têtes pour inclure des informations supplémentaires sur l'élément récupéré ou reçu. Vous pouvez le voir dans l'onglet Headers du panneau DevTools Network, où trois types sont affichés:

• General (Général) représente les en-têtes généraux pertinents pour l'ensemble de l'interaction requête-réponse.
• En-têtes de réponse affiche une liste d'en-têtes spécifiques à la réponse réelle du serveur.
• En-têtes de requête affiche une liste d'en-têtes associés à la requête par le client.

Examinez l'en-tête accept-encoding dans Request Headers.

accept-encoding est utilisé par le navigateur pour spécifier les formats d'encodage de contenu ou les algorithmes de compression qu'il prend en charge. Il existe de nombreux algorithmes de compression de texte, mais seuls trois sont compatibles avec la compression (et la décompression) des requêtes réseau HTTP:

• Gzip (gzip): format de compression le plus utilisé pour les interactions entre le serveur et le client. Il s'appuie sur l'algorithme Deflate et est compatible avec tous les navigateurs actuels.
• Déflation (deflate): n'est pas couramment utilisé.
• Brotli (br): algorithme de compression plus récent qui vise à améliorer davantage les ratios de compression, ce qui peut entraîner des chargements de pages encore plus rapides. Il est compatible avec les dernières versions de la plupart des navigateurs.

L'exemple d'application présenté dans ce tutoriel est identique à celui décrit dans l'atelier de programmation Supprimer le code inutilisé, à la différence près que Express est désormais utilisé comme framework de serveur. Dans les sections suivantes, nous allons explorer la compression statique et dynamique.

Compression dynamique

La compression dynamique consiste à compresser les éléments à la volée, à mesure qu'ils sont demandés par le navigateur.

Avantages

• Il n'est pas nécessaire de créer et de mettre à jour des versions compressées enregistrées des composants.
• La compression instantanée fonctionne particulièrement bien pour les pages Web générées dynamiquement.

Inconvénients

• La compression des fichiers à des niveaux supérieurs pour obtenir de meilleurs taux de compression prend plus de temps. Cela peut entraîner une baisse des performances, car l'utilisateur attend que les composants soient compressés avant d'être envoyés par le serveur.

Compression dynamique avec Node/Express

Le fichier server.js est responsable de la configuration du serveur de nœuds qui héberge l'application.

const express = require('express');

const app = express();

app.use(express.static('public'));

const listener = app.listen(process.env.PORT, function() {
  console.log('Your app is listening on port ' + listener.address().port);
});

Actuellement, il s'agit d'importer express et d'utiliser le middleware express.static pour charger tous les fichiers HTML, JS et CSS statiques dans le répertoire public/ (ces fichiers sont créés par webpack à chaque compilation).

Pour vous assurer que tous les éléments sont compressés chaque fois qu'ils sont demandés, vous pouvez utiliser la bibliothèque de middleware de compression. Commencez par l'ajouter en tant que devDependency dans package.json :

"devDependencies": {
  //...
  "compression": "^1.7.3"
},

Importez-le ensuite dans le fichier serveur server.js:

const express = require('express');
const compression = require('compression');

Ajoutez-le en tant qu'intergiciel avant le montage de express.static:

//...

const app = express();

app.use(compression());

app.use(express.static('public'));

//...

Actualisez maintenant l'application et examinez la taille du bundle dans le panneau Network (Réseau).

De 225 Ko à 61,6 Ko ! Dans Response Headers, un en-tête content-encoding indique que le serveur envoie ce fichier encodé avec gzip.

Compression statique

L'idée de la compression statique est de compresser et d'enregistrer les éléments à l'avance.

Avantages

• La latence due à des niveaux de compression élevés n'est plus un problème. Rien ne doit se produire à la volée pour compresser les fichiers, car ils peuvent désormais être récupérés directement.

Inconvénients

• Les éléments doivent être compressés à chaque compilation. Les temps de compilation peuvent augmenter considérablement si des niveaux de compression élevés sont utilisés.

Compression statique avec Node/Express et webpack

Étant donné que la compression statique implique de compresser les fichiers à l'avance, les paramètres webpack peuvent être modifiés pour compresser les éléments lors de l'étape de compilation. Pour ce faire, vous pouvez utiliser CompressionPlugin.

Commencez par l'ajouter en tant que devDependency dans package.json:

"devDependencies": {
  //...
  "compression-webpack-plugin": "^1.1.11"
},

Comme tout autre plug-in webpack, importez-le dans le fichier de configuration, webpack.config.js:.

const path = require("path");

//...

const CompressionPlugin = require("compression-webpack-plugin");

et l'incluez dans le tableau plugins:

module.exports = {
  //...
  plugins: [
    //...
    new CompressionPlugin()
  ]
}

Par défaut, le plug-in compresse les fichiers de compilation à l'aide de gzip. Consultez la documentation pour découvrir comment ajouter des options pour utiliser un algorithme différent ou inclure/exclure certains fichiers.

Lorsque l'application se recharge et se recompile, une version compressée du bundle principal est désormais créée. Ouvrez la console Glitch pour examiner le contenu du répertoire public/ final servi par le serveur Node.

• Cliquez sur le bouton Tools (Outils).
• Cliquez sur le bouton Console.
• Dans la console, exécutez les commandes suivantes pour accéder au répertoire public et afficher tous ses fichiers :

cd public
ls

La version compressée du lot, main.bundle.js.gz, est désormais également enregistrée ici. CompressionPlugin compresse également index.html par défaut.

La prochaine étape consiste à demander au serveur d'envoyer ces fichiers compressés par gzip chaque fois que leurs versions JS d'origine sont demandées. Pour ce faire, définissez une nouvelle route dans server.js avant que les fichiers ne soient diffusés avec express.static.

const express = require('express');
const app = express();

app.get('*.js', (req, res, next) => {
  req.url = req.url + '.gz';
  res.set('Content-Encoding', 'gzip');
  next();
});

app.use(express.static('public'));

//...

app.get permet d'indiquer au serveur comment répondre à une requête GET pour un point de terminaison spécifique. Une fonction de rappel est ensuite utilisée pour définir la manière de gérer cette requête. Le parcours fonctionne comme suit :

• Spécifier '*.js' comme premier argument signifie que cela fonctionne pour chaque point de terminaison déclenché pour extraire un fichier JS.
• Dans le rappel, .gz est associé à l'URL de la requête et l'en-tête de réponse Content-Encoding est défini sur gzip.
• Enfin, next() s'assure que la séquence continue vers le prochain rappel.

Une fois l'application actualisée, examinez à nouveau le panneau Network.

Comme précédemment, la taille du lot a été nettement réduite !

Conclusion

Cet atelier de programmation a abordé le processus de minimisation et de compression du code source. Ces deux techniques deviennent la norme dans de nombreux outils disponibles aujourd'hui. Il est donc important de savoir si votre chaîne d'outils les prend déjà en charge ou si vous devez commencer à appliquer les deux processus vous-même.