Amélioration des performances de chargement des pages Next.js et Gatsby grâce à la segmentation précise

Une nouvelle stratégie de fragmentation du webpack dans Next.js et Gatsby limite le code en double pour améliorer les performances de chargement des pages.

Houssein Djirdeh

Chrome collabore avec les outils et les frameworks de l'écosystème Open Source JavaScript. Un certain nombre d'optimisations plus récentes ont été récemment ajoutées pour améliorer les performances de chargement de Next.js et de Gatsby. Cet article décrit une stratégie améliorée de fragmentation précise, désormais fournie par défaut dans les deux frameworks.

Introduction

Comme de nombreux frameworks Web, Next.js et Gatsby utilisent webpack comme bundle principal. Webpack v3 a introduit CommonsChunkPlugin pour permettre de générer des modules partagés entre différents points d'entrée dans un ou plusieurs fragments "commons". Le code partagé peut être téléchargé séparément et stocké dans le cache du navigateur dès le début, ce qui peut améliorer les performances de chargement.

Ce modèle est devenu populaire avec de nombreux frameworks d'applications monopages adoptant une configuration de point d'entrée et de regroupement ressemblant à ceci:

Bien que pratique, le concept de regroupement de tout le code de module partagé dans un seul bloc présente des limites. Les modules qui ne sont pas partagés dans chaque point d'entrée peuvent être téléchargés pour les routes qui ne les utilisent pas, ce qui entraîne le téléchargement de plus de code que nécessaire. Par exemple, lorsque page1 charge le segment common, il charge le code pour moduleC, même si page1 n'utilise pas moduleC. Pour cette raison, ainsi que pour quelques autres, webpack v4 a supprimé le plug-in au profit d'un nouveau : SplitChunksPlugin.

Amélioration du découpage

Les paramètres par défaut de SplitChunksPlugin conviennent à la plupart des utilisateurs. Plusieurs segments de fractionnement sont créés en fonction d'un certain nombre de conditions pour éviter d'extraire du code en double sur plusieurs routes.

Cependant, de nombreux frameworks Web qui utilisent ce plug-in suivent toujours une approche "single-commons" pour la division des fragments. Next.js, par exemple, générerait un bundle commons contenant tout module utilisé dans plus de 50% des pages et dans toutes les dépendances du framework (react, react-dom, etc.).

const splitChunksConfigs = {
  …
  prod: {
    chunks: 'all',
    cacheGroups: {
      default: false,
      vendors: false,
      commons: {
        name: 'commons',
        chunks: 'all',
        minChunks: totalPages > 2 ? totalPages * 0.5 : 2,
      },
      react: {
        name: 'commons',
        chunks: 'all',
        test: /[\\/]node_modules[\\/](react|react-dom|scheduler|use-subscription)[\\/]/,
      },
    },
  },

Bien que l'inclusion de code dépendant du framework dans un bloc partagé signifie qu'il peut être téléchargé et mis en cache pour n'importe quel point d'entrée, l'heuristique basée sur l'utilisation consistant à inclure des modules courants utilisés dans plus de la moitié des pages n'est pas très efficace. La modification de ce ratio n'entraînerait que l'un des deux résultats suivants:

• Si vous réduisez le ratio, plus de code inutile est téléchargé.
• Si vous augmentez le ratio, plus de code est dupliqué sur plusieurs routes.

Pour résoudre ce problème, Next.js a adopté une configuration différente pour SplitChunksPlugin, qui réduit le code inutile pour n'importe quelle route.

• Tout module tiers suffisamment volumineux (supérieur à 160 ko) est divisé en son propre segment.
• Un bloc frameworks distinct est créé pour les dépendances du framework (react, react-dom, etc.).
• autant de segments partagés que nécessaire (jusqu'à 25) ;
• La taille minimale d'un bloc à générer est définie sur 20 Ko.

Cette stratégie de segmentation précise présente les avantages suivants :

• Les temps de chargement des pages sont améliorés. L'émission de plusieurs segments partagés au lieu d'un seul réduit la quantité de code inutile (ou en double) pour n'importe quel point d'entrée.
• Amélioration de la mise en cache lors des navigations La division des bibliothèques volumineuses et des dépendances de framework en fragments distincts réduit le risque d'invalidation du cache, car il est peu probable que les deux soient modifiées tant qu'une mise à niveau n'est pas effectuée.

Vous pouvez voir l'ensemble de la configuration adoptée par Next.js dans webpack-config.ts.

Autres requêtes HTTP

SplitChunksPlugin a défini la base du découpage précis, et l'application de cette approche à un framework comme Next.js n'était pas un concept entièrement nouveau. Cependant, de nombreux frameworks ont continué à utiliser une seule heuristique et une stratégie de bundle "commons" pour plusieurs raisons. Cela inclut la crainte que de nombreuses requêtes HTTP puissent affecter négativement les performances du site.

Les navigateurs ne peuvent ouvrir qu'un nombre limité de connexions TCP vers une seule origine (6 pour Chrome). Par conséquent, en réduisant le nombre de segments générés par un bundler, vous pouvez vous assurer que le nombre total de requêtes reste inférieur à ce seuil. Toutefois, cela ne s'applique qu'à HTTP/1.1. Le multiplexage dans HTTP/2 permet de diffuser plusieurs requêtes en parallèle à l'aide d'une seule connexion sur une seule origine. En d'autres termes, nous n'avons généralement pas à nous soucier de limiter le nombre de blocs émis par notre bundleur.

Tous les principaux navigateurs sont compatibles avec HTTP/2. Les équipes Chrome et Next.js voulaient savoir si l'augmentation du nombre de requêtes en divisant le seul bundle "commons" de Next.js en plusieurs segments partagés affecterait les performances de chargement. Il a commencé par mesurer les performances d'un seul site tout en modifiant le nombre maximal de requêtes parallèles à l'aide de la propriété maxInitialRequests.

Lors d'une moyenne de trois essais multiples sur une même page Web, les heures load, start-render et First Contentful Paint sont toutes restées à peu près les mêmes lorsque le nombre maximal de requêtes initiales a été modifié (de 5 à 15). Il est intéressant de noter que nous avons constaté une légère surcharge des performances uniquement après avoir procédé à une répartition agressive de plusieurs centaines de requêtes.

Cela a montré que rester en dessous d'un seuil fiable (20 à 25 requêtes) permettait de trouver le bon équilibre entre les performances de chargement et l'efficacité du cache. Après quelques tests de référence, le nombre de maxInitialRequest a été sélectionné sur 25.

La modification du nombre maximal de requêtes exécutées en parallèle a entraîné la création de plusieurs groupes partagés et leur séparation appropriée pour chaque point d'entrée a considérablement réduit la quantité de code inutile pour la même page.

Ce test ne visait qu'à modifier le nombre de requêtes pour voir s'il y avait un impact négatif sur les performances de chargement de la page. Les résultats suggèrent que la valeur optimale pour maxInitialRequests sur la page de test était 25, car elle a réduit la taille de la charge utile JavaScript sans ralentir la page. La quantité totale de code JavaScript nécessaire pour hydrater la page est restée à peu près la même, ce qui explique pourquoi les performances de chargement de la page n'ont pas nécessairement été améliorées avec la réduction de la quantité de code.

webpack utilise 30 Ko comme taille minimale par défaut pour la génération d'un bloc. Toutefois, associer une valeur maxInitialRequests de 25 à une taille minimale de 20 Ko a permis d'améliorer la mise en cache.

Réductions de taille avec des fragments précis

De nombreux frameworks, y compris Next.js, s'appuient sur le routage côté client (géré par JavaScript) pour injecter de nouvelles balises de script à chaque transition de route. Mais comment prédéterminer ces blocs dynamiques au moment de la compilation ?

Next.js utilise un fichier manifeste de compilation côté serveur pour déterminer les blocs de sortie utilisés par différents points d'entrée. Pour fournir ces informations au client, un fichier manifeste de compilation côté client abrégée a été créé pour mapper toutes les dépendances de chaque point d'entrée.

// Returns a promise for the dependencies for a particular route
getDependencies (route) {
  return this.promisedBuildManifest.then(
    man => (man[route] && man[route].map(url => `/_next/${url}`)) || []
  )
}

Cette nouvelle stratégie de segmentation précise a été déployée pour la première fois dans Next.js derrière un indicateur, où elle a été testée sur un certain nombre d'utilisateurs précoces. De nombreux éditeurs ont constaté une réduction significative de la quantité totale de JavaScript utilisée sur l'ensemble de leur site:

La version finale a été fournie par défaut dans la version 9.2.

Gatsby

Gatsby suivait la même approche consistant à utiliser une heuristique basée sur l'utilisation pour définir des modules courants :

config.optimization = {
  …
  splitChunks: {
    name: false,
    chunks: `all`,
    cacheGroups: {
      default: false,
      vendors: false,
      commons: {
        name: `commons`,
        chunks: `all`,
        // if a chunk is used more than half the components count,
        // we can assume it's pretty global
        minChunks: componentsCount > 2 ? componentsCount * 0.5 : 2,
      },
      react: {
        name: `commons`,
        chunks: `all`,
        test: /[\\/]node_modules[\\/](react|react-dom|scheduler)[\\/]/,
      },

En optimisant leur configuration webpack pour adopter une stratégie de segmentation granulaire similaire, ils ont également constaté des réductions importantes du code JavaScript sur de nombreux grands sites :

Consultez le PR pour comprendre comment ils ont implémenté cette logique dans leur configuration webpack, qui est envoyée par défaut dans la version 2.20.7.

Conclusion

Le concept d'envoi de blocs précis n'est pas propre à Next.js, Gatsby ni même à webpack. Tout le monde devrait envisager d'améliorer la stratégie de segmentation de son application si elle suit une approche de gros bundle "communs", quel que soit le framework ou le bundleur de modules utilisé.

• Si vous souhaitez appliquer les mêmes optimisations de fragmentation à une application vanilla React, consultez cet exemple d'application React. Il utilise une version simplifiée de la stratégie de fragmentation précise et peut vous aider à appliquer le même type de logique à votre site.
• Pour le rattachement, les segments sont créés de manière précise par défaut. Consultez manualChunks si vous souhaitez configurer manuellement le comportement.