# View Transitions sur WordPress : des navigations fluides sans SPA

> L'API View Transitions permet d'animer le passage d'une page à l'autre en HTML classique, sans transformer un site WordPress en application monopage. Voici comment l'activer et ce que cela change réellement pour les métriques.

- Auteur : Clément Hadrot
- Publié le : 2025-02-27
- Mis à jour le : 2025-02-27
- Catégorie : Performance
- URL : https://wpmoderne.dev.wordpress-developpement.fr/performance/view-transitions-wordpress-navigations-fluides/

## L’essentiel

- L'API fonctionne aussi bien en navigation classique multi-pages qu'en SPA
- Une extension dédiée l'active sans toucher au thème pour un rendu de base
- L'effet sur les métriques Core Web Vitals est neutre à positif si l'implémentation reste légère

Étape 1 : comprendre ce que l'API résout. Le reproche classique fait aux sites WordPress classiques, par rapport aux applications monopages construites en React ou Vue, est la rupture visuelle entre deux pages : un flash blanc, un rechargement complet, aucune continuité visuelle. L'API View Transitions du navigateur permet d'obtenir une transition animée entre deux pages HTML distinctes, sans construire une architecture d'application monopage ni charger de framework JavaScript lourd.

Étape 2 : vérifier le support navigateur nécessaire. La version « multi-pages » de l'API (`@view-transition` en CSS, déclenchée automatiquement par la navigation du navigateur) est supportée par Chrome et les navigateurs basés sur Chromium depuis leurs versions récentes de 2024-2025 ; Firefox et Safari suivent avec un support plus partiel au moment de la rédaction. Le comportement de repli en l'absence de support est simplement l'absence de transition, sans erreur ni dégradation de la navigation classique.

## Étape 3 : activer la transition la plus simple, en CSS pur

La forme la plus légère consiste à déclarer la participation à une transition de vue directement en CSS, sans aucun JavaScript :

```
@view-transition {
  navigation: auto;
}

::view-transition-old(root),
::view-transition-new(root) {
  animation-duration: 0.25s;
}
```

Cette déclaration suffit à obtenir un fondu enchaîné basique entre deux pages du même domaine, pour peu que le navigateur du visiteur supporte la fonctionnalité. Aucune extension n'est nécessaire pour ce niveau minimal : quelques lignes ajoutées à la feuille de style du thème, via l'éditeur de style additionnel des personnalisations ou un fichier CSS enfant.

## Étape 4 : nommer des éléments pour des transitions ciblées

> L'essentiel à retenir : L'API fonctionne aussi bien en navigation classique multi-pages qu'en SPA ; Une extension dédiée l'active sans toucher au thème pour un rendu de base ; L'effet sur les métriques Core Web Vitals est neutre à positif si l'implémentation reste légère

Pour un effet plus soigné, par exemple faire glisser l'image mise en avant d'une carte d'article vers la position de l'image mise en avant sur la page article elle-même, il faut nommer explicitement les éléments concernés avec la propriété CSS `view-transition-name`, appliquée de façon cohérente sur les deux pages :

```
.carte-article .image-a-la-une {
  view-transition-name: image-article-en-cours;
}

/* Sur le template article individuel */
.entete-article .image-a-la-une {
  view-transition-name: image-article-en-cours;
}
```

Le nom doit être unique par élément visible à l'écran au moment de la transition ; utiliser le même nom sur plusieurs éléments simultanément affichés provoque une erreur silencieuse et l'annulation de l'effet pour cet élément.

## Étape 5 : passer par une extension pour aller plus vite

Pour une mise en place rapide sans écrire de CSS soi-même, plusieurs extensions WordPress dédiées enveloppent l'API View Transitions avec des préréglages (fondu, glissement, zoom) configurables depuis l'administration, avec une détection automatique du support navigateur et un repli propre en son absence. Cette approche convient pour un rendu de base rapide ; un travail CSS sur mesure reste préférable dès que des éléments spécifiques du thème doivent être animés individuellement.

## Étape 6 : mesurer l'impact sur les métriques

Sur un site de test comparé avant et après activation, la transition en elle-même n'a montré aucun effet mesurable sur le LCP ni sur l'INP, l'animation se déclenchant après le rendu principal de la page suivante et reposant sur des propriétés CSS compositées par le moteur de rendu plutôt que sur du JavaScript coûteux en fil principal. Le seul point de vigilance mesuré concerne le CLS : une transition mal calée peut créer un déplacement visuel temporaire si les dimensions des éléments transitionnés diffèrent sensiblement entre les deux pages.

## Ce que cette API ne fait pas

Contrairement au Speculative Loading introduit plus tard en WordPress 6.8, la View Transitions API n'accélère en rien le chargement des données de la page suivante : elle habille visuellement une navigation qui se produit de toute façon, sans préchargement anticipé du contenu.

## En résumé

L'API View Transitions apporte une touche d'expérience utilisateur proche des applications modernes, sans les compromis de performance et de complexité d'une architecture monopage. Sa mise en place minimale tient en quelques lignes de CSS, son effet sur les métriques Core Web Vitals reste neutre si l'implémentation évite les décalages de mise en page, et son absence de support sur un navigateur donné se dégrade proprement vers une navigation classique.