Next.js – Bien comprendre le comportement par défaut du composant Link et son prefetch

Développer avec Next.js, suppose d’utiliser le composant <Link> pour la navigation interne. Pourtant, derrière la simplicité de ce composant se cache un mécanisme qui peut avoir des conséquences : le prefetch .

Le prefetch, c’est quoi exactement ?

Le prefetch ne précharge pas une page HTML complète comme on pourrait le penser. Il télécharge seulement les fichiers statiques nécessaires :

• Le bundle JavaScript de la page
• Les données statiques si la page utilise getStaticProps
• Avec l’App Router (Next.js 13+), parfois les layouts partagés

Ces fichiers viennent du dossier _next/ et ne touchent pas au serveur. Une fois téléchargés, ils sont mis en cache côté client.

Quand le prefetch est-il déclenché ?

Le prefetch ne fonctionne qu’en production, et seulement pour les liens visibles à l’écran (dans le viewport). Il peut également se déclencher au survol d’un lien, avec un petit délai pour éviter les déclenchements accidentels.

Résultat : sur une page avec beaucoup de liens utilisant le composant <Link>, ceux qui sont affichés dans le viewport vont commencer à précharger discrètement certains éléments de leurs pages cibles.

Le problème

Même si le serveur n’est pas sollicité, chaque lien préchargé consomme :

• De la bande passante (qui peut être limitée sur mobile)
• Des requêtes HTTP supplémentaires
• De la mémoire côté navigateur
• De l’énergie

Si l’utilisateur ne clique jamais sur ces liens, tout ce trafic réseau est inutile. Pire, cela peut ralentir le chargement initial de la page si trop de ressources sont préchargées en arrière-plan.

Le cas critique : les listes non paginées

Imaginez une page avec une liste de 100 articles, chacun avec un lien vers sa page détail. Si tous ces liens sont visibles (liste infinie, pas de pagination), Next.js va tenter de précharger tous les liens visibles dans le viewport. Même avec un viewport limité, on peut facilement se retrouver avec 20-30 requêtes simultanées qui partent en arrière-plan.

C’est exactement le genre de situation où le prefetch automatique devient contre-productif.

Côté métriques, cela peut entraîner une dégradation des Core Web Vitals et l’écoindex de votre site.

Reprendre le contrôle – Une stratégie au cas par cas

Next.js permet de désactiver le prefetch mais, à ma connaissance, seulement au niveau de chaque lien :

// Désactiver pour un lien spécifique
<Link href="/page" prefetch={false}>
  Page
</Link>

A ce jour il ne semble pas exister d’option globale officielle pour désactiver le prefetch par défaut sur toute l’application.

Il s’agit donc de faire preuve de discernement et de distinguer au cas par cas, en analysant le parcours utilisateurs, les pages qui ont un intérêt à conserver ce mécanisme :

• Est-ce une page-clé dans le parcours utilisateur ? (Oui → laisser le prefetch)
• Est-ce une page rarement visitée ou annexe ? (Non → désactiver le prefetch)
• Y a-t-il beaucoup de liens visibles d’un coup (ex : footer, navigation secondaire, longue liste) ? → potentiellement trop de prefetch simultanés, il faut arbitrer.

Illustration

Illustrons avec un exemple simplifié. Prenons une structure de site Next.js simple (très très simple) qui présente dans le viewport de nombreux liens utilisant <Link> avec prefetch activé par défaut.

Au chargement de la page on peut observer le mécanisme de prefetch en action (les tailles en ko sont ridicules car les pages de destinations sont quasiment vides et ne reflètent pas le poids d’une page réelle en production). On peut constater sur l’image ci-dessous que Next.js va, appliquant le comportement par défaut, précharger les éléments pour tous les liens affichés que ce soit les pages importantes, les pages secondaires, les produits mis en avant ou les articles. Or toutes ces pages n’ont pas la même importance dans le parcours utilisateurs et certaines vont être préchargées pour rien, juste « au cas où ». Or dans une démarche d’écoconception chaque ko chargé compte.

Si nous appliquons le prefetch avec discernement sur les liens essentielles (arbitraires pour l’exemple) le nombre de requêtes diminue ainsi que le volume de données transférées tout en gardant le bénéfice du prefetch pour les pages réellement essentielles.

Ce qu’il faut retenir

Le prefetch automatique part d’une bonne intention : rendre la navigation plus fluide pour l’utilisateur. Mais il faut avoir conscience de ce mécanisme par défaut et savoir quand s’en servir, et surtout quand l’éviter.

Pour les liens vers des pages importantes du parcours utilisateur, conserver ce mécanisme peut valoir le coup. Pour les liens secondaires ou les pages rarement visitées, mieux vaut le désactiver.

C’est un compromis à trouver entre performance perçue, nombre de requêtes et consommation de ressources. Tous les liens ne méritent pas le même traitement et une bonne gestion du composant <Link> peut être un levier supplémentaire d’optimisation en matière de performance et d’écoconception.