Style-Recalculation: wenn CSS erst im Browser bremst

Die erste Kostenart ist gut messbar und wird selten gemessen: Trefferversuche ohne Treffer. Die Engine prüft einen Selektor gegen ein Element, stellt fest, dass er nicht passt, und verwirft das Ergebnis. Diese Arbeit taucht in keiner Deckungsanalyse auf, weil die Regel ja korrekt ungenutzt bleibt – sie kostet trotzdem Zeit. In der Beispielausgabe der Chrome-Dokumentation steht dazu ein Satz, der die Größenordnung greifbar macht: Die Engine hat versucht, diesen einen Selektor 1.104 (Chrome for Developers) Mal zuzuordnen, ohne ein einziges Element zu treffen. Solche Regeln stammen typischerweise aus Baukästen, Kampagnenvorlagen und alten Themenpaketen, die in jedem Bündel mitreisen. Wie man diesen Bestand systematisch aufräumt, beschreibt der Beitrag zum Finden und Entfernen ungenutzten CSS.

Die zweite Kostenart ist der Umfang der Invalidierung. Sie entsteht nicht im Stylesheet, sondern im Skript: an der Stelle, an der eine Klasse gesetzt, ein Attribut geändert oder eine Eigenschaft geschrieben wird. Je weiter oben der Knoten sitzt und je breiter die betroffenen Selektoren greifen, desto mehr Elemente wandern in die Neubewertung. In der Beispielaufnahme der Dokumentation zeigt der Bericht neben der Dauer auch die Zahl der betroffenen Elemente – gut 900 (web.dev) in jenem Fall, bei einer Stilberechnung von etwas über 25 Millisekunden (web.dev). Das ist kein Extremfall, sondern eine gewöhnliche Umschaltung; die 25 Millisekunden sind bereits ein Achtel der Frist, die für die gesamte Interaktion zur Verfügung steht.

Die vier Zeilen hängen zusammen, aber sie werden mit verschiedenen Werkzeugen gefunden. Regelmenge und Dateiaufteilung stehen im Bündel, die Trefferversuche stehen in der Aufnahme, der Invalidierungsumfang steht im Skript. Ein Bericht, der nur die Byte-Größe des CSS ausweist, deckt genau eine dieser vier Zeilen ab – und ausgerechnet die, die auf schnellen Verbindungen am wenigsten wehtut. Wie eine Prüfung aussieht, die alle vier Ebenen zusammenführt, zeigt unsere Frontend-Optimierung.

In einer Aufnahme des Leistungsbereichs heißt der gesuchte Eintrag Recalculate Style. Er erscheint dort, wo der Browser die berechneten Stile für einen Teil des Baums neu bestimmt, und er trägt zwei Angaben, die zusammen die Diagnose tragen: die Dauer und die Zahl der betroffenen Elemente. Werden diese Einträge lang, hilft die Registerkarte Selector Stats dabei zu verstehen, welcher der eigenen CSS-Selektoren die meiste Zeit verbraucht (Chrome for Developers). Die Tabelle führt je Selektor die verbrauchte Zeit, die Trefferversuche und die tatsächlichen Treffer – damit lässt sich Verlustarbeit von notwendiger Arbeit trennen, statt nach Gefühl zu kürzen.

Ein Detail entscheidet über die Brauchbarkeit der Messung: Selector Stats ist standardmäßig abgeschaltet, weil die Erhebung den Aufnahmen zusätzlichen Aufwand hinzufügt (Chrome for Developers). Die Absolutwerte einer Aufnahme mit eingeschalteter Statistik sind deshalb nicht mit denen einer gewöhnlichen Aufnahme vergleichbar. Für die Diagnose ist das unerheblich, weil die Rangfolge der Selektoren erhalten bleibt; für einen Vorher-Nachher-Beleg ist es entscheidend, weil sonst der Messaufbau selbst den Unterschied erzeugt. Zwei Aufnahmen, dieselbe Einstellung, derselbe Ablauf – sonst vergleicht man zwei verschiedene Messungen miteinander.

Die naheliegende Antwort lautet: kürzere Selektoren. Sie ist richtig, aber sie ist die kleinere Hälfte. Die Dokumentation nennt die Zahl der neu bewerteten Elemente ausdrücklich als den oft wichtigeren Hebel gegenüber der Selektorkomplexität (web.dev). Praktisch heißt das: Eine Umschaltung, die statt am Wurzelelement an dem Container stattfindet, der die Änderung tatsächlich betrifft, verkleinert den Prüfbereich unmittelbar – ohne dass eine einzige Regel umgeschrieben werden muss. Und sie ist in der Regel schneller umgesetzt als ein Umbau des Stylesheets.

Zwei Punkte gehören zusammen gedacht: Animationen und Stilberechnung. Eine Übergangsanimation, die eine Eigenschaft verändert, welche die Geometrie berührt, löst in jedem Bild erneut Stil- und Layoutarbeit aus. Die Zeitleiste zeigt das als Kette gleichartiger Einträge über viele Rahmen hinweg. Welche Eigenschaften sich stattdessen ohne diese Kette animieren lassen, behandelt der Beitrag zu flüssigen Animationen ohne Ruckeln. Bei Shops kommt hinzu, dass Varianten- und Filterumschaltungen häufig ganze Listen neu bewerten lassen – ein Muster, das die Shopware-Performance regelmäßig stärker prägt als die Startseite.

Zum Nachweis gehört ein zweiter Blick. Eine Laboraufnahme belegt, dass ein Selektor Zeit verbraucht; erst die Felddaten belegen, dass diese Zeit bei den Besuchern ankommt. Beide Quellen nebeneinanderzulegen ist ein eigener Arbeitsschritt, den der Beitrag zu Felddaten und Laborwerten beschreibt. Und weil die Erhebung im Feld personenbezogene Fragen berührt, gehört die rechtliche Seite in dieselbe Planung: Was ohne Einwilligung zulässig ist, klärt der Beitrag zur Performance-Messung ohne Einwilligung. Wie sich der Aufwand insgesamt auf die drei Kennzahlen verteilt, ordnet unsere Übersicht zu den Core Web Vitals ein.