Layout, Paint und Composite: Die Rendering-Pipeline

Nachdem der Renderbaum erstellt wurde, durchläuft der Browser drei Phasen: Layout (Berechnung der Größen und Positionen von Elementen), Paint (Füllen der Pixel mit Farben, Text und Bildern) und Compositing (Zusammenführen der gerenderten Ebenen und Anzeigen auf dem Bildschirm).

Beim Layout wird die Geometrie – Breite, Höhe sowie x/y-Position – für jedes Element berechnet. Änderungen an Eigenschaften, die die Geometrie beeinflussen (width, margin, padding, font-size, position), lösen ein Layout für das Element und möglicherweise seinen gesamten Teilbaum aus – die kostenintensivste Phase.

Beim Paint werden die Pixel jeder Ebene gefüllt: Hintergründe, Rahmen, Text und Schatten. Änderungen an color, background-color, visibility oder border-radius lösen einen Repaint ohne erneutes Layout aus – das ist günstiger als ein Layout, aber bei großen neu zu zeichnenden Bereichen immer noch kostspielig.

Der Compositor führt Ebenen mithilfe der GPU zusammen. CSS-Eigenschaften, die nur das Compositing beeinflussen – transform und opacity –, können animiert werden, ohne Layout oder Paint auszulösen. Die GPU verarbeitet sie mit 60 FPS und minimaler CPU-Beteiligung.

csstriggers.com (heute browserseitige Dokumentation) dokumentiert für jede Browser-Engine, welche CSS-Eigenschaften Layout, Paint und/oder Compositing auslösen. Verwenden Sie die Übersicht, um Animationseigenschaften zu prüfen. Bevorzugen Sie transform und opacity für animierte Eigenschaften.

Layout-Thrashing tritt auf, wenn JavaScript in einer Schleife zwischen dem Lesen von Layout-Eigenschaften (offsetWidth) und dem Schreiben von Style-Eigenschaften wechselt. Jeder Schreibvorgang macht das Layout ungültig; jeder Lesevorgang erzwingt einen synchronen Reflow. Bündeln Sie alle Lesevorgänge vor allen Schreibvorgängen, um Thrashing zu vermeiden.

Nur transform und opacity werden vollständig vom Compositor verarbeitet, wenn sich das Element auf einer eigenen Ebene befindet. Das Animieren jeder anderen Eigenschaft – sogar left/top – löst im Hauptthread ein Layout oder Paint aus und kann zu Ruckeln führen.

Browser verschieben Elemente auf eine eigene GPU-Ebene, wenn sie will-change: transform, eine CSS-Animation für transform/opacity, eine fixe Position mit Compositing-Nachbarn oder eine 3D-Transformation haben. Jede Ebene verwendet GPU-Speicher – zu viele Ebenen führen zu Speicherdruck.

Ein Paint-Sturm tritt auf, wenn in jedem Frame ein großer Teil der Seite neu gezeichnet wird. Erstellen Sie in den Chrome DevTools unter Rendering → Paint flashing ein Profil, um die Bereiche mit Neuzeichnungen zu identifizieren. Isolieren Sie häufig animierte Elemente auf eigenen Ebenen, um den Neuzeichnungsbereich zu begrenzen.

Zeichnen Sie in den Chrome DevTools ein Performance-Profil auf. Das Flammendiagramm zeigt die Ereignisse Layout, Update Layer Tree, Paint und Composite. Lange Layout- oder Paint-Balken weisen auf Engpässe hin. Streben Sie Frame-Zeiten unter 16 ms an, um 60 fps beizubehalten.

Animieren Sie nach Möglichkeit transform und opacity. Verwenden Sie für Reveal-Animationen clip-path statt width/height – clip-path ist in modernen Browsern für den Compositor geeignet. Vermeiden Sie die Animation von box-shadow. Verwenden Sie stattdessen opacity zusammen mit einem Pseudo-Element, das einen vorab gerenderten Schatten enthält.

Welche zwei CSS-Eigenschaften können animiert werden, ohne Layout oder Paint auszulösen?

Die Rendering-Pipeline – Layout, Paint, Composite – bestimmt die Animationsleistung. Layout ist am aufwendigsten, Paint verursacht einen mittleren Aufwand und reine Composite-Eigenschaften (transform, opacity) werden von der GPU verarbeitet. Wenn Sie die Auslöser verstehen, können Sie flüssige Animationen mit 60 fps erstellen, ohne Layout-Thrashing oder Paint-Stürme zu verursachen.