Optimisation des imports en Next.js

Réduire la taille du bundle généré par Next.js

Lorsque l'on importe nos composants dans nos pages de cette façon :

import {
  ComponentA,
  ComponentB,
  ComponentC
} from '@components'

// ...

Ce qu'il se passe réellement lors de la construction du bundle (next build), c'est que webpack resolve l'intégralité du fichier @components/index.

En d'autres mots, si vous exportez aussi ComposantD, ComposantE, etc... ils seront dans le source code compilé de la page, même s'ils ne sont pas utilisés.

Il s'agit du comportement standard de webpack, tout ceci est normal. Même si cela peut nous porter préjudice :

Nous devons alors, demander à webpack de purger le code inutilisé pour nous. Cette opération s'appelle faire du tree shaking, je vous invite à voir la documentation de webpack d'un peu plus près.

Première solution pour optimiser notre bundle Next

Une solution un peu plus longue, en fonction de la densité de votre code consiste à isoler les imports de chaque composant. Ainsi, vous aurez une ligne par composant et cela risque de prendre un peu de place :

import { ComponentA } from '@components/component-a'
import { ComponentB } from '@components/component-b'
import { ComponentC } from '@components/component-c'

J'entends que cette solution peut être fastidieuse à mettre en place, surtout si votre projet comporte énormément de pages et de composants.

Mais le jeu en vaut la chandelle :

Dans notre cas, nous obtenons un gain de 16% par rapport au premier build.

Une solution plus laxiste pour optimiser la taille du bundle Next.js

Cette seconde méthode n'est pas forcément la plus propre et ne vous permettra pas d'avoir une réelle maîtrise de tout ce qu'il se passe en dessous, mais elle aura l'avantage de vous faire gagner du temps.

Cette méthode consiste à ajouter une ligne de configuration dans votre package.json afin de préciser à webpack comment effectuer son build.

{
    ...
    "sideEffects": false
}

Et voilà, le tour est joué, vous aurez à peu près le même résultat, voire le même résultat lors du build. En revanche, ici, nous précisons juste à webpack de supprimer le deadcode lors du build. En théorie, cela devrait suffire mais nous ne sommes pas à l'abris d'un imprévu étant donné que nous n'avons pas manuellement exclus ce qui semble "inutilisé".

On a souvent tendance à minimiser l'impact du poids des pages sur la performance de notre site, mais à tord. Il a été maintes et maintes fois démontré que les sites les plus lents perdent du trafic, sans doute à cause de l'impatience des utilisateurs, à qui les moyens actuels (fibre, serveurs performants, 5G, etc...) apportent encore plus de confort.