Czy View Transitions działają na iOS Safari?

Tak, od Safari 17.4 (marzec 2024). Starsze wersje iOS dostają graceful fallback — klasyczną nawigację bez animacji, bez błędów. Użytkownik nie odczuwa degradacji, tylko brak efektu wizualnego.

Czy mogę używać View Transitions w istniejącym projekcie Astro?

Tak. Dodanie ` ` do layoutu jest non-destructive. Strony bez atrybutów `transition:*` dostaną domyślny cross-fade. Named transitions możesz dodawać stopniowo, tam gdzie mają realny wpływ na orientację użytkownika.

Czy View Transitions wpływają na performance?

`ClientRouter` to około 4 KB JS gzipped. Animacje są natywne w przeglądarce — CPU use jest minimalny. Perceived performance zwykle rośnie: płynne przejście jest postrzegane jako szybsze niż reload, nawet gdy czas do pierwszego paint jest identyczny.

Czy można wyłączyć View Transitions dla konkretnych linków?

Tak, dodaj atrybut `data-astro-reload` do linku, który ma robić pełny reload zamiast animowanego przejścia: ```html Klasyczna nawigacja ```

Czy View Transitions działają z anchorami (`#section`)?

Tak, Astro obsługuje anchor linki — przejście do sekcji na tej samej stronie animuje scroll, a między stronami scroll pozycjonuje się do elementu o odpowiednim ID po nawigacji.

Astro View Transitions — płynne przejścia między stronami bez budowania SPA

Tradycyjne — każde kliknięcie to pełny reload. Szybko, przewidywalnie, ale wizualnie szorstko. Astro łączy oba światy: animowane przejścia jak w , prosta architektura MPA, zero kompromisów wydajnościowych.

Skąd się wziął View Transitions API

View Transitions to natywne API przeglądarki, które pozwala animować przejścia między stanami DOM. Początkowo było zaimplementowane tylko w Chrome (2023), potem dołączyło Safari (17.4+, marzec 2024), a Firefox dodał natywne wsparcie dopiero w wersji 144 (październik 2025) — i to najpierw dla przejść w obrębie jednego dokumentu. Dla przeglądarek bez natywnego API Astro robi — zwykły reload strony, bez animacji, ale też bez błędów.

Astro było jednym z pierwszych frameworków, które zintegrowały View Transitions w sposób end-to-end. Do Astro 4 komponent nazywał się <ViewTransitions />. W Astro 5.0 został przemianowany na <ClientRouter />, żeby lepiej odzwierciedlać zakres działania (to klient-side router, który wykorzystuje View Transitions tam, gdzie to możliwe) — stara nazwa działała jeszcze jako alias z ostrzeżeniem o wycofaniu. Astro 6.0 usunęło <ViewTransitions /> całkowicie, więc na bieżących wersjach stosujemy <ClientRouter />.

Setup — trzy linie kodu

Żeby dodać View Transitions do całej strony, dodajesz jedną rzecz w layoucie:

Code

---
// src/layouts/Layout.astro
import { ClientRouter } from 'astro:transitions';
---
 
<html lang="pl">
<head>
  <meta charset="UTF-8" />
  <title><slot name="title">StriveLab</slot></title>
  <ClientRouter />
</head>
<body>
  <slot />
</body>
</html>

Po dodaniu <ClientRouter /> Astro automatycznie przechwytuje kliknięcia w linki wewnętrzne i zamiast pełnego reloadu robi animowane przejście z wykorzystaniem View Transitions API (jeśli przeglądarka wspiera) lub soft-reload (jeśli nie).

To wszystko. Bez zmian w stronach, bez konfiguracji, bez bibliotek zewnętrznych.

Co dokładnie się dzieje pod maską

Kiedy user klika link wewnętrzny:

Astro przechwytuje kliknięcie przez event listener.
Pobiera nową stronę przez fetch().
Uruchamia document.startViewTransition() (lub fallback).
Podmienia <body> na nową treść.
Przeglądarka animuje przejście — domyślnie .

Efekt — user widzi płynne przejście zamiast białego błysku reloadu. Nawigacja wstecz/do przodu w przeglądarce też działa z animacjami.

Named transitions — precyzyjne animacje dla wybranych elementów

Sam cross-fade jest fajny, ale prawdziwą wartość View Transitions zyskują, kiedy dodajesz named transitions — oznaczone elementy, które mają animować między stronami w skoordynowany sposób.

Weźmy typowy przykład — lista artykułów i strona pojedynczego artykułu. Chcesz, żeby po kliknięciu miniaturka obrazu „powiększyła się" do pełnowymiarowego obrazu hero na nowej stronie.

Code

---
// src/pages/blog/index.astro - lista artykułów
import { getCollection } from 'astro:content';
 
const posts = await getCollection('blog');
---
 
<ul>
  {posts.map((post) => (
    <li>
      <a href={`/blog/${post.id}/`}>
        <img
          src={post.data.image}
          alt={post.data.title}
          transition:name={`hero-${post.id}`}
        />
        <h2 transition:name={`title-${post.id}`}>{post.data.title}</h2>
      </a>
    </li>
  ))}
</ul>

Code

---
// src/pages/blog/[...slug].astro - strona artykułu
const { post } = Astro.props;
---
 
<article>
  <img
    src={post.data.image}
    alt={post.data.title}
    transition:name={`hero-${post.id}`}
  />
  <h1 transition:name={`title-${post.id}`}>{post.data.title}</h1>
</article>

Kluczem do sukcesu jest to samo transition:name na obu stronach. Przeglądarka widzi, że element hero-post-123 istnieje na stronie A i B, i automatycznie animuje przejście między pozycjami i rozmiarami.

Dla bloga ze zdjęciami efekt jest natychmiastowy: tapnąć miniaturkę, płynna ekspansja do pełnego hero artykułu. Wizualnie nieodróżnialne od natywnej aplikacji iOS/Android.

Persistent state — zachowanie stanu przy nawigacji

Kolejny problem nawigacji MPA — tracisz stan elementów pomiędzy stronami. Formularz kontaktowy, audio player, kontrolki video — wszystko resetuje się przy reloadzie.

Astro daje transition:persist:

Code

<!-- src/layouts/Layout.astro -->
<audio controls transition:persist="audio-player">
  <source src="/podcast.mp3" type="audio/mpeg" />
</audio>
 
<slot />

Element oznaczony transition:persist nie jest zniszczony między stronami — zachowuje swój stan (pozycja odtwarzania, focus, wartość inputa). User może słuchać podcastu w headerze i przechodzić między artykułami bez przerywania odtwarzania.

Typowe zastosowania to player audio lub video, formularze wieloetapowe (jeśli nie zmieniają się między stronami), widgety czatu i koszyk w e-commerce — wszędzie tam, gdzie reset stanu przy nawigacji jest prawdziwym problemem użytkownika.

Dyrektywy animacji — dostosowanie efektu

Domyślny cross-fade działa w większości przypadków, ale możesz wybrać inny preset:

Code

<main transition:animate="slide">
  <slot />
</main>

Dostępne presety:

fade — cross-fade (domyślny)
slide — wsunięcie z prawej/lewej
none — brak animacji
Custom — własna animacja CSS

Custom animation:

Code

---
import { fade } from 'astro:transitions';
 
const customFade = fade({ duration: '0.4s' });
---
 
<main transition:animate={customFade}>
  <slot />
</main>

Albo całkowicie własna, z keyframe'ami:

Code

@keyframes slideInFromRight {
  from {
    transform: translateX(50px);
    opacity: 0;
  }
  to {
    transform: translateX(0);
    opacity: 1;
  }
}
 
@keyframes slideOutToLeft {
  from {
    transform: translateX(0);
    opacity: 1;
  }
  to {
    transform: translateX(-50px);
    opacity: 0;
  }
}
 
::view-transition-old(root) {
  animation: slideOutToLeft 0.3s ease-in;
}
 
::view-transition-new(root) {
  animation: slideInFromRight 0.3s ease-out;
}

Selektory ::view-transition-old i ::view-transition-new to natywne API przeglądarki — możesz stylować przejścia jak każdy inny element CSS.

Lifecycle events — reagowanie na zmiany strony

ClientRouter emituje eventy, które pozwalają reagować na nawigację:

Code

<script>
  // Przed rozpoczęciem nawigacji
  document.addEventListener('astro:before-preparation', (e) => {
    console.log('Going to', e.to)
  })
 
  // Po załadowaniu nowej strony
  document.addEventListener('astro:page-load', () => {
    console.log('Page loaded')
    // Re-init third-party scripts, analytics etc.
  })
 
  // Po animacji przejścia
  document.addEventListener('astro:after-swap', () => {
    console.log('DOM updated')
  })
</script>

To przydaje się szczególnie przy re-inicjalizacji skryptów analitycznych (GA, Plausible) po nowej stronie, re-aplikowaniu motywu (dark/light) po nawigacji i trackingu konwersji.

Pułapki i ograniczenia

1. Scroll position. Domyślnie Astro resetuje scroll do góry przy nawigacji, ale jeśli chcesz zachować pozycję scrollowania (np. przy kliknięciu w sekcję w tej samej stronie), musisz to obsłużyć ręcznie.

2. Skrypty globalne. Skrypty w <head> ładowane są raz. Jeśli zainicjowałeś coś (np. Intersection Observer) na stronie A, po przejściu na B trzeba to zainicjować ponownie — stąd event astro:page-load.

3. Forms. ClientRouter obsługuje formularze GET i POST, ale przy krytycznych flow (płatność, logowanie, upload pliku) często lepiej dodać data-astro-reload, żeby zachować klasyczne zachowanie przeglądarki.

4. Third-party widgets. Widgety wstrzykujące treść do DOM (np. komentarze Disqus, social embeds) często nie lubią podmiany <body>. Oznacz je transition:persist lub reinicjalizuj na astro:page-load.

5. Przeglądarki bez pełnego wsparcia. Astro ma strategie fallbacku dla przeglądarek bez natywnego View Transitions API. UX pozostaje poprawny, ale animacje nie muszą być identyczne między silnikami.

Dostępność i skrypty po nawigacji

View Transitions wyglądają jak warstwa wizualna, ale technicznie zmieniają sposób, w jaki strona reaguje po kliknięciu linku. Dlatego wdrożenie powinno mieć krótką checklistę dostępności i utrzymania skryptów.

Każda strona musi mieć sensowny <title> i główny <h1>, bo ClientRouter używa ich do ogłaszania zmiany trasy technologiom wspomagającym — bez tego użytkownik czytnika ekranu nie wie, że nawigacja w ogóle nastąpiła. Astro respektuje , ale własne animacje CSS też muszą mieć wariant ograniczonego ruchu — systemowe preferencje użytkownika powinny wygrywać z estetyką strony. Skrypty inicjalizujące obserwatory, tooltipy, galerie albo analytics uruchamiaj po astro:page-load, a nie tylko przy pierwszym ładowaniu dokumentu. Elementy z dużym stanem (player audio, koszyk) oznaczaj transition:persist tylko wtedy, gdy naprawdę mają przetrwać zmianę strony. Linki do krytycznych procesów, paneli zewnętrznych i formularzy transakcyjnych oznacz data-astro-reload.

SEO — czy View Transitions nie zaszkodzą?

Obawa, która regularnie wraca: „Skoro Astro podmienia <body> przez JS, czy Google widzi wszystko?"

Odpowiedź: tak, widzi. View Transitions działają po załadowaniu statycznego HTML-a dla docelowej strony. Jeśli Google crawler wchodzi bezpośrednio na /blog/moj-wpis/, dostaje pełny, statyczny HTML — dokładnie tak samo, jakby ClientRouter nie istniał. Animacje są tylko warstwą UX dla użytkownika klikającego linki wewnętrzne.

Więcej o SEO w Astro piszę w osobnym artykule.

Kiedy NIE używać View Transitions

View Transitions to dobre narzędzie, ale nie każde środowisko na nie zasługuje. Jeśli strona to głównie workflow z formularzami wieloetapowymi, ClientRouter komplikuje stan bardziej, niż wart jest efekt wizualny — w takim przypadku lepiej rozważyć czysty SPA (React/Next.js) albo Astro bez ClientRouter. Podobnie gdy wiele komponentów dzieli stan: MPA + View Transitions to antywzorzec, a nie usprawnienie. ClientRouter waży ~4 KB JS, więc dla landing page'a z jednym CTA, gdzie każdy kilobajt jest na wagę złota, można go spokojnie pominąć.

Dla bloga, portfolio, dokumentacji, strony firmowej czy lekkiego e-commerce View Transitions są wygraną bezsporną — i to jedną z tych rzadkich, gdzie dodanie funkcji jednocześnie poprawia wydajność postrzeganą przez użytkownika.

Porównanie z SPA

Pytanie, które dostaję regularnie: „Skoro Astro + View Transitions daje płynne przejścia, to po co w ogóle SPA?"

Odpowiedź zależy od charakteru aplikacji. Jeśli to treść z nawigacją, w której strony są de facto niezależne — Astro z View Transitions jest prostsze, szybsze i wydajniejsze niż Next.js SPA. Jeśli to aplikacja z dużym, współdzielonym state'em, gdzie użytkownik spędza czas w jednej „sesji" — SPA nadal ma przewagę.

Szczegółowe porównanie obu podejść znajdziesz w artykule o Astro vs Next.js.

Skąd się wziął View Transitions API

Setup — trzy linie kodu

Żeby dodać View Transitions do całej strony, dodajesz jedną rzecz w layoucie:

Code

---
// src/layouts/Layout.astro
import { ClientRouter } from 'astro:transitions';
---
 
<html lang="pl">
<head>
  <meta charset="UTF-8" />
  <title><slot name="title">StriveLab</slot></title>
  <ClientRouter />
</head>
<body>
  <slot />
</body>
</html>

To wszystko. Bez zmian w stronach, bez konfiguracji, bez bibliotek zewnętrznych.

Co dokładnie się dzieje pod maską

Kiedy user klika link wewnętrzny:

Astro przechwytuje kliknięcie przez event listener.
Pobiera nową stronę przez fetch().
Uruchamia document.startViewTransition() (lub fallback).
Podmienia <body> na nową treść.
Przeglądarka animuje przejście — domyślnie .

Efekt — user widzi płynne przejście zamiast białego błysku reloadu. Nawigacja wstecz/do przodu w przeglądarce też działa z animacjami.

Named transitions — precyzyjne animacje dla wybranych elementów

Weźmy typowy przykład — lista artykułów i strona pojedynczego artykułu. Chcesz, żeby po kliknięciu miniaturka obrazu „powiększyła się" do pełnowymiarowego obrazu hero na nowej stronie.

Code

---
// src/pages/blog/index.astro - lista artykułów
import { getCollection } from 'astro:content';
 
const posts = await getCollection('blog');
---
 
<ul>
  {posts.map((post) => (
    <li>
      <a href={`/blog/${post.id}/`}>
        <img
          src={post.data.image}
          alt={post.data.title}
          transition:name={`hero-${post.id}`}
        />
        <h2 transition:name={`title-${post.id}`}>{post.data.title}</h2>
      </a>
    </li>
  ))}
</ul>

Code

---
// src/pages/blog/[...slug].astro - strona artykułu
const { post } = Astro.props;
---
 
<article>
  <img
    src={post.data.image}
    alt={post.data.title}
    transition:name={`hero-${post.id}`}
  />
  <h1 transition:name={`title-${post.id}`}>{post.data.title}</h1>
</article>

Dla bloga ze zdjęciami efekt jest natychmiastowy: tapnąć miniaturkę, płynna ekspansja do pełnego hero artykułu. Wizualnie nieodróżnialne od natywnej aplikacji iOS/Android.

Persistent state — zachowanie stanu przy nawigacji

Kolejny problem nawigacji MPA — tracisz stan elementów pomiędzy stronami. Formularz kontaktowy, audio player, kontrolki video — wszystko resetuje się przy reloadzie.

Astro daje transition:persist:

Code

<!-- src/layouts/Layout.astro -->
<audio controls transition:persist="audio-player">
  <source src="/podcast.mp3" type="audio/mpeg" />
</audio>
 
<slot />

Dyrektywy animacji — dostosowanie efektu

Domyślny cross-fade działa w większości przypadków, ale możesz wybrać inny preset:

Code

<main transition:animate="slide">
  <slot />
</main>

Dostępne presety:

fade — cross-fade (domyślny)
slide — wsunięcie z prawej/lewej
none — brak animacji
Custom — własna animacja CSS

Custom animation:

Code

---
import { fade } from 'astro:transitions';
 
const customFade = fade({ duration: '0.4s' });
---
 
<main transition:animate={customFade}>
  <slot />
</main>

Albo całkowicie własna, z keyframe'ami:

Code

@keyframes slideInFromRight {
  from {
    transform: translateX(50px);
    opacity: 0;
  }
  to {
    transform: translateX(0);
    opacity: 1;
  }
}
 
@keyframes slideOutToLeft {
  from {
    transform: translateX(0);
    opacity: 1;
  }
  to {
    transform: translateX(-50px);
    opacity: 0;
  }
}
 
::view-transition-old(root) {
  animation: slideOutToLeft 0.3s ease-in;
}
 
::view-transition-new(root) {
  animation: slideInFromRight 0.3s ease-out;
}

Selektory ::view-transition-old i ::view-transition-new to natywne API przeglądarki — możesz stylować przejścia jak każdy inny element CSS.

Lifecycle events — reagowanie na zmiany strony

ClientRouter emituje eventy, które pozwalają reagować na nawigację:

Code

<script>
  // Przed rozpoczęciem nawigacji
  document.addEventListener('astro:before-preparation', (e) => {
    console.log('Going to', e.to)
  })
 
  // Po załadowaniu nowej strony
  document.addEventListener('astro:page-load', () => {
    console.log('Page loaded')
    // Re-init third-party scripts, analytics etc.
  })
 
  // Po animacji przejścia
  document.addEventListener('astro:after-swap', () => {
    console.log('DOM updated')
  })
</script>

To przydaje się szczególnie przy re-inicjalizacji skryptów analitycznych (GA, Plausible) po nowej stronie, re-aplikowaniu motywu (dark/light) po nawigacji i trackingu konwersji.

Pułapki i ograniczenia

Dostępność i skrypty po nawigacji

SEO — czy View Transitions nie zaszkodzą?

Obawa, która regularnie wraca: „Skoro Astro podmienia <body> przez JS, czy Google widzi wszystko?"

Więcej o SEO w Astro piszę w osobnym artykule.

Kiedy NIE używać View Transitions

Porównanie z SPA

Pytanie, które dostaję regularnie: „Skoro Astro + View Transitions daje płynne przejścia, to po co w ogóle SPA?"

Szczegółowe porównanie obu podejść znajdziesz w artykule o Astro vs Next.js.

Astro View Transitions — płynne przejścia między stronami bez budowania SPA

Skąd się wziął View Transitions API

Setup — trzy linie kodu

Co dokładnie się dzieje pod maską

Named transitions — precyzyjne animacje dla wybranych elementów

Persistent state — zachowanie stanu przy nawigacji

Dyrektywy animacji — dostosowanie efektu

Lifecycle events — reagowanie na zmiany strony

Pułapki i ograniczenia

Dostępność i skrypty po nawigacji

SEO — czy View Transitions nie zaszkodzą?

Kiedy NIE używać View Transitions

Porównanie z SPA

Czytaj dalej

Astro View Transitions — płynne przejścia między stronami bez budowania SPA

Skąd się wziął View Transitions API

Setup — trzy linie kodu

Co dokładnie się dzieje pod maską

Named transitions — precyzyjne animacje dla wybranych elementów

Persistent state — zachowanie stanu przy nawigacji

Dyrektywy animacji — dostosowanie efektu

Lifecycle events — reagowanie na zmiany strony

Pułapki i ograniczenia

Dostępność i skrypty po nawigacji

SEO — czy View Transitions nie zaszkodzą?

Kiedy NIE używać View Transitions

Porównanie z SPA

Czytaj dalej