Pendant des années, les transitions animées entre pages relevaient du tour de force. Soit on adoptait un framework SPA (Next.js, Nuxt, Astro avec view transitions natives), soit on bricolait avec des bibliothèques JavaScript qui interceptaient la navigation et redessinaient le DOM à la main. Sur WordPress, la plupart des intégrateurs renonçaient simplement : trop de plugins, trop de risques de casse, peu de retour sur investissement.
La View Transitions API change la donne. Standardisée par le W3C, elle permet au navigateur lui-même de gérer les transitions visuelles entre deux états d'une page — ou désormais entre deux pages distinctes. En avril 2026, son support couvre les trois moteurs majeurs : Blink (Chrome 111+, Edge 111+), WebKit (Safari 18+) et Gecko (Firefox 133+) pour le mode mono-document, avec le mode multi-document qui s'étend rapidement après son arrivée dans Chrome 126.
Pour un site WordPress, cela ouvre une voie pragmatique : ajouter des transitions élégantes sans réécrire le thème en JavaScript, sans plugin lourd, et sans dégrader les performances Core Web Vitals.
Comprendre les deux modes : mono-document et multi-document
L'API distingue deux scénarios. Le mode mono-document (parfois appelé SPA) intervient à l'intérieur d'une même page : on modifie le DOM, et document.startViewTransition() capture l'avant et l'après pour les interpoler. C'est la version originelle, celle que les applications monopage modernes utilisent.
Le mode multi-document (MPA) couvre la navigation classique : on clique sur un lien, le navigateur charge une nouvelle page, et la transition s'opère entre les deux documents. Aucun JavaScript n'est requis ; tout passe par une règle CSS @view-transition. C'est précisément ce mode qui rend l'API intéressante pour WordPress, où la navigation reste fondamentalement multi-page.
La règle de base est sobre :
@view-transition {
navigation: auto;
}Placée dans la feuille de styles principale, elle suffit à activer une transition en fondu enchaîné par défaut entre toutes les pages de même origine. Le visiteur clique sur un article, le navigateur effectue son chargement, puis fait apparaître la nouvelle page avec un enchaînement doux plutôt qu'un saut sec.
Activer la View Transitions API sur un thème WordPress
Concrètement, l'intégration se fait au niveau du thème enfant. Dans le style.css ou une feuille dédiée enregistrée via wp_enqueue_style, on ajoute la règle ci-dessus. Le pré-requis est que les pages partagent la même origine (ce qui est le cas par défaut sur WordPress) et que le navigateur du visiteur prenne en charge l'API. Pour les autres, la dégradation est gracieuse : pas de transition, mais aucune erreur, aucun avertissement.
Pour aller au-delà du simple fondu, on personnalise les pseudo-éléments générés par l'API. Lors d'une transition, le navigateur crée une arborescence accessible depuis CSS : ::view-transition, ::view-transition-group(*), ::view-transition-image-pair(*), ::view-transition-old(*) et ::view-transition-new(*). Chacun peut être animé indépendamment.
Un exemple courant sur un blog WordPress consiste à faire glisser le contenu principal vers la gauche tout en faisant entrer le nouvel article par la droite.
@view-transition {
navigation: auto;
}
::view-transition-old(root) {
animation: 250ms ease-in both slide-out-left;
}
::view-transition-new(root) {
animation: 300ms ease-out both slide-in-right;
}
@keyframes slide-out-left {
to { transform: translateX(-30px); opacity: 0; }
}
@keyframes slide-in-right {
from { transform: translateX(30px); opacity: 0; }
}L'effet est subtil mais perçu comme fluide par les utilisateurs, sans surcharger le navigateur.
Animer un élément précis entre deux pages
L'aspect le plus séduisant de l'API se révèle quand on nomme un élément avec view-transition-name. Prenons le cas typique d'une grille d'articles : la vignette de l'article cliqué doit grossir et devenir l'image principale de la page suivante. Sur WordPress, c'est le scénario d'un blog avec des cartes d'articles qui s'ouvrent sur le permalien complet.
Côté liste (par exemple archive.php ou home.php), on assigne un nom unique à chaque image mise en avant :
<?php while ( have_posts() ) : the_post(); ?>
<article class="post-card">
<a href="<?php the_permalink(); ?>">
<?php the_post_thumbnail( 'medium', [
'style' => 'view-transition-name: post-' . get_the_ID() . ';'
] ); ?>
<h2><?php the_title(); ?></h2>
</a>
</article>
<?php endwhile; ?>Côté article (single.php), l'image mise en avant porte le même nom :
<?php
the_post_thumbnail( 'large', [
'style' => 'view-transition-name: post-' . get_the_ID() . ';'
] );
?>Le navigateur reconnaît qu'il s'agit du même élément logique et orchestre une animation morph fluide entre les deux positions et tailles. Pas de bibliothèque, pas de calcul manuel : la couche de présentation native s'en charge.
Le piège de la mise en cache et des plugins WordPress
Voilà où l'expérience WordPress complique légèrement les choses. Plusieurs plugins de cache ou d'optimisation (WP Rocket, Autoptimize, LiteSpeed Cache) injectent leurs propres scripts de pré-chargement ou de navigation instantanée. Certains, comme la fonctionnalité Instant Page de WP Rocket, interceptent les clics et chargent la page suivante en arrière-plan. Sans précaution, leur logique entre en conflit avec le déclenchement natif des view transitions.
La règle pratique : tester systématiquement avec et sans cache, et désactiver le pré-chargement JavaScript si on observe des saccades. À l'inverse, le pré-chargement HTTP (rel=prefetch, Speculation Rules) reste compatible et améliore même la perception de vitesse pendant la transition.
Polylang, qui équipe itamde.com, ne pose en revanche aucun souci. Les transitions multi-documents fonctionnant uniquement en même origine, le passage entre les versions linguistiques bénéficie automatiquement de l'animation, sans configuration supplémentaire.
Accessibilité : respecter prefers-reduced-motion
Un point trop souvent oublié dans les démos en ligne. Les transitions animées peuvent provoquer des malaises chez les personnes sensibles au mouvement, et la WCAG 2.1 AA impose de respecter la préférence système prefers-reduced-motion. Avec la View Transitions API, c'est immédiat :
@media (prefers-reduced-motion: reduce) {
::view-transition-old(*),
::view-transition-new(*) {
animation: none !important;
}
}On désactive les animations pour les utilisateurs qui en font la demande, sans casser la navigation. Le contenu apparaît instantanément, comme dans un site classique.
Quel impact sur les Core Web Vitals ?
Question légitime, surtout après les ajustements Google de début 2026 qui ont renforcé le poids de l'INP (Interaction to Next Paint). La View Transitions API passe par la couche de composition du navigateur, hors du thread principal. Concrètement, une transition bien construite n'augmente ni le LCP ni l'INP de manière mesurable.
Deux pièges existent toutefois. Premièrement, multiplier les view-transition-name sur des dizaines d'éléments par page crée une surcharge GPU sur les appareils modestes — il faut cibler les éléments vraiment significatifs (images mises en avant, titres principaux), pas la totalité de la page. Deuxièmement, des animations trop longues (au-delà de 400 ms) retardent la perception d'arrivée sur la nouvelle page et frustrent l'utilisateur. La fourchette confortable se situe entre 200 et 350 ms.
Ce que cela change dans nos projets
Pour un studio comme le nôtre, la View Transitions API supprime un choix technique souvent douloureux : faut-il sortir de WordPress et passer à une stack headless pour offrir des transitions modernes ? La réponse, en 2026, est non. Un thème WordPress classique, bien tenu, peut désormais proposer une expérience visuelle proche d'une application native, sans dépendance JavaScript supplémentaire.
L'effort d'intégration tient en quelques dizaines de lignes de CSS. Le retour côté utilisateur est immédiat, surtout sur mobile où le saut entre deux pages reste la principale rupture perceptive. Et puisque la dégradation est silencieuse, aucun risque pour les visiteurs sur navigateurs anciens.
Reste une seule contrainte : le multi-document n'est pas encore généralisé partout. Pour un site qui vise un trafic majoritairement européen sur Chrome, Edge et Safari récents, la couverture est largement suffisante dès aujourd'hui. Pour un projet plus large, on combine view transitions natives sur les navigateurs compatibles et fallback simple ailleurs — ce que l'API fait déjà toute seule.
0 commentaire