Ajouter View Transitions à Astro

Easton editorial illustration: build pipeline conveyor

Vous avez passé du temps à construire un blog avec Astro, le design et la mise en page sont soignés — mais au clic sur un lien, la page blanchit soudainement avant d’afficher le contenu suivant. On passe d’une animation fluide type iPhone à un saut sec façon Windows 98.

L’an dernier, en aidant un ami sur son site, il m’a demandé après avoir vu un portfolio : « Pourquoi, chez eux, l’image du projet s’agrandit en douceur au clic, alors que chez nous c’est un rechargement brutal ? » J’étais un peu gêné — fallait-il tout réécrire en SPA React ? On perdrait alors l’avantage du statique Astro.

Jusqu’à ce que je découvre la combinaison View Transitions API + Astro. La première fois, j’ai été bluffé : 2 lignes dans le <head> du Layout, et les changements de page deviennent des transitions fluides. Pas de React, pas de Vue, pas même de bibliothèque JavaScript.

Dans cet article, je vous guide pas à pas :

Ce qu’est l’API View Transitions et pourquoi elle explose en 2025 (support navigateur > 85 %)
3 façons de l’activer dans Astro (des 2 lignes les plus simples aux personnalisations avancées)
Comment obtenir fondu, glissement, morphing d’éléments et autres effets
Un cas pratique complet : transition fluide de la liste d’articles vers la page détail
Pièges courants et solutions (croisez les doigts, je les ai tous rencontrés)

Prêt à donner à votre site Astro une expérience digne d’une app ? C’est parti.

Qu’est-ce que l’API View Transitions ? Pourquoi c’est si intéressant ?

La « magie » native du navigateur — sans aucune bibliothèque

L’API View Transitions est une fonctionnalité native du navigateur. En résumé : vous indiquez au navigateur « je vais changer de contenu », il prend deux « photos » (l’ancienne page et la nouvelle), puis génère automatiquement une animation fluide entre les deux.

Concret ? Sur l’accueil de votre blog, un titre « Tutoriel Astro » mène à l’article. En navigation classique : accueil disparaît → écran blanc → page détail. Avec View Transitions, le navigateur reconnaît que le titre est « le même élément » sur les deux pages et le déplace en douceur de la liste vers le haut de l’article, pendant que le reste apparaît en fondu.

Le plus intéressant : ces animations sont générées automatiquement — pas besoin de CSS complexe ni de GSAP, Framer Motion ou autre.

Pourquoi obtenir un effet SPA sans React/Vue ?

Pour les transitions de page, beaucoup pensent d’abord à React Router ou Vue Router + composants transition. Ces approches ont un défaut commun : elles alourdissent.

Les SPA traditionnelles exigent :

Une application monopage, routes gérées entièrement en JavaScript
Un bundle plus lourd, premier affichage plus lent
Un traitement SEO à part (même si c’est mieux qu’avant)

Astro + View Transitions, c’est plus élégant :

Architecture multi-pages (MPA) : chaque page est un HTML indépendant, SEO naturellement favorable
Chargement à la demande : seulement le JS et CSS de la page courante
API native : surcoût minimal, pas d’augmentation du bundle
Amélioration progressive : les navigateurs non compatibles retombent sur une navigation classique

J’ai testé : même blog, version React SPA ~300 Ko+, version Astro ~50 Ko — et View Transitions n’ajoute presque rien au poids.

85 %+

Support navigateur

Taux de support de l’API View Transitions en 2025

50 Ko vs 300 Ko

Taille du bundle

Version Astro ~6× plus légère qu’une SPA React

2 lignes

Code de configuration

Ajouter <ViewTransitions /> dans le head du Layout

Support navigateur en 2025 : on peut s’y fier

Bonne nouvelle : en 2025, le support de l’API View Transitions dépasse 85 %.

En détail :

Chrome 111+ : transitions intra-document (changement d’état dans la même page)
Chrome 126+ : transitions inter-documents (navigation entre pages) — ce qu’on utilise dans Astro
Safari : pris en charge
Edge : basé sur Chromium, entièrement compatible
Firefox 144+ (octobre 2025) : View Transitions est un pilier d’Interop 2025, Firefox a rattrapé son retard

Même l’équipe React a intégré View Transitions dans le cœur de la lib en 2025 (react@canary). L’API devient un standard du front-end.

Et les ~15 % restants ? Astro gère la dégradation : navigation classique, fonctionnalité intacte, sans animation. C’est la force de l’amélioration progressive.

3 méthodes pour activer View Transitions dans Astro

Théorie terminée, passons à la pratique — de la plus simple à la plus avancée.

Méthode 1 : activation globale (recommandée, 2 lignes)

Pour des transitions sur tout le site, c’est la voie la plus simple. Ouvrez votre Layout (src/layouts/BaseLayout.astro ou src/layouts/Layout.astro) et ajoutez ces deux lignes dans <head> :

---
import { ViewTransitions } from 'astro:transitions';
---
<html>
  <head>
    <title>My Astro Site</title>
    <ViewTransitions />
  </head>
  <body>
    <slot />
  </body>
</html>

C’est tout ! Lancez le serveur de dev (npm run dev), cliquez sur un lien : la transition devient un fondu fluide.

La première fois, j’ai cru à un cache navigateur — après plusieurs rechargements, confirmé : c’est vraiment aussi simple.

Cas d’usage : blogs, sites de documentation, portfolios — tout site où l’effet doit être global.

Méthode 2 : activation à la demande (pages spécifiques)

Parfois, seules certaines pages ont besoin d’animations — accueil et à propos oui, back-office non. Ajoutez dans le <head> de la page concernée :

---
import { ClientRouter } from 'astro:transitions';
---
<html>
  <head>
    <title>About Page</title>
    <ClientRouter />
  </head>
  <body>
    <!-- Contenu de la page -->
  </body>
</html>

ClientRouter est le nouveau nom (avant ViewTransitions). Astro l’a renommé pour mieux refléter son rôle : il intercepte la navigation et transforme la MPA en « pseudo-SPA ». L’ancien nom fonctionne encore.

Cas d’usage : applications mixtes, pages avec traitements particuliers.

Méthode 3 : validation rapide (sans modifier le code)

Pour tester sans toucher au projet, utilisez la démo officielle Astro :

👉 View Transitions Demo

Liste vers détail, galerie d’images, lecteur musical… Jouez avec la démo, repérez l’effet qui vous plaît, puis implémentez-le chez vous.

Conseil : ouvrez avec un navigateur compatible (Chrome 126+, Safari ou Firefox récent).

3 signes que c’est activé

Après avoir ajouté le code, comment vérifier ?

Plus de flash blanc : transition fluide, pas de saut « blanc → nouvelle page »
Éléments communs non rechargés : la barre de navigation reste en place (voir transition:persist plus bas)
Pas d’erreur en console : sinon, version Astro trop ancienne ou mauvaise config

La première fois que la nav n’a pas clignoté, j’ai cru à une illusion — en comparant avec View Transitions désactivé, j’ai confirmé que ça marchait.

Personnaliser les transitions — aligner l’effet sur votre marque

Le fondu par défaut est sobre ; parfois on veut plus de personnalité. Voici 4 techniques, du débutant à l’avancé.

Technique 1 : transition:animate pour le type d’animation

Astro propose 4 animations via transition:animate. Exemple — contenu qui glisse depuis la droite :

<article transition:animate="slide">
  <h1>Titre de l'article</h1>
  <p>Contenu de l'article...</p>
</article>

Les 4 animations intégrées :

fade (défaut) : fondu, le plus polyvalent
slide : glissement depuis la droite, idéal pour les pages détail
initial : style par défaut du navigateur, quasi sans animation
none : désactive l’animation pour certains éléments

Mon combo habituel : slide pour le contenu principal, fade pour la sidebar — plus de profondeur.

Vous pouvez ajuster la durée avec fade() et slide() :

---
import { fade, slide } from 'astro:transitions';
---
<article transition:animate={slide({ duration: '0.5s' })}>
  <!-- Glissement de 0,5 s -->
</article>

<aside transition:animate={fade({ duration: '0.2s' })}>
  <!-- Fondu de 0,2 s -->
</aside>

Technique 2 : transition:name pour le morphing

La fonctionnalité la plus impressionnante. transition:name indique au navigateur : « ces éléments sur deux pages sont le même objet — anime la transformation. »

Cas classique : titre de la liste vers le détail.

Page liste (index.astro) :

<ul>
  <li>
    <a href="/posts/astro-guide">
      <h2 transition:name="post-title-astro-guide">Guide complet Astro</h2>
    </a>
  </li>
</ul>

Page détail (posts/astro-guide.astro) :

<article>
  <h1 transition:name="post-title-astro-guide">Guide complet Astro</h1>
  <p>Contenu de l'article...</p>
</article>

Les deux titres partagent transition:name="post-title-astro-guide". Au clic, le titre se déplace de la liste vers le haut du détail, taille et couleur incluses.

Important : la valeur de transition:name doit être unique sur chaque page. Pour plusieurs articles, utilisez une valeur dynamique :

{posts.map(post => (
  <h2 transition:name={`post-title-${post.slug}`}>{post.title}</h2>
))}

La première fois que j’ai vu le titre « voler » vers le haut du détail, j’ai eu l’impression d’une vraie prouesse technique.

Technique 3 : transition:persist pour conserver l’état

Certains éléments doivent rester inchangés lors de la navigation :

Lecteur musical (lecture non interrompue)
Barre de navigation (éviter le re-render)
Icône panier (conserver le compteur)

Utilisez transition:persist :

<MusicPlayer client:load transition:persist />

Le composant n’est pas détruit puis recréé — il est « déplacé » vers la nouvelle page. L’état interne (progression de lecture, etc.) est conservé.

Usage avancé : avec transition:persist-props

Par défaut, transition:persist re-render le composant avec les nouvelles props. Si vous ne voulez pas mettre à jour les props (champ de recherche dans la nav, saisie utilisateur préservée), ajoutez transition:persist-props :

<SearchBar
  client:load
  transition:persist
  transition:persist-props
/>

Sur un site de documentation, l’utilisateur saisit une requête, clique un lien — le texte reste. Gain d’expérience net.

Technique 4 : contrôle global des animations

Pour une animation par défaut sur toute la page, sur <html> :

<html transition:animate="slide">
  <head>
    <ViewTransitions />
  </head>
  <body>
    <!-- Tout le contenu hérite de slide -->
  </body>
</html>

Puis surchargez au besoin :

<nav transition:animate="fade">
  <!-- Nav en fade -->
</nav>

<article>
  <!-- Article en slide hérité -->
</article>

Flexible pour les projets de grande taille.

Cas pratique : une expérience de transition complète pour un blog

Théorie et astuces posées — construisons un flux accueil → détail d’article.

Contexte

Structure type :

Accueil : liste d’articles avec titre, extrait, couverture
Détail : article complet avec titre, couverture, corps

Objectifs :

Clic sur le titre → déplacement fluide vers le haut du détail (morphing)
Même chose pour la couverture
Reste du contenu en fondu
Navigation persistante, sans clignotement

Étape 1 : activer View Transitions dans le Layout

Dans src/layouts/BaseLayout.astro :

---
import { ViewTransitions } from 'astro:transitions';

interface Props {
  title: string;
}

const { title } = Astro.props;
---
<!DOCTYPE html>
<html lang="fr">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width" />
    <title>{title}</title>
    <ViewTransitions />
  </head>
  <body>
    <nav transition:persist transition:name="main-nav">
      <a href="/">Accueil</a>
      <a href="/about">À propos</a>
    </nav>
    <main>
      <slot />
    </main>
  </body>
</html>

La nav combine transition:persist et transition:name="main-nav" pour éviter le flash.

Étape 2 : page liste — transition:name sur titre et couverture

Dans src/pages/index.astro :

---
import BaseLayout from '../layouts/BaseLayout.astro';

const posts = await Astro.glob('./posts/*.md');
---
<BaseLayout title="Mon blog">
  <h1>Derniers articles</h1>
  <div class="post-list">
    {posts.map(post => (
      <article class="post-card">
        <a href={post.url}>
          <img
            src={post.frontmatter.cover}
            alt={post.frontmatter.title}
            transition:name={`cover-${post.frontmatter.slug}`}
          />
          <h2 transition:name={`title-${post.frontmatter.slug}`}>
            {post.frontmatter.title}
          </h2>
          <p>{post.frontmatter.excerpt}</p>
        </a>
      </article>
    ))}
  </div>
</BaseLayout>

Points clés :

Couverture : transition:name={'cover-${post.frontmatter.slug}'}
Titre : transition:name={'title-${post.frontmatter.slug}'}
slug garantit l’unicité par article

Étape 3 : page détail — mêmes transition:name

Dans le template d’article (src/layouts/PostLayout.astro) :

---
import BaseLayout from './BaseLayout.astro';

const { frontmatter } = Astro.props;
---
<BaseLayout title={frontmatter.title}>
  <article class="post-detail">
    <img
      src={frontmatter.cover}
      alt={frontmatter.title}
      transition:name={`cover-${frontmatter.slug}`}
      class="cover-image"
    />
    <h1 transition:name={`title-${frontmatter.slug}`}>
      {frontmatter.title}
    </h1>
    <div class="post-meta">
      <time>{frontmatter.date}</time>
      <span>{frontmatter.author}</span>
    </div>
    <div class="post-content" transition:animate="slide">
      <slot />
    </div>
  </article>
</BaseLayout>

Couverture et titre : mêmes transition:name que la liste. Corps : transition:animate="slide".

Étape 4 : CSS pour fluidifier

Dans le Layout ou les styles globaux :

/* Optimisation des performances de transition */
[transition:name] {
  will-change: transform;
}

/* Couverture en liste et en détail */
.post-card img {
  width: 100%;
  height: 200px;
  object-fit: cover;
  border-radius: 8px;
}

.post-detail .cover-image {
  width: 100%;
  max-height: 400px;
  object-fit: cover;
  border-radius: 12px;
}

/* Titres */
.post-card h2 {
  font-size: 1.5rem;
  color: #333;
}

.post-detail h1 {
  font-size: 2.5rem;
  color: #111;
  margin-top: 1rem;
}

will-change: transform indique au navigateur qu’une transformation est prévue — optimisation anticipée.

Étape 5 : tester

npm run dev

Sur l’accueil, cliquez un titre. Vous devriez voir :

Titre qui se déplace de la liste vers le haut du détail, taille incluse
Couverture qui suit et s’agrandit
Navigation immobile
Reste (extrait, date…) en fondu

La première fois, c’était exactement l’effet recherché — net gain UX vs navigation classique.

Option : état de chargement

Pour des articles lourds, un délai peut apparaître. Astro fournit des hooks :

<script>
  document.addEventListener('astro:before-preparation', () => {
    // Afficher l'animation de chargement
    document.body.classList.add('loading');
  });

  document.addEventListener('astro:page-load', () => {
    // Masquer l'animation de chargement
    document.body.classList.remove('loading');
  });
</script>

<style>
  body.loading::after {
    content: '';
    position: fixed;
    top: 50%;
    left: 50%;
    width: 40px;
    height: 40px;
    border: 4px solid #f3f3f3;
    border-top: 4px solid #3498db;
    border-radius: 50%;
    animation: spin 1s linear infinite;
  }

  @keyframes spin {
    0% { transform: rotate(0deg); }
    100% { transform: rotate(360deg); }
  }
</style>

Un spinner pendant le chargement complète l’expérience.

Astuces avancées et problèmes courants

Bases et cas pratique couverts — pièges rencontrés et solutions.

Astuce avancée 1 : respecter prefers-reduced-motion

Certains utilisateurs (troubles vestibulaires, préférence personnelle) activent « réduire les animations » dans les paramètres système. À respecter.

Astro et le navigateur gèrent une partie automatiquement ; vous pouvez aussi contrôler manuellement :

@media (prefers-reduced-motion: reduce) {
  * {
    animation-duration: 0.01ms !important;
    animation-iteration-count: 1 !important;
    transition-duration: 0.01ms !important;
  }
}

Ou dans un composant Astro :

<div transition:animate={
  typeof window !== 'undefined' &&
  window.matchMedia('(prefers-reduced-motion: reduce)').matches
    ? 'none'
    : 'slide'
}>
  Contenu
</div>

Détail souvent oublié, mais important pour une partie des utilisateurs.

Astuce avancée 2 : cycle de vie des scripts

En MPA classique, chaque navigation relance les scripts. Avec View Transitions, la navigation devient « pseudo-SPA » — comportement différent.

Événements Astro :

// Page chargée (premier chargement et après navigation)
document.addEventListener('astro:page-load', () => {
  console.log('Contenu de page mis à jour');
  // Réinitialiser composants UI, rebinder événements, etc.
});

// Navigation imminente
document.addEventListener('astro:before-preparation', () => {
  console.log('Navigation vers une nouvelle page');
  // Nettoyer timers, annuler requêtes réseau, etc.
});

// Navigation annulée (ex. bouton retour)
document.addEventListener('astro:after-swap', () => {
  console.log('DOM mis à jour, animation pas encore terminée');
});

Piège courant : listeners non nettoyés dans astro:before-preparation → fuites mémoire. J’avais un listener de scroll non retiré ; après plusieurs navigations, la page ralentissait.

Astuce avancée 3 : optimiser les performances

View Transitions est léger, mais beaucoup d’éléments animés peuvent ralentir :

Limiter les éléments en transition : transition:name sur les éléments clés seulement
will-change: transform : optimisation anticipée
Éviter reflow pendant l’animation : pas de width, height, padding en pleine animation
Tester sur appareils réels : la machine de dev n’est pas celle des visiteurs

/* Bonne pratique */
.animated-element {
  will-change: transform, opacity;
  transform: translateX(0);
}

/* À éviter */
.animated-element {
  width: 100px; /* width déclenche reflow, mauvaises perfs */
}

Problème 1 : l’animation ne s’active pas

Symptôme : transition:name présent, navigation brutale sans animation.

Causes et solutions :

transition:name dupliqué sur la même page
Noms différents entre liste et détail
Navigateur incompatible : console DevTools
Astro trop ancien : View Transitions depuis Astro 3.0+

# Vérifier la version Astro
npx astro --version

# Mettre à jour Astro
npm install astro@latest

Problème 2 : clignotement ou saut d’éléments

Symptôme : flash ou décalage pendant la transition.

Causes et solutions :

Styles CSS incohérents : display, position identiques sur les deux pages
Image pas encore chargée : loading="eager" ou hauteur fixe
Pas de transition:persist : nav, lecteur — ajoutez-le

<!-- Éviter le flash d'image -->
<img
  src={cover}
  loading="eager"
  style="height: 200px"
  transition:name="cover"
/>

Problème 3 : mauvaise direction au retour arrière

Symptôme : animation OK en avant, même sens au retour.

Solution : Astro gère souvent la direction ; avec animations custom :

document.addEventListener('astro:before-preparation', (event) => {
  const isBack = event.direction === 'back';
  if (isBack) {
    document.documentElement.classList.add('reverse-animation');
  }
});

.reverse-animation [transition:animate="slide"] {
  animation-direction: reverse;
}

Problème 4 : conflit avec scripts tiers

Symptôme : Google Analytics, pubs, etc. ne fonctionnent plus après View Transitions.

Cause : ces scripts s’exécutent au chargement initial ; View Transitions intercepte la navigation sans les prévenir.

Solution : relancer dans astro:page-load :

document.addEventListener('astro:page-load', () => {
  // Google Analytics
  if (typeof gtag !== 'undefined') {
    gtag('config', 'GA_MEASUREMENT_ID', {
      page_path: window.location.pathname,
    });
  }

  // Facebook Pixel
  if (typeof fbq !== 'undefined') {
    fbq('track', 'PageView');
  }
});

J’avais des stats GA fausses après l’ajout de View Transitions — déclenchement manuel nécessaire.

Compatibilité et amélioration progressive

Support élevé (85 %+), mais pas universel. Astro dégrade proprement : navigation classique, site fonctionnel.

Détection manuelle :

if (document.startViewTransition) {
  console.log('Navigateur compatible View Transitions');
} else {
  console.log('Non compatible — dégradation automatique');
}

Navigateurs modernes : expérience fluide. Anciens : site intact.

Conclusion

Récapitulons :

API View Transitions + Astro = la solution la plus simple pour des transitions de page. Pas de React, pas de Vue, pas de bibliothèque tierce — 2 lignes dans le <head> du Layout suffisent pour une expérience digne d’une app.

Du fondu de base au glissement personnalisé, au morphing et à la persistance d’état, on transforme une MPA rigide en application web moderne et fluide — sur une API native, surcoût minimal, dégradation automatique.

Pour commencer :

Méthode la plus simple : <ViewTransitions /> dans le Layout, observer l’effet par défaut
Repérer ce qui impressionne : nav sans clignotement, morphing du titre
Personnaliser : transition:animate, transition:name selon votre charte
Tester en conditions réelles : navigateurs et appareils variés

Sur chaque nouveau projet, j’active View Transitions en premier — si simple, si efficace. Parfois, la bonne UX ne demande pas de code complexe, juste le bon outil.

En cas de blocage :

Documentation Astro
View Transitions Demo pour l’inspiration
Console navigateur pour les erreurs

Si vous réalisez un effet sympa avec View Transitions, partagez le lien en commentaire — j’aimerais voir vos créations.

Ouvrez votre projet Astro et rendez votre site fluide !

Configuration complète d'Astro View Transitions

2 lignes de code pour une expérience fluide digne d'une app — de la configuration de base aux personnalisations avancées, avec cas pratique complet

⏱️ Estimated time: 15 min

1
Step 1: Comprendre l'API View Transitions et le support navigateur
Qu'est-ce que l'API View Transitions :
• Fonctionnalité native du navigateur
• Vous indiquez « je vais changer de contenu »
• Le navigateur capture deux « photos » (ancienne et nouvelle page)
• Puis génère une animation fluide entre les deux
• Animations automatiques — pas de CSS complexe ni GSAP, Framer Motion, etc.

Support > 85 % en 2025 :
• Chrome 111+ : transitions intra-document
• Chrome 126+ : transitions inter-documents (usage Astro)
• Safari : pris en charge
• Edge : Chromium, entièrement compatible
• Firefox 144+ : pris en charge (pilier Interop 2025)

L'équipe React a intégré View Transitions en 2025 (react@canary) — l'API est devenue un standard.

Compatibilité :
• Astro dégrade automatiquement
• Navigation classique sur navigateurs non compatibles
• Fonctionnalité intacte, sans animation
• Amélioration progressive
2
Step 2: Avantages de la combinaison Astro + View Transitions
Pourquoi un effet SPA sans React/Vue :

Problèmes des SPA traditionnelles :
• Application monopage obligatoire
• Routes entièrement en JavaScript
• Bundle plus lourd, premier affichage plus lent
• SEO à traiter à part

Avantages Astro + View Transitions :
• MPA conservée, HTML indépendant par page, SEO favorable
• Chargement à la demande (JS/CSS de la page courante)
• API native, surcoût minimal, pas d'augmentation du bundle
• Amélioration progressive, dégradation transparente

Comparaison :
• Même blog : SPA React ~300 Ko+, Astro ~50 Ko
• View Transitions n'augmente presque pas le poids
3
Step 3: 3 méthodes d'activation : du plus simple au personnalisé
Méthode 1 — la plus simple :
• <ViewTransitions /> dans le <head> du Layout
• 2 lignes de code
• Transitions fluides immédiates
• Sans React, Vue ou bibliothèque JS

Méthode 2 — personnalisation :
• transition:animate : fade, slide, none
• transition:name pour nommer les éléments
• Le navigateur reconnaît le même titre accueil/détail
• Déplacement fluide de la liste vers le haut de l'article

Méthode 3 — avancé :
• Morphing : vignette liste → grande image détail
• Persistance d'état : scroll, saisie de formulaire
• Durée et courbes d'animation personnalisées
4
Step 4: Cas pratique : transition fluide liste → détail
Cas complet :

Scénario :
• Accueil avec titre « Tutoriel Astro »
• Clic → page détail

Navigation classique :
• Accueil disparaît → écran blanc → détail

Avec View Transitions :
• Même élément titre reconnu sur les deux pages
• Déplacement fluide liste → haut du détail
• Reste en fondu

Étapes :
1. <ViewTransitions /> dans le head du Layout
2. transition:name sur le titre (ex. transition:name="article-title")
3. Option : transition:animate="slide"
4. Tester sur navigateurs et appareils

Résultat :
• Nav sans clignotement
• Morphing du titre
• Transition fluide des images
• UX type app au lieu d'un saut brutal
5
Step 5: Problèmes courants et bonnes pratiques
Problèmes courants : 1) Animation inactive (vérifier le support navigateur, console), 2) Morphing peu naturel (transition:name identique, structure d'éléments similaire), 3) Performance (API native légère ; trop d'éléments animés peut ralentir — cibler les éléments clés). Bonnes pratiques : commencer par <ViewTransitions /> et l'effet par défaut ; repérer ce qui impressionne (nav, morphing du titre) ; personnaliser avec transition:animate et transition:name ; tester en conditions réelles. Compatibilité : support > 85 %, Astro dégrade sur les navigateurs restants — navigation classique, site fonctionnel.

FAQ

Qu'est-ce que l'API View Transitions ? Pourquoi c'est intéressant ?

L'API View Transitions est une fonctionnalité native du navigateur : vous indiquez « je vais changer de contenu », il capture deux « photos » (ancienne et nouvelle page) et génère une animation fluide entre les deux.

Les animations sont automatiques — pas de CSS complexe ni GSAP, Framer Motion, etc.

Exemple : titre « Tutoriel Astro » sur l'accueil, clic vers le détail.
• Classique : accueil disparaît → écran blanc → détail
• Avec View Transitions : même élément reconnu, titre déplacé en douceur vers le haut du détail, reste en fondu

Quel est le support navigateur en 2025 ? Peut-on s'y fier ?

Support > 85 % en 2025 :
• Chrome 111+ : transitions intra-document
• Chrome 126+ : transitions inter-documents (usage Astro)
• Safari : pris en charge
• Edge : Chromium, entièrement compatible
• Firefox 144+ : pris en charge (Interop 2025)

React a intégré View Transitions en 2025 (react@canary) — standard du front-end.

Les ~15 % restants ? Astro dégrade : navigation classique, fonctionnalité intacte, sans animation — amélioration progressive.

Pourquoi un effet SPA sans React/Vue ?

SPA traditionnelles :
• Application monopage, routes en JavaScript
• Bundle plus lourd, premier affichage plus lent
• SEO à traiter à part

Astro + View Transitions :
• MPA, HTML indépendant, SEO favorable
• Chargement à la demande
• API native, surcoût minimal
• Dégradation transparente

Test : même blog, React SPA ~300 Ko+, Astro ~50 Ko — View Transitions n'ajoute presque rien.

Comment activer View Transitions dans Astro ? Combien de méthodes ?

Méthode 1 — la plus simple :
• <ViewTransitions /> dans le <head> du Layout
• 2 lignes, transitions fluides
• Sans React, Vue ou bibliothèque JS

Méthode 2 — personnalisation :
• transition:animate (fade, slide, none)
• transition:name pour lier les éléments entre pages
• Titre déplacé de la liste vers le haut du détail

Méthode 3 — avancé :
• Morphing d'images (vignette → grand format)
• Persistance d'état (scroll, formulaires)
• Durée et courbes personnalisées

Comment réaliser une transition fluide liste → détail ?

Cas : titre « Tutoriel Astro » sur l'accueil, clic vers le détail.
• Classique : accueil → blanc → détail
• View Transitions : même élément, déplacement fluide du titre, reste en fondu

Étapes :
1) <ViewTransitions /> dans le head du Layout
2) transition:name sur le titre (ex. transition:name="article-title")
3) Option : transition:animate="slide"
4) Tester navigateurs et appareils

Résultat : nav stable, morphing du titre, images fluides, UX type app.

Quels problèmes courants et bonnes pratiques avec View Transitions ?

Problèmes :
1) Animation inactive : support navigateur, console
2) Morphing peu naturel : transition:name identique, structure similaire
3) Performance : API légère ; limiter les éléments animés

Bonnes pratiques :
• Commencer par <ViewTransitions /> et l'effet par défaut
• Repérer nav sans clignotement, morphing du titre
• Personnaliser transition:animate, transition:name
• Tester en conditions réelles

Compatibilité : > 85 %, Astro dégrade ailleurs. Détection : if (document.startViewTransition).

14 min de lecture · Publié le: 2 déc. 2025 · Mis à jour le: 27 juil. 2026

Easton

Technologie