Warum eine Seite langsam wirkt, obwohl alle Servermetriken zeigen, dass sie schnell ist

Jemand sagt, Ihre Webseite ist langsam. Sie öffnen das Dashboard und alles ist grün. Antwortzeiten im niedrigen Bereich von Millisekunden, keine Fehler, keine Überlastung, nichts über der Schwelle irgendwo.

Beide haben recht, und der Grund ist nicht subtil, wenn man ihn sieht: Ihre Servermetriken und Ihr Besucher messen zwei verschiedene Dinge, und die Überschneidung zwischen ihnen ist kleiner als fast jeder erwartet.

Zwei Uhren, die zu unterschiedlichen Zeiten starten

Die Uhr Ihres Servers startet, wenn eine Anfrage ankommt, und stoppt, wenn sie damit fertig ist, eine Antwort zu schreiben. Dieses Intervall ist das, das Ihre Überwachung meldet, und es ist eine echte Messung einer echten Sache.

Die Uhr des Besuchers startet, wenn er klickt, und stoppt nicht, bis die Seite etwas gezeichnet hat, das er gesucht hat. Zwischen diesen beiden Momenten sitzen: ein DNS- Lookup, eine TCP-Verbindung, ein TLS-Handshake, die Arbeit Ihres Servers, die Antwort auf dem Rückweg, HTML-Parsing, die Stylesheets und Schriftarten und Skripte, die HTML dann anfordert, von denen jedes die meisten der obigen Schritte wiederholt, und schließlich das Rendern.

Ihr Server war an einem Schritt beteiligt. Eine Seite kann 80 Millisekunden auf Ihrem Server verbringen und vier Sekunden damit, nutzbar zu werden, und nichts in Ihrer Anwendungsüberwachung ist falsch, wenn es 80 Millisekunden sagt.

Die Zahl, die den Server beschreibt, und diejenigen, die die Erfahrung beschreiben

Die serverseitige Zahl ist Time to First Byte, die Google als Messung “der Zeit zwischen dem Start der Navigation zu einer Seite und wenn das erste Byte einer Antwort ankommt” beschreibt. Ihre Anleitung ist, dass “die meisten Websites ein TTFB von 0,8 Sekunden oder weniger anstreben sollten”.

Aber sie sind explizit über ihre Grenzen: “Da TTFB kein Core Web Vitals-Metrik ist, ist es nicht absolut notwendig, dass Websites die ‘gute’ TTFB-Schwelle erreichen, sofern es nicht ihre Fähigkeit behindert, bei den Metriken, die wichtig sind, gut zu schneiden.”

Die Metriken, die wichtig sind, sind die drei Core Web Vitals, und jede beantwortet eine Frage, die eine Person tatsächlich erkennen würde.

Largest Contentful Paint ist, wenn das größte Element auf dem Bildschirm das Zeichnen beendet, was der engste maschinelle Proxy für “die Seite erschien” ist. Das Ziel ist, dass “LCP innerhalb von 2,5 Sekunden nach dem Start des Ladens der Seite auftreten sollte”.

Interaction to Next Paint ist, wie lange die Seite dauert, um sichtbar zu reagieren, nachdem jemand damit interagiert: “Seiten sollten ein INP von 200 Millisekunden oder weniger haben”. Es ersetzte First Input Delay als stabiles Core Web Vital im Jahr 2024, und die Änderung ist wichtig. FID maß nur die Verzögerung vor Beginn der Verarbeitung, während INP den ganzen Weg bis zum nächsten Paint misst. Eine Seite, die Ihren Klick sofort akzeptierte und dann eingefroren wurde, schnitt bei der alten Metrik gut ab.

Cumulative Layout Shift geht überhaupt nicht um Geschwindigkeit. Es misst, wie viel sich die Seite beim Laden bewegt, und das Ziel ist “0,1 oder weniger”. Es ist auf dieser Liste, weil eine Seite, die unter Ihrem Daumen springt, auf eine Weise kaputt aussieht, die sich für die Person langsam anfühlt, auch wenn nichts war.

Das Detail, das die meisten dieser Argumente löst

Core Web Vitals werden beim “75. Perzentil der Seitenaufrufe, segmentiert über mobile und Desktop-Geräte” bewertet.

Nicht der Durchschnitt. Das 75. Perzentil, was bedeutet, dass einer von vier Besuchen schlimmer ist als die Zahl, die Sie betrachten. Das ist absichtlich: Ein Durchschnitt wird von den Menschen dominiert, denen es bereits gut ging. Ihre eigenen Besuche sind in dieser komfortablen Mehrheit fast von Konstruktion aus, da Sie in der Nähe Ihrer Server sind, auf einer guten Verbindung, auf einer schnellen Maschine, mit einem warmen Cache.

Wenn also ein Besucher sagt, die Seite ist langsam, und Ihr Dashboard sagt, sie ist schnell, ist die ehrliche Lesart nicht, dass einer von Ihnen sich irrt. Es ist, dass Sie auf den Mittelwert einer Verteilung schauen, deren Ende die gesamte Beschwerde ist.

Schwach

"Seite ist langsam." Dashboard überprüft, p50-Antwortzeit 90 ms, wird als nicht reproduzierbar geschlossen.

Besser

"Langsam auf der Produktseite, etwa 6 Sekunden, bevor etwas angezeigt wird, auf mobilen Daten." LCP ist die Metrik; TTFB war in Ordnung, also geht die Zeit irgendwo hin, nachdem die Antwort ankommt.

Wo die Zeit tatsächlich hingeht

Sobald Sie akzeptieren, dass die Lücke real ist, gibt es nur wenige Orte, an denen sie sich versteckt, und sie sind jedes Mal die gleichen.

Render-blockierende Ressourcen. Die HTML kam schnell an und fragte dann nach einem Stylesheet, und der Browser wird nicht angezeigt, bis er es hat. Jede blockierende Anfrage im Head wird zur Zeit vor dem Anzeigen von etwas addiert.

Schriftarten. Eine Webschrift, die nicht vorgeladen ist, kann Text unsichtbar lassen oder lange nach Abschluss des Layouts neu gestaltet lassen, was sowohl das größte Paint verzögert als auch, falls es reflowiert, der Layoutverschiebung zuführt.

Bilder ohne Dimensionen. Die häufigste Ursache für Layoutverschiebung. Der Browser kann den Platz nicht reservieren, also bewegt sich alles darunter, wenn das Bild ankommt.

JavaScript auf einem langsamen Gerät. Dies ist auf einer Entwicklungsmaschine von Konstruktion aus unsichtbar. Das Parsing und Ausführen eines großen Pakets kostet einen Bruchteil einer Sekunde auf einem Laptop und mehrere Sekunden auf einem Mittelklasse- Telefon, und die Seite reagiert während der ganzen Zeit nicht auf Tippen.

Die Entfernung. Ein Besucher auf der anderen Seite der Welt zahlt die Round Trip mehrmals, bevor Ihr schneller Server überhaupt gefragt wird. Dies ist der gleiche Grund, warum eine Beeinträchtigung eines Services, auf den Sie sich verlassen auf Sie landet, nicht auf den, der es verursacht hat.

Was Sie stattdessen fragen sollten statt “Können Sie präziser sein”

“Es ist langsam” kann nicht umgesetzt werden, aber die drei Dinge, die es umsetzbar machen, sind alle einfach zu fragen, und keines erfordert, dass der Reporter einen der obigen Punkte versteht.

• Welche Seite und worauf haben sie gewartet. Langsam, um überhaupt zu erscheinen, langsam, um nach einem Tippen zu reagieren, oder sich beim Laden herumzubewegen. Das sind drei verschiedene Metriken und drei verschiedene Ursachen.
• Worauf und auf welcher Verbindung. Ein fünf Jahre altes Android auf mobilen Daten und ein Desktop auf Glasfaser sind nicht die gleiche Seite.
• Ungefähr wie lange und ob es immer ist. Der Unterschied zwischen “immer etwa sechs Sekunden” und “manchmal hängt es” ist der Unterschied zwischen einer schweren Seite und einem intermittierenden Fehler. Sie teilen keine Fixes.

Das, was das Ratespiel vollständig entfernt, ist eine Aufzeichnung der Anfragen, wie sie tatsächlich auf ihrer Maschine passiert sind. Das Netzwerk-Log zeigt, wo die Sekunden hingegangen sind, nicht wo Sie denken, dass sie hingegangen sind.

Was man daraus mitnehmen sollte

Ein grünes Dashboard ist kein Beweis, dass die Seite schnell ist. Es ist ein Beweis, dass der Teil, den Sie instrumentiert haben, schnell ist, und dieser Teil ist ein Schritt in einer Sequenz, die der Besucher ganz erlebt.

Messen Sie, was sie erleben, beim Perzentil, in dem die Beschwerden leben, nicht beim Durchschnitt. Behandeln Sie Ihre eigene Erfahrung mit Ihrer eigenen Seite als den am wenigsten repräsentativen Datenpunkt, auf den Sie Zugriff haben.