Der teuerste Main-Thread-Fresser
unserer Website war ein Farbverlauf.

Der teuerste Main-Thread-Verbraucher der ganzen Seite war ein Farbverlauf, der 60 Mal pro Sekunde neu berechnet wurde, obwohl er sich nie verändert hat.

Unsere Startseite hat einen animierten Hintergrund-Effekt, den SilkBackground — ein feines, sich bewegendes Seidenmuster, gerendert über ein HTML-Canvas-Element. Bis vor kurzem hat genau dieser Effekt die eigene Seite ausgebremst, und zwar an einer Stelle, die man beim bloßen Anschauen nie vermutet hätte.

Auf den Punkt: Im dunklen Theme wird über den Effekt ein radialer Farbverlauf gelegt, der für die Tiefenwirkung sorgt. Der Code hat diesen Verlauf bei jedem einzelnen Frame neu berechnet — obwohl er sich nie ändert, solange sich die Fenstergröße nicht ändert. Ein Audit mit echten Google-Daten hat das als den mit Abstand teuersten Main-Thread-Posten der ganzen Seite entlarvt. Der Fix war eine einzige zusätzliche Zeile Code.

Wie wir es gefunden haben

Ausgelöst hat es ein auffällig schlechter Performance-Wert bei einem Re-Audit-Durchlauf, der erstmals echte Google-Felddaten einbezogen hat — PageSpeed Insights, Search Console und CrUX statt nur statischer Checks. Die PSI-Labordaten zeigten für die Startseite eine Scripting-Bootup-Zeit von rund 6 Sekunden und ganze 20 Long Tasks — also 20 Momente, in denen der Main Thread am Stück so lange blockiert war, dass die Seite auf nichts mehr reagieren konnte. Für eine Seite, die im Wesentlichen aus Text, Bildern und einem dezenten Hintergrund-Effekt besteht, war das ein deutliches Warnsignal.

Die Ursache: ein Farbverlauf, 60 Mal pro Sekunde neu gebaut

Der SilkBackground-Effekt läuft über eine Canvas-Render-Schleife, die kontinuierlich neue Frames zeichnet. Im dunklen Theme wird zusätzlich eine radiale Abdunklung über das Muster gelegt, damit die Fläche mehr Tiefe bekommt statt flach und gleichmäßig hell zu wirken. Diese Abdunklung wird über ctx.createRadialGradient() erzeugt — eine Methode, die abhängig von Breite und Höhe der Zeichenfläche ist, aber nicht vom aktuellen Frame.

Im Code stand dieser Aufruf trotzdem direkt in der Render-Schleife: bei jedem Frame ein neuer Farbverlauf, mit denselben zwei Farbstopps, auf derselben Fläche, mit demselben Ergebnis — nur eben neu berechnet, statt das bereits berechnete Ergebnis einfach weiterzuverwenden.

Der Fix: einmal cachen statt bei jedem Frame neu bauen

Die Lösung ändert nichts am sichtbaren Ergebnis, nur daran, wie oft es berechnet wird: Der Farbverlauf wird jetzt in einer Variablen zwischengespeichert und nur dann neu erzeugt, wenn diese Variable noch leer ist — was nach dem ersten Zeichnen und nach jedem Resize der Fall ist, sonst nie. Die Render-Schleife greift bei jedem weiteren Frame einfach auf den bereits vorhandenen Farbverlauf zu, statt ihn neu zu bauen.

Das Ergebnis

Ein aktueller PageSpeed-Insights-Lauf auf der Live-Seite zeigt, wo die Startseite seitdem steht — Barrierefreiheit, Best Practices und SEO liegen jeweils zusätzlich bei 100:

PageSpeed Insights, Mobile-Emulation (Moto G Power, gedrosseltes 4G) — Live-Messung vom 30. August 2026. Die "Vorher"-Werte stammen aus dem PSI-Lab-Report, der den Fix ausgelöst hat.

Was das für Ihr Unternehmen bedeutet

Dieser Bug war unsichtbar, solange man nur auf das Ergebnis schaut — die Seite sah vorher genauso aus wie nachher. Sichtbar wurde er erst durch echte Lab- und Felddaten, nicht durch bloßes Betrachten der Seite. Genau das ist der Grund, warum wir bei Kundenprojekten nicht nur einmalig beim Launch prüfen, sondern mit echten Google-Daten nachfassen: Animierte Effekte, Canvas-Elemente oder aufwendige Interaktionen sehen im Browser oft unauffällig aus und kosten trotzdem messbar Main-Thread-Zeit — bis jemand mit den richtigen Werkzeugen gezielt nachschaut.

FAQ