Ladezeit ist messbar, und genau deshalb wird sie häufig falsch gemessen. Ein einzelner Test mit einem guten Ergebnis beweist nichts, und ein Wert von 100 auf dem Desktop sagt nichts über die Erfahrung eines Besuchers auf dem Telefon.
Felddaten und Labordaten
Felddaten stammen von echten Besuchen: echte Geräte, echte Verbindungen, echte Standorte. Sie sind der Maßstab, weil sie die Wirklichkeit abbilden. Ihr Nachteil: Sie brauchen genug Besucher, sind wenige Wochen alt und sagen nicht, welche Zeile das Problem verursacht.
Labordaten entstehen bei einem simulierten Testaufruf unter definierten Bedingungen. Sie sind reproduzierbar, sofort verfügbar und schlüsseln die Ursachen auf. Ihr Nachteil: Die simulierten Bedingungen entsprechen nicht Ihrem Publikum.
Die Arbeitsteilung ist eindeutig: Bewertet wird nach Felddaten, gearbeitet wird mit Labordaten.
Für eine neue Seite ohne genug Besucher liegen keine Felddaten vor. Dann bleibt der Labortest, mit dem Bewusstsein, dass er ein Anhaltspunkt ist.
Die Werte und was sie bedeuten
| Wert | Bedeutung | Ursache bei schlechtem Ergebnis |
|---|---|---|
| TTFB, Zeit bis zum ersten Byte | Serverantwortzeit | fehlendes Caching, langsames Hosting, alte PHP-Version |
| FCP, erste Darstellung | wann überhaupt etwas erscheint | blockierende Stilangaben, Schriften von fremden Servern |
| LCP | wann der Hauptinhalt sichtbar ist | großes unkomprimiertes Bild, langsamer Server |
| CLS | wie stark das Layout verrutscht | Bilder ohne Maße, nachgeladene Elemente |
| INP | Reaktion auf Eingaben | zu viel JavaScript, meist Fremdskripte |
| Gesamtgröße | übertragene Datenmenge | Bilder, Schriften, Skripte |
| Anzahl der Anfragen | wie viele Dateien geladen werden | viele Plugins, viele Fremddienste |
Die erste Zeile ist der Trennwert für die Fehlersuche: Ist die Zeit bis zum ersten Byte gut und die Gesamtladezeit schlecht, liegt das Problem im Frontend, also bei Bildern, Schriften und Skripten. Ist sie schlecht, liegt es beim Server.
Details zu LCP, INP und CLS stehen in Core Web Vitals.
Der Messablauf
1. Felddaten ansehen, sofern vorhanden. In der Search Console gibt es einen Bericht zur Nutzungserfahrung, getrennt nach mobil und Desktop. Er zeigt, welcher Anteil der Aufrufe in welchem Bereich liegt.
2. Labortest, mobil, mit leerem Cache. Drei bis fünf Messungen derselben Seite, weil Einzelwerte schwanken. Der Median ist aussagekräftiger als der beste Wert.
3. Mehrere Seitentypen messen, nicht nur die Startseite. Eine Detailseite mit Bildergalerie und eine Formularseite verhalten sich anders.
4. Wasserfalldiagramm ansehen. Es zeigt, welche Datei wann geladen wird und was worauf wartet. Hier findet man die konkrete Ursache: das große Bild, die sechs Schriftschnitte, das Skript, das alles blockiert.
5. Nach jeder Maßnahme neu messen, eine Maßnahme zur Zeit. Wer drei Dinge gleichzeitig ändert, weiß nicht, welches gewirkt hat.
6. Referenzwerte festhalten, mit Datum. Ohne Vorher-Wert lässt sich später nicht beurteilen, ob etwas schlechter geworden ist.
Häufige Messfehler
Im eigenen Browser mit gefülltem Cache. Die Seite ist bereits geladen, alles kommt aus dem Zwischenspeicher. Das Ergebnis ist bedeutungslos.
Nur auf dem Desktop messen. Die Mehrheit der Besucher kommt vom Telefon, und dort ist die Rechenleistung geringer.
Direkt nach einer Änderung messen, bevor der Cache neu aufgebaut ist. Der erste Aufruf nach einer Cache-Löschung ist immer der langsamste.
Einmal messen und ein Urteil bilden. Serverlast schwankt.
Nur die Startseite messen. Sie ist häufig die am besten optimierte Seite.
Auf eine Punktzahl optimieren. Eine Punktzahl ist eine Zusammenfassung. Wer sie verbessert, ohne die Felddaten zu prüfen, kann an der falschen Stelle arbeiten.
Was nach der Messung zu tun ist
Die Reihenfolge nach Wirkung ist bei fast jeder Seite dieselbe:
- Bilder auf die benötigte Größe bringen und komprimieren, siehe Bilder optimieren
- Bildmaße im Markup ergänzen
- Schriften lokal ausliefern, auf benötigte Schnitte begrenzen, siehe Webfonts optimieren
- Caching aktivieren, siehe Caching und CDN
- Fremdskripte reduzieren
- Erst danach über Theme, Hosting oder CDN nachdenken
Die ersten drei Schritte sind an einem Nachmittag erledigt und decken bei einer typischen unoptimierten Seite den größten Teil des Potenzials ab.
Dauerhaft beobachten
Eine einmalige Optimierung hält nicht. Jedes neue Plugin, jedes eingebettete Element und jedes große Bild verschlechtert die Werte wieder.
Praktikabel ist eine monatliche Prüfung: Felddaten in der Search Console ansehen, ein Labortest auf der Startseite und einer auf einer Detailseite. Zehn Minuten, und Verschlechterungen fallen auf, solange die Ursache noch bekannt ist.