Next-Js
Senior
Quiz-Nextjs-Senior
Performance-Nextjs
Edge-Runtime
Streaming-Ssr
Caching
Turbo-Monorepo
Image-Optimization
Questions-Entretien-Nextjs-Senior
Qcm-Nextjs-Avance
React-Server-Components
Architecture-Nextjs
Front-End
📝
Entretien Next.js Senior : performance et architecture
20 questions avancées Next.js : optimisation des performances, edge runtime, streaming SSR, caching, monorepo Turbo, image optimization et architectures avancées.
Banque de révision : les 30 questions corrigées
Voici l'intégralité des 30 questions de « Entretien Next.js Senior : performance et architecture », chacune avec sa bonne réponse et son explication. Le quiz interactif ci-dessus en tire une sélection aléatoire à chaque tentative — utilisez cette liste complète pour réviser.
Explication :
Les 4 couches : 1) Request Memoization (React, durée d'une requête, dédoublonne les fetch identiques), 2) Data Cache (Next.js, persiste entre requêtes, invalidé par
revalidateTag/revalidatePath), 3) Full Route Cache (HTML et RSC payload statiques sur le serveur), 4) Router Cache (cache in-memory côté client, durée de session ou 30s pour pages dynamiques).
Pour debugger le cache : activez les logs avec
logging: { fetches: { fullUrl: true } } dans next.config.js.
Explication :
Le PPR (expérimental, activable avec
experimental: { ppr: true }) permet de pré-rendre une coquille statique au build tout en laissant des "trous" pour le contenu dynamique qui sera streamé. Combine le meilleur du statique (instantané) et du dynamique (données fraîches).
Dans PPR, tout ce qui est hors Suspense devient statique. Placez le contenu dynamique dans des
<Suspense> pour créer les "trous" dynamiques.
Explication :
Turbopack est le nouveau bundler écrit en Rust par l'équipe Next.js (dirigée par le créateur de Webpack). Il offre des temps de compilation 5 à 10 fois plus rapides grâce à la compilation incrémentale et au cache. Limitation actuelle : disponible uniquement en développement (
next dev --turbo).
Activez Turbopack dans
next.config.js avec experimental: { turbo: {} } ou via next dev --turbo. Webpack reste utilisé pour le build production.
Explication :
On tague les fetch :
fetch(url, { next: { tags: ["posts"] } }). Pour révalider, on appelle revalidateTag("posts") dans une Server Action ou Route Handler. Tous les composants utilisant ce fetch seront mis à jour.
Combinez avec un webhook (ex: CMS headless) qui appelle votre endpoint de révalidation avec un token secret pour la sécurité.
Explication :
Une Server Action est sérialisée côté serveur en une référence unique. Quand elle est appelée depuis un Client Component (via form action ou appel direct), Next.js envoie une requête POST avec les arguments sérialisés. Le serveur reconstitue le contexte, exécute la fonction, et retourne le résultat.
Les Server Actions créent automatiquement un endpoint POST. Pour les appels directs (pas via formulaire), utilisez
startTransition pour une meilleure UX.
Explication :
Le RSC Payload est une représentation sérialisée spéciale (pas du JSON ni du HTML pur) de l'arbre de composants React rendu côté serveur. Il contient les éléments React, les props, et les références aux Client Components. Il est streamé au client qui le reconstitue en UI.
Ce format n'est pas destiné à être lu directement. React côté client l'interprète pour hydrater l'interface. C'est ce qui permet de ne pas envoyer le code JavaScript des Server Components.
Explication :
Le streaming SSR (
renderToPipeableStream) envoie le HTML progressivement. Pour optimiser TTFB : réduire le travail serveur, utiliser le caching. Pour optimiser LCP : mettre le contenu principal (above-the-fold) hors Suspense pour qu'il soit envoyé en premier.
Structurez vos pages : contenu critique hors Suspense envoyé immédiatement, contenu secondaire (commentaires, sidebar) dans des Suspense streamés après.
Explication :
L'Edge Runtime exécute le code sur les serveurs edge de Vercel/Cloudflare, géographiquement proches de l'utilisateur. Limitations : pas de
fs, net, child_process, modules natifs. Supporte les APIs Web standard : fetch, Request, Response, crypto, URL.
Activez avec
export const runtime = "edge". Idéal pour Middleware, vérifications de tokens, A/B testing, redirections géolocalisées.
Explication :
Le pattern consiste à avoir un Server Component "page" qui orchestre le fetching de données (souvent via Promise.all pour la parallélisation) et passe les résultats en props à des composants enfants spécialisés (Server ou Client). Cela maximise le rendu serveur et minimise le JavaScript client.
Structure recommandée :
Page (Server, data fetching) → Layout (Server, structure) → InteractiveWidget (Client, interactivité).
Explication :
Le hook
useOptimistic() (basé sur React 18) prend l'état initial et une fonction de mise à jour. On passe addOptimistic() dans l'action du formulaire. L'UI se met à jour immédiatement. Si la Server Action échoue, React rollback automatiquement.
Pattern complet :
const [optimisticMessages, addOptimistic] = useOptimistic(messages, (state, newMsg) => [...state, newMsg]).
Explication :
React Forget (en développement chez Meta) est un compilateur qui analyse automatiquement le code pour déterminer ce qui doit être mémorisé. Objectif : éliminer le besoin d'utiliser manuellement
useMemo, useCallback, React.memo. Next.js l'intégrera dès sa sortie stable.
Forget permettra aux développeurs de se concentrer sur la logique métier sans se soucier des optimisations de re-rendu. Impact majeur sur la DX (Developer Experience).
Explication :
Next.js utilise SWC (Speedy Web Compiler, écrit en Rust) pour la transpilation TypeScript/JSX (remplace Babel) et Turbopack (Rust) pour le bundling en développement (remplace Webpack). Les deux sont écrits en Rust pour des performances nettement supérieures.
SWC est utilisé par défaut. Turbopack s'active avec
next dev --turbo. En production, Webpack (ou Turbopack quand il sera stable) est utilisé.
Explication :
L'ISR avec stale-while-revalidate : quand une requête arrive après la période de revalidate, Next.js sert d'abord la version en cache (stale, rapide), puis déclenche la régénération en arrière-plan. La prochaine requête verra la nouvelle version. Configurable via
next: { revalidate: 60 } ou on-demand.
Pour des données critiques qui doivent être fraîches, utilisez
cache: "no-store". Pour des données moins critiques, un revalidate plus long réduit la charge serveur.
Explication :
Next.js supporte les fichiers
.env.local, .env.development, .env.production. Dans next.config.js, on peut conditionner la configuration : if (process.env.NODE_ENV === "production") { ... }. Vercel gère automatiquement les environnements de preview.
Utilisez
NEXT_PUBLIC_VERCEL_ENV sur Vercel pour détecter l'environnement (development/preview/production).
Explication :
La colocation consiste à placer les fichiers liés à une fonctionnalité dans le même dossier que la route (ex:
app/dashboard/_components/, app/dashboard/_actions/). Les dossiers préfixés par _ ne sont pas routables. Cela améliore la maintenabilité et la clarté.
Organisation type :
app/route/_components/ (UI), app/route/_actions/ (Server Actions), app/route/_lib/ (utilitaires), app/route/__tests__/ (tests).
Explication :
Next.js protège automatiquement contre CSRF en exigeant un token dans les requêtes POST des Server Actions. Il faut en plus vérifier l'authentification/autorisation dans chaque Server Action (
if (!session) throw new Error("Unauthorized")).
Créez un wrapper
authenticatedAction(action) qui vérifie les droits avant d'exécuter l'action métier.
Explication :
Avec les Client Components, chaque composant est hydraté indépendamment. Dans un
<Suspense>, l'hydratation est différée jusqu'à ce que le contenu soit prêt. Cela permet de prioriser l'hydratation des parties interactives critiques et de réduire le Time to Interactive (TTI).
Pour les composants lourds non critiques (commentaires, chatbots), enveloppez-les dans un Suspense pour ne pas bloquer l'hydratation du reste.
Explication :
Vercel propose un pipeline CI/CD intégré : chaque push Git déclenche un build et déploiement (avec preview deployment pour les PRs). Pour l'ISR on-demand, on expose un endpoint dans
app/api/revalidate/route.js qui appelle revalidateTag(), et le CMS/webhook l'appelle après chaque mise à jour de contenu.
Sécurisez l'endpoint de révalidation avec un token secret passé en query param ou header.
Explication :
Les Server Components et Server Actions peuvent se connecter directement aux BDD. Meilleures pratiques : utiliser un ORM (Prisma, Drizzle), créer un singleton pour la connexion (éviter les connexions multiples en dev avec HMR), utiliser les DataBase as a Service (Vercel Postgres, Neon, PlanetScale) pour le serverless.
En développement, Next.js peut créer plusieurs instances. Utilisez le pattern singleton :
globalThis.prisma ??= new PrismaClient().
Explication :
Le Middleware sur Edge Runtime est idéal : rapide, proche de l'utilisateur. Il peut lire un cookie de bucket, et réécrire
/page vers /page-variant-a ou /page-variant-b de manière transparente pour l'utilisateur.
Stockez le bucket dans un cookie (via
request.cookies.set()) pour assurer la persistance de la variante pendant la session.
Explication :
Les fonctions dynamiques (
cookies(), headers(), searchParams) marquent automatiquement la route comme dynamique (SSR). Next.js ne peut pas pré-rendre une page qui dépend de données de requête. Le "Dynamic IO" (en cours de développement) permettra un contrôle plus fin.
Si vous utilisez ces fonctions, la page ne sera pas statique, même avec
cache: "force-cache". Structurez votre application pour isoler ces dépendances.
Explication :
Les Parallel Routes utilisent des "slots" nommés avec
@ : app/@sidebar/page.js. Les Intercepting Routes utilisent (.) (même niveau), (..) (parent), (...) (racine) pour intercepter la navigation vers une route et l'afficher dans un modal par exemple.
Cas d'usage classique : galerie photo. Clic sur une photo → affichage dans un modal (intercepting), mais rafraîchissement → page dédiée.
Explication :
Next.js élimine automatiquement le code mort (tree-shaking) lors du build. Optimisations supplémentaires :
dynamic(() => import(...), { ssr: false }) pour les bibliothèques client-only, @next/bundle-analyzer pour visualiser les dépendances, et modulariser les imports (importer uniquement ce qui est utilisé).
Activez l'analyseur :
ANALYZE=true npm run build. Surveillez les grosses dépendances et remplacez-les par des alternatives plus légères.
Explication :
L'App Router n'a pas de solution i18n intégrée (contrairement au Pages Router). L'approche recommandée : Middleware pour détecter/rediriger selon la locale, structure de routes
app/[lang]/page.js, et bibliothèque comme next-intl qui supporte les Server Components. next-intl est la solution la plus populaire pour l'App Router. Elle supporte les Server Components, les messages async, et la négociation de locale.
Explication :
Next.js permet une architecture composable où différentes parties de l'application peuvent être développées, testées et déployées indépendamment. Via Turbopack/Webpack Module Federation, on peut même charger des micro-frontends distants.
Pour les grandes équipes, les monorepos (Turborepo) avec Next.js permettent de partager des composants entre applications tout en maintenant l'indépendance des déploiements.
Explication :
Les plugins Next.js suivent le pattern
(nextConfig) => nextConfig. Ils modifient la configuration Webpack, ajoutent des fonctionnalités. Exemples : next-pwa (PWA), @next/mdx (MDX), next-sitemap. S'utilisent avec withPlugins() ou en chaînant.
Pattern standard :
const withPWA = require("next-pwa"); module.exports = withPWA({ ...nextConfig }).
Explication :
Le Skew Protection évite les erreurs quand un utilisateur a chargé une ancienne version de la page (avec d'anciens liens vers des assets) mais que le serveur a été mis à jour entre-temps. Next.js gère cela en versionnant les assets et en maintenant les anciennes versions accessibles temporairement.
Sur Vercel, les anciens déploiements restent accessibles, garantissant que les utilisateurs sur d'anciennes sessions ne rencontrent pas d'erreurs 404 sur les assets.
Explication :
Next.js supporte OpenTelemetry (
@vercel/otel) pour le tracing distribué (traces, spans, métriques). Vercel Analytics offre les Web Vitals (LCP, CLS, INP). Pour les logs, utiliser des logs structurés (JSON) avec des niveaux (info, warn, error) et une plateforme de log management.
Activez OpenTelemetry :
experimental: { instrumentationHook: true } puis instrumentation.ts à la racine.
Explication :
Stratégie complète : Tests unitaires (Jest/Vitest pour les fonctions pures), Tests de composants (Testing Library + mocks pour les Server Components), Tests d'intégration (tester les Server Actions et API routes), Tests E2E (Playwright pour les parcours utilisateur complets).
Playwright est recommandé par Vercel. Utilisez
@playwright/test avec le mode headless pour la CI/CD.
Explication :
Next.js détecte la plateforme de déploiement (Vercel, Netlify, Node.js, Docker) via les variables d'environnement et optimise automatiquement la sortie. Le
output: "standalone" dans next.config.js crée un bundle autonome pour Docker. Next.js s'adapte au serverless, edge, ou serveur traditionnel.
Pour Docker :
output: "standalone" dans next.config.js. Le dossier .next/standalone contiendra tout le nécessaire pour exécuter l'application. 
Quiz
Senior
20 questions
15 min
Entretien React Senior : performance et testing
Quiz
Junior
20 questions
15 min
Entretien Next.js Junior : data fetching et middleware
Quiz
Débutant
20 questions
15 min
Entretien Next.js Débutant : pages, routing et SSR
Quiz
Senior
20 questions
15 min
jQuery Senior — Architecture patterns
Quiz
Senior
20 questions
15 min
Entretien Vue Senior : performance et patterns
Quiz
Senior
20 questions
15 min
Entretien JavaScript Senior — Event Loop et Prototypes
Quiz
Senior
20 questions
15 min
Entretien CSS Senior — Architecture et Performance
Quiz
Senior
20 questions
15 min
HTML Senior — Performance et APIs
Quiz
Senior
20 questions
15 min
Entretien Spring Boot Senior : microservices et cloud
Quiz
Senior
20 questions
15 min
Entretien Angular Senior — OnPush, SSR et Architecture
Quiz
Junior
20 questions
15 min
Entretien jQuery Junior : AJAX, plugins et perf
Quiz
Senior
20 questions
15 min
Entretien Node.js Senior — Performance, Streams et Scaling
Quiz
Senior
20 questions
20 min
Entretien Git Senior — Workflows, Hooks et Internals
Quiz
Junior
20 questions
15 min
Entretien React Junior : Hooks, Context et Router
Quiz
Senior
20 questions
15 min
Entretien TypeScript Senior — Decorators et Utility Types
Quiz
Senior
20 questions
20 min
Python Django/FastAPI Senior — Architecture & Perf
Quiz
Junior
20 questions
15 min
Entretien Vue Junior : Composition API et Pinia
Quiz
Débutant
20 questions
15 min
Entretien JavaScript Débutant : variables et syntaxe
Quiz
Senior
20 questions
15 min
Entretien Scrum Senior : transformations agiles
Quiz
Débutant
20 questions
15 min