Per anni, le transizioni animate fra pagine sono state un'impresa tecnica. O si adottava un framework SPA (Next.js, Nuxt, Astro con view transitions integrate), oppure si lavorava di pezza con librerie JavaScript che intercettavano la navigazione e ridisegnavano il DOM a mano. Su WordPress, la maggior parte degli integratori rinunciava: troppi plugin, troppo rischio di rotture, poco ritorno sull'investimento.
La View Transitions API cambia il quadro. Standardizzata dal W3C, permette al browser stesso di gestire le transizioni visive fra due stati di una pagina — e ora anche fra due pagine distinte. Ad aprile 2026 il supporto copre i tre motori principali: Blink (Chrome 111+, Edge 111+), WebKit (Safari 18+) e Gecko (Firefox 133+) per la modalità mono-documento, mentre la modalità multi-documento si sta diffondendo rapidamente dopo l'arrivo in Chrome 126.
Per un sito WordPress, questo apre una strada pragmatica: aggiungere transizioni eleganti senza riscrivere il tema in JavaScript, senza plugin pesanti e senza compromettere le prestazioni dei Core Web Vitals.
Le due modalità: mono-documento e multi-documento
L'API distingue due scenari. La modalità mono-documento (a volte chiamata SPA) interviene all'interno della stessa pagina: si modifica il DOM e document.startViewTransition() cattura il prima e il dopo per interpolarli. È la versione originale, quella che usano le applicazioni single-page moderne.
La modalità multi-documento (MPA) copre la navigazione classica: si clicca su un link, il browser carica una nuova pagina e la transizione si svolge fra i due documenti. Non serve JavaScript; tutto passa da una regola CSS @view-transition. È proprio questa modalità a rendere l'API interessante per WordPress, dove la navigazione resta fondamentalmente multi-pagina.
La regola di base è essenziale:
@view-transition {
navigation: auto;
}Inserita nel foglio di stili principale, basta ad attivare una transizione in dissolvenza incrociata fra tutte le pagine della stessa origine. Il visitatore clicca un articolo, il browser lo carica e poi rivela la nuova pagina con un passaggio morbido invece di un salto secco.
Attivare la View Transitions API su un tema WordPress
In pratica, l'integrazione si fa a livello di tema figlio. Nel style.css o in un foglio dedicato registrato con wp_enqueue_style, si aggiunge la regola sopra. Il prerequisito è che le pagine condividano la stessa origine (impostazione predefinita su WordPress) e che il browser del visitatore supporti l'API. Per gli altri il degrado è elegante: nessuna transizione, nessun errore, nessun avviso.
Per andare oltre la semplice dissolvenza, si personalizzano gli pseudo-elementi generati dall'API. Durante una transizione il browser crea un albero accessibile da CSS: ::view-transition, ::view-transition-group(*), ::view-transition-image-pair(*), ::view-transition-old(*) e ::view-transition-new(*). Ognuno può essere animato in modo indipendente.
Un esempio comune su un blog WordPress è far scivolare il contenuto principale verso sinistra mentre il nuovo articolo entra da destra.
@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'effetto è discreto ma percepito come fluido dagli utenti, senza appesantire il browser.
Animare un elemento preciso fra due pagine
L'aspetto più interessante dell'API si rivela quando si nomina un elemento con view-transition-name. Prendiamo il caso tipico di una griglia di articoli: la miniatura dell'articolo cliccato deve ingrandirsi e diventare l'immagine in evidenza della pagina successiva. Su WordPress è lo scenario di un blog con card di articoli che si aprono sul permalink completo.
Lato elenco (per esempio archive.php o home.php), si assegna un nome univoco a ogni immagine in evidenza:
<?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; ?>Lato articolo (single.php), l'immagine in evidenza porta lo stesso nome:
<?php
the_post_thumbnail( 'large', [
'style' => 'view-transition-name: post-' . get_the_ID() . ';'
] );
?>Il browser riconosce che si tratta dello stesso elemento logico e orchestra un'animazione morph fluida fra le due posizioni e dimensioni. Niente librerie, niente calcoli manuali: se ne occupa il livello di presentazione nativo.
L'insidia della cache e dei plugin WordPress
È qui che l'esperienza WordPress complica leggermente le cose. Diversi plugin di cache o di ottimizzazione (WP Rocket, Autoptimize, LiteSpeed Cache) iniettano i propri script di preloading o di navigazione istantanea. Alcuni, come la funzionalità Instant Page di WP Rocket, intercettano i click e caricano la pagina successiva in background. Senza precauzioni, la loro logica entra in conflitto con l'attivazione nativa delle view transitions.
La regola pratica: testare sempre con e senza cache, e disattivare il preloading JavaScript se si notano scatti. Al contrario, il preloading HTTP (rel=prefetch, Speculation Rules) resta compatibile e migliora persino la percezione di velocità durante la transizione.
Polylang, che gestisce itamde.com, non crea invece alcun problema. Poiché le transizioni multi-documento funzionano solo nella stessa origine, il passaggio fra le versioni linguistiche beneficia automaticamente dell'animazione, senza configurazione aggiuntiva.
Accessibilità: rispettare prefers-reduced-motion
Un punto troppo spesso dimenticato nelle demo online. Le transizioni animate possono provocare malesseri nelle persone sensibili al movimento, e le WCAG 2.1 AA impongono di rispettare la preferenza di sistema prefers-reduced-motion. Con la View Transitions API è immediato:
@media (prefers-reduced-motion: reduce) {
::view-transition-old(*),
::view-transition-new(*) {
animation: none !important;
}
}Si disattivano le animazioni per gli utenti che ne fanno richiesta, senza rompere la navigazione. Il contenuto appare istantaneamente, come su un sito tradizionale.
Quale impatto sui Core Web Vitals?
Domanda legittima, soprattutto dopo gli aggiustamenti Google di inizio 2026 che hanno rafforzato il peso dell'INP (Interaction to Next Paint). La View Transitions API passa dal compositor del browser, fuori dal thread principale. In pratica, una transizione costruita bene non aumenta né LCP né INP in modo misurabile.
Restano però due insidie. Primo, moltiplicare i view-transition-name su decine di elementi per pagina crea un sovraccarico GPU sui dispositivi modesti — bisogna mirare solo agli elementi davvero significativi (immagini in evidenza, titoli principali), non l'intera pagina. Secondo, animazioni troppo lunghe (oltre i 400 ms) ritardano la percezione di arrivo sulla nuova pagina e frustrano l'utente. La fascia comoda si colloca fra i 200 e i 350 ms.
Cosa cambia nei nostri progetti
Per uno studio come il nostro, la View Transitions API elimina una decisione tecnica spesso dolorosa: bisogna uscire da WordPress e passare a uno stack headless per offrire transizioni moderne? La risposta, nel 2026, è no. Un tema WordPress classico, ben curato, può ora proporre un'esperienza visiva vicina a quella di un'applicazione nativa, senza dipendenze JavaScript aggiuntive.
Lo sforzo di integrazione sta in poche decine di righe di CSS. Il riscontro lato utente è immediato, soprattutto su mobile dove il salto fra due pagine resta la principale rottura percepita. E poiché il degrado è silenzioso, nessun rischio per i visitatori su browser più datati.
Resta un solo limite: la modalità multi-documento non è ancora generalizzata ovunque. Per un sito che mira a un traffico prevalentemente europeo su Chrome, Edge e Safari recenti, la copertura è oggi ampiamente sufficiente. Per un progetto più vasto si combinano view transitions native sui browser compatibili e un fallback semplice altrove — cosa che l'API gestisce già da sola.
0 Commenti