View Transitions API sur une landing page Next.js : fondu utile ou gadget ?

Cliquer sur une carte de template et atterrir sur sa fiche détaillée, cliquer sur « voir la démo » et basculer sur la page live, valider un formulaire et arriver sur la page de remerciement : sur une landing page classique, chacune de ces navigations se traduit par un cut brutal. L'ancienne page disparaît, un blanc bref s'affiche, la nouvelle page apparaît d'un bloc. Rien ne relie visuellement les deux écrans, même quand ils partagent un élément identique — la même image de produit, le même titre, le même bouton. Le View Transitions API du navigateur, que Next.js peut désormais piloter nativement, s'attaque précisément à cette coupure : il permet de dire au navigateur « cet élément-là reste le même, anime son déplacement plutôt que de le faire disparaître puis réapparaître ».

Ce que le View Transitions API change concrètement

Le View Transitions API est une fonctionnalité native des navigateurs (Chrome, Edge, et Safari depuis la version 18) qui capture un instantané visuel de l'état « avant » d'une page, laisse le DOM se mettre à jour vers l'état « après », puis anime automatiquement le passage de l'un à l'autre — un fondu par défaut, ou une animation personnalisée via CSS. Il ne s'agit pas d'une bibliothèque JavaScript à charger et maintenir : c'est le navigateur lui-même qui gère la capture et l'animation, sans code de transition à écrire à la main. Depuis Next.js 15, un composant expérimental <ViewTransition> de React (activé via experimental: { viewTransition: true } dans next.config) permet d'envelopper les éléments concernés et de nommer ceux qui doivent persister d'une route à l'autre — la navigation entre routes de l'App Router déclenche alors la transition automatiquement, sans repasser par un composant client dédié aux animations.

Pourquoi la continuité visuelle joue sur la perception, pas seulement sur l'esthétique

L'intérêt ne se limite pas à un effet joli. Une étude publiée en 2025 dans le Journal of Consumer Research par Yu Ding (Baruch College) et Ellie Kyung (Babson College), consacrée à la vitesse d'animation et au temps d'attente perçu (disponible sur Google Scholar), montre une relation en forme de U inversé entre la vitesse d'une animation et le temps d'attente perçu par l'utilisateur : une animation à vitesse modérée réduit davantage l'attente perçue qu'une absence totale d'animation, mais aussi qu'une animation trop rapide ou trop lente, parce qu'elle capte l'attention sans pour autant la saturer. Une étude antérieure, présentée en 2010 à la conférence CHI par Jarmo Huhtala, Ari-Heikki Sarjanoja, Jani Mäntyjärvi et leurs coauteurs (disponible sur Google Scholar), va dans le même sens sur un autre point précis : montrer un fragment de l'écran suivant plus tôt dans la transition est ce qui fait le plus baisser la perception du temps d'attente, davantage que la durée totale de l'animation elle-même. Autrement dit, ce n'est pas l'animation en tant que telle qui rassure l'utilisateur pendant un chargement, c'est la promesse visuelle que quelque chose de connu va continuer d'exister de l'autre côté.

Où ce fondu a un vrai rôle sur une landing page

• D'une grille de templates vers une fiche détaillée : la vignette cliquée s'agrandit en douceur vers l'image hero de la page suivante, plutôt que de disparaître pour réapparaître ailleurs — utile sur une page qui présente plusieurs offres côte à côte, où le paradoxe du choix rend déjà la comparaison mentalement coûteuse.
• Du hero vers la démo live d'un template : sur le template liste d'attente SaaS (démo), un visiteur qui clique sur « voir la démo » garde le même repère visuel (le nom du produit, le bouton) le temps que la page suivante se charge, ce qui réduit l'impression d'avoir quitté le site.
• Du formulaire vers la page de remerciement : faire persister le bouton d'envoi qui se transforme en confirmation visuelle évite le petit flottement où l'utilisateur se demande si sa soumission a bien été prise en compte.
• Entre deux étapes d'un formulaire en plusieurs étapes : la barre de progression et les champs déjà remplis glissent plutôt que de sauter d'un écran à l'autre, en cohérence avec ce que recommande déjà notre article sur la barre de progression.

Le mettre en place sans casser ce qui marche déjà

1. Activer le flag experimental.viewTransition dans next.config, en testant d'abord sur une route secondaire plutôt que sur la page qui porte la conversion principale.
2. Nommer un identifiant de transition (viewTransitionName) uniquement sur les un ou deux éléments qui doivent réellement persister d'une page à l'autre — une image, un titre, un bouton — pas sur la mise en page entière.
3. Garder une durée d'animation courte (150 à 250 ms environ) : au-delà, l'effet ralentit la navigation perçue plus qu'il ne la fluidifie, à rebours de l'intérêt même de la fonctionnalité.
4. Respecter prefers-reduced-motion en désactivant la transition animée pour les visiteurs qui l'ont demandé au niveau système — le navigateur bascule alors sur un changement instantané, sans code supplémentaire à écrire.
5. Vérifier que la navigation reste identique sur un navigateur qui ne supporte pas encore l'API (Firefox, notamment) : sans le View Transitions API, le changement de page se fait simplement sans transition animée, aucune fonctionnalité n'est perdue.

Les limites à connaître avant d'investir dessus

• Statut expérimental. Le composant <ViewTransition> de React n'est disponible que sur les versions Canary et reste marqué expérimental dans la documentation de Next.js 15 — à réévaluer avant un déploiement large sur une page de conversion critique.
• Support navigateur partiel. Les transitions entre routes fonctionnent aujourd'hui sur Chrome, Edge et Safari 18+, mais pas encore sur Firefox : l'effet dégrade proprement (navigation normale, sans transition), ce qui rend son adoption sans risque fonctionnel, mais son bénéfice reste invisible pour une partie du trafic.
• Ce n'est pas un levier de performance. Le View Transitions API améliore la perception d'une navigation déjà rapide ; il ne compense en rien un temps de réponse serveur lent ou un LCP dégradé. Sur ces points, la Speculation Rules API et le Partial Prerendering ont un effet direct sur la vitesse réelle ; le View Transitions API n'agit que sur la vitesse ressentie une fois la page déjà là.
• Un mauvais fallback casse la mise en page. Comme pour toute animation liée au chargement, un contenu qui n'a pas encore sa taille finale au moment de la transition réintroduit un décalage visuel — voir notre article sur le Core Web Vitals CLS.

Faut-il l'ajouter à une landing page LanderKit ?

Ce n'est pas une priorité au sens où l'entendent nos articles sur la vitesse de chargement ou le TTFB : une landing page lente avec des transitions élégantes reste une landing page lente. Mais une fois les fondamentaux de performance réglés, le View Transitions API est l'un des rares effets visuels dont le coût d'implémentation est proche de zéro (pas de bibliothèque, quelques lignes CSS et un flag) pour un bénéfice réel sur les parcours à plusieurs pages — typiquement le passage d'une grille de templates à une fiche produit, ou d'un formulaire à sa confirmation. Chaque template LanderKit étant livré comme un mini-projet Next.js autonome, rien n'empêche de l'activer au cas par cas sur les deux ou trois transitions qui comptent réellement, sans toucher au reste du site ni prendre le risque de dégrader l'expérience sur les navigateurs qui ne le supportent pas encore.