Ladezeit der Website testen: Serverantwort und Bremsen im Quelltext

Was der Ladezeit-Check misst

Der Server von bemuar.com ruft die eingegebene Seite einmal ab, folgt allen Weiterleitungen und stoppt für die letzte Station die Zeit bis zum ersten Byte der Antwort, Verbindungsaufbau und Verschlüsselung eingeschlossen. Danach liest er den Quelltext dieser einen Seite. Kein Browser stellt sie dar, Bilder, Schriften und Skripte werden nicht geladen, JavaScript läuft nicht. Die Messung beschreibt also die Serverseite, nicht das, was ein Besucher am Handy erlebt. Sie hängt auch vom Netzweg zwischen dem Server von bemuar.com und Ihrem Hoster ab. Im Ergebnis ist der Bereich Ladezeit zuerst geöffnet, die übrigen fünf Bereiche lassen sich darunter aufklappen.

Serverantwort: die Grenzwerte des Checks

Bis 800 Millisekunden gilt die Antwort als in Ordnung, darüber gibt es einen Hinweis, über 1.500 Millisekunden ein Problem. Diese Schwellen hat Bemuar für den Check festgelegt, eine Norm sind sie nicht. Lange Antwortzeiten entstehen meist dort, wo der Server jede Seite bei jedem Aufruf neu zusammenbaut: in Systemen mit vielen Erweiterungen, ohne Seiten-Cache oder auf knapp bemessenem Hosting. Die erste Messung nach längerer Ruhe kann langsamer ausfallen, weil ein Cache erst gefüllt wird. Welche Stellschrauben es gibt, beschreibt Ladezeit. Liegt die Bremse beim Hosting, übernimmt Bemuar auf Wunsch Hosting, Updates und Backups, siehe Website-Pflege.

Weiterleitungen kommen obendrauf

Die gemessene Serverantwort gilt nur für die Seite, bei der der Check am Ende ankommt. Jede Weiterleitung davor kostet eine zusätzliche Anfrage. Der Check zählt sie: Eine oder zwei gelten als in Ordnung, ab drei gibt es einen Hinweis. Ohne Angabe beginnt er mit https://. Wer die Kette ab der unverschlüsselten Adresse sehen will, gibt http:// mit ein. Eine typische lange Kette führt von http://beispiel.de über https://beispiel.de und https://www.beispiel.de bis zu /start/. Besser führt jede Schreibweise mit einer einzigen Weiterleitung ans Ziel. Welche Adresse am Ende geprüft wurde, steht im Kopf des Ergebnisses.

HTML-Größe und Komprimierung

Gemessen wird das HTML in entpackter Form. Über 500 KB gibt es einen Hinweis, Dateien über 3 MB liest der Check nur bis zu dieser Grenze. So große HTML-Dateien entstehen meist durch eingebettete Daten, direkt in den Code geschriebene Bilder oder Baukästen, die viel Code in jede Seite setzen. Zusätzlich prüft der Check, ob der Server die Antwort komprimiert schickt, etwa mit gzip oder Brotli, und nennt das Verfahren. Fehlt die Komprimierung, gibt es einen Hinweis. Sie lässt sich meist im Hosting-Paket oder in der Server-Konfiguration einschalten.

Zahl der Dateien und blockierende Skripte

Der Check zählt eingebundene Skriptdateien und Stylesheets. Sind es zusammen mehr als 30, gibt es einen Hinweis, weil jede Datei eine eigene Anfrage braucht. Er zählt nur, er lädt die Dateien nicht und kennt deshalb ihre Größe nicht. Außerdem sucht er im Kopfbereich nach Skripten ohne defer oder async, die keine Module sind. Sie halten die Darstellung an, bis sie geladen und ausgeführt sind, der Hinweis nennt ihre Zahl. Oft lässt sich ein Skript mit defer später ausführen oder nur auf den Seiten laden, die es brauchen. Testen Sie die Seite nach solchen Änderungen gründlich, denn nicht jedes Skript verträgt das.

Bilder im Quelltext

Bilder ohne width und height im HTML ergeben einen Hinweis, weil der Browser ohne diese Angaben keinen Platz reservieren kann und das Layout beim Laden springt. Google misst dieses Springen als Cumulative Layout Shift. Als Info ohne Einfluss auf die Punkte nennt der Check Bilder, deren Adresse auf .jpg, .png oder .gif endet, und meldet, wenn bei mehr als vier Bildern keines loading="lazy" trägt. Er liest dabei nur das src-Attribut: Bietet ein picture-Element schon WebP an, zählt das JPG im img-Tag trotzdem mit. Das erste große Bild sollte nicht verzögert laden. Formate und Größen erklärt Bilder optimieren.

HTTP-Version und Cache-Control

Zwei Angaben stehen nur als Info da: die Protokollversion und der Header Cache-Control. Die Version gibt an, wie der Abruf durch den Check übertragen wurde, etwa HTTP/1.1 oder HTTP/2. Ein Browser kann mit demselben Server eine andere Version aushandeln. Bei Cache-Control zeigt der Check den Inhalt des Headers oder meldet, dass er fehlt. Er gilt hier nur für das HTML. Wie lange Bilder, Schriften und Stylesheets im Browser bleiben dürfen, ist oft getrennt eingestellt und lässt sich in den Entwicklerwerkzeugen des Browsers nachsehen.

Core Web Vitals: messen Sie im Browser

Wie schnell der größte Inhalt erscheint, wie zügig die Seite auf Tippen reagiert und wie stark das Layout springt, entsteht erst im Browser. Google nennt dafür Grenzwerte, bis zu denen ein Wert als gut gilt: Largest Contentful Paint bis 2,5 Sekunden, Interaction to Next Paint bis 200 Millisekunden, Cumulative Layout Shift bis 0,1. Diese Werte misst der Ladezeit-Check nicht. PageSpeed Insights von Google zeigt sie, bei ausreichend Besuchen auch aus echten Nutzungsdaten. Der Check ergänzt das um die Serverantwort und um Befunde im Quelltext.

Messungen wiederholen und vergleichen

Einzelne Messungen schwanken, deshalb lohnt der Vergleich mehrerer Durchläufe. Nach jeder Prüfung steht die geprüfte Adresse im Link der Seite, ein Neuladen startet die Messung erneut. Jede Wiederholung zählt zu den 20 Prüfungen, die pro Stunde möglich sind. Ändern Sie zwischen zwei Messungen nur eine Sache, etwa den Cache, dann sehen Sie, was gewirkt hat. Die Sekundenzahl im Kopf des Ergebnisses ist die Dauer der gesamten Prüfung mit robots.txt, Sitemap, http-Variante und Zertifikat, nicht die Ladezeit Ihrer Seite. Antwortet die Seite mit Fehler 403, blockiert vermutlich eine Firewall den Check, der sich als BemuarWebsiteCheck meldet. Die Werte beschreiben dann nur die Fehlerseite.