Ladezeit der Website: woran es meist liegt und was zuerst hilft
Wer auf eine Seite warten muss, springt oft ab, bevor er etwas gelesen hat. Die Ursachen sind selten geheimnisvoll: ein träger Server, zu schwere Dateien, zu viele Skripte und fehlendes Zwischenspeichern.
Kurz zusammengefasst
- Es gibt nicht die eine Ladezeit. Gemessen werden mehrere Zeitpunkte, vom ersten Byte bis zur Bedienbarkeit.
- Die größten Hebel sind meist Bilder, Hosting mit Seiten-Cache und weniger Skripte von Fremdanbietern.
- Komprimierung, wenige Weiterleitungen und sinnvolles Caching kosten wenig Aufwand und wirken bei jedem Besuch.
- Core Web Vitals sind Googles Maß für Ladegefühl, Reaktion und Stabilität des Layouts, ein Signal unter vielen.
- PageSpeed Insights liefert Messwerte und Hinweise. Arbeiten Sie diese nach Wirkung ab, nicht nach Punktzahl.
Was mit Ladezeit gemeint ist
Hinter dem Wort stecken mehrere Momente. Zuerst antwortet der Server, dann erscheint der erste Inhalt, später das größte sichtbare Element, und erst danach lässt sich die Seite zuverlässig bedienen. Wie lange das dauert, hängt vom Gerät, von der Verbindung und vom Ort der Messung ab. Ein Handy mit schwachem Empfang im Zug erlebt dieselbe Seite anders als ein Rechner mit Glasfaser im Büro. Deshalb sagt eine einzelne Zahl wenig. Aussagekräftiger ist ein Vergleich vorher und nachher, unter gleichen Bedingungen gemessen.
Server-Antwortzeit
Bevor irgendetwas angezeigt wird, muss der Server die Seite liefern. Bei Seiten, die ein Baukasten oder ein Redaktionssystem bei jedem Aufruf neu zusammensetzt, steckt hier oft die erste Verzögerung. Ein Gartenbaubetrieb mit vielen Plugins und einem knapp bemessenen Hosting-Paket wartet manchmal spürbar, bis das erste Byte ankommt, obwohl die Bilder gar nicht groß sind.
Helfen können ein Seiten-Cache, der fertige Seiten bereithält, eine aktuelle PHP-Version, weniger Erweiterungen und ein Paket mit ausreichend Leistung. Auch der Standort des Servers spielt eine Rolle: Liegt er in Europa, sind die Wege für Besucher in Deutschland kurz. Rein statische Seiten ohne Datenbank sind hier im Vorteil, weil nichts berechnet werden muss.
Seitengewicht
Das Seitengewicht ist die Summe aller Dateien, die ein Besucher für eine Seite laden muss. Den größten Anteil haben meist Bilder (siehe Bilder optimieren), danach kommen Schriften in mehreren Schnitten, Skripte von Baukästen und Slidern sowie Videos. Die Startseite eines Restaurants mit Hintergrundvideo und fünf Schriftschnitten wiegt schnell mehr, als ein Handy im Mobilfunknetz in angenehmer Zeit lädt. Eine einfache Regel: Jede Datei braucht einen Grund. Was nichts zur Aussage der Seite beiträgt, kann weg oder später nachgeladen werden.
Komprimierung
Textdateien wie HTML, CSS und JavaScript lassen sich vor der Übertragung komprimieren. Der Browser entpackt sie sofort, und es muss deutlich weniger durch die Leitung. Gebräuchlich sind gzip und das neuere Brotli. Auf den meisten Servern ist das ein Schalter in der Konfiguration. Bei Bildern bringt eine zusätzliche Komprimierung dieser Art nichts, weil JPEG, WebP und AVIF schon komprimiert sind. Ob sie aktiv ist, erkennen Sie am Antwortkopf des Servers, der unter Content-Encoding die Kodierung nennt, oder an den Hinweisen der Messwerkzeuge.
Weiterleitungen
Jede Weiterleitung kostet eine zusätzliche Anfrage, bevor die eigentliche Seite geladen wird. Eine Kette über http, https und www ergibt schnell drei Sprünge, die jeder Besucher bei jedem Aufruf mitmacht. Besser ist ein einziger Sprung auf die endgültige Adresse. Aktualisieren Sie außerdem interne Links, die noch auf alte Adressen zeigen, damit sie gar nicht erst umgeleitet werden müssen. Das passende Hintergrundwissen zu Zertifikat und Umleitung finden Sie bei HTTPS und SSL-Zertifikat.
Blockierende Skripte und Stylesheets
Der Browser baut eine Seite schrittweise auf. Trifft er im Kopf der Seite auf ein Skript ohne die Attribute defer oder async, unterbricht er den Aufbau, bis die Datei geladen und ausgeführt ist. Stylesheets halten die Anzeige zurück, bis sie geladen sind, damit die Seite nicht ungestaltet aufblitzt. Beides nennt man blockierend. Bei Skripten helfen defer und async, und nicht benötigte Dateien gehören gar nicht auf die Seite. Ein typischer Fall: Das Plugin für das Kontaktformular lädt seine Dateien auf jeder Unterseite, obwohl das Formular nur auf einer steht. Besonders genau lohnt der Blick auf Skripte von Fremdanbietern, etwa Chat-Fenster, Statistik oder eingebettete Feeds, denn jedes braucht eine eigene Verbindung und lässt sich nicht von Ihnen beschleunigen. Zugleich berührt das den Datenschutz, mehr dazu unter Cookies und Einwilligung.
Caching und HTTP-Version
Beim Caching merkt sich der Browser Dateien, die sich selten ändern, und holt sie beim nächsten Besuch nicht erneut. Gesteuert wird das über den Antwortkopf Cache-Control, der festlegt, wie lange eine Datei als aktuell gilt. Logo, Schriften und Stylesheets eignen sich gut für lange Zeiträume. Damit Änderungen trotzdem ankommen, bekommen solche Dateien oft eine Versionsnummer im Namen: Ändert sich der Name, lädt der Browser die neue Datei sofort. Zusätzlich gibt es den Seiten-Cache auf dem Server, der oben bei der Antwortzeit erwähnt wurde. Beides zusammen macht wiederkehrende Besuche merklich schneller.
Auch die Version des Übertragungsprotokolls spielt mit. Bei HTTP/2 und HTTP/3 laufen viele Dateien gleichzeitig über eine einzige Verbindung, bei HTTP/1.1 muss der Browser dafür mehrere Verbindungen öffnen. Viele Hosting-Pakete bieten HTTP/2 heute von Haus aus an. Wenn nicht, lohnt eine Nachfrage beim Anbieter.
Core Web Vitals in groben Zügen
Google beurteilt die Seitenerfahrung unter anderem mit drei Messgrößen. Largest Contentful Paint (LCP) misst, wann der größte sichtbare Inhalt erscheint. Interaction to Next Paint (INP) zeigt, wie zügig die Seite auf Tippen und Klicken reagiert. Cumulative Layout Shift (CLS) erfasst, wie stark Elemente beim Laden springen. Als gut gelten nach Googles veröffentlichten Grenzwerten ein LCP bis 2,5 Sekunden, ein INP bis 200 Millisekunden und ein CLS bis 0,1. Gemessen wird bevorzugt bei echten Besuchern. Die Werte sind ein Faktor unter vielen. Eine bestimmte Platzierung folgt daraus nicht, und ein hervorragender Wert ersetzt keinen guten Inhalt.
PageSpeed Insights richtig lesen
Das kostenlose Werkzeug von Google zeigt zwei Arten von Ergebnissen. Die Felddaten stammen aus echten Besuchen mit Chrome und stehen nur zur Verfügung, wenn eine Seite genug Besucher hat. Die Labordaten kommen aus einem simulierten Test, der bei jedem Lauf etwas anders ausfällt. Messen Sie deshalb mehrmals und getrennt für Mobilgerät und Desktop. Unter den Ergebnissen stehen Hinweise, die sich nach Einsparung sortieren lassen. Nicht jeder Punkt lohnt den Aufwand, und 100 Punkte sind kein Ziel an sich. Wichtig ist, dass reale Besucher die Seite zügig nutzen können.
Eine sinnvolle Reihenfolge
- Bilder in passender Größe und modernem Format ausliefern
- Hosting prüfen und Seiten-Cache aktivieren
- Skripte und Plugins ausmisten, vor allem von Fremdanbietern
- Schriften auf das Nötige beschränken und selbst ausliefern
- Weiterleitungsketten kürzen und Caching für Dateien einrichten
Erste Einschätzung per Werkzeug
Beim kostenlosen Ladezeit-Check holt der Server von bemuar.com Ihre Seite einmal ab und wertet die Antwort aus. Der Test nennt die Antwortzeit des Servers, die Größe des HTML, die Komprimierung, die Zahl der Skripte, Stylesheets und Bilder, blockierende Skripte im Kopfbereich, Weiterleitungen, HTTP-Version und Cache-Control. Er liest nur den ausgelieferten Quelltext, führt kein JavaScript aus und misst weder die Core Web Vitals noch die Ladezeit in einem Browser. Für diese Werte ist PageSpeed Insights die passende Ergänzung.
Soll Ihre Seite neu aufgebaut werden, beschreibt Webdesign, wie Bemuar dabei vorgeht.
Kontakt
Erzählen Sie kurz, worum es geht. Sie bekommen eine persönliche Antwort per E-Mail oder Telefon.
[email protected]Projekt in Wolfsburg oder direkt in der Region? Für Termine vor Ort ist bemuar.de die richtige Adresse.