# Checklist d’audit performance Next.js ## 12 points à vérifier avant une mise en production **Auteur :** Guillaume Fossier — freelance fullstack TypeScript **Public :** dirigeant, CTO ou tech lead d’agence digitale livrant des projets Next.js / React / TypeScript **Version :** 22 mai 2026 Avant une mise en production, la performance ne se résume pas à “le site semble rapide sur mon MacBook”. Ce document propose une checklist courte, actionnable, orientée projets agence. L’objectif : identifier les risques concrets avant qu’ils ne deviennent des tickets urgents, des pages lentes ou une réunion de crise déguisée en “petit point rapide”. --- ## 1. Core Web Vitals : mesurer avant d’optimiser 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 : LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1. Mesurez en local pour détecter les régressions, mais validez toujours avec des données terrain en production : Lighthouse simule, les utilisateurs subissent. **À faire** - Ajouter une mesure locale via Lighthouse ou Lighthouse CI sur les routes critiques. - Collecter les métriques réelles en production avec `web-vitals` ou Vercel Speed Insights. - Suivre mobile et desktop séparément, surtout si le trafic mobile est majoritaire. **Outil recommandé** `@lhci/cli` ou `web-vitals` --- ## 2. Images : éviter que le hero devienne un conteneur maritime 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. **À faire** - Utiliser `next/image` avec `width` / `height` ou `fill` + `sizes`. - Servir AVIF/WebP quand possible, sans forcer AVIF si l’encodage devient trop coûteux. - Utiliser `placeholder="blur"` pour les visuels importants, mais pas comme pansement sur une image trop lourde. **Outil recommandé** `next/image` --- ## 3. Fonts : contrôler le chargement typographique 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. **À faire** - Utiliser `next/font` pour self-hoster les fonts. - Limiter les variantes réellement utilisées. - Vérifier que le texte reste lisible pendant le chargement via `display: "swap"` quand le compromis visuel est acceptable. **Outil recommandé** `next/font/google` ou `next/font/local` --- ## 4. Bundle JavaScript : inspecter ce que le navigateur avale 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. **À faire** - Lancer une analyse de bundle avant release. - Remplacer les imports globaux par des imports ciblés quand la librairie le permet. - Déplacer les composants interactifs au plus bas niveau possible. **Outil recommandé** `@next/bundle-analyzer` ou `pnpm next experimental-analyze` --- ## 5. Rendering strategy : choisir par route, pas par religion 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é. **À faire** - Classer chaque route : statique, révalidable, dynamique ou interactive. - Éviter `"use client"` au niveau page/layout sauf nécessité réelle. - Documenter les routes qui exigent des données temps réel ou quasi temps réel. **Outil recommandé** `next build` avec inspection des routes générées --- ## 6. Caching : rendre explicite ce qui est frais, révalidé ou jamais caché 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. **À faire** - Définir les `revalidate` par ressource, pas au hasard dans le code. - Utiliser les tags de cache pour invalider proprement les contenus liés. - Vérifier les headers CDN sur les pages publiques critiques. **Outil recommandé** `fetch(url, { next: { revalidate: 3600, tags: ["..."] } })` --- ## 7. Server Components : réduire le JavaScript client sans casser l’UX 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. **À faire** - Charger les données serveur dans les Server Components quand c’est possible. - Encapsuler les zones lentes derrière des boundaries `Suspense`. - Garder les composants client petits et proches de l’interaction. **Outil recommandé** React `Suspense` --- ## 8. Edge Runtime vs Node.js : ne pas mettre l’Edge partout par réflexe 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. **À faire** - Réserver Edge aux middlewares et routes légères à forte sensibilité latence. - Vérifier la compatibilité des dépendances avant migration. - Garder Node.js pour les traitements lourds ou les intégrations backend complexes. **Outil recommandé** `export const runtime = "edge"` ou `export const runtime = "nodejs"` --- ## 9. Database queries : tuer les N+1 avant qu’ils ne tuent la page 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. **À faire** - Identifier les routes qui déclenchent plusieurs requêtes par item affiché. - Vérifier les index sur les colonnes de filtre, jointure et tri. - Configurer le connection pooling selon l’hébergeur et le runtime. **Outil recommandé** `EXPLAIN ANALYZE` --- ## 10. Third-party scripts : charger tard ce qui n’est pas vital 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. **À faire** - Charger les scripts via `next/script`, pas via `