PageSpeed 95: unser Protokoll

Anspruch trifft eigene Seite

Wir versprechen Kunden Websites mit PageSpeed 90+, und ein solches Versprechen ist wohlfeil, solange man es nicht an der eigenen Seite beweisen muss. Also haben wir es getan – dokumentiert, mit Zahlen, ohne die guten Momente herauszupicken. Der Ausgangspunkt war schon ordentlich, aber nicht das Ziel: 91 Punkte mobil in der Produktion. Am Ende standen 94, in guten Läufen 95, der Speed Index fiel von 3,7 auf 1,8 Sekunden, der LCP liegt bei 3,1 Sekunden und der Layout-Shift bei glatt null.

Interessant sind nicht die Zahlen, sondern der Weg dahin. Es waren zwei Hebel, und beide erzählen etwas darüber, wo moderne Websites wirklich Zeit verlieren.

Hebel 1: Das CMS gehört nicht ins Browser-Bundle

Unsere Preistabelle ist eine Client-Komponente, weil sie interaktiv ist, und sie las ihre Daten über den Sanity-Client – denselben, mit dem wir serverseitig das CMS abfragen. Das klang praktisch und war ein stiller Ballast: Der CMS-Client zog rund 38 Kilobyte in genau den Chunk, den jeder Besucher sofort laden muss, obwohl die Preise sich zwischen zwei Deploys ohnehin nicht ändern.

Die Lösung war unspektakulär und genau deshalb richtig. Die Client-Komponente liest jetzt eine statische Datenkopie, während der volle CMS-Zugriff dort bleibt, wo er hingehört – auf dem Server. Der Browser bekommt nur noch, was er wirklich braucht. Solche versteckten Passagiere im Bundle sind einer der häufigsten Gründe, warum eine an sich schnelle Seite im Labor einbricht, und sie fallen nur auf, wenn man den Chunk mal aufmacht und nachschaut.

Hebel 2: Eine Animation, die sich selbst abschaltet

Der zweite Hebel ist subtiler. Unsere Hero-Headline wird per SplitText animiert, Buchstabe für Buchstabe, und das sieht gut aus – solange es schnell passiert. Auf einem langsamen Gerät aber kommen Schriften und Hydration spät, und wenn dann noch die Animation den Text neu aufbaut, verschiebt sich der Moment, in dem der größte Inhalt sichtbar wird. Der LCP leidet, ausgerechnet dort, wo es am meisten wehtut.

Also haben wir der Animation ein Zeitbudget gegeben. Kommen Fonts und Hydration später als 1.200 Millisekunden nach dem Start der Navigation, überspringt sich das Reveal einfach selbst: Der servergerenderte Text, der ohnehin schon da steht, bleibt stehen, und der frühe Paint bleibt der LCP. Auf einem schnellen Rechner sieht niemand einen Unterschied, auf einem langsamen greift der Schutz.

Und hier kommt die ehrliche Pointe. Dieser Kniff verbessert nicht den hübschen Laborwert, den ein einzelner Testlauf ausspuckt – er schützt die echten, langsamen Geräte da draußen, die Google als Field Data misst. Labor und Feld sind eben nicht dasselbe, und wer nur auf die Laborzahl optimiert, poliert ein Schaufenster, hinter dem die echten Nutzer trotzdem warten. Diesen Unterschied zu verstehen, ist wichtiger als jeder einzelne Punkt im Report.

Warum wir Messwerte committen

Bleibt die Frage, wie man so etwas überhaupt sauber misst. Man könnte lokal Lighthouse laufen lassen, täglich, automatisiert – und würde sich Zahlen einhandeln, die von der Auslastung des eigenen Rechners abhängen und in Wahrheit nichts beweisen. Wir gehen den anderen Weg und fragen die PageSpeed-API, dieselbe Quelle, aus der auch Google seine Werte zieht. Das Ergebnis wird einmal bewusst gemessen, reviewt und als Baseline committet, statt im Hintergrund vor sich hin zu rauschen.

MERKSATZ

Performance ist kein Zufall, sondern ein Protokoll.

Genau das meinen wir, wenn wir sagen, Performance sei kein Zufall, sondern ein Protokoll. Nicht ein Glückstreffer an einem guten Tag, sondern ein nachvollziehbarer Weg, den man wiederholen und belegen kann. Wie dieses Protokoll in unsere Arbeit an SEO, GEO & AIO eingebettet ist, hängt am selben Prinzip: messen, zeigen, nicht behaupten.