100 Punkte bei PageSpeed: Was wir dafür geändert haben
Ladezeit ist ein Rankingfaktor, aber die üblichen Ratschläge helfen selten. Dieser Beitrag beschreibt, was wir an der eigenen Seite tatsächlich verändert haben, welche Maßnahme wie viel brachte und wo wir falsch abgebogen sind.
Das Wichtigste in Kürze
- Der größte Einzelgewinn kam nicht vom Verkleinern von Dateien, sondern davon, eine Bibliothek von 458 KB durch 6 KB eigenen Code zu ersetzen.
- Die zweitgrößte Ursache war eine halb konfigurierte Kompression: Der Server komprimierte nur HTML, nicht CSS und JavaScript.
- Ein Layout-Sprung von Wert 1 kostete 24 Punkte – verursacht durch nachgeladenes CSS, das erst nach dem ersten Bildaufbau griff.
- Was am wenigsten brachte: Bildformate. Was am meisten brachte: Dinge weglassen.
Der Ausgangswert war 58 von 100 auf dem Handy. Das ist kein schlechter Wert für eine Website mit 3D-Effekt im Kopfbereich, aber ein Wert, den Google in der mobilen Suche spürbar bestraft. Am Ende standen 100 Punkte auf dem Rechner und 98 auf dem Handy, bei ebenfalls 100 für Barrierefreiheit.
Was folgt, ist keine allgemeine Checkliste, sondern der tatsächliche Verlauf – einschließlich der Stellen, an denen wir uns geirrt haben.
Die Ausgangslage
| Messwert (mobil) | vorher | nachher |
|---|---|---|
| Leistung | 58 | 98 |
| Barrierefreiheit | 95 | 100 |
| Erster Bildaufbau | 6,1 s | 1,4 s |
| Größtes Element sichtbar | 11,1 s | 2,1 s |
| Übertragen gesamt | 298 KB | 184 KB |
| davon JavaScript | 121 KB | 5 KB |
Die fünf Eingriffe, die wirklich zählten
1. Die Bibliothek ersetzen, nicht optimieren
Der Kopfbereich zeigt eine Partikelwolke in 3D. Dafür lief eine bekannte Grafikbibliothek – 458 KB nach dem Verkleinern. Die Messung wies aus, dass 51 KB davon überhaupt nie ausgeführt wurden.
Der entscheidende Blick war die Frage, wie viel wir tatsächlich brauchen. Es waren elf Bausteine: Renderer, Szene, Kamera, Geometrie, Material und ein paar Hilfsklassen. Alles davon lässt sich direkt gegen die Grafikschnittstelle des Browsers programmieren.
Ergebnis: 458 KB wurden zu 6 KB. Die Darstellung ist identisch – wir haben dieselben Shader übernommen.
2. Die Kompression war nur halb eingeschaltet
In der Serverkonfiguration stand die Kompression auf „an" – aber die Zeile, welche Dateitypen komprimiert werden sollen, war auskommentiert. Das ist die Voreinstellung vieler Distributionen. Ergebnis: Es wurde ausschließlich HTML komprimiert.
Die Grafikbibliothek ging also unkomprimiert über die Leitung. Nach dem Einschalten: 1243 KB wurden zu 251 KB. Zusätzlich legen wir die komprimierten Fassungen jetzt vorberechnet daneben, damit der Server nicht bei jedem Abruf neu rechnet.
Aufwand: zwei Zeilen Konfiguration. Wirkung: knapp ein Megabyte pro Erstaufruf.
3. Die Animationsbibliothek ganz entfernen
Für Einblendungen beim Scrollen lief eine weitere Bibliothek, 114 KB. Die Messung wies sie zusätzlich als Verursacherin erzwungener Layout-Umbrüche aus – sie fragte während des Scrollens Geometrie ab und zwang den Browser dazu, das Layout mitten in der Bewegung neu zu berechnen.
Ersetzt durch einen IntersectionObserver, der lediglich eine Klasse setzt. Die eigentliche Bewegung macht CSS. 114 KB weniger, keine Umbrüche mehr, rund 40 Zeilen eigener Code.
4. Das Favicon war 205 KB groß
Eine Kleinigkeit mit erstaunlicher Wirkung, weil sie sehr früh geladen wird. Ersetzt durch eine SVG-Datei mit 6 KB, erzeugt aus dem vorhandenen Logo.
Wusstest du schon?
Für die Anzeige in den Google-Suchergebnissen nützt ein SVG-Favicon nichts – Google akzeptiert dort nur Rasterformate, und das Bild muss quadratisch sein mit einer Kantenlänge, die ein Vielfaches von 48 Pixeln ist.
Wer also nur ein SVG hinterlegt, bekommt im Suchergebnis den grauen Platzhalter statt des eigenen Logos. Beides nebeneinander anzugeben, ist der richtige Weg.
5. Geometrie im Animationsframe abfragen
Ein Skript las bei jedem Scroll-Ereignis die Gesamthöhe des Dokuments aus. Diese Eigenschaft kann der Browser nicht aus dem Gedächtnis beantworten – er muss dafür das Layout der ganzen Seite neu durchrechnen, mitten im Scrollen.
Die Regel, die daraus folgt und die überall gilt: Im Ereignis lesen, im Bild danach schreiben. Nie andersherum. Seitdem wird die Seitenhöhe einmal gemessen und gemerkt, statt sechzig Mal pro Sekunde neu erfragt.
Der Fehler, der 24 Punkte kostete
Um die letzte blockierende Anfrage loszuwerden, hatten wir das Stylesheet geteilt: Der für den sichtbaren Bereich nötige Teil kam direkt ins Dokument, der Rest wurde nachgeladen. Ein gängiges Vorgehen.
Der Schnitt lag bei einer Marke in der Quelldatei, hinter der wir den sichtbaren Bereich vermutet hatten. Tatsächlich standen dahinter die Regeln für das Logo im Kopfbereich, für die Abstände darunter und für die Einblendungen. Die Seite baute sich also ohne sie auf und wurde eine Sekunde später zurechtgeschoben.
Das Ergebnis: Cumulative Layout Shift von 1,0 – und damit 76 statt 100 Punkte auf dem Rechner. Besonders unangenehm: Lokal mit gebremster Leitung war der Wert 0, weil das Stylesheet dort früh genug ankam. Der Fehler war nur auf schneller Verbindung sichtbar.
Die Lehre: Entweder das ganze Stylesheet ins Dokument oder gar keins. Ein Teil-Einbau setzt voraus, dass man exakt weiß, welche Regel im sichtbaren Bereich gebraucht wird – und das weiß man bei einer wachsenden Seite nie dauerhaft.
Was wenig brachte
Der Vollständigkeit halber die Maßnahmen, die in jeder Anleitung stehen und bei uns kaum messbar waren:
Bildformate. Unsere Startseite hat kaum Bilder – das Logo ist eine SVG-Datei. Wo Bilder vorkommen, lohnt die Umwandlung natürlich; als Haupthebel taugt sie nur bei bildlastigen Seiten.
Schriften weiter verkleinern. Wir hosten zwei Schriftfamilien selbst und laden die im sichtbaren Bereich nötigen vor. Weitere Optimierung wäre möglich, bewegt den Wert aber nicht.
Serverstandort. Vielfach empfohlen, in unserem Fall irrelevant: Die Zeit bis zum ersten Byte lag bereits bei 20 Millisekunden. Wer dort schon gut liegt, gewinnt durch ein Verteilnetz nichts.
Das Vorgehen zum Nachmachen
- Messen, bevor irgendetwas geändert wird. Mobil und Desktop getrennt, die Werte notieren.
- Die größte übertragene Datei suchen. Fast immer ist es JavaScript. Die Frage ist nicht, wie man sie verkleinert, sondern ob man sie braucht.
- Kompression prüfen. Nicht ob sie eingeschaltet ist, sondern für welche Dateitypen.
- Blockierende Anfragen zählen. Jede Stylesheet-Datei im Kopfbereich hält den ersten Bildaufbau auf.
- Ohne Bremse auf Layout-Sprünge prüfen. Der eine Test, der bei uns gefehlt hat.
- Nach jeder Änderung neu messen. Sonst weiß man am Ende nicht, was gewirkt hat.
Hilf mir, den PageSpeed-Bericht meiner Seite in eine Reihenfolge zu übersetzen. Sei streng; lobe nichts. Meine Messwerte: - Mobil: [Punktzahl], Desktop: [Punktzahl] - LCP, TBT, CLS je Gerät: [Werte] - Größte übertragene Dateien mit Größe: [Liste] - Render-blockierende Anfragen: [Liste] - Meldungen aus dem Bericht: [Text einfügen] Zur Seite: - Wie sie gebaut ist: [CMS / statisch / Baukasten] - Wird JavaScript für den sichtbaren Inhalt gebraucht? [ja/nein] - Wie wird CSS ausgeliefert? [extern / vorab / teilweise vorab] Aufgaben: 1. Ordne jede Meldung einer Ursache zu und sag, welche Kennzahl sie beeinflusst – LCP, TBT oder CLS. 2. Sortiere die Maßnahmen nach Wirkung pro Aufwand. Nenne bei jeder, wie viele Punkte sie realistisch bewegt und warum. 3. Nenne die Maßnahmen aus dem Bericht, die bei meiner Bauart praktisch nichts bringen – und begründe, statt sie einfach wegzulassen. 4. Frage bei jeder großen JavaScript-Datei zuerst, ob sie gebraucht wird, bevor du das Verkleinern vorschlägst. 5. Weise darauf hin, wenn CSS nur teilweise vorab ausgeliefert wird, und erkläre, warum das für CLS schlechter sein kann als gar nicht. 6. Nenne, was ich nach jeder Änderung neu messen sollte. Erfinde keine Messwerte.
Fazit
Die Punktzahl selbst ist nicht das Ziel – sie ist ein Messwert, kein Geschäftsergebnis. Was zählt, ist die Erfahrung dahinter: Eine Seite, die nach 1,4 Sekunden lesbar ist, wird von mehr Menschen gelesen als eine, die sechs Sekunden braucht. Bei mobilen Besuchern über Mobilfunk ist der Unterschied größer als jede Textoptimierung.
Der Weg dorthin führte in unserem Fall über eine einzige wiederkehrende Frage: Brauchen wir das? Fünf von sechs Eingriffen bestanden darin, etwas zu entfernen, nicht etwas hinzuzufügen.
Häufige Fragen
Wie erreicht man 100 Punkte bei PageSpeed Insights?
Bei den meisten Websites über drei Schritte: die größte JavaScript-Datei entfernen oder ersetzen, die Kompression für CSS und JavaScript tatsächlich einschalten, und Layout-Sprünge beseitigen. Bildformate und Serverstandort sind selten der Engpass.
Wie wichtig ist Ladezeit für das Google-Ranking?
Sie ist ein bestätigter Faktor, aber kein starker – Inhalt und Relevanz wiegen schwerer. Der größere Effekt ist indirekt: Langsame Seiten werden häufiger abgebrochen, und dieses Verhalten fließt in die Bewertung ein.
Was ist Cumulative Layout Shift und wie behebt man es?
Der Messwert für Elemente, die nach dem ersten Bildaufbau ihre Position ändern. Häufigste Ursachen: Bilder ohne feste Maße, nachgeladene Stylesheets und Schriften mit stark abweichenden Metriken. Behoben wird es, indem der Platz vorab feststeht – über Breiten- und Höhenangaben oder ein festes Seitenverhältnis.
Sollte man das CSS ins HTML einbauen?
Bei kleinen Stylesheets ja, dann aber vollständig. Ein Teil-Einbau mit Nachladen des Rests spart eine Anfrage und handelt sich dafür Layout-Sprünge ein, sobald eine Regel im sichtbaren Bereich fehlt. Bei uns waren es 7 KB gepackt – dafür lohnt sich der vollständige Einbau.
Wie viel bringt der Verzicht auf Bibliotheken?
In unserem Fall den größten Einzelposten: 458 KB Grafikbibliothek wurden zu 6 KB eigenem Code, dazu 114 KB Animationsbibliothek auf null. Ob sich das lohnt, hängt davon ab, wie viel der Bibliothek man tatsächlich nutzt – die Messung weist ungenutztes JavaScript aus.
Marketing, das sich selbst aufsetzt
Die Studio Engine ist in der Beta. Jetzt Platz sichern und von Anfang an mitgestalten.
An Beta teilnehmen →