Ladegeschwindigkeit der Website mit webpagetest.org testen

Das Thema Ladegeschwindigkeit ist kein Neues: schon zu Beginn des Webs war die Ladezeit ein wichtiger Faktor für den Erfolg einer Website – die Bandbreite der Internetanschlüsse war so gering – erinnern wir uns: 56k Modems waren Ende der 1990er Jahre oftmals das Höchste der Gefühle; heute sind Anschlüsse mit 100 MBit und mehr keine Seltenheit -, dass bereits ein paar hundert Kilobyte die Obergrenze für eine Seite war, bei der eine anständige Ladezeit möglich war.

Mit steigender Bandbreite hat sich die Lage im Bereich Desktop Computer zumindest theoretisch einigermaßen entspannt. Die immer größere Nutzung von mobilen Endgeräten und immer größerer Bildschirme mit hoher Auflösung (damals, Ende der 1990er, z. B. 19″ mit 1.200 x 800 Pixel, heute, z. B. 27″ mit 2.560 x 1.440 Pixel) versetzt die Website Betreiber in eine ähnliche Lage wie damals – es ist ein bisschen dasselbe Problem wie das Smartphone-Akku Problem: Akkus werden immer leistungsfähiger, aber die Geräte verbrauchen immer mehr Strom.

Heute bekommt die Ladezeit eine neue Dimension: Suchmaschinen, allen voran Google, integrieren die Ladezeit in die Berechnung des Indexes. Vereinfacht gesagt: Je langsamer eine Website lädt, umso weiter hinten wird sie in Suchergebnissen angezeigt. Spätestens seit diesem Zeitpunkt ist das Thema bei professionellen Website Betreibern angekommen und ein regelrechtes Wettrennen hat begonnen. Stand 2026: Google bewertet das Ladeerlebnis vor allem über die Core Web Vitals – Largest Contentful Paint (LCP, wann der größte sichtbare Inhalt geladen ist), Interaction to Next Paint (INP, wie schnell die Seite auf Eingaben reagiert) und Cumulative Layout Shift (CLS, wie stark das Layout beim Laden springt). Das ist ein Ranking-Faktor unter vielen; guter Inhalt bleibt wichtiger.

Es gibt mehrere Ebenen auf denen sich Optimierungen bemerkbar machen können. Einerseits die mit der Verbindung an sich zu tun haben, bzw. mit der „Power“ – im Autovergleich: die Anzahl PS, ob das Auto aerodynamisch ist, wie viel es wiegt… Andererseits ob eine Website gut gebaut ist, unnötige Ladevorgänge von Elementen verhindert – im Autovergleich: der Fahrer; fährt er denn optimal, kennt er die Strecke oder muss er an allen Ampeln stehen bleiben? Es gibt sicher bessere Vergleiche als die mit dem Auto 😉 Jedenfalls werden die 2 Ebenen in den folgenden Absätzen genauer erklärt.

• Infrastruktur: generell spielt es eine Rolle ob die Website auf einem Shared Hosting Server oder einem dedicated Server betrieben wird. Die Geschwindigkeit beginnt bereits bei der Internet-Anbindung des Rechenzentrums und wie die Router des Anbieters die verschiedenen Server verbindet. Daraus resultiert nicht nur die Geschwindigkeit sondern auch der sogenannte Time to first Byte, eine Messgröße für die Zeit, die benötigt wird bis der erste Byte vom Server beim Client ankommt.
• Web Server: der Webserver spielt ebenfalls eine Rolle in der Optimierung. Ganz allgemein sind Webserver mit Nginx schneller als Apache – das muss nicht unbedingt so sein, mit etwas Konfigurationsarbeit kann auch Apache fliegen. Aber nicht nur der Wechsel der Software bringt Geschwindigkeit. Auch Einstellungen wie Keep-Alive führen dazu, dass die Verbindung zum Webserver nicht nach jedem Request neu verhandelt werden muss.
• Caching ist ein komplexes Thema, da es auf vielen Ebenen Caching gibt (CDN, HTTP Reverse Proxy wie Varnish Cache, local Cache, Datenbank Cache wie memcached oder Redis, …). Caching gehört zu den effektivsten Optionen, um die Ladezeit zu verkürzen, je nach dem wie es eingesetzt wird. Es sei angemerkt, dass nicht immer alles gecacht werden kann – Seiten mit hoher Änderungsfrequenz wie z. B. Nachrichtenportale möchten, dass Besucher immer die neuesten Artikel zu sehen bekommen.

Hier in kürze die Bedeutung der 6 Punkte:

1. First Byte Time: Dauer für den Empfang des ersten Bytes des Webservers. Dieser Wert lässt sich vor allem auf Hosting-Ebene beeinflussen, z. B. durch Caching. Der Wert ist abhängig von der physikalischen Hosting-Umgebung (Rechenzentrum, Server) und der momentanen Auslastung der Systeme.
2. Keep-alive enabled: Option des Webservers, die bewirkt, dass die Verbindung zwischen Server und Browser offen bleibt und somit vermieden wird, dass jedes Mal der TCP-Handshake neu ausgehandelt werden soll. Eine Webseite hat oftmals 100 oder mehr Elemente, die geladen werden sollen – da kann eine vermeintlich kleine Optimierung schon mal was bewirken. Mit HTTP/2 und HTTP/3 werden heute ohnehin viele Dateien parallel über eine Verbindung geladen.
3. Compress transfer: ebenfalls eine Webserver-Einstellung. Der Webserver kann die Daten komprimiert übertragen, sodass weniger Daten übertragen werden brauchen. Moderne Browser können inzwischen alle mit komprimierten Datenübertragung umgehen.
4. Compress images: hier sind die Website-Betreiber gefragt. Der Indikator zeigt wie gut die Bilder, die geladen werden, komprimiert sind. Lässt sich die Größe (ohne Qualitätsverlust) verringern?
5. Cache static content: kommen die angezeigten Elemente vom Cache oder wurden diese frisch vom Webserver ausgegeben?
6. Effective use of CDN: werden die Inhalte von einem CDN (Content Delivery Network) ausgegeben?

In der oberen Tabelle sind weitere Werte abzulesen, die als Ergebnis des Geschwindigkeitstests zu verstehen sind. Hier wird die Geschwindigkeit der Anzeige der Website in einzelne Stufen unterteilt, um besser nachzuvollziehen, wo die Ladezeiten entstehen.