Définir des budgets de performance avec webpack

Milica Mihajlija

Webpack combine tous vos fichiers importés et les empaquette en un ou plusieurs fichiers de sortie appelés bundles. Les offres groupées sont intéressantes, mais à mesure que votre application se développe, le nombre de groupes augmente également. Vous devez surveiller les tailles des lots pour vous assurer qu'elles ne deviennent pas trop volumineuses et qu'elles n'affectent pas le temps de chargement de votre application. Webpack prend en charge la définition de budgets de performances en fonction de la taille des éléments et peut garder un œil sur la taille des bundles pour vous.

Pour la voir en action, voici une application qui compte le nombre de jours restants avant le Nouvel An. Il est basé sur 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 fournie 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 codée par couleur des assets et de leur taille, saisissez webpack dans la console.

webpack

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

Ces avertissements sont activés par défaut en mode production, et le seuil par défaut est de 244 Kio sans compression 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, mais il vous donnera également une recommandation sur la manière de réduire la taille de vos bundles. Pour en savoir plus sur les techniques recommandées, consultez la page Web Fundamentals (Principes fondamentaux du Web – en anglais).

Définir un budget de performances personnalisé

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

Pour cette démonstration simple, essayez d'être encore plus conservateur et définissez le budget sur 100 Ko (97,7 Kio). Dans webpack.config.js, ajoutez le code suivant :

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

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

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

Dans ce cas, un seul groupe sert également de point d'entrée.

Les valeurs possibles de 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 de l'utiliser dans les environnements de développement.
2. error: affiche un message d'erreur en rouge, mais la compilation réussit tout de même. Ce paramètre est recommandé pour les builds de production.
3. false: aucun avertissement ni aucune erreur ne s'affiche.

Optimisation

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. Un grand nombre d'entre eux sont présentés dans la section 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 créées, mais seulement du fait qu'elles sont 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 à échanger. Il est donc important de les utiliser à bon escient. Après quelques recherches, vous pouvez souvent trouver des alternatives plus petites aux bibliothèques populaires qui font le même travail (date-fns est une bonne alternative pour moment.js). Parfois, il est plus judicieux de ne pas utiliser de framework ni de bibliothèque si cela a un impact significatif sur les performances.

La suppression du code inutilisé est un bon moyen d'optimiser les applications qui incluent des bibliothèques tierces volumineuses. Le guide de suppression du code inutilisé explique en détail ce processus. Voici un moyen rapide de 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');

Et supprimez cette ligne:

const moment = require('moment');

Cela demande quelques calculs, mais vous pouvez implémenter le même compte à rebours avec un script JavaScript vanilla:

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 gagné 223 Kio (230 Ko) et l'application n'a pas atteint son budget.🎉

Surveiller

La configuration d'un budget de performances dans Webpack ne nécessite que quelques lignes de code et vous serez averti si vous ajoutez (accidentellement) une dépendance importante. Bien que cette mention permette de l'oublier, le Webpack peut garantir que vous êtes toujours conscient des conséquences sur les performances.