PageSpeed von 91 auf 95: Was wirklich geholfen hat

Eine Zahl braucht ein Vorher und Nachher

Diese Website startete in der mobilen Produktionsmessung bei 91 PageSpeed-Punkten. Nach zwei gezielten Änderungen lagen wiederholte Läufe bei 94 bis 95. Der Speed Index sank von 3,7 auf 1,8 Sekunden, der gemessene LCP lag bei 3,1 Sekunden und der Layout Shift bei 0.

Diese Werte sind eine datierte Labormessung, keine Garantie für jedes Gerät. Ihr Nutzen liegt in der Diagnose und im Vergleich unter ähnlichen Bedingungen.

Hebel 1: unnötigen Code aus dem Startpfad nehmen

Die Preistabelle ist interaktiv und läuft deshalb als Client-Komponente. Ursprünglich importierte sie den Sanity-Client, obwohl sich ihre Daten zwischen zwei Deployments nicht änderten. Damit landeten rund 38 Kilobyte zusätzlicher Code im Browser-Bundle jedes Besuchers.

Die Lösung war eine statische, typisierte Datenkopie für die Client-Komponente. Der vollständige CMS-Zugriff bleibt auf dem Server. Das spart nicht spektakulär viele Dateien, aber genau den Code, der im kritischen Startpfad keinen Nutzen hatte.

Der übertragbare Test lautet:

• Öffne die Bundle-Analyse oder Build-Ausgabe.
• Suche in frühen Client-Chunks nach Server-SDKs, Editoren, Diagrammbibliotheken oder Daten, die schon beim Build feststehen.
• Verschiebe nicht interaktive Arbeit auf den Server.
• Miss erneut, bevor du den nächsten Hebel anfasst.

Hebel 2: Gestaltung bekommt ein Zeitbudget

Die Hero-Headline wird animiert. Auf schnellen Geräten ist das unkritisch. Treffen Schriften und Hydration spät ein, kann ein nachträglicher Neuaufbau jedoch den größten sichtbaren Inhalt verzögern.

Deshalb besitzt das Reveal ein Budget: Sind Schriften und Hydration 1.200 Millisekunden nach Navigationsbeginn noch nicht bereit, wird die Animation übersprungen. Der serverseitig gerenderte Text bleibt sichtbar und der frühe Paint wird nicht für einen dekorativen Effekt geopfert.

Das Prinzip ist wichtiger als der konkrete Wert. Eine Animation darf die Kernbotschaft ergänzen, aber nicht ihre Auslieferung blockieren. Prüfe für jedes große Above-the-fold-Element:

1. 1.Ist der Inhalt schon im Server-HTML vorhanden?
2. 2.Reserviert das Layout seine endgültige Größe?
3. 3.Kann die Animation ohne Funktionsverlust entfallen?
4. 4.Greift die Einstellung „prefers-reduced-motion“ vollständig?

Labor und Feld beantworten verschiedene Fragen

Lighthouse beziehungsweise PageSpeed Lab simuliert definierte Bedingungen und eignet sich für reproduzierbare Diagnosen. Felddaten aus dem Chrome User Experience Report fassen reale Erfahrungen über einen längeren Zeitraum zusammen. Ein guter Laborlauf kann schlechte Felddaten nicht widerlegen; fehlende Felddaten bedeuten bei kleinen Websites nicht automatisch gute oder schlechte Nutzung.

Halte deshalb im Protokoll fest:

• URL und Deployment
• Datum und Messquelle
• Gerätetyp und Standort, soweit verfügbar
• drei Läufe statt eines einzelnen Bestwerts
• Median sowie auffällige Ausreißer
• genaue Codeänderung zwischen den Messungen

Warum ich die Baseline versioniere

Lokale Lighthouse-Läufe hängen von Rechner, Hintergrundprozessen und Netzwerk ab. Für die veröffentlichte Baseline nutze ich die PageSpeed-API, prüfe die Ergebnisse bewusst und committe den Messstand zusammen mit Datum und URL. So bleibt sichtbar, welche Zahl zu welchem Codezustand gehörte.

Eine tägliche Automation wäre nicht grundsätzlich falsch. Sie lohnt sich, wenn Schwellenwerte, Alarmweg und Messumgebung stabil definiert sind. Ohne diese Disziplin produziert sie vor allem wechselnde Zahlen.

So startest du mit einer belastbaren Baseline

Miss die Produktionsseite dreimal und sichere den Median. Prüfe danach LCP-Element, JavaScript im Startpfad, Bilddimensionen, Schriften und Layout-Verschiebungen. Wähle den größten plausiblen Engpass und ändere nur diesen. Erst nach der Kontrollmessung folgt der nächste.

Hör auf, wenn Aufwand und messbarer Nutzen auseinanderlaufen. Die letzten zwei Punkte sind selten wichtiger als ein verständlicher Inhalt, ein funktionierendes Formular oder ein stabiler Betrieb.