Test visuel Next.js : le guide complet pour sécuriser vos applications React SSR

Points clés

Next.js multiplie les modes de rendu (SSR, SSG, ISR, App Router) et chacun peut produire un résultat visuel différent pour la même page
L'hydratation React est une source majeure de régressions visuelles invisibles aux tests fonctionnels traditionnels
Les approches basées sur Storybook ne testent pas le rendu réel de vos pages Next.js dans des conditions de production
Un outil de test visuel agnostique au framework qui capture le résultat final dans le navigateur est la seule garantie fiable

Le test visuel, selon la définition de l'ISTQB, désigne « la vérification que l'interface utilisateur d'un logiciel s'affiche conformément aux spécifications visuelles attendues, en comparant des captures d'écran de référence à l'état actuel de l'application ».

Quand vous appliquez cette discipline à une application Next.js, les choses se compliquent considérablement. Next.js n'est pas une simple application React. C'est un framework qui propose au moins quatre modes de rendu différents — parfois sur la même page. Et chaque mode peut produire un résultat visuel subtilement différent, pour des raisons que vos tests unitaires et d'intégration ne détecteront jamais.

Selon le State of JS 2024, Next.js est utilisé par 58 % des développeurs React en production. C'est le standard de facto pour les applications React professionnelles. Et pourtant, la plupart des équipes utilisant Next.js n'ont pas de stratégie de test visuel adaptée à ses spécificités.

Pourquoi Next.js rend le test visuel plus important, pas moins

Argument courant : « Next.js gère le rendu pour nous, pas besoin de vérifier visuellement chaque page. » C'est exactement l'inverse de la réalité.

Next.js rend le test visuel plus critique précisément parce qu'il multiplie les chemins de rendu. Avec une SPA React simple, le rendu était prévisible : tout côté client. Avec Next.js, la même page peut être rendue côté serveur à la première requête, puis hydratée côté client, puis partiellement re-rendue lors de la navigation client. Chaque étape peut introduire un écart visuel.

Le problème de l'hydratation

L'hydratation est le processus par lequel React prend le HTML généré côté serveur et le « réactive » côté client en attachant les listeners. En théorie, le résultat visuel devrait être identique avant et après. En pratique, il l'est rarement à 100 %.

Les causes : styles calculés côté serveur ne tenant pas compte de la fenêtre réelle, composants qui dépendent de window affichant un fallback en SSR, fonts web non disponibles au moment du rendu serveur causant un FOUT, animations CSS démarrant à l'hydratation.

Résultat : un écart visuel entre ce que le serveur envoie et ce que l'utilisateur voit après hydratation. Souvent subtil — quelques pixels d'offset, du texte qui se redistribue, une image qui saute. Mais réel.

Aucun test unitaire ne le détecte. Seul un test visuel, qui capture une image de la page rendue dans un vrai navigateur après hydratation complète, peut confirmer que le résultat final correspond à ce que vous attendez.

Les quatre modes de rendu et leurs pièges

Le rendu statique (SSG) génère du HTML au build. Le plus prévisible, mais si vos données changent entre builds, vos pages affichent des données obsolètes.

Le rendu côté serveur (SSR) génère du HTML à chaque requête. Contenu dynamique. La même URL peut produire un rendu différent selon l'heure, l'utilisateur, les données. Le test visuel doit gérer cette variabilité, ce qui requiert une stratégie de mocking ou de stabilisation.

L'Incremental Static Regeneration (ISR) est hybride : page statique mais régénérée périodiquement. Le piège est la transition entre l'ancienne et la nouvelle version. Si votre layout a changé, cette transition peut être visuellement incohérente.

L'App Router (Next.js 13+) ajoute Server Components, streaming, et layouts imbriqués. Une page mélange Server Components et Client Components. Le résultat est un rendu progressif où le contenu apparaît par chunks — et chaque chunk peut introduire un décalage visuel.

Approches pour tester visuellement une app Next.js

Playwright : la force brute

Playwright a un avantage majeur : il teste la vraie page, dans un vrai navigateur, avec rendu complet (SSR + hydratation + CSS + fonts). Vous capturez ce que l'utilisateur voit réellement.

Mais Playwright a des limites pour le test visuel. C'est un outil de développeur. Il faut écrire et maintenir des scripts. Sur une app de 100 pages × 3 viewports × plusieurs états, la dette de maintenance explose. La comparaison de captures est basique (pixel-by-pixel avec seuil de tolérance). L'infrastructure de baseline est à votre charge.

Chromatic via Storybook : l'illusion des composants isolés

Chromatic capture les screenshots de vos composants Storybook. Si vous avez déjà Storybook, ça se branche directement.

Mais pour Next.js, problème fondamental : il ne teste pas vos pages. Il teste vos composants isolés. Or les régressions les plus dangereuses ne viennent pas des composants individuels — elles viennent de leur interaction, du layout global, du rendu SSR, de l'hydratation, des layouts imbriqués de l'App Router.

Un bouton qui s'affiche parfaitement en Storybook peut casser votre layout dans un flex container. Un composant de navigation qui passe tous les tests Chromatic peut causer un cumulative layout shift de 0,3 chargé via SSR avec une font web. Chromatic ne verra jamais ces problèmes.

Delta-QA : test visuel de la vraie page, sans code

Delta-QA capture des screenshots de vos vraies pages — celles que voient vos utilisateurs — et compare entre deux versions. Pas besoin que Delta-QA sache que vous utilisez Next.js, App Router ou Pages Router. Il capture le résultat final dans le navigateur, après SSR, après hydratation, après chargement des fonts, après exécution du JS client. Ce qu'il compare, c'est exactement ce que voit votre utilisateur.

Cette approche résout les trois problèmes : les écarts d'hydratation sont capturés, les interactions composants/layout sont visibles, et la maintenance est minimale.

Spécificités Next.js et comment les gérer

Contenu dynamique

Si votre page Next.js affiche un compteur en temps réel ou un timestamp, chaque capture diffère sans régression. Solution : zones d'exclusion. Vous indiquez les régions à contenu variable, l'outil les ignore.

Fonts et FOUT

Le Flash of Unstyled Text est un classique Next.js. Solution : attendre que les fonts soient chargées avant de capturer. L'API document.fonts.ready garantit ça. Delta-QA intègre cette attente nativement.

Animations et transitions

Les composants animés introduisent du non-déterminisme. Bonne pratique : désactiver les animations CSS et JS dans l'environnement de test visuel. Delta-QA propose cette option nativement.

Layouts imbriqués de l'App Router

Un changement dans un layout parent affecte toutes les pages enfants. Une modification de padding dans le root layout peut décaler le contenu de dizaines de pages. Sans test visuel systématique, vous ne découvrez ce type de régression qu'en production. Le test visuel couvre cette surface automatiquement.

Intégrer le test visuel dans votre pipeline CI/CD

Vous push votre code → CI build et déploie sur preview (Vercel, Netlify) → Delta-QA capture et compare avec les baselines de production → résultats dans la merge request → équipe valide ou rejette.

C'est particulièrement naturel avec Vercel, qui crée automatiquement un preview pour chaque branche. Delta-QA se branche sur cette URL pour capturer, ce qui veut dire que vous testez votre app dans des conditions quasi-production.

Métriques à suivre

Taux de détection des régressions visuelles avant prod — l'objectif est d'approcher 100 %.

Ratio de faux positifs — si plus de 20 % de vos différences détectées sont des faux positifs, votre config a besoin d'être affinée.

Temps moyen de review — si l'équipe passe plus de 15 min par MR à examiner les diffs visuelles, vous capturez trop de bruit.

Nombre de pages couvertes / total — l'objectif : 100 % des pages critiques.

FAQ

Le test visuel remplace-t-il les tests unitaires pour Next.js ?

Non, il les complète. Tests unitaires = logique des composants. Tests d'intégration = composants ensemble. Test visuel = résultat final correspond à ce qu'on attend. Les trois sont nécessaires.

Comment gérer les Server Components Next.js dans le test visuel ?

Aucune difficulté spécifique. Le test visuel capture le résultat final dans le navigateur, agnostique au mode de rendu. C'est la différence clé avec une approche comme Chromatic, qui exige de rendre chaque composant dans un environnement spécifique.

Combien de viewports tester pour une app Next.js ?

Au minimum trois : mobile (375px), tablette (768px), desktop (1440px). Ajoutez un breakpoint intermédiaire si votre design change significativement entre tablette et desktop.

Le test visuel ralentit-il mon pipeline CI/CD Next.js ?

Avec Delta-QA, capture et comparaison tournent en parallèle du reste du pipeline. Pour 50 pages × 3 viewports, comptez 2 à 5 minutes — négligeable comparé au build Next.js (5-10 min).

Puis-je utiliser le test visuel avec le draft mode Next.js ?

Oui et c'est recommandé. Le draft mode permet de prévisualiser du contenu non publié d'un CMS headless. Le test visuel peut capturer les pages en draft pour vérifier qu'un contenu non publié ne casse pas le layout avant publication.

Delta-QA fonctionne-t-il avec le Middleware Next.js ?

Oui. Le Middleware s'exécute au niveau Edge avant le rendu. Delta-QA capture le résultat final après exécution. Pour l'A/B testing, vous pouvez configurer Delta-QA pour capturer les variantes en passant les bons cookies/headers.

Conclusion

Next.js est un framework puissant. Mais cette puissance a un coût en complexité de rendu que la plupart des équipes sous-estiment. SSR, ISR, App Router, Server Components, streaming, layouts imbriqués — chaque feature ajoute un chemin qui peut produire un résultat visuel inattendu.

Le test visuel n'est pas un luxe pour les apps Next.js. C'est une nécessité. Et l'outil que vous choisissez doit être capable de capturer le résultat réel de votre application — pas des composants isolés dans un environnement artificiel.

Si vous développez avec Next.js et n'avez pas encore de stratégie de test visuel, vous volez à l'aveugle. Il est temps d'y remédier.

Essayer Delta-QA gratuitement →