De impact van CSS View Transitions op webprestaties
Begrijp waarom en wanneer view transitions de webprestaties kunnen beïnvloeden

De impact van de View Transition API op prestaties
De View Transition API stelt ontwikkelaars in staat om vloeiende visuele overgangen tussen weergaven op dezelfde site mogelijk te maken, zelfs voor multi-page applications (MPA's). Deze view transitions worden afgehandeld door CSS-transities tussen twee paginaweergaven. Historisch gezien veroorzaken CSS-transities tijdens het laden van de pagina een vertraging in de LCP-metric. We vermoedden dat deze tussenliggende view transitions ook prestatie-implicaties hebben, met name op mobiele apparaten en tragere CPU's. Onze Real User Monitoring (RUM) data bevestigden deze vermoedens, samen met andere interessante inzichten in het effect op Core Web Vitals, met name de Largest Contentful Paint (LCP).
Laatst beoordeeld door Arjen Karel in februari 2026

Bevindingen uit RUM-data
Om ons idee te valideren dat view transitions een negatieve invloed hebben op de Largest Contentful Paint, hebben we een reeks A/B-tests opgezet op 5 verschillende sites en deze 7 dagen laten draaien. Bij 50% van de paginaweergaven voegden we @view-transition { navigation: auto;} toe aan de stylesheets van de pagina, terwijl de andere 50% van de paginaweergaven zonder deze stijlen werd geserveerd.
We verzamelden meer dan 500.000 paginaweergaven, waarvan uiteindelijk 120.000 mobiele paginaweergaven werden geanalyseerd omdat ze afkomstig waren van mobiele navigaties binnen dezelfde site.
Real-user monitoring data heeft aangetoond dat het implementeren van de View Transition API ongeveer 70ms toevoegt aan de Largest Contentful Paint voor herhaalde mobiele paginaweergaven. Deze toename in LCP-tijd is noemenswaardig, gezien de aanbeveling van Google dat LCP binnen 2,5 seconden na het begin van het laden van de pagina moet plaatsvinden voor een goede user experience.

Correlatie met CPU-prestaties
Na het bevestigen van de negatieve impact van view transitions op LCP, hebben we verder onderzocht. We hebben een reeks experimenten opgezet om automatisch dezelfde 2 pagina's te testen met en zonder view transitions. De resultaten tonen een duidelijke correlatie tussen CPU-snelheid en de impact van view transitions op LCP. De bevindingen geven aan dat hoe trager de CPU, hoe sterker het negatieve effect op LCP bij het gebruik van view transitions.
| Configuratie | Met View Transition | Zonder View Transition | Verschil (ms) |
|---|---|---|---|
| Geen throttling + netwerkcaching | 287 ms | 282 ms | 5 ms |
| Geen throttling + geen netwerkcaching | 338 ms | 311 ms | 37 ms |
| 6x CPU-vertraging + netwerkcaching | 527 ms | 523 ms | 4 ms |
| 6x CPU-vertraging + geen netwerkcaching | 442 ms | 413 ms | 29 ms |
| 20x CPU-vertraging + netwerkcaching | 756 ms | 716 ms | 40 ms |
| 20x CPU-vertraging + geen netwerkcaching | 1281 ms | 1204 ms | 77 ms |
Als je dit zelf wilt testen, bezoek dan onze view transition experiment homepage op GitHub.
Deze resultaten benadrukken drie belangrijke observaties:
- View transitions vertragen de LCP: Paginaweergaven met view transitions zijn trager dan paginaweergaven zonder view transition-effecten.
- CPU-snelheid is een belangrijke factor: CPU-snelheid heeft een hoge correlatie met het LCP-verschil bij weergaven met en zonder paginatransitie-effecten. Dit is vooral belangrijk voor low-end mobiele apparaten.
- Er is een 'sweet spot' voor paginasnelheid: Bij 6x vertraging heeft LCP betere prestaties zonder netwerkcache. De simpele reden is dat bij deze CPU-snelheid het LCP-element nog niet is gedecodeerd zonder netwerkcaching en de transitie wordt toegepast op een lege pagina. Direct na de eenvoudigere transitie naar een lege pagina wordt het LCP-element geschilderd. Blijkbaar is dit de sweet spot waar het efficiënter is om naar een lege pagina over te gaan dan om tussen afbeeldingen over te gaan. Vanuit een UX-perspectief is het natuurlijk beter om tussen afbeeldingen over te gaan.
Browserondersteuning
De View Transition API bereikte de Baseline Newly Available-status in oktober 2025. Same-document view transitions werken nu in Chrome 111+, Edge 111+, Firefox 144+ en Safari 18+, wat ongeveer 89% van het wereldwijde browserverkeer dekt. Cross-document view transitions (degene die worden geactiveerd door @view-transition { navigation: auto; }) hebben iets beperktere ondersteuning maar werken in alle grote browsers behalve oudere Firefox-versies.
Deze brede ondersteuning betekent dat meer ontwikkelaars view transitions zullen adopteren, waardoor de prestatie-implicaties nog relevanter worden.
@view-transition { navigation: auto; } begrijpen
Traditioneel vereiste het implementeren van view transitions uitgebreid gebruik van CSS en JavaScript. De View Transition API vereenvoudigt dit proces door ontwikkelaars in staat te stellen transities declaratief te definiëren. De View Transition API werkt door snapshots vast te leggen van de oude en nieuwe staat van een document, de DOM bij te werken terwijl rendering wordt onderdrukt, en CSS-animaties te gebruiken om de transitie uit te voeren.
Implementatievoorbeeld
Hier is een basisvoorbeeld van hoe je cross-document view transitions kunt inschakelen in je CSS:
@view-transition {
navigation: auto;
}
Of in combinatie met een media query om tablet- of desktopapparaten te targeten:
@media (min-width: 768px) {
@view-transition {
navigation: auto;
}
}
Deze eenvoudige toevoeging zorgt ervoor dat de browser de transitie automatisch afhandelt bij het navigeren tussen pagina's op dezelfde origin.
Toegankelijkheid: prefers-reduced-motion
Gebruikers die de voorkeur geven aan verminderde beweging mogen niet gedwongen worden door animaties. Wikkel je view transition-regel in een prefers-reduced-motion media query. Dit verwijdert ook de LCP-penalty voor die gebruikers.
@media (prefers-reduced-motion: no-preference) {
@view-transition {
navigation: auto;
}
}
De LCP-kosten elimineren met Speculation Rules
De beste manier om view transitions te gebruiken zonder de LCP-penalty is ze te combineren met de Speculation Rules API. Wanneer de browser de volgende pagina prerendert voordat de gebruiker klikt, animeert de view transition tussen twee reeds gerenderde staten. Het LCP-element is al geladen en gedecodeerd, dus de transitie voegt geen meetbare vertraging toe. Als je om zowel esthetiek als prestaties geeft, is dit de combinatie die je moet gebruiken.
Aanbevelingen
De View Transition API biedt vloeiende en visueel aangename transities tussen navigaties. Dit kan leiden tot kleine voordelen in bedrijfsmetrics zoals lagere bouncepercentages en hogere betrokkenheid. Echter, vooral op low-end mobiele apparaten, moeten ontwikkelaars de prestatie-implicaties zorgvuldig overwegen. Dit zijn mijn aanbevelingen:
- Controleer eerst je LCP-budget. Als je mobiele LCP al boven de 2,0 seconden ligt, brengt het toevoegen van 70ms transitie-overhead je dichter bij het falen. Los eerst LCP op, voeg daarna transities toe.
- Combineer met Speculation Rules. Het prerenderen van de bestemmingspagina elimineert de LCP-kosten van view transitions volledig.
- Gebruik prefers-reduced-motion. Het inpakken van view transitions in een reduced motion media query respecteert gebruikersvoorkeuren en verwijdert de prestatiekosten voor gebruikers die geen animaties willen.
- Test met echte gebruikers. Labtests vangen niet het volledige scala aan apparaten en netwerkomstandigheden op dat je bezoekers gebruiken. Voer een A/B-test uit met CoreDash om de daadwerkelijke impact op je LCP te meten voor en na het inschakelen van view transitions.
- Overweeg alleen desktop. Onze data toont aan dat desktopapparaten met snelle CPU's vrijwel geen LCP-impact ervaren (5ms). Het beperken van view transitions tot desktop via een
min-widthmedia query is een redelijk compromis.
Search Console flagged your site?
When Google flags your Core Web Vitals you need a clear diagnosis fast. I deliver a prioritized fix list within 48 hours.
Request Urgent Audit
