So prüfen Sie die Geschwindigkeit einer Website

Der schnelle Weg: einen echten Browser-Test ausführen

Geben Sie die URL in einen Page-Speed-Test ein und lassen Sie ihn die Seite in einem echten Browser laden, statt zu schätzen. Ein guter Report gibt Ihnen einen Screenshot dessen, was gerendert wurde, die Gesamtzeiten, und eine Aufschlüsselung pro Anfrage, die zeigt, welches Bild, Skript oder Drittanbieter-Aufruf langsam war. Diese Aufschlüsselung ist es, die aus "die Seite ist langsam" ein "diese eine Schriftdatei blockiert das Rendering für 1,8 Sekunden" macht.

Führen Sie ihn direkt nach einem Deploy aus, nach einem Plugin- oder Theme-Update, und bevor Sie sich auf eine Hosting- oder CDN-Änderung festlegen. Das sind die Momente, in denen sich die Geschwindigkeit ändert und niemand es bemerkt.

Selbst über die Kommandozeile messen

Für die Server-Seite der Geschichte brauchen Sie überhaupt keinen Browser. curl kann seine eigene Zeitaufschlüsselung ausgeben:

curl -o /dev/null -sS -w   "dns:%{time_namelookup}s connect:%{time_connect}s tls:%{time_appconnect}s ttfb:%{time_starttransfer}s total:%{time_total}s\n"   https://example.com/

Das misst nur eine Anfrage für das HTML-Dokument allein, es wird also immer schneller wirken als die echte Seite. Genau deshalb ist es nützlich: Es isoliert den Server vom Browser. Ist ttfb hier hoch, hilft keine noch so gute Bildoptimierung. Ist ttfb niedrig und die Seite fühlt sich trotzdem langsam an, liegt das Problem in dem, was der Browser tun muss, nachdem das HTML angekommen ist.

Was TTFB, LCP und vollständige Ladezeit bedeuten

• Time to First Byte (TTFB). Wie lange der Server brauchte, um mit dem Antworten zu beginnen, einschließlich DNS, Verbindungsaufbau, TLS und der eigenen Verarbeitung des Servers. Ein hoher TTFB deutet auf Hosting, Datenbankabfragen oder Backend-Code, nicht auf die Assets der Seite.
• Largest Contentful Paint (LCP). Wann das größte sichtbare Element im Viewport fertig gerendert war, meist ein Hero-Bild, ein Video-Poster oder ein großer Textblock. Das ist die Zahl, die dem am nächsten kommt, was ein Besucher "als die Seite erschien" nennen würde. Google behandelt 2,5 Sekunden oder weniger als gut.
• Load / vollständige Ladezeit. Wann der Browser mit dem Laden des Dokuments und seiner blockierenden Ressourcen fertig war. Alles, was der Besucher sehen kann, ist normalerweise deutlich vor diesem Zeitpunkt fertig.
• Gesamtzeit bis zur Ruhe. Ladezeit plus alles, was danach noch läuft, etwa Skripte, die Daten abrufen, sobald die Seite fertig aussieht. Eine Seite kann fertig aussehen und trotzdem beschäftigt sein, und diese Arbeit konkurriert mit dem ersten Scroll oder Klick des Besuchers.
• Anfragen und übertragene Bytes. Wie viele Dateien die Seite gezogen hat und wie viel heruntergeladen wurde. Das sind die Hebel hinter fast jeder Zahl oben.

Lesen Sie sie zusammen. Niedriger TTFB mit hohem LCP bedeutet, dass der Browser zu viel tut: zu viele Anfragen, rendering-blockierende Skripte, oder ein riesiges Hero-Bild. Hoher TTFB mit allem anderen normal bedeutet, dass der Server der Engpass ist, noch bevor der Browser überhaupt beteiligt ist.

Warum ein Test von einem Ort in die Irre führt

Es ist normal, dieselbe URL zweimal zu testen und zwei unterschiedliche Ergebnisse zu bekommen, und keines davon ist falsch. Drei Dinge treiben den größten Teil der Streuung:

• Entfernung. Ein Test in der Nähe des Servers hat einen kürzeren Netzwerkpfad als einer von einem anderen Kontinent. Sind Ihre Besucher in Europa und Sie testen aus derselben Stadt wie Ihr Server, messen Sie den Best Case, nicht den typischen Fall.
• Geräteprofil. Ein Test kann ein mobiles Gerät mit kleinerem Viewport, anderem User-Agent und gedrosselter Verbindung emulieren. Eine für Desktop optimierte Seite schneidet unter mobiler Emulation absichtlich sehr unterschiedlich ab.
• Caching und Aufwärmen. Die erste Anfrage kann auf einen kalten Cache am CDN oder in der Anwendung treffen; die zweite wird warm bedient. Führen Sie eine Seite zwei- oder dreimal aus und nutzen Sie das Muster, nicht den einzelnen schnellsten Lauf.

Ein einzelner Test lohnt sich trotzdem. Es bedeutet nur, dass eine Zahl nur zusammen mit den Bedingungen Bedeutung trägt, unter denen sie gemessen wurde.

Wie Sie einen Waterfall lesen

Der Waterfall ist die Zeitleiste pro Anfrage, ein Balken pro Datei, geordnet danach, wann sie begann. Vier Muster tauchen immer wieder auf:

1. Ein langer erster Balken, bevor irgendetwas anderes beginnt. Das ist TTFB auf dem HTML, und alles wartet dahinter in der Schlange.
2. Eine Treppe, bei der jede Anfrage erst beginnt, wenn die vorherige endet. Das ist eine Abhängigkeitskette, meist ein Skript, das ein weiteres Skript lädt, das den eigentlichen Inhalt lädt. Ketten sind das teuerste Muster im Diagramm.
3. Ein breiter Balken in der Mitte von einer Drittanbieter-Domain. Werbung, Chat-Widgets, Analytics und Schriftarten sitzen hier, und ein langsamer Drittanbieter verzögert Ihre eigene Seite, wenn er synchron geladen wird.
4. Ein dichtes Cluster winziger Balken. Dutzende kleiner Dateien, jede mit eigenem Verbindungs-Overhead. Weniger, größere, gecachte Dateien schlagen meist viele kleine.

Balken in Rot oder mit 4xx- und 5xx-Codes verdienen Aufmerksamkeit, auch wenn die Seite gut aussieht, denn eine fehlschlagende Anfrage kostet trotzdem Zeit, bevor sie fehlschlägt.

Eine Verlangsamung erwischen, nach der niemand gesucht hat

Ein einzelner Test sagt Ihnen, wie die Seite einmal abgeschnitten hat, von einem Ort, auf einem Geräteprofil. Das ist es, was Sie wollen, wenn Sie etwas Bestimmtes untersuchen. Es ist nicht das, was Sie wollen, wenn das Ziel ist, eine Verlangsamung überhaupt zu bemerken: Seiten werden Update für Update schwerer, und niemand führt an einem ruhigen Dienstag einen manuellen Test aus. Geplantes Page-Speed-Monitoring führt denselben Test im Intervall von denselben Standorten aus, hält die Historie fest und alarmiert, wenn die Zahlen einen Schwellenwert überschreiten. Führen Sie jetzt einen mit dem Page-Speed-Test aus, und sehen Sie sich Server-Antwortzeit an, falls sich herausstellt, dass der langsame Teil der Server ist.