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 font aussi. Vous devez surveiller les tailles de bundle pour vous assurer qu'elles ne deviennent pas trop importantes 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 les tailles de bundle à votre place.

Pour voir comment cela fonctionne, voici une application qui compte les jours restants avant le Nouvel An. Il est conçu avec React et moment.js. (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 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 leurs tailles, triés par couleur, saisissez webpack dans la console.

webpack

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

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

Webpack ne vous avertit pas seulement, mais vous donne également des recommandations sur la façon de 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é

Le budget de performances approprié dépend de la nature de votre projet. Il est toujours préférable de faire vos propres recherches. En règle générale, il est conseillé de ne pas dépasser 170 Ko de ressources critiques compressées/minimisées.

Pour cette démonstration simple, essayez d'être encore plus prudent et définissez le budget sur 100 ko (97,7 ko). 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 est effectuée. Il est préférable de l'utiliser dans les environnements de développement.
2. error: affiche un message d'erreur rouge, mais la compilation est toujours acceptée. Ce paramètre est recommandé pour les builds de production.
3. false: aucun avertissement ni aucune erreur ne s'affiche.

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 de réduire les temps de chargement. (De nombreux exemples 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 créées, mais seulement de leur fonctionnalité et de leur rapidité. Si vous dépassez le budget de performances, il est temps de réfléchir aux optimisations possibles.

Dans la pratique, les grands frameworks côté client sont généralement difficiles à remplacer. Il est donc important de les utiliser judicieusement. Avec un peu de recherche, 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 plus judicieux de ne pas utiliser du tout de framework ou de bibliothèque si cela a un impact significatif sur les performances.

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

Dans app/components/Countdown.jsx, supprimez les éléments suivants:

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

Supprimez cette ligne:

const moment = require('moment');

Cela nécessite un peu de calcul, mais vous pouvez implémenter le même compte à rebours avec JavaScript standard:

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 économisé 223 ko (230 ko) et l'application est sous le budget.🎉

Surveiller

La configuration d'un budget de performances dans webpack ne nécessite que quelques lignes de code. Vous serez averti si vous ajoutez (accidentellement) une grande dépendance. Comme dit le proverbe, "loin des yeux, loin du cœur", mais webpack peut vous assurer que vous êtes toujours au courant des conséquences sur les performances.