L'impatto delle CSS View Transitions sulle prestazioni web
Comprendi perché e quando le view transitions possono influire sulle prestazioni web

L'impatto della View Transition API sulle prestazioni
La View Transition API consente agli sviluppatori di abilitare transizioni visive fluide tra le viste sullo stesso sito, anche per le applicazioni multipagina (MPA). Queste view transitions sono gestite da transizioni CSS tra due viste di pagina. Storicamente, le transizioni CSS durante il caricamento della pagina causano un ritardo nella metrica LCP. Sospettavamo che queste view transitions tra le pagine avessero implicazioni sulle prestazioni, in particolare sui dispositivi mobili e sulle CPU più lente. I nostri dati di Real User Monitoring (RUM) hanno confermato questi sospetti, insieme ad altre interessanti osservazioni sull'effetto sui Core Web Vitals, in particolare il Largest Contentful Paint (LCP).
Ultima revisione di Arjen Karel a febbraio 2026

Risultati dei dati RUM
Per validare la nostra idea che le view transitions influiscano negativamente sul Largest Contentful Paint, abbiamo configurato una serie di test A/B su 5 siti diversi e li abbiamo lasciati in esecuzione per 7 giorni. Sul 50% delle visualizzazioni di pagina abbiamo aggiunto @view-transition { navigation: auto;} ai fogli di stile della pagina, mentre l'altro 50% delle visualizzazioni di pagina è stato servito senza questi stili.
Abbiamo raccolto oltre 500.000 visualizzazioni di pagina, di cui alla fine 120.000 visualizzazioni mobili sono state analizzate perché originate da navigazioni mobili all'interno dello stesso sito.
I dati di Real User Monitoring hanno rivelato che l'implementazione della View Transition API aggiunge circa 70ms al Largest Contentful Paint per le visualizzazioni mobili ripetute. Questo aumento nel tempo di LCP è degno di nota, considerando la raccomandazione di Google secondo cui il LCP dovrebbe verificarsi entro 2,5 secondi dall'inizio del caricamento della pagina per una buona user experience.

Correlazione con le prestazioni della CPU
Dopo aver confermato l'impatto negativo delle view transitions sul LCP, abbiamo approfondito l'indagine. Abbiamo configurato una serie di esperimenti per testare automaticamente le stesse 2 pagine con e senza view transitions. I risultati mostrano una chiara correlazione tra la velocità della CPU e l'impatto delle view transitions sul LCP. I risultati indicano che più lenta è la CPU, più pronunciato è l'effetto negativo sul LCP quando si utilizzano le view transitions.
| Configurazione | Con View Transition | Senza View Transition | Differenza (ms) |
|---|---|---|---|
| Nessun throttling + cache di rete | 287 ms | 282 ms | 5 ms |
| Nessun throttling + senza cache di rete | 338 ms | 311 ms | 37 ms |
| Rallentamento CPU 6x + cache di rete | 527 ms | 523 ms | 4 ms |
| Rallentamento CPU 6x + senza cache di rete | 442 ms | 413 ms | 29 ms |
| Rallentamento CPU 20x + cache di rete | 756 ms | 716 ms | 40 ms |
| Rallentamento CPU 20x + senza cache di rete | 1281 ms | 1204 ms | 77 ms |
Se desideri testarlo tu stesso, visita la nostra homepage dell'esperimento sulle view transition su GitHub.
Questi risultati evidenziano tre osservazioni chiave:
- Le view transitions rallentano il LCP: Le visualizzazioni di pagina con view transitions sono più lente rispetto alle visualizzazioni senza effetti di view transition.
- La velocità della CPU è un fattore importante: La velocità della CPU ha un'alta correlazione con la differenza di LCP nelle visualizzazioni con e senza effetti di transizione di pagina. Questo è particolarmente importante per i dispositivi mobili di fascia bassa.
- Esiste uno 'sweet spot' per la velocità della pagina: Con un rallentamento di 6x, il LCP ha prestazioni migliori senza cache di rete. La ragione semplice è che a questa velocità della CPU l'elemento LCP non è ancora stato decodificato senza cache di rete e la transizione viene applicata a una pagina vuota. Immediatamente dopo la transizione più semplice verso una pagina vuota, l'elemento LCP viene dipinto. Apparentemente questo è lo sweet spot in cui è più efficiente fare la transizione verso una pagina vuota che fare la transizione tra immagini. Dal punto di vista della UX è ovviamente meglio fare la transizione tra immagini.
Supporto dei browser
La View Transition API ha raggiunto lo stato Baseline Newly Available nell'ottobre 2025. Le view transitions dello stesso documento ora funzionano in Chrome 111+, Edge 111+, Firefox 144+ e Safari 18+, coprendo circa l'89% del traffico globale dei browser. Le view transitions tra documenti (quelle attivate da @view-transition { navigation: auto; }) hanno un supporto leggermente più ristretto ma funzionano in tutti i principali browser tranne le versioni più vecchie di Firefox.
Questo ampio supporto significa che più sviluppatori adotteranno le view transitions, rendendo le implicazioni sulle prestazioni ancora più rilevanti.
Comprendere @view-transition { navigation: auto; }
Tradizionalmente, l'implementazione delle view transitions richiedeva un uso estensivo di CSS e JavaScript. La View Transition API semplifica questo processo consentendo agli sviluppatori di definire le transizioni in modo dichiarativo. La View Transition API funziona catturando istantanee degli stati vecchio e nuovo di un documento, aggiornando il DOM sopprimendo il rendering e utilizzando animazioni CSS per eseguire la transizione.
Esempio di implementazione
Ecco un esempio base di come abilitare le view transitions tra documenti nel tuo CSS:
@view-transition {
navigation: auto;
}
Oppure in combinazione con una media query per dispositivi tablet o desktop:
@media (min-width: 768px) {
@view-transition {
navigation: auto;
}
}
Questa semplice aggiunta consente al browser di gestire automaticamente la transizione durante la navigazione tra pagine della stessa origin.
Accessibilità: prefers-reduced-motion
Gli utenti che preferiscono il movimento ridotto non dovrebbero essere costretti a subire animazioni. Avvolgi la tua regola di view transition in una media query prefers-reduced-motion. Questo rimuove anche la penalità LCP per quegli utenti.
@media (prefers-reduced-motion: no-preference) {
@view-transition {
navigation: auto;
}
}
Eliminare il costo LCP con le Speculation Rules
Il modo migliore per utilizzare le view transitions senza la penalità LCP è combinarle con la Speculation Rules API. Quando il browser esegue il prerender della pagina successiva prima che l'utente faccia clic, la view transition anima tra due stati già renderizzati. L'elemento LCP è già caricato e decodificato, quindi la transizione non aggiunge alcun ritardo misurabile. Se ti interessano sia l'estetica che le prestazioni, questa è la combinazione da utilizzare.
Raccomandazioni
La View Transition API offre transizioni fluide e visivamente piacevoli tra le navigazioni. Questo può portare a piccoli benefici nelle metriche di business come tassi di rimbalzo più bassi e maggiore engagement. Tuttavia, specialmente sui dispositivi mobili di fascia bassa, gli sviluppatori devono considerare attentamente le implicazioni sulle prestazioni. Ecco le mie raccomandazioni:
- Controlla prima il tuo budget LCP. Se il tuo LCP mobile è già sopra i 2,0 secondi, aggiungere 70ms di overhead per la transizione ti avvicina al fallimento. Correggi prima il LCP, aggiungi le transizioni dopo.
- Combina con le Speculation Rules. Il prerendering della pagina di destinazione elimina completamente il costo LCP delle view transitions.
- Usa prefers-reduced-motion. Avvolgere le view transitions in una media query di movimento ridotto rispetta le preferenze degli utenti e rimuove il costo prestazionale per gli utenti che non desiderano animazioni.
- Testa con utenti reali. I test di laboratorio non catturano l'intera gamma di dispositivi e condizioni di rete utilizzati dai tuoi visitatori. Esegui un test A/B con CoreDash per misurare l'impatto reale sul tuo LCP prima e dopo l'abilitazione delle view transitions.
- Considera solo il desktop. I nostri dati mostrano che i dispositivi desktop con CPU veloci subiscono quasi nessun impatto sul LCP (5ms). Limitare le view transitions al desktop tramite una media query
min-widthè un compromesso ragionevole.
Pinpoint the route, device, and connection that fails.
CoreDash segments every metric by route, device class, browser, and connection type. Real time data. Not the 28 day average Google gives you.
Explore Segmentation
