Website-Ladezeit richtig messen und einordnen
Was LCP, INP und CLS aussagen, warum Desktop-Werte nicht für Mobilgeräte gelten und wie du Performance vor und nach einer Überarbeitung vergleichst.
Zuerst festlegen, was „geladen“ bedeutet
Bis zur ersten Serverantwort, bis zum größten sichtbaren Inhalt und bis zum load-Ereignis vergehen unterschiedliche Zeiten. Eine pauschale Aussage wie „in 0,6 Sekunden geladen“ bleibt ohne Messdefinition begrenzt. Sie sagt nicht automatisch, wann alle Drittanbieter eingebunden sind oder eine Buchung vollständig nutzbar ist.
Für einen Projektvergleich sollten dieselbe URL, dasselbe Werkzeug und vergleichbare Bedingungen verwendet werden. Halte Datum, Teststandort, Gerätesimulation und Cachezustand fest. Wiederhole die Messung und dokumentiere die Streuung, statt nur den schnellsten Einzelwert zu zeigen.
Die drei Core Web Vitals auseinanderhalten
LCP beschreibt, wann das größte relevante Inhaltselement im sichtbaren Bereich erscheint. INP betrachtet die Reaktionszeit auf Interaktionen. CLS bewertet unerwartete Layoutverschiebungen. Eine Website kann schnell sichtbar werden und trotzdem beim Öffnen des Menüs langsam reagieren oder während des Lesens springen.
Google nennt für gute Werte LCP bis 2,5 Sekunden, INP bis 200 Millisekunden und CLS bis 0,1. Bewertet wird bei Felddaten das 75. Perzentil, getrennt nach Mobilgeräten und Desktop. Das bedeutet: Ein einzelner schneller Desktop-Test ist kein Nachweis, dass alle drei Kriterien bei echten Besuchern erfüllt sind.
Warum Labor und echte Besucher abweichen
Ein Labortest arbeitet mit kontrollierten oder simulierten Bedingungen. Reale Besucher nutzen unterschiedliche Geräte, Verbindungen und Browser. Sie öffnen verschiedene Unterseiten und interagieren zu unterschiedlichen Zeitpunkten. Deshalb können Labor- und Felddaten unterschiedliche, jeweils nützliche Informationen liefern.
Labordaten helfen bei der Fehlersuche und beim Vergleich einer konkreten Änderung. Felddaten zeigen, wie die Seite über viele reale Besuche erlebt wird. Wenn für eine kleine Website keine ausreichenden öffentlichen Felddaten vorliegen, ist das kein positives oder negatives Performanceurteil. Die Datenbasis fehlt schlicht.
Die Ursachen in sinnvoller Reihenfolge prüfen
- Erreichbarkeit und Serverantwort: Kommt für wichtige Seiten zuverlässig eine erfolgreiche Antwort?
- Sichtbarer Hauptinhalt: Blockieren große Bilder, Schriften oder Skripte den Einstieg?
- Interaktion: Reagieren Menü, Formular und Auswahlfelder auch unter Last?
- Layout: Haben Bilder, Einbettungen und nachgeladene Bereiche reservierten Platz?
Komprimiere Bilder passend zur tatsächlichen Darstellung und liefere geeignete Größen aus. Prüfe danach, welche Skripte für den ersten Nutzerweg nötig sind. Ein neuer Hostingtarif löst nicht automatisch ein Problem, dessen Ursache im Bildvolumen oder clientseitiger Ausführung liegt.
Wichtige Wege zusätzlich funktional testen
Eine schnelle Startseite reicht für ein Hotel nicht aus. Zimmerauswahl, Datumsfelder, Formular, Übergang zum Buchungssystem und die mobile Nutzung gehören zum eigentlichen Zweck. Miss diese Strecken separat und überprüfe ihre Funktion. Ein Drittanbieter kann andere Laufzeiten und technische Grenzen haben als die eigene Seite.
Performance und Funktion sind deshalb zwei getrennte Prüffragen: Wie schnell erscheint die Oberfläche? Und kann der Gast seine Aufgabe tatsächlich erledigen? Ein grüner Messwert beantwortet nur die erste Frage teilweise.
Ergebnisse ohne Übertreibung kommunizieren
Im Mühlentor-Projekt stehen rund 27 Sekunden vor der technischen Überarbeitung einzelnen Desktop-Messungen von etwa 0,6 Sekunden danach gegenüber. Diese Projektangaben illustrieren die Veränderung. Ohne vollständiges Messprotokoll sollte daraus weder ein universeller Durchschnitt noch eine garantierte mobile Ladezeit gemacht werden.
Für deine eigene Dokumentation empfiehlt sich eine kleine Tabelle mit URL, Messgröße, Bedingungen, Wiederholungen und Median. Ergänze Funktionsprüfungen und verbleibende Abhängigkeiten. So bleibt der Vergleich auch später nachvollziehbar und unterstützt weitere Entscheidungen.
Quellen & Vertiefung
Die verlinkten Originalquellen erläutern die Grundlagen. Rechenbeispiele und Handlungsempfehlungen sind unsere Einordnung.
Häufige Fragen
Sind 100 Lighthouse-Punkte das Ziel?
Der Wert ist eine Orientierung unter Testbedingungen. Entscheidend sind außerdem reale Nutzung, funktionierende Aufgaben und die einzelnen Messgrößen.
Muss ich jede bestehende Website neu entwickeln?
Nein. Zuerst sollten Ursache und Leistungsumfang einer Überarbeitung geklärt werden. Manche Probleme lassen sich gezielt im vorhandenen System beheben.