Warum eure Website langsam ist, obwohl sie neu ist

Im August haben wir unsere eigene Seite durch PageSpeed Insights geschickt. Nicht, weil etwas kaputt aussah. Sie fühlte sich schnell an, auf jedem Gerät, das hier im Büro liegt.

Der Bericht meldete 19.250 Millisekunden Total Blocking Time. Über neunzehn Sekunden, in denen der Browser auf nichts reagiert hätte. Auf dem Handy fand Lighthouse nicht einmal einen Wert für den Largest Contentful Paint und brach mit einem Fehler ab.

Wir haben zwei Tage gebraucht, um zu verstehen, warum. Das Ergebnis lohnt sich zu erzählen, weil beide Ursachen nichts mit dem zu tun haben, was man zuerst verdächtigt.

Die erste Ursache: eine Grafikkarte, die es nicht gibt

Unser Hintergrund ist ein WebGL-Shader. Ein Flussfeld, das sich langsam bewegt. Auf jedem Rechner mit Grafikkarte kostet das ungefähr nichts.

PageSpeed Insights misst aber in Containern ohne Grafikkarte. Chrome fällt dann auf Software-Rasterung zurück, und ab da muss der Prozessor jeden einzelnen Frame Pixel für Pixel in den Bildschirmspeicher kopieren.

Der entscheidende Punkt, und der hat uns einen halben Tag gekostet: Diese Kosten hängen allein an der Fläche. Wie kompliziert der Shader rechnet, spielt keine Rolle.

Wir haben es andersherum gelernt. Erst haben wir die Shader-Mathematik vereinfacht, von fünf Oktaven auf drei. Gewinn: 10 Millisekunden. Dann haben wir die gerenderte Fläche geviertelt. Die Zeit in „Other“ fiel von 7.861 auf 3.362 Millisekunden.

Die Lösung war am Ende unspektakulär:

• Software-Rasterung erkennen und das Feld dann als Standbild einfrieren. Wer keine Grafikkarte hat, sieht ein schönes Bild statt einer ruckelnden Animation.
• Die Pixelzahl deckeln. 600.000 auf dem Desktop, 250.000 auf dem Handy. Das Canvas wird in CSS auf volle Breite gezogen, der Browser skaliert die kleinere Textur hoch. Im direkten Vergleich zweier Screenshots ist der Unterschied nicht zu finden, weil die Fläche ohnehin unter einer Maske und 85 Prozent Deckkraft liegt.
• Die Bildrate auf rund 30 Bilder pro Sekunde begrenzen. Das Feld fließt so langsam, dass jedes zweite Bild keine sichtbare Information trägt.

Das klingt nach einem Spezialfall für Seiten mit WebGL. Ist es aber nicht. Dieselbe Gruppe von Geräten trifft es bei jedem aufwendigen visuellen Effekt: ältere Notebooks, virtuelle Maschinen, Chrome mit abgeschalteter Hardwarebeschleunigung. Und die Messwerkzeuge, an denen Google eure Seite bewertet, gehören dazu.

Die zweite Ursache: die Einblendung auf der Überschrift

Fast jede moderne Website blendet Inhalte beim Scrollen ein. Wir auch. Die Technik ist simpel: Das Element startet auf opacity: 0, ein Beobachter setzt eine Klasse, sobald es ins Bild kommt, und dann fährt es hoch.

Wir hatten diese Klasse auf der großen Überschrift im Hero.

Genau diese Überschrift ist auf fast jeder Seite das größte Textelement im ersten Bildschirm. Also der Kandidat für den Largest Contentful Paint, den Wert, an dem Google die gefühlte Ladezeit festmacht.

Ein Element mit opacity: 0 zählt dafür nicht. Lighthouse fand keinen stabilen Kandidaten, meldete NO_LCP und brach in der Folge auch die Messung von Blockierzeit und Interaktivität ab. Der ganze Bericht war deshalb so katastrophal, nicht weil die Seite so langsam war.

Die Regel, die wir daraus gemacht haben, passt in einen Satz: Was beim Laden ohnehin im Bild steht, braucht keine Einblendung.

Was wir vergeblich verdächtigt haben

Wir haben eine Menge Dinge gemessen, die sich als unschuldig herausstellten. Vielleicht spart euch das Zeit:

Die Maske über dem Shader. Die Deckkraft. Das Hochheben in eine eigene GPU-Ebene per will-change. Die Shader-Kompilierung selbst, die messbar 0,0 Millisekunden braucht. Die Partikelfelder, die drei Prozent der Zeit ausmachten gegenüber 96 Prozent für den Shader. GSAP. Das Reveal-System als solches. Und die doppelt im DOM liegenden Navigations-Panels, die nach Kompression sage und schreibe 96 Byte kosten.

Der Reflex, zuerst die Bibliotheken zu verdächtigen, ist verständlich. In unserem Fall hätte er zu nichts geführt.

Das Ergebnis

Mobil von 45 auf 95. Desktop von 85 auf 100. Ohne Grafikkarte von 59 auf 100.

Und das ist der eigentliche Grund, warum wir das aufschreiben: Wir haben an der Seite optisch nichts verändert. Kein Effekt ist verschwunden, keine Animation fehlt. Es waren zwei Entscheidungen an zwei Stellen.

Was das für eure Seite heißt

Wenn eure Website neu ist und sich trotzdem zäh anfühlt, lohnen sich zwei Fragen, bevor ihr irgendetwas umbaut.

Erstens: Steht eine Einblendung auf eurem größten Text im ersten Bildschirm? Das lässt sich in den Entwicklerwerkzeugen in einer Minute prüfen. Element auswählen, nach opacity suchen.

Zweitens: Wie sieht die Seite ohne Grafikkarte aus? In Chrome lässt sich die Hardwarebeschleunigung abschalten. Wer dann eine Diashow sieht, weiß, was die Messwerkzeuge sehen.

Beides kostet euch eine Viertelstunde. Und beides erklärt erstaunlich oft die Zahl, die niemand sich erklären konnte.

Wenn ihr wollt, schauen wir uns eure Seite gemeinsam an. Das Erstgespräch kostet nichts, und wir sagen ehrlich, ob sich ein Umbau lohnt oder ob zwei Zeilen reichen.