22 mai 2026 · Performance · ressource · 12 points · 4 chapitres

Checklist d’audit performance Next.js

12 points à vérifier avant une mise en production. Pensée pour les agences digitales qui livrent du Next.js. Courte, actionnable, scannable en 30 secondes.

Markdown CC-BY 4.0 — partage libre

Avant une mise en production, la performance ne se résume pas à « le site semble rapide sur mon MacBook ». Cette checklist propose les vérifications minimales orientées projets agence — identifier les risques avant qu’ils ne deviennent des tickets urgents, des pages lentes ou une réunion de crise déguisée en « petit point rapide ».

Chapitre I

Ce que voit l’utilisateur

Core Web Vitals

« mesurer avant d’optimiser »

Le piège

Lighthouse simule. Les utilisateurs subissent.

≤ 2,5 s
LCP
Chargement
≤ 200 ms
INP
Réactivité
≤ 0,1
CLS
Stabilité
À faire
  • Mesure locale via Lighthouse CI sur les routes critiques.
  • Collecte terrain avec web-vitals ou Vercel Speed Insights.
  • Suivre mobile et desktop séparément.
Avec
@lhci/cli ou web-vitals
Pourquoi

Les trois métriques à surveiller sont LCP pour le chargement, INP pour la réactivité et CLS pour la stabilité visuelle. Les seuils « bons » recommandés par Google sont ci-contre. Mesurez en local pour détecter les régressions, mais validez toujours avec des données terrain en production : Lighthouse simule, les utilisateurs subissent.

Images

« éviter que le hero devienne un conteneur maritime »

Le piège

Le hero 4K « au cas où » = LCP qui se traîne.

À faire
  • next/image avec width / height ou fill + sizes.
  • AVIF / WebP quand l’encodage suit, sans forcer AVIF.
  • placeholder="blur" ciblé, pas comme alibi.
Avec
next/image
Pourquoi

Les images sont souvent le premier poste de poids sur une landing, un site vitrine ou une page e-commerce. next/image aide, mais ne corrige pas un mauvais dimensionnement, un sizes absent ou un visuel 4K exporté « au cas où ». Le LCP est souvent une image hero : elle doit être servie au bon format, à la bonne taille et avec des dimensions intrinsèques.

Fonts

« contrôler le chargement typographique »

Le piège

Six graisses, trois familles = du CLS pour rien.

À faire
  • next/font pour self-hoster.
  • Limiter aux variantes réellement utilisées.
  • display: "swap" quand le compromis visuel passe.
Avec
next/font/google ou next/font/local
Pourquoi

Les polices peuvent provoquer du CLS, ralentir le rendu initial ou bloquer inutilement le texte. next/font permet de self-hoster et d’optimiser les fonts sans dépendre d’un CDN Google Fonts au runtime. Le bon choix dépend du projet : une identité premium peut justifier une fonte spécifique, mais rarement six graisses et trois familles.

Third-party scripts

« charger tard ce qui n’est pas vital »

Le piège

Un script tiers dégrade tout, sans avoir l’air d’être votre code.

À faire
  • Tout passer par next/script, pas de <script> brut.
  • lazyOnload pour tout ce qui n’est pas critique.
  • Supprimer les tags non utilisés avant la prod.
Avec
next/script
Pourquoi

Analytics, chat widgets, pixels publicitaires, AB testing : chaque script tiers défend sa priorité comme si le monde dépendait de lui. En réalité, beaucoup peuvent attendre l’hydratation partielle ou l’inactivité navigateur. Un script tiers peut dégrader INP, LCP et la stabilité de page sans apparaître comme « votre » code.

Chapitre II

Architecture du code

04
Ne pas expédier un camion pour livrer une enveloppe.

Bundle JavaScript

« inspecter ce que le navigateur avale »

Le piège

"use client" trop haut dans l’arbre = bundle qui explose.

À faire
  • Analyse de bundle avant chaque release.
  • Imports ciblés au lieu d’imports globaux.
  • Composants interactifs au plus bas niveau possible.
Avec
@next/bundle-analyzer
Pourquoi

Un projet Next.js peut être « server-first » sur le papier et livrer trop de JavaScript côté client dans les faits. Les causes classiques : composants marqués "use client" trop haut dans l’arbre, librairies UI importées globalement, dépendances lourdes pour un petit besoin. Le but n’est pas d’avoir zéro JS, mais de ne pas expédier un camion pour livrer une enveloppe.

Rendering strategy

« choisir par route, pas par religion »

Le piège

SSR/SSG/ISR ne sont pas des camps politiques.

À faire
  • Classer chaque route : statique / révalidable / dynamique / interactive.
  • Pas de "use client" au niveau page/layout sauf nécessité.
  • Documenter les routes temps-réel ou quasi temps-réel.
Avec
next build + inspection des routes
Pourquoi

SSG, ISR, SSR, Server Components et Client Components ne sont pas des camps politiques. Une page marketing stable peut être statique. Une page de catalogue peut utiliser ISR. Un espace connecté avec données très fraîches peut nécessiter SSR ou du fetching serveur dynamique. Le mauvais choix coûte soit en performance, soit en fraîcheur, soit en complexité.

Server Components

« réduire le JavaScript client sans casser l’UX »

Le piège

La frontière client/serveur héritée d’un copier-coller.

À faire
  • Données serveur dans les Server Components.
  • Zones lentes derrière des boundaries Suspense.
  • Composants client petits, proches de l’interaction.
Avec
React Suspense
Pourquoi

Les Server Components sont utiles pour charger les données côté serveur, réduire le bundle client et garder les secrets hors du navigateur. Ils ne remplacent pas les composants client : formulaires riches, filtres instantanés et interactions locales restent côté client. La frontière doit être volontaire, pas héritée d’un copier-coller.

Edge Runtime vs Node.js

« ne pas mettre l’Edge partout par réflexe »

Le piège

L’Edge partout par réflexe = deps natives cassées.

Edge Runtime

Pour
  • Middlewares globaux
  • Routes légères sensibles à la latence
  • Réponses proches de l’utilisateur
Limites
  • APIs Node.js limitées
  • Pas d’accès filesystem
  • Dépendances natives incompatibles

Node.js

Pour
  • ORM, drivers DB classiques
  • Traitement lourd, génération PDF
  • Toutes les dépendances Node
Limites
  • Latence plus élevée à l’échelle globale
  • Cold start plus lourd selon l’hébergeur
À faire
  • Edge pour middlewares et routes légères latence-sensibles.
  • Compat des dépendances vérifiée avant migration.
  • Node pour les traitements lourds et intégrations backend.
Avec
export const runtime = "edge" ou "nodejs"
Pourquoi

L’Edge Runtime peut réduire la latence pour certaines routes légères et globales. Mais il limite les APIs Node.js, l’accès filesystem et certaines dépendances natives. Pour des tâches avec ORM, drivers DB, traitement lourd, génération PDF ou dépendances Node classiques, le runtime Node reste souvent plus simple et plus robuste.

Chapitre III

Données

Caching

« rendre explicite ce qui est frais, révalidé ou jamais caché »

Le piège

Un bug de cache ressemble à un bug métier.

À faire
  • Définir revalidate par ressource, pas au hasard.
  • Tags de cache pour invalider proprement.
  • Vérifier les headers CDN sur les pages critiques.
Avec
fetch(url, { next: { revalidate, tags } })
Pourquoi

Le cache Next.js est puissant, mais il peut produire des comportements surprenants si l’équipe ne formalise pas les règles. Entre fetch, revalidate, tags, CDN et headers HTTP, un bug de cache ressemble souvent à un bug métier. Le bon réflexe : définir la durée de vie attendue des données par type de contenu.

Database queries

« tuer les N+1 avant qu’ils ne tuent la page »

Le piège

Une requête « ok » seule = catastrophique en boucle.

À faire
  • Routes qui déclenchent plusieurs requêtes par item.
  • Index sur les colonnes de filtre, jointure, tri.
  • Connection pooling selon hébergeur et runtime.
Avec
EXPLAIN ANALYZE
Pourquoi

Une page rapide localement peut s’effondrer en production à cause d’un N+1, d’un index manquant ou d’un pool de connexions mal dimensionné. Sur Postgres, l’audit doit couvrir la requête, son plan, son volume et sa fréquence. Une requête « acceptable » seule peut devenir catastrophique dans une boucle.

Chapitre IV

Vie en production

Monitoring production

« observer les vraies lenteurs »

Le piège

Sans monitoring : on pilote phares éteints.

À faire
  • Core Web Vitals collectés côté production.
  • Tracing sur les routes serveur critiques.
  • Erreurs reliées au commit ou à la release.
Avec
OpenTelemetry · Sentry · Vercel Analytics
Pourquoi

Une mise en production sans monitoring performance revient à piloter de nuit avec les phares éteints, ce qui reste une stratégie, mais plutôt dans les films catastrophes. Il faut suivre les erreurs, les métriques web, les traces serveur et les routes lentes. Le minimum utile : savoir quelle route ralentit, pour quels utilisateurs, après quel déploiement.

Build & deploy

« optimiser sans rendre le pipeline illisible »

Le piège

Pipeline lent → fréquence de livraison qui chute.

Étape 01
Install
Cache CI ciblé
Étape 02
Build
Multi-stage
Étape 03
Test
Mesuré séparément
Étape 04
Artifact
Upload propre
À faire
  • Cache de build adapté à votre CI.
  • Docker multi-stage si vous déployez en container.
  • Mesurer séparément install · build · test · upload.
Avec
Turborepo cache · Docker multi-stage
Pourquoi

Le build fait partie de la performance perçue par l’équipe. Un pipeline trop lent réduit la fréquence de livraison et pousse à regrouper trop de changements. Mais l’optimisation ne doit pas transformer le déploiement en cathédrale ésotérique. Cache, étapes Docker et builds incrémentaux doivent rester compréhensibles.

En résumé

Une checklist ne rend pas un site rapide.
Elle réduit les angles morts avant livraison.

Sur un projet agence, c’est souvent là que se gagne la différence : moins d’urgence, moins d’allers-retours client, moins de « ça marchait sur staging ».

Cette checklist vient de ma pratique sur des projets clients en renfort agence. Si vous voulez l’avis d’un dev externe sur un projet en cours, écrivez-moi en deux lignes.

Sources utiles

Documentation et références

Guillaume Fossier · Freelance fullstack · guillaume-fullstack.dev

Date de publication : 22 mai 2026

Licence : CC-BY 4.0 — partage autorisé avec attribution.