Définir des budgets de performance avec webpack

Milica Mihajlija

Webpack combine tous vos fichiers importés et les regroupe dans un ou plusieurs fichiers de sortie appelés "bundles". Le regroupement est pratique, mais à mesure que votre application se développe, vos bundles le feront aussi. Vous devez surveiller la taille des bundles pour vous assurer qu'ils ne deviennent pas trop volumineux et n'affectent pas le temps de chargement de votre application. Webpack permet de définir des budgets de performances en fonction de la taille des composants et peut surveiller la taille des bundles pour vous.

Pour voir comment cela fonctionne, voici une application qui compte les jours restants jusqu'au Nouvel An. Il est conçu avec React et moment.js. (Tout comme les applications réelles qui s'appuient de plus en plus sur des frameworks et des bibliothèques. 😉)

Mesurer

Cet atelier de programmation contient déjà l'application groupée avec webpack.

1. Cliquez sur Remix to Edit (Remixer pour modifier) pour rendre le projet modifiable.
2. Cliquez sur Terminal (remarque : si le bouton "Terminal" ne s'affiche pas, vous devrez peut-être utiliser l'option "Plein écran").
3. Pour obtenir une liste des composants et de leur taille, avec un code couleur, saisissez webpack dans la console.

webpack

Le bundle principal est mis en surbrillance en jaune, car il est supérieur à 244 Kio (250 Ko).

Ces avertissements sont activés par défaut en mode production. Le seuil par défaut est de 244 Kio non compressés, à la fois pour les éléments et les points d'entrée (la combinaison de tous les éléments utilisés lors du chargement initial d'une page).

Webpack vous avertira et vous donnera des conseils pour réduire la taille de vos bundles. Pour en savoir plus sur les techniques recommandées, consultez Web Fundamentals.

Définir un budget de performances personnalisé

Un budget de performances approprié dépendra de la nature de votre projet. Il est toujours préférable de faire vos propres recherches. Une bonne règle de base consiste à fournir moins de 170 Ko de ressources critiques compressées/minifiées.

Pour cette démo simple, essayez d'être encore plus conservateur et définissez le budget sur 100 ko (97,7 kio). Dans webpack.config.js, ajoutez les éléments suivants :

module.exports = {
  //...
  performance: {
    maxAssetSize: 100000,
    maxEntrypointSize: 100000,
    hints: "warning"
  }
};

Le nouveau budget de performances est défini en octets :

• 100 000 octets pour les composants individuels (maxAssetSize)
• 100 000 octets pour le point d'entrée (maxEntrypointSize)

Dans ce cas, il n'y a qu'un seul bundle, qui sert également de point d'entrée.

Les valeurs possibles pour hints sont les suivantes :

1. warning (par défaut) : affiche un message d'avertissement jaune, mais la compilation réussit. Il est préférable d'utiliser cette fonctionnalité dans les environnements de développement.
2. error : un message d'erreur rouge s'affiche, mais la compilation réussit quand même. Ce paramètre est recommandé pour les versions de production.
3. false : aucun avertissement ni aucune erreur ne s'affichent.

Optimiser

L'objectif d'un budget de performances est de vous avertir des problèmes de performances avant qu'ils ne deviennent trop difficiles à résoudre. Il existe toujours plusieurs façons de créer une application, et certaines techniques permettent d'accélérer les temps de chargement. (Beaucoup d'entre eux sont documentés dans Optimiser votre code JavaScript.) 🤓)

Les frameworks et les bibliothèques facilitent la vie des développeurs, mais les utilisateurs finaux ne se soucient pas vraiment de la façon dont les applications sont conçues. Ils veulent simplement qu'elles soient fonctionnelles et rapides. Si vous dépassez le budget de performances, il est temps de réfléchir à d'éventuelles optimisations.

Dans le monde réel, les grands frameworks côté client sont généralement difficiles à remplacer. Il est donc important de les utiliser à bon escient. En faisant quelques recherches, vous pouvez souvent trouver des alternatives plus petites aux bibliothèques populaires qui font tout aussi bien l'affaire (date-fns est une bonne alternative à moment.js). Il est parfois préférable de ne pas utiliser de framework ni de bibliothèque du tout si cela a un impact important sur les performances.

La suppression du code inutilisé est un bon moyen d'optimiser les applications qui incluent de grandes bibliothèques tierces. Le guide sur la suppression du code inutilisé explique ce processus en détail. Voici une méthode rapide pour réécrire le code du compte à rebours sans utiliser moment.js.

Dans app/components/Countdown.jsx, supprimez :

const today = moment();
const yearEnd = moment().endOf('year');
const daysLeft = yearEnd.diff(today, 'days');

Supprimez cette ligne :

const moment = require('moment');

Cela demande un peu de calculs, mais vous pouvez implémenter le même compte à rebours avec JavaScript brut :

const today = new Date();
const year = today.getFullYear();
const yearEnd = new Date(year,11,31); //months are zero indexed in JS
const timeDiff = Math.abs(yearEnd.getTime() - today.getTime());
const daysLeft = Math.ceil(timeDiff / (1000 * 3600 * 24));

Supprimez maintenant moment.js de package.json et exécutez à nouveau webpack dans la console pour créer le bundle optimisé.

Et voilà ! Vous avez réduit la taille de l'application de 223 Kio (230 Ko), qui respecte désormais le budget.🎉

Surveiller

La configuration d'un budget de performances dans webpack ne nécessite que quelques lignes de code. Vous recevrez un avertissement si vous ajoutez (accidentellement) une dépendance importante. Le dicton dit "loin des yeux, loin du cœur", mais webpack peut s'assurer que vous êtes conscient des implications en termes de performances à tout moment.