Web-Farb-Performance: Verläufe, Schatten und Filter

Farbe in CSS ist nicht kostenlos. Jeder gemalte Pixel auf einer Webseite kostet Rechenzyklen — entweder auf der CPU, wo der Haupt-Thread Layout- und Malvorgänge ausführt, oder auf der GPU, wo Compositing und bestimmte visuelle Effekte verarbeitet werden. In den meisten Fällen sind die Kosten vernachlässigbar und werden nie auffallen. Doch wenn Designs anspruchsvoller werden — mit mehrschichtigen Verläufen, mehreren Box-Schatten, CSS-Filtern und Backdrop-Unschärfen — häufen sich diese Kosten auf. Auf leistungsschwächerer mobiler Hardware kann der Unterschied zwischen einem Design mit durchdachtem Farb-Rendering und einem, das diese Kosten ignoriert, der Unterschied zwischen einer flüssigen 60-fps-Erfahrung und einem ruckelnden, akkufressenden Interface sein.

Dieser Leitfaden vermittelt ein entwicklerorientiertes Verständnis davon, wie Browser Farbe verarbeiten, welche farbbezogenen CSS-Eigenschaften teuer sind und warum, was „GPU-Beschleunigung" in der Praxis tatsächlich bedeutet und welche spezifischen Muster Rendering-Engpässe erzeugen — zusammen mit praktischen Alternativen, die die visuelle Absicht bewahren und gleichzeitig die Performancekosten reduzieren.

Wie Browser Farbe rendern

Um zu verstehen, warum einige Farbeffekte teuer sind, muss man die Rendering-Pipeline des Browsers verstehen. Moderne Browser (Chromium, Firefox, Safari/WebKit) verarbeiten eine Seite durch mehrere Stufen, bevor Pixel auf dem Bildschirm erscheinen.

Die Rendering-Pipeline

1. Style-Neuberechnung: Der Browser berechnet, welche CSS-Regeln auf jedes Element zutreffen, und ermittelt ihre endgültigen berechneten Werte (die Kaskaden-, Spezifitäts- und Vererbungsphase).

2. Layout: Der Browser berechnet Größe und Position jedes Elements auf der Seite — das Box-Modell, Flexbox, Grid, Flow-Positionierung.

3. Rendering (Paint): Der Browser rastert jedes Element in Pixel-Bitmaps. Hier werden Farbe, Verläufe, Schatten, Rahmen und Hintergründe gezeichnet. Das Rendering erfolgt standardmäßig auf der CPU.

4. Compositing: Der Browser setzt die gerenderten Ebenen zu einem endgültigen Bild zusammen, das an das Display gesendet wird. Wenn bestimmte Elemente zu eigenen Compositor-Ebenen befördert wurden (siehe GPU-Beschleunigung unten), erfolgt das Compositing auf der GPU.

Zentrale Performance-Erkenntnis: Layout und Rendering sind die teuren Phasen. Compositing ist vergleichsweise günstig, da es auf bereits rasterisierten Bitmaps mit der parallelen Pixelverarbeitungshardware der GPU arbeitet. Das Ziel der Performance-Optimierung ist es, Rendering zu minimieren und Animationen in der Compositing-Phase zu halten, anstatt bei jedem Frame ein Rendering zu erfordern.

Rendering- vs. Compositing-Eigenschaften

CSS-Eigenschaften lassen sich nach der Pipeline-Phase kategorisieren, die sie beim Ändern beeinflussen:

Eigenschaften, die beim Ändern Layout + Rendering + Compositing erfordern: width, height, margin, padding, font-size, border-width. Diese sollten nicht animiert werden.

Eigenschaften, die beim Ändern Rendering + Compositing erfordern: color, background-color, border-color, box-shadow, outline, background-image (Verläufe). Diese überspringen die Layout-Neuberechnung, erfordern aber dennoch, dass der Browser Pixel neu rendert.

Eigenschaften, die nur Compositing erfordern: transform, opacity. Änderungen an diesen Eigenschaften — einschließlich Translation, Rotation, Skalierung und Einblendung — können vollständig vom GPU-Compositor verarbeitet werden, ohne die CPU-Rendering-Pipeline zu berühren. Deshalb sind CSS-Transform-Animationen immer der bevorzugte Ansatz für Bewegung.

Wenn du einen box-shadow oder einen Verlauf über CSS-Transitions animierst, muss der Browser das Element bei jedem Frame neu rendern — ein CPU-gebundener Vorgang, der mit der JavaScript-Ausführung im Haupt-Thread konkurriert. Auf einem leistungsschwächeren Gerät, das mehrere Animationen gleichzeitig ausführt, werden hier Frames fallen gelassen.

Rendering-Performance von Verläufen

CSS-Verläufe gehören zu den häufigsten farbbezogenen Performance-Überlegungen im modernen Webdesign. Sie erscheinen in Hintergründen, Schaltflächenzuständen, Overlays, Hero-Bereichen und zunehmend als dezente Texturelemente. Das Verständnis ihrer Rendering-Kosten verhindert übermäßige Nutzung.

Wie Verläufe gerendert werden

Jeder CSS-Verlauf — linear, radial, konisch oder ihre sich wiederholenden Varianten — wird von der CPU während der Rendering-Phase rasteriert. Der Browser berechnet den Farbwert jedes Pixels innerhalb des Bounding Box des Elements und interpoliert dabei zwischen den Farbstopps des Verlaufs im Farbraum des Verlaufs. Diese Berechnung erfolgt bei jedem Rendering des Elements.

Für einen einfachen, stabilen Verlaufshintergrund auf einem nicht animierenden Element werden diese Kosten einmalig bezahlt und das Ergebnis zwischengespeichert. Performance-Probleme entstehen, wenn Verläufe:

• Animiert werden (der Verlaufswert ändert sich bei jedem Frame)
• Auf sehr großen Elementen angewendet werden (mehr Pixel = mehr Berechnung)
• Mehrfach überlagert werden (mehrere Verlaufshintergründe oder Verläufe auf mehreren gestapelten Elementen)
• In Kombination mit anderen teuren Eigenschaften auf demselben Element verwendet werden

Die Kosten der Verlaufsanimation

Das Animieren eines Verlaufs mit CSS-Transitions oder Keyframe-Animationen erzwingt bei jedem Frame ein Rendering-Vorgang. Das liegt daran, dass background-image (die Eigenschaft, die Verläufe enthält) eine Rendering-Phasen-Eigenschaft ohne Compositor-Abkürzung ist.

Teuer — für 60-fps-Animationen vermeiden:

/* Erzwingt CPU-Rendering bei jedem Frame */
@keyframes shimmer {
  from { background: linear-gradient(90deg, #f0f0f0 0%, #e0e0e0 50%, #f0f0f0 100%); }
  to { background: linear-gradient(90deg, #e0e0e0 0%, #f0f0f0 50%, #e0e0e0 100%); }
}

Besser — stattdessen den Transform eines Pseudo-Elements animieren:

.shimmer-container {
  position: relative;
  overflow: hidden;
  background: #f0f0f0;
}

.shimmer-container::after {
  content: '';
  position: absolute;
  inset: 0;
  background: linear-gradient(90deg, transparent 0%, rgba(255,255,255,0.6) 50%, transparent 100%);
  /* Das Animieren von Transform löst nur Compositing aus, kein Rendering */
  transform: translateX(-100%);
  animation: shimmer 1.5s infinite;
}

@keyframes shimmer {
  to { transform: translateX(200%); }
}

Die Pseudo-Element-Technik erstellt den Verlauf einmalig und bewegt ihn dann mit transform, was in der Compositing-Phase bleibt. Das visuelle Ergebnis ist identisch; die Performancekosten sind dramatisch geringer, da bei keinem Animationsframe ein Rendering stattfindet.

Große Verlaufsflächen

Ein Verlauf, der den gesamten Viewport auf einem 4K-Display abdeckt, bedeutet das Interpolieren von Farben über ungefähr 8 Millionen Pixel. Auf einem M-Series Mac ist das trivial. Auf einem Budget-Android-Gerät kann das Rendern eines vollseitigen Verlaufs mehrere Millisekunden dauern — und wenn dieses Element jemals neu gerendert wird (aufgrund eines Scrolls, einer Größenänderung oder einer DOM-Änderung in der Nähe), werden diese Kosten wiederholt bezahlt.

Maßnahmen für große Verlaufsflächen: - Das Verlaufselement mit will-change: transform in eine eigene Ebene befördern, wenn es während der Interaktion nicht neu gerendert wird - Ein kleines Verlaufs-Hintergrundbild (über background-image: url()) anstelle eines CSS-Verlaufs verwenden, wenn der Verlauf statisch ist — Rasterbilder sind bei sehr großen Größen generell günstiger zu rendern als berechnete Verläufe - Für vollseitige Verläufe, die die Seitenästhetik definieren, sie auf dem body oder einem Wrapper-Element setzen und sicherstellen, dass nichts ihr Rendering während der Interaktion auslöst

Verlaufsfarb-Interpolation: sRGB vs. OKLCH

CSS-Verläufe können Farben jetzt in verschiedenen Farbräumen mit der in-Syntax interpolieren:

background: linear-gradient(in oklch, #FF5733, #3355FF);
background: linear-gradient(in sRGB, #FF5733, #3355FF);
background: linear-gradient(in hsl, #FF5733, #3355FF);

OKLCH-Interpolation erzeugt wahrnehmungsuniforme Verläufe — der Mittelpunkt sieht wirklich wie der Mittelpunkt zwischen den beiden Farben aus, wie die menschliche Wahrnehmung sie erlebt, ohne den desaturierten „Grauschlamm"-Übergang, den sRGB-Interpolation bei bestimmten Farbtonpaaren erzeugt. ColorFYIs Verlaufsgenerator erzeugt CSS-Verlaufscode, den du mit Farbraum-Spezifikationen anpassen kannst.

Aus Performance-Sicht beeinflusst der Farbinterpolationsraum die Rasterisierungskosten nicht wesentlich — die CPU berechnet die Zwischenfarben anders, aber die Pixelanzahl ist dieselbe. Wähle den Interpolationsraum nach visueller Qualität, nicht nach Performance.

Box-Shadow-Kosten und Alternativen

box-shadow ist eine der visuell ubiquitärsten CSS-Eigenschaften und auch eine der teureren zu rendern. Das Verständnis, was ihn kostspielig macht und wann Alternativen verwendet werden sollten, ist praktisches Wissen für performance-sensibles UI-Design.

Warum Box-Shadow teuer ist

Ein box-shadow rendert eine verschwommene, versetzte Kopie der Form des Elements. Der Unschärfe-Algorithmus arbeitet Pixel für Pixel in einem Bereich, der über die Grenzen des Elements hinausgeht (der Unschärferadius in jede Richtung). Ein box-shadow mit einem großen Unschärferadius — box-shadow: 0 20px 60px rgba(0,0,0,0.3) — verwischt über einen Radius von 60 px und dehnt den gerenderten Bereich erheblich über das sichtbare Element hinaus aus.

Kostenfaktoren: - Unschärferadius: Größere Unschärfe = mehr Pixel, die während der Unschärfeberechnung verarbeitet werden. Die Rechenkosten skalieren mit dem Unschärferadius. - Spread: Erhöht die Schatten-Größe und vergrößert damit den zu verarbeitenden Pixelbereich. - Mehrere Schatten: box-shadow akzeptiert kommagetrennte Mehrfachwerte. Drei Box-Schatten kosten ungefähr dreimal so viel wie einer. - Große Elemente: Ein vollbreiter Container mit einem großen Box-Schatten kann einen erheblichen Viewport-Bereich abdecken.

Wann Box-Shadow problematisch wird

Ein einzelnes box-shadow: 0 2px 8px rgba(0,0,0,0.15) auf einer Standard-Card-Komponente ist im Wesentlichen kostenlos. Die Kosten werden spürbar, wenn:

• Viele Elemente mit großen Box-Schatten gleichzeitig im Viewport vorhanden sind
• Ein Element mit einem großen Box-Schatten häufig neu gerendert wird (durch Hover-Zustände, scroll-getriebene Layout-Änderungen oder dynamische Inhalte)
• Box-Schatten über JavaScript oder CSS-Transitions animiert werden (jeder Frame erfordert ein Rendering)

Alternativen zu Box-Shadow

Filter Drop-Shadow: Für nicht-rechteckige Elemente (insbesondere SVG-Icons oder Bilder mit Transparenz) wendet filter: drop-shadow() den Schatten auf die tatsächlich sichtbaren Pixel anstatt auf den Bounding Box an — was ein visuell genaueres Ergebnis erzeugt. Die Performance ist ähnlich wie bei box-shadow, aber bei nicht-rechteckigem Inhalt ist der gerenderte Bereich kleiner.

Pseudo-Element-Schatten: Einen Schatten mit einem ::after-Pseudo-Element mit einem Verlaufshintergrund in der Schattenfarbe erstellen, absolut hinter dem Element positioniert. Dieses Pseudo-Element kann zu seiner eigenen Compositor-Ebene befördert werden und erzwingt bei Zustandsänderungen kein Rendering des Hauptelements.

.card {
  position: relative;
}

.card::after {
  content: '';
  position: absolute;
  inset: 10px 0 -10px;
  background: radial-gradient(ellipse at center, rgba(0,0,0,0.25) 0%, transparent 70%);
  z-index: -1;
  /* Stabiles Element — einmalig gerendert, günstig composited */
}

Rahmen und Outline anstelle von Elevationsschatten: Für UI-Elemente, die Schatten primär zur Anzeige von Interaktivität oder Auswahlzustand verwenden (nicht zur visuellen Elevation), ist eine dezente border- oder outline-Farbänderung ein erheblich günstigerer Rendering-Vorgang als das Hinzufügen oder Ändern eines box-shadow bei Hover.

CSS-Filter-Performance

CSS filter wendet pixelbasierte Bildverarbeitung — Unschärfe, Helligkeit, Kontrast, Sättigung, Farbtonrotation und andere — auf ein Element und seinen Inhalt an. Im Gegensatz zu den meisten CSS-Eigenschaften werden Filter nach dem Rendern des Elements angewendet und arbeiten auf den rasterisierten Pixeln.

Filter ist grundsätzlich teuer

Jede Filteroperation verarbeitet jeden Pixel im Bounding Box des Elements (und bei Unschärfe einen Bereich darüber hinaus). Das ist eine erhebliche CPU-Berechnung und erfolgt zur Rendering-Zeit.

Spezifische Filterkosten: - blur(): Bei weitem der teuerste Filter. Der Gaußsche Unschärfe-Algorithmus besucht jeden Pixel mehrfach mit einem Kernel, der mit dem Unschärferadius skaliert. Große Unschärfe auf einem großen Element ist eines der teuersten Dinge, die man in CSS tun kann. - brightness(), contrast(), saturate(), opacity(): Pixel-für-Pixel-Transformationen, aber einzeln — viel günstiger als Unschärfe, ungefähr proportional zur Pixelfläche des Elements. - hue-rotate(): Ebenfalls relativ günstig — eine Farbmatrix-Multiplikation pro Pixel. - drop-shadow(): Teuer aus denselben Gründen wie Unschärfe (der Schatten ist eine verwischte Kopie).

GPU-Beschleunigung für Filter

Browser werden filter-Operationen unter bestimmten Bedingungen GPU-beschleunigen — insbesondere wenn das Element bereits eine Compositor-Ebene hat oder wenn der Filter mit einem Transform kombiniert wird. Dies ist jedoch nicht garantiert und das genaue Verhalten variiert je nach Browser-Version und Gerät.

Um die GPU-Beschleunigung von Filtern zu fördern:

/* Das Hinzufügen eines Transform befördert das Element zu einer Compositor-Ebene */
.filter-element {
  filter: blur(4px) brightness(0.9);
  transform: translateZ(0); /* Befördert zu einer eigenen Compositor-Ebene */
}

Beachte, dass das Erstellen von Compositor-Ebenen einen eigenen Overhead hat — jede Ebene verbraucht GPU-Speicher. Das Erstellen vieler Ebenen (eine pro Card-Komponente in einer langen Liste) kann dazu führen, dass dem Browser der GPU-Speicher ausgeht und er auf CPU-Rendering zurückfällt, was schlechter ist als überhaupt keine Beförderung. Verwende Ebenenbeförderung bewusst, nicht universell.

Filter animieren

Das Animieren eines Filters erzeugt standardmäßig eine Rendering-bei-jedem-Frame-Situation. Ausnahmen sind: - filter: opacity() — Opacity ist in modernen Browsern Compositor-freundlich - Filter auf Elementen, die explizit mit GPU-beschleunigten Transforms befördert wurden

Unschärfe nicht animieren:

/* Schlechte Performance — verwischt einen großen Bereich bei jedem Animationsframe */
.element:hover {
  transition: filter 0.3s;
  filter: blur(8px);
}

Alternative: Unschärfe mit contain und Ebenenbeförderung:

Wenn Unschärfe-Animation aus Design-Gründen unbedingt notwendig ist, auf ein kleines Element anwenden, das Element mit contain: paint oder isolation: isolate vom Rest des Dokuments isolieren und will-change: filter verwenden, um auf Ebenenbeförderung hinzuweisen — wobei zu verstehen ist, dass dies auf schwacher Hardware immer noch ein teurer Vorgang ist.

Backdrop-Filter-Überlegungen

backdrop-filter wendet Filtereffekte auf die Pixel hinter einem Element an — häufig für Milchglas-Effekte verwendet. Es gehört zu den rechenintensivsten CSS-Funktionen.

Warum Backdrop-Filter teuer ist

Im Gegensatz zu filter, der die eigenen gerenderten Pixel eines Elements verarbeitet, erfordert backdrop-filter, dass der Browser:

1. Alle Inhalte hinter dem Element rendert (den „Backdrop")
2. Den Filter auf diese Pixel als Backdrop für das aktuelle Element anwendet
3. Den Inhalt des aktuellen Elements über den gefilterten Backdrop rendert

Schritt 1 bedeutet, dass jedes Element hinter dem backdrop-filter-Element rasteriert werden muss, um den Backdrop zu erzeugen. Jede Änderung an einem Element hinter dem backdrop-filter erfordert ein erneutes Rendern des Backdrops und eine erneute Filteranwendung.

Das hat eine kaskadierende Konsequenz: Wenn ein backdrop-filter: blur()-Element auf einer Seite mit animierten oder scrollenden Inhalten dahinter existiert, löst jedes Scroll oder jeder Animationsframe ein erneutes Backdrop-Rendering und eine erneute Filteranwendung aus. Auf mittlerer mobiler Hardware ist dies häufig die Ursache für Scroll-Ruckelns.

Praktische Nutzungsregeln für Backdrop-Filter

Sparsam verwenden: Die Anzahl der backdrop-filter-Elemente auf einer Seite begrenzen. Ein Milchglas-Modal ist in Ordnung. Eine Sticky-Kopfzeile, eine Seitenleiste, ein Tooltip und ein Modal, die alle gleichzeitig backdrop-filter: blur() verwenden, ist oft zu viel für mobile Hardware, um es flüssig zu handhaben.

Den Unschärferadius begrenzen: backdrop-filter: blur(4px) ist sinnvoll günstiger als backdrop-filter: blur(20px). Der Gaußsche Unschärfe-Kernel wächst mit dem Radius und erhöht direkt die Berechnung. Den kleinsten Unschärferadius verwenden, der die Design-Absicht erfüllt.

contain: layout paint verwenden: Die contain-Eigenschaft teilt dem Browser mit, dass das Element und seine Kinder visuell eigenständig sind. Auf Elementen, die backdrop-filter verwenden, kann contain: layout paint die Rendering-Oberfläche reduzieren.

Einen soliden Fallback bereitstellen: @supports verwenden, um einen soliden, opaken Hintergrund für Geräte und Browser bereitzustellen, bei denen backdrop-filter zu teuer oder nicht unterstützt wäre:

.glass-panel {
  background: rgba(255, 255, 255, 0.9); /* Fallback */
}

@supports (backdrop-filter: blur(1px)) {
  .glass-panel {
    background: rgba(255, 255, 255, 0.5);
    backdrop-filter: blur(12px);
  }
}

GPU-Beschleunigungstechniken

„GPU-Beschleunigung" in einem Web-Kontext bedeutet das Verschieben von Rendering-Arbeit von der CPU-gesteuerten Rendering-Pipeline zum GPU-Compositor. Die GPU ist für die peinlich parallele Arbeit der Verarbeitung von Pixel-Arrays optimiert — sie kann Ebenen compositen und einfache Transformationen um mehrere Größenordnungen schneller anwenden als die CPU-Rendering-Pipeline.

Wie Ebenenbeförderung funktioniert

Wenn ein Browser entscheidet, dass ein Element eine eigene Compositor-Ebene benötigt: 1. Rasteriert er den gerenderten Inhalt des Elements in eine GPU-Textur (Bitmap im GPU-Speicher) 2. Weist er die GPU bei nachfolgenden Frames an, diese Textur an einer bestimmten Position und Opazität zu compositen, ohne sie erneut zu rasterisieren

Für stabile Inhalte bedeutet das, dass die Rendering-Kosten einmalig bezahlt werden. Für animierte Inhalte (Transforms, Opacity) bedeutet es, dass die Animation ohne CPU-Rendering-Aktivität bei jedem Frame fortschreiten kann.

Ebenenbeförderung auslösen

Browser befördern Elemente automatisch zu Compositor-Ebenen, wenn sie erkennen: - CSS-transform-Animationen oder -Transitions - CSS-opacity-Animationen oder -Transitions - position: fixed oder position: sticky-Elemente (in einigen Browsern) - Elemente mit deklariertem will-change: transform oder will-change: opacity

Manuelle Beförderung mit will-change:

/* Hinweis, dass dieses Element animiert wird */
.animated-card {
  will-change: transform, opacity;
}

will-change nur für Elemente verwenden, von denen bekannt ist, dass sie animieren werden. Die universelle Anwendung (z. B. * { will-change: transform }) verbraucht GPU-Speicher für jedes Element, was kontraproduktiv ist und speicherschwache Geräte zum Absturz bringen kann.

Die Transform- und Opacity-Regel

Die universelle GPU-Performance-Regel für CSS-Farb- und visuelle Effektanimationen: Nur transform und opacity animieren. Beide Eigenschaften haben garantierte Compositor-only-Codepfade in allen gängigen Browsern. Alles andere — einschließlich Farbe, Hintergrund, Schatten und Filter — erfordert CPU-Rendering bei jedem Frame.

Wenn ein Design einen Farbübergang bei Hover erfordert (z. B. eine Schaltfläche, die von #3B82F6 zu #2563EB wechselt), sind die CPU-Rendering-Kosten eines einzelnen Elements, das seine Farbe ändert, vernachlässigbar. Wenn 30 Cards auf einer Seite gleichzeitig ihren Box-Schatten beim Scrollen ändern, werden die kumulativen CPU-Kosten sichtbar. Entsprechend designen.

Tatsächliche Rendering-Performance messen

Der Performance-Tab in Browser-DevTools zeichnet Rendering-Vorgänge auf. Eine Nutzerinteraktion oder Animation aufzeichnen, dann die Frame-Aufschlüsselung auf „Paint"- und „Composite Layers"-Aufgaben untersuchen. Grün gefärbte Aufgaben im Flammen-Diagramm sind Compositor-Operationen (günstig); grün mit „Paint"-Beschriftung markierte Aufgaben sind CPU-Rendering-Vorgänge (teurer). Wenn „Paint"-Aufgaben während einer Animation erscheinen, mit dem „Paint Flashing"-Overlay im Rendering-Panel untersuchen, welches Element sie auslöst.

Das Wichtigste in Kürze

• Die Browser-Rendering-Pipeline ist: Style-Neuberechnung → Layout → Rendering → Compositing. Farb-Eigenschaften betreffen die Rendering-Phase; nur transform und opacity können während Animationen in der Compositing-Phase bleiben.
• Das Animieren von Verläufen, Box-Schatten oder Farben erzwingt CPU-Rendering bei jedem Frame — auf leistungsschwacher Hardware verursacht das Ruckeln. Die Lösung ist, stattdessen einen transform auf einem Pseudo-Element zu animieren.
• Box-Shadow-Kosten skalieren mit Unschärferadius, Spread, Elementgröße und Anzahl der Schatten. Pseudo-Element-Verläufe als Alternative für performance-sensible Hover-Effekte verwenden.
• CSS filter: blur() ist eine der teuersten Operationen in CSS — es verarbeitet jeden Pixel in einem Bereich proportional zum Unschärferadius. Nur mit expliziter Ebenenbeförderung und einer Contain-Strategie animieren.
• backdrop-filter ist noch teurer als filter — es erfordert das erneute Rendern des gesamten Backdrops. Die Anzahl gleichzeitiger Backdrop-Filter-Elemente begrenzen und Unschärferadien so klein wie das Design erlaubt halten. Solide Hintergrund-Fallbacks bereitstellen.
• will-change: transform verwenden, um Elemente zu GPU-Compositor-Ebenen zu befördern, bevor sie animieren — aber sparsam, da jede Ebene GPU-Speicher verbraucht.
• ColorFYIs Verlaufsgenerator verwenden, um CSS-Verlaufscode zu erstellen, dann Verlaufsanimationen mit der Pseudo-Element-Transform-Technik implementieren, um sie in der Compositor-Phase zu halten.
• Vor der Optimierung messen: Das Performance-Panel in Chrome oder Firefox DevTools verwenden, um zu bestätigen, wo Rendering-Kosten tatsächlich existieren, bevor Code-Änderungen vorgenommen werden.