Der Einfluss von CSS View Transitions auf die Web-Performance
Verstehen Sie, warum und wann View Transitions die Web-Performance beeinflussen können

Der Einfluss der View Transition API auf die Performance
Die View Transition API ermöglicht es Entwicklern, flüssige visuelle Übergänge zwischen Ansichten auf derselben Website zu aktivieren, auch für Multi-Page Applications (MPAs). Diese View Transitions werden durch CSS-Übergänge zwischen zwei Seitenansichten gesteuert. Historisch gesehen verursachen CSS-Übergänge beim Seitenladen eine Verzögerung der LCP-Metrik. Wir vermuteten, dass diese Zwischen-Seiten-View-Transitions ebenfalls Performance-Auswirkungen haben, insbesondere auf Mobilgeräten und langsameren CPUs. Unsere Real User Monitoring (RUM)-Daten bestätigten diese Vermutungen, zusammen mit weiteren interessanten Erkenntnissen über die Auswirkungen auf die Core Web Vitals, insbesondere den Largest Contentful Paint (LCP).
Zuletzt überprüft von Arjen Karel im Februar 2026

RUM-Daten-Ergebnisse
Um unsere Idee zu validieren, dass View Transitions den Largest Contentful Paint negativ beeinflussen, haben wir eine Reihe von A/B-Tests auf 5 verschiedenen Websites eingerichtet und diese 7 Tage lang laufen lassen. Bei 50% der Seitenaufrufe fügten wir @view-transition { navigation: auto;} zu den Stylesheets der Seite hinzu, während die anderen 50% der Seitenaufrufe ohne diese Styles ausgeliefert wurden.
Wir sammelten über 500.000 Seitenaufrufe, von denen letztendlich 120.000 mobile Seitenaufrufe analysiert wurden, da sie von mobilen Navigationen innerhalb derselben Website stammten.
Real User Monitoring-Daten haben aufgedeckt, dass die Implementierung der View Transition API ungefähr 70ms zum Largest Contentful Paint für wiederkehrende mobile Seitenaufrufe hinzufügt. Dieser Anstieg der LCP-Zeit ist bemerkenswert, wenn man bedenkt, dass Google empfiehlt, dass LCP innerhalb von 2,5 Sekunden nach Beginn des Seitenladens stattfinden sollte, um eine gute user experience zu gewährleisten.

CPU-Performance-Korrelation
Nachdem wir den negativen Einfluss von View Transitions auf LCP bestätigt hatten, untersuchten wir weiter. Wir führten eine Reihe von Experimenten durch, um automatisch dieselben 2 Seiten mit und ohne View Transitions zu testen. Die Ergebnisse zeigen eine klare Korrelation zwischen CPU-Geschwindigkeit und dem Einfluss von View Transitions auf LCP. Die Erkenntnisse deuten darauf hin, dass je langsamer die CPU, desto ausgeprägter der negative Effekt auf LCP bei Verwendung von View Transitions ist.
| Konfiguration | Mit View Transition | Ohne View Transition | Differenz (ms) |
|---|---|---|---|
| Keine Drosselung + Netzwerk-Caching | 287 ms | 282 ms | 5 ms |
| Keine Drosselung + kein Netzwerk-Caching | 338 ms | 311 ms | 37 ms |
| 6x CPU-Drosselung + Netzwerk-Caching | 527 ms | 523 ms | 4 ms |
| 6x CPU-Drosselung + kein Netzwerk-Caching | 442 ms | 413 ms | 29 ms |
| 20x CPU-Drosselung + Netzwerk-Caching | 756 ms | 716 ms | 40 ms |
| 20x CPU-Drosselung + kein Netzwerk-Caching | 1281 ms | 1204 ms | 77 ms |
Wenn Sie dies selbst testen möchten, besuchen Sie unsere View Transition Experiment-Startseite auf GitHub.
Diese Ergebnisse heben drei wichtige Beobachtungen hervor:
- View Transitions verlangsamen den LCP: Seitenaufrufe mit View Transitions sind langsamer als Seitenaufrufe ohne View Transition-Effekte.
- CPU-Geschwindigkeit ist ein wichtiger Faktor: Die CPU-Geschwindigkeit hat eine hohe Korrelation mit dem LCP-Unterschied bei Ansichten mit und ohne Page Transition-Effekte. Dies ist besonders wichtig für leistungsschwache Mobilgeräte.
- Es gibt einen Performance-"Sweet Spot": Bei 6-facher Drosselung hat LCP ohne Netzwerk-Cache eine bessere Performance. Der einfache Grund ist, dass bei dieser CPU-Geschwindigkeit das LCP-Element ohne Netzwerk-Caching noch nicht dekodiert wurde und der Übergang auf eine leere Seite angewendet wird. Unmittelbar nach dem einfacheren Übergang zu einer leeren Seite wird das LCP-Element gerendert. Offenbar ist dies der Sweet Spot, an dem es effizienter ist, zu einer leeren Seite überzugehen als zwischen Bildern. Aus UX-Perspektive ist es natürlich besser, zwischen Bildern zu überblenden.
Browser-Unterstützung
Die View Transition API erreichte im Oktober 2025 den Status Baseline Newly Available. Same-Document View Transitions funktionieren jetzt in Chrome 111+, Edge 111+, Firefox 144+ und Safari 18+ und decken damit etwa 89% des weltweiten Browser-Traffics ab. Cross-Document View Transitions (die durch @view-transition { navigation: auto; } ausgelöst werden) haben eine etwas geringere Unterstützung, funktionieren aber in allen großen Browsern außer älteren Firefox-Versionen.
Diese breite Unterstützung bedeutet, dass mehr Entwickler View Transitions einsetzen werden, was die Performance-Auswirkungen noch relevanter macht.
@view-transition { navigation: auto; } verstehen
Traditionell erforderte die Implementierung von View Transitions umfangreichen Einsatz von CSS und JavaScript. Die View Transition API vereinfacht diesen Prozess, indem sie Entwicklern ermöglicht, Übergänge deklarativ zu definieren. Die View Transition API funktioniert, indem sie Snapshots des alten und neuen Zustands eines Dokuments erfasst, das DOM aktualisiert, während das Rendering unterdrückt wird, und CSS-Animationen verwendet, um den Übergang auszuführen.
Implementierungsbeispiel
Hier ist ein einfaches Beispiel, wie Sie Cross-Document View Transitions in Ihrem CSS aktivieren:
@view-transition {
navigation: auto;
}
Oder in Kombination mit einer Media Query für Tablet- oder Desktop-Geräte:
@media (min-width: 768px) {
@view-transition {
navigation: auto;
}
}
Diese einfache Ergänzung ermöglicht es dem Browser, den Übergang automatisch zu handhaben, wenn zwischen Seiten desselben Ursprungs navigiert wird.
Barrierefreiheit: prefers-reduced-motion
Nutzer, die reduzierte Bewegung bevorzugen, sollten nicht zu Animationen gezwungen werden. Umschließen Sie Ihre View Transition-Regel mit einer prefers-reduced-motion-Media Query. Dies entfernt auch die LCP-Belastung für diese Nutzer.
@media (prefers-reduced-motion: no-preference) {
@view-transition {
navigation: auto;
}
}
Die LCP-Kosten mit Speculation Rules eliminieren
Der beste Weg, View Transitions ohne die LCP-Belastung zu nutzen, ist sie mit der Speculation Rules API zu kombinieren. Wenn der Browser die nächste Seite vorrendert, bevor der Nutzer klickt, animiert die View Transition zwischen zwei bereits gerenderten Zuständen. Das LCP-Element ist bereits geladen und dekodiert, sodass der Übergang keine messbare Verzögerung hinzufügt. Wenn Ihnen sowohl Ästhetik als auch Performance wichtig sind, ist dies die Kombination, die Sie verwenden sollten.
Empfehlungen
Die View Transition API bietet flüssige und visuell ansprechende Übergänge zwischen Navigationen. Dies kann zu kleinen Vorteilen bei Geschäftsmetriken wie niedrigeren Absprungraten und höherem Engagement führen. Allerdings müssen Entwickler insbesondere auf leistungsschwachen Mobilgeräten die Performance-Auswirkungen sorgfältig abwägen. Hier sind meine Empfehlungen:
- Prüfen Sie zuerst Ihr LCP-Budget. Wenn Ihr mobiler LCP bereits über 2,0 Sekunden liegt, bringt Sie der zusätzliche Transition-Overhead von 70ms näher ans Nichtbestehen. Beheben Sie zuerst LCP, fügen Sie Transitions später hinzu.
- Kombinieren Sie mit Speculation Rules. Das Vorrendern der Zielseite eliminiert die LCP-Kosten von View Transitions vollständig.
- Verwenden Sie prefers-reduced-motion. Das Einschließen von View Transitions in eine Reduced-Motion-Media Query respektiert Nutzerpräferenzen und entfernt die Performance-Kosten für Nutzer, die keine Animationen wünschen.
- Testen Sie mit echten Nutzern. Lab-Tests erfassen nicht die volle Bandbreite der Geräte und Netzwerkbedingungen, die Ihre Besucher verwenden. Führen Sie einen A/B-Test mit CoreDash durch, um den tatsächlichen Einfluss auf Ihren LCP vor und nach der Aktivierung von View Transitions zu messen.
- Erwägen Sie nur Desktop. Unsere Daten zeigen, dass Desktop-Geräte mit schnellen CPUs fast keinen LCP-Einfluss erfahren (5ms). View Transitions über eine
min-width-Media Query auf Desktop zu beschränken, ist ein vernünftiger Kompromiss.
Find out what is actually slow.
I map your critical rendering path using real field data. You get a clear answer on what blocks LCP, what causes INP spikes, and where layout shifts originate.
Book a Deep Dive
