Die Auswirkungen von CSS View Transitions auf die Web-Performance

Die Auswirkungen 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 ermöglichen, sogar für Multi-Page-Applications (MPAs). Diese View Transitions werden durch CSS-Übergänge zwischen 2 Seitenansichten gehandhabt. Historisch gesehen verursachen CSS-Übergänge während des Seitenladens eine Verzögerung der LCP-Metriken. Wir vermuteten, dass diese Arten von Übergängen zwischen Seitenansichten auch Auswirkungen auf die Leistung haben, insbesondere auf mobilen Geräten und langsameren CPUs. Unsere Forschung und Real-User-Monitoring (RUM) Daten haben diesen Verdacht bestätigt, zusammen mit anderen interessanten Einblicken in ihre Auswirkung auf die Core Web Vitals, insbesondere den Largest Contentful Paint (LCP).

>

RUM-Daten-Ergebnisse

Um unsere Idee zu validieren, dass View-Transition den Largest Contentful Paint negativ beeinflusst, 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 schließlich 120.000 mobile Seitenaufrufe analysiert wurden, da sie aus 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 wiederholte mobile Seitenaufrufe hinzufügt. Dieser Anstieg der LCP-Zeit ist bemerkenswert, wenn man Googles Empfehlung berücksichtigt, dass LCP innerhalb von 2,5 Sekunden auftreten sollte, nachdem die Seite erstmals geladen wurde, um eine gute Benutzererfahrung zu gewährleisten.

CPU-Performance-Korrelation

Nachdem wir die negativen Auswirkungen von View Transitions auf LCP bestätigt hatten, untersuchten wir weiter. Wir gingen dazu über, eine Reihe von Experimenten einzurichten, um automatisch dieselben 2 Seiten mit und ohne View-Transitions zu testen. Die Ergebnisse zeigen eine klare Korrelation zwischen CPU-Geschwindigkeit und der Auswirkung von View Transitions auf LCP. Die Ergebnisse zeigen an, dass je langsamer die CPU ist, desto ausgeprägter ist der negative Effekt auf LCP bei der Verwendung von View Transitions

Konfiguration	Mit View Transition	Ohne View Transition	Unterschied (ms)
Keine Drosselung + Netzwerk-Caching	287 ms	282 ms	5 ms
Keine Drosselung + kein Netzwerk-Caching	338 ms	311 ms	37 ms
6x CPU-Verlangsamung + Netzwerk-Caching	527 ms	523 ms	4 ms
6x CPU-Verlangsamung + kein Netzwerk-Caching	442 ms	413 ms	29 ms
20x CPU-Verlangsamung + Netzwerk-Caching	756 ms	716 ms	40 ms
20x CPU-Verlangsamung + kein Netzwerk-Caching	1281 ms	1204 ms	77 ms

Wenn Sie dies selbst testen möchten, besuchen Sie unsere [url=https://corewebvitals.github.io/view-transition/]View Transition Experiment Homepage[/url] auf github

Diese Ergebnisse heben drei Schlüsselbeobachtungen hervor:

• View Transitions verlangsamen den LCP: Seitenaufrufe mit View Transitions sind langsamer als Seitenaufrufe ohne View-Transition-Effekte.
• CPU-Geschwindigkeit ist ein wichtiger Faktor: CPU-Geschwindigkeit hat eine hohe Korrelation mit dem LCP-Unterschied in Ansichten mit und ohne Seitenübergangseffekte
• Es gibt einen Pagespeed 'Sweet Spot': Bei 6x Verlangsamung hat LCP eine bessere Leistung ohne Netzwerk-Cache. 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 gemalt. Anscheinend ist dies der Sweet Spot, wo es effizienter ist, zu einer leeren Seite überzugehen, als zwischen Bildern überzugehen. Aus UX-Perspektive ist es natürlich besser, zwischen Bildern überzugehen.

Verständnis von view-transition: navigation: auto;

Traditionell erforderte die Implementierung von View Transitions umfangreiche Verwendung 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 Schnappschüsse der alten und neuen Zustände eines Dokuments aufnimmt, das DOM aktualisiert, während das Rendering unterdrückt wird, und CSS-Animationen verwendet, um den Übergang auszuführen.

Implementierungsbeispiel

Hier ist ein grundlegendes Beispiel, wie man view-transition-name: auto in Ihrem CSS verwendet:

@view-transition {
  navigation: auto;
}

Oder in Kombination mit einer Media Query, um Tablet- oder Desktop-Geräte anzusprechen:

@media (min-width: 768px){
  @view-transition{
    navigation:auto
  }
}

Diese einfache Ergänzung ermöglicht es dem Browser, den Übergang dieses Elements automatisch zu handhaben, wenn eine View Transition auftritt.

Ästhetik und Leistung ausbalancieren

Die View Transition API bietet flüssige und möglicherweise visuell ansprechende Übergänge zwischen Navigationen. Dies könnte zu kleinen Vorteilen bei Geschäftskennzahlen wie niedrigeren Absprungraten und möglicherweise höheren Verkäufen führen. Jedoch, insbesondere auf Low-End-Browsern wie Mobilgeräten, müssen Entwickler sorgfältig ihre Leistungs implikationen berücksichtigen. Hier sind meine Empfehlungen:

• Leistungstests: Führen Sie gründliche Tests auf verschiedenen Geräten und Netzwerkbedingungen durch, um sicherzustellen, dass die Vorteile von View Transitions mögliche Leistungskosten überwiegen.
• Selektive Implementierung: Seien Sie vorsichtig bei der Anwendung von View-Transitions. Testen Sie ihre Wirkung auf Leistung und Geschäftskennzahlen. Überlegen Sie dann sorgfältig, auf welchen Gerätetypen Sie View Transitions implementieren.