Rendu et cache Next.js, statique ou dynamique

L'outil le plus utile de tout ce chantier. Il est gratuit, et personne ne l'ouvre jamais.

La commande npm run build affiche à la fin la liste complète de vos routes, avec un symbole devant chacune et une légende en bas. Vous y lisez d'un coup d'oeil si une page est fabriquée à la compilation, prégénérée à partir de paramètres, ou recalculée à chaque visite.

Ce que ce tableau révèle, et qu'aucun autre outil ne montre aussi vite.

• Une page que vous croyiez figée et qui est en réalité dynamique. Le coupable est presque toujours une lecture de paramètres d'adresse ou d'en-têtes quelque part dans l'arbre.
• Le poids du code envoyé au navigateur, affiché route par route. Une page à 400 kilooctets a un problème, et c'est souvent un composant client trop haut placé.
• Le nombre de pages prégénérées, à comparer avec ce que vous attendiez.

Prenez l'habitude de lire ces 20 lignes après chaque build sérieux. Un site qui bascule en dynamique le fait toujours par accident, une page à la fois, sans que personne ne s'en aperçoive.

Ce tableau détermine aussi votre facture d'hébergement. Un site entièrement figé se sert pour presque rien, un site dynamique demande un environnement d'exécution qui suit le trafic, comme nous le détaillons dans notre article sur l'hébergement de Next.js en France.

Le cas est universel. Un blog, un catalogue, un annuaire. L'adresse contient un identifiant, et Next.js ne peut pas deviner les valeurs possibles.

Sans indication, ces pages sont recalculées à chaque visite. 100 personnes ouvrent le même article, le serveur va chercher 100 fois la même donnée et refabrique 100 fois le même HTML.

La fonction generateStaticParams résout cela. Elle renvoie la liste des valeurs possibles, et Next.js fabrique toutes ces pages pendant la compilation. Le visiteur reçoit ensuite du HTML déjà prêt, sans aucune attente.

2 points pratiques.

• Le repli sur les pages non prégénérées. Si quelqu'un ouvre une adresse absente de la liste, elle est fabriquée à ce moment-là puis mémorisée pour les visiteurs suivants. Seule la première personne attend. Ce comportement n'existe que si vous avez implémenté la fonction, ce qui permet de ne prégénérer que vos 200 pages les plus importantes sur un catalogue de 50000.
• La donnée qui bouge. Prégénérer un contenu qui change plusieurs fois par jour vous expose à servir une version périmée. Sur ces pages, prévoyez une régénération périodique ou une invalidation déclenchée par votre outil de publication.

Traitez au passage le cas de la page introuvable. Une adresse sans donnée doit renvoyer une vraie page d'erreur, avec le bon code de statut. Une page vide qui répond correctement est le pire signal possible pour un robot, qui la lit comme un contenu de mauvaise qualité plutôt que comme une absence.

Voici ce qui a changé en profondeur, et qui règle le reproche le plus entendu sur Next.js.

Le principe est inversé. Avec les Cache Components activés dans la configuration, tout ce qui va chercher une donnée s'exécute à chaque requête, sauf si vous demandez explicitement le contraire. Fini le cache implicite qui gardait une donnée sans que personne ne l'ait décidé.

3 outils, tous stables depuis la version 16.2.

• use cache. Une directive posée en tête d'un fichier, d'une fonction ou d'un composant. Ce qu'elle couvre est mémorisé.
• cacheLife. La durée de vie, exprimée en profils lisibles comme des minutes, des heures ou des jours, ou avec des valeurs précises si vous en avez besoin.
• cacheTag et updateTag. Une étiquette posée sur une entrée, qui permet ensuite d'invalider exactement cette entrée quand la donnée change, sans purger le reste.

Ce trio remplace la fonction unstable_cache, désormais dépréciée. Si votre projet l'utilise encore, c'est le chemin de migration officiel.

Un mot sur le préfixe qui a disparu. Ces interfaces portaient jusqu'ici une mention d'instabilité, ce qui a longtemps freiné leur adoption en production. Ce n'est plus le cas depuis la version 16.2, elles sont sorties de cette zone d'incertitude.

C'est le modèle le plus intéressant de la version 16, et il évite d'avoir à choisir.

Le constat de départ est rageant. Une page produit est figée à 95 %, sauf le stock. Un tableau de bord est identique pour tous, sauf le nom de l'utilisateur. Avant, un seul élément personnel suffisait à faire basculer toute la page en calcul à la demande.

Le prérendu partiel casse cette règle. La coque de la page part instantanément depuis le cache, avec sa mise en page, ses textes et ses images. Les zones vraiment variables arrivent ensuite, en flux, et se remplacent à leur place exacte. Activer les Cache Components suffit à en faire le comportement par défaut, l'ancien réglage expérimental n'existe plus.

La mise en oeuvre repose sur le composant Suspense, qui délimite chaque zone dynamique et affiche une attente pendant son calcul.

Un conseil de rendu qui vaut pour tout le monde. Remplacez les roues qui tournent par des silhouettes grises reprenant la forme du contenu à venir. La durée réelle est identique, la perception est très différente, parce que l'oeil comprend déjà où les choses vont apparaître et se prépare à agir.

Le fichier loading.tsx applique le même principe au changement de page. Placé dans un dossier, il ne vaut que pour cette section, ce qui permet une attente qui ressemble à la page attendue plutôt qu'un chargement générique sur tout le site.

Terminons par une mise au point, parce que le sujet est souvent survendu.

La vitesse est un critère de classement, mais un critère modeste. Elle sert surtout de départage entre 2 pages de qualité comparable, et elle pénalise surtout les sites franchement lents. Aucune optimisation de cache ne fera monter un contenu médiocre.

Là où le gain est certain, c'est avant le classement.

• L'abandon. Une part importante des visiteurs quitte une page qui met plus de 3 secondes à s'afficher. Ils ne sont jamais comptés comme des lecteurs, seulement comme du trafic perdu.
• Le budget d'exploration. Un site rapide est exploré plus largement à ressources égales. Sur un gros catalogue, cela décide du nombre de pages réellement connues de Google.
• La conversion. C'est le seul chiffre qui intéresse un dirigeant, et il réagit à la vitesse bien plus nettement que le classement.

Avant d'optimiser le cache, vérifiez d'où vient la lenteur. Sur beaucoup de sites, elle ne vient pas du serveur mais des effets visuels posés par-dessus, sujet que nous traitons dans notre article sur ce que coûtent vraiment les effets à la mode.

La bonne façon de poser le problème. Le cache n'est pas une technique de référencement. C'est une technique de service. Il rend le site agréable, et un site agréable est mieux traité par tout le monde, robots compris. Notre analyse complète de Next.js remet ces gains en face de leur coût réel.