Der erste Schritt beim Erstellen einer Website, die schnell geladen wird, besteht darin, eine zeitnahe Antwort vom Server für das HTML einer Seite zu erhalten. Wenn Sie eine URL in die Adressleiste des Browsers eingeben, sendet der Browser eine GET-Anfrage an den Server, um die Seite abzurufen. Die erste Anfrage für eine Webseite ist für eine HTML-Ressource. Es ist ein wichtiges Leistungsziel, dafür zu sorgen, dass HTML schnell und mit minimalen Verzögerungen eintrifft.
Diese erste Anfrage nach HTML durchläuft mehrere Schritte, die jeweils einige Zeit in Anspruch nehmen. Wenn Sie die für jeden Schritt benötigte Zeit verkürzen, erhalten Sie eine schnellere Time to First Byte (TTFB). Die TTFB ist zwar nicht der einzige Messwert, auf den Sie sich konzentrieren sollten, wenn es um die Ladegeschwindigkeit von Seiten geht, aber eine hohe TTFB erschwert es, die festgelegten „guten“ Grenzwerte für Messwerte wie Largest Contentful Paint (LCP) und First Contentful Paint (FCP) zu erreichen.
Umleitungen minimieren
Wenn eine Ressource angefordert wird, kann der Server mit einer Weiterleitung antworten, entweder mit einer permanenten Weiterleitung (301 Moved Permanently-Antwort) oder einer temporären Weiterleitung (302 Found-Antwort).
Weiterleitungen verlangsamen die Seitenladezeit, da der Browser eine zusätzliche HTTP-Anfrage am neuen Speicherort stellen muss, um die Ressource abzurufen. Es gibt zwei Arten von Weiterleitungen:
- Umleitungen mit demselben Ursprung, die vollständig innerhalb Ihres Ursprungs erfolgen. Diese Arten von Weiterleitungen liegen vollständig in Ihrer Hand, da die Logik für die Verwaltung dieser Weiterleitungen ausschließlich auf Ihrem Webserver vorhanden ist.
- Ursprungsübergreifende Weiterleitungen, die von einem anderen Ursprung initiiert werden. Diese Arten von Weiterleitungen liegen in der Regel außerhalb Ihrer Kontrolle.
Cross-Origin-Weiterleitungen werden häufig von Anzeigen, URL-Kürzungsdiensten und anderen Drittanbieterdiensten verwendet. Auch wenn Sie keinen Einfluss auf Weiterleitungen zwischen verschiedenen Ursprüngen haben, sollten Sie darauf achten, dass es nicht zu mehreren Weiterleitungen kommt. Das kann beispielsweise der Fall sein, wenn eine Anzeige auf eine HTTP-Seite verweist, die wiederum auf die entsprechende HTTPS-Seite weiterleitet, oder wenn eine Weiterleitung zwischen verschiedenen Ursprüngen zu Ihrem Ursprung führt, aber dann eine Weiterleitung zum selben Ursprung auslöst.
HTML-Antworten im Cache speichern
Das Zwischenspeichern von HTML-Antworten ist schwierig, da die Antwort möglicherweise Links zu anderen wichtigen Ressourcen wie CSS, JavaScript, Bildern und anderen Ressourcentypen enthält. Diese Ressourcen können in ihren jeweiligen Dateinamen einen eindeutigen Fingerabdruck enthalten, der sich je nach Inhalt einer Datei ändert. Das bedeutet, dass Ihr im Cache gespeichertes HTML-Dokument nach einer Bereitstellung möglicherweise veraltet ist, da es Verweise auf veraltete untergeordnete Ressourcen enthält.
Dennoch kann eine kurze Cache-Lebensdauer – anstatt gar kein Caching – Vorteile haben, z. B. dass eine Ressource in einem CDN im Cache gespeichert werden kann, wodurch die Anzahl der Anfragen, die vom Ursprungsserver bereitgestellt werden, reduziert wird. Im Browser können Ressourcen neu validiert werden, anstatt sie noch einmal herunterzuladen. Dieser Ansatz eignet sich am besten für statische Inhalte, die sich in keinem Kontext ändern. Die Ressourcen können für eine bestimmte Anzahl von Minuten gecacht werden, die Sie für angemessen halten. Fünf Minuten für statische HTML-Ressourcen sind ein guter Wert und sorgen dafür, dass regelmäßige Updates nicht unbemerkt bleiben.
Wenn der HTML-Inhalt einer Seite in irgendeiner Weise personalisiert ist, z. B. für einen authentifizierten Nutzer, sollten Sie aus verschiedenen Gründen, darunter Sicherheit und Aktualität, wahrscheinlich überhaupt keine Inhalte im Cache speichern. Wenn eine HTML-Antwort im Browser des Nutzers zwischengespeichert wird, können Sie den Cache nicht ungültig machen. Daher ist es in solchen Fällen am besten, HTML-Caching ganz zu vermeiden.
Eine vorsichtige Methode zum Caching von HTML besteht darin, die Antwortheader ETag oder Last-Modified zu verwenden. Ein ETag-Header (auch als Entitäts-Tag bezeichnet) ist eine Kennung, die die angeforderte Ressource eindeutig repräsentiert, oft durch Verwendung eines Hashs des Inhalts der Ressource:
ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"
Immer wenn sich die Ressource ändert, muss ein neuer ETag-Wert generiert werden. Bei nachfolgenden Anfragen sendet der Browser den ETag-Wert über den If-None-Match-Anfrageheader. Wenn der ETag auf dem Server mit dem vom Browser gesendeten übereinstimmt, antwortet der Server mit einer 304 Not Modified-Antwort und der Browser verwendet die Ressource aus dem Cache. Dadurch entsteht zwar immer noch eine Netzwerklatenz, aber eine 304 Not Modified-Antwort ist viel kleiner als eine vollständige HTML-Ressource.
Die Netzwerklatenz, die mit der erneuten Validierung der Aktualität einer Ressource verbunden ist, ist jedoch ein Nachteil. Wie bei vielen anderen Aspekten der Webentwicklung sind Kompromisse unvermeidlich. Es liegt an Ihnen, zu entscheiden, ob sich der zusätzliche Aufwand für das Caching von HTML auf diese Weise lohnt oder ob es besser ist, auf Nummer sicher zu gehen und HTML-Inhalte überhaupt nicht zu cachen.
Serverantwortzeiten messen
Wenn eine Antwort nicht im Cache gespeichert ist, hängt die Antwortzeit des Servers stark von Ihrem Hostinganbieter und dem Backend-Anwendungsstack ab. Eine Webseite, die eine dynamisch generierte Antwort liefert, z. B. durch Abrufen von Daten aus einer Datenbank, hat möglicherweise eine höhere TTFB als eine statische Webseite, die ohne nennenswerte Rechenzeit im Backend sofort bereitgestellt werden kann. Wenn ein Ladesymbol angezeigt und dann alle Daten auf der Clientseite abgerufen werden, wird der Aufwand von einer eher vorhersehbaren serverseitigen Umgebung in eine potenziell unvorhersehbare clientseitige Umgebung verlagert. Wenn Sie den clientseitigen Aufwand minimieren, verbessern sich in der Regel nutzerorientierte Messwerte.
Wenn Nutzer im Feld einen langsamen TTFB feststellen, können Sie mithilfe des Server-Timing-Antwortheaders Informationen dazu bereitstellen, wo die Zeit auf dem Server verbracht wurde:
Server-Timing: auth;dur=55.5, db;dur=220
Der Wert eines Server-Timing-Headers kann mehrere Messwerte sowie eine Dauer für jeden Messwert enthalten. Diese Daten können dann mithilfe der Navigation Timing API von Nutzern erhoben und analysiert werden, um festzustellen, ob es zu Verzögerungen kommt. Im vorherigen Code-Snippet enthält der Antwortheader zwei Zeitangaben:
- Die Zeit, die für die Authentifizierung eines Nutzers (
auth) benötigt wurde, betrug 55,5 Millisekunden. - Die Datenbankzugriffszeit (
db) betrug 220 Millisekunden.
Prüfen Sie auch Ihre Hosting-Infrastruktur und stellen Sie sicher, dass Sie über genügend Ressourcen verfügen, um den Traffic auf Ihrer Website zu bewältigen. Shared-Hosting-Anbieter sind oft anfällig für eine hohe TTFB. Dedizierte Lösungen, die schnellere Reaktionszeiten bieten, sind möglicherweise teurer.
Komprimierung
Textbasierte Antworten wie HTML, JavaScript, CSS und SVG-Bilder sollten komprimiert werden, um ihre Übertragungsgröße im Netzwerk zu reduzieren und sie schneller herunterzuladen. Die am häufigsten verwendeten Komprimierungsalgorithmen sind gzip und Brotli. Brotli führt zu einer Verbesserung von etwa 15 bis 20 % gegenüber Gzip.
Die Komprimierung wird oft automatisch von den meisten Webhosting-Anbietern eingerichtet. Wenn Sie die Komprimierungseinstellungen jedoch selbst konfigurieren oder optimieren können, sollten Sie Folgendes beachten:
- Nach Möglichkeit Brotli verwenden: Wie bereits erwähnt, bietet Brotli eine ziemlich deutliche Verbesserung gegenüber Gzip und Brotli wird in allen wichtigen Browsern unterstützt. Verwenden Sie nach Möglichkeit Brotli. Wenn Ihre Website jedoch von vielen Nutzern mit älteren Browsern verwendet wird, sollten Sie Gzip als Fallback verwenden, da jede Komprimierung besser ist als keine.
- Die Dateigröße ist wichtig. Sehr kleine Ressourcen (weniger als 1 KiB) lassen sich nicht gut oder manchmal gar nicht komprimieren. Die Effektivität jeder Art von Datenkomprimierung hängt davon ab, dass eine große Menge an Daten vorhanden ist, mit der ein Komprimierungsalgorithmus arbeiten kann, um komprimierbare Bits zu finden. Je größer eine Datei ist, desto besser funktioniert die Komprimierung. Sie sollten jedoch nicht sehr große Ressourcen nur deshalb bereitstellen, weil sie effektiver komprimiert werden können. Große Ressourcen wie JavaScript und CSS benötigen nach dem Entpacken durch den Browser deutlich mehr Zeit zum Parsen und Auswerten. Außerdem können sie sich häufiger ändern, auch wenn die Änderungen nur geringfügig sind, da jede Änderung zu einem anderen Dateihash führt.
- Dynamische und statische Komprimierung Dynamische und statische Komprimierung sind unterschiedliche Ansätze, um festzulegen, wann eine Ressource komprimiert werden soll. Bei der dynamischen Komprimierung wird eine Ressource zum Zeitpunkt der Anfrage und manchmal bei jeder Anfrage komprimiert. Bei der statischen Komprimierung werden Dateien dagegen im Voraus komprimiert. Zum Zeitpunkt der Anfrage ist keine Komprimierung erforderlich. Bei der statischen Komprimierung wird die Latenz entfernt, die durch die Komprimierung selbst entsteht. Bei der dynamischen Komprimierung kann dies zu längeren Serverantwortzeiten führen. Statische Ressourcen wie JavaScript, CSS und SVG-Bilder sollten statisch komprimiert werden, während HTML-Ressourcen – insbesondere, wenn sie dynamisch für authentifizierte Nutzer generiert werden – dynamisch komprimiert werden sollten.
Die Komprimierung selbst zu optimieren ist schwierig. Daher ist es oft am besten, diese Aufgabe einem Content Delivery Network (CDN) zu überlassen, das im nächsten Abschnitt beschrieben wird. Wenn Sie diese Konzepte kennen, können Sie jedoch besser beurteilen, ob Ihr Hosting-Anbieter die Komprimierung richtig verwendet. So können Sie Ihre Komprimierungseinstellungen optimieren, um die bestmögliche Leistung für Ihre Website zu erzielen.
Content Delivery Networks (CDNs)
Ein Content Delivery Network (CDN) ist ein verteiltes Netzwerk von Servern, die Ressourcen von Ihrem Ursprungsserver im Cache speichern und sie dann von Edge-Servern bereitstellen, die sich physisch näher an Ihren Nutzern befinden. Die physische Nähe zu Ihren Nutzern verkürzt die Round-Trip-Zeit (RTT). Optimierungen wie HTTP/2 oder HTTP/3, Caching und Komprimierung ermöglichen es dem CDN, Inhalte schneller bereitzustellen, als wenn sie von Ihrem Ursprungsserver abgerufen würden. Durch die Verwendung eines CDN kann der TTFB Ihrer Website in einigen Fällen erheblich verbessert werden.
Wissen testen
Welche Art von Weiterleitung haben Sie vollständig unter Kontrolle?
Der Server-Timing-Header kann mehrere Messwerte enthalten.
Welcher Servertyp befindet sich wahrscheinlich am nächsten an Ihren Endnutzern?
Als Nächstes: Kritischen Pfad verstehen
Nachdem Sie sich mit einigen Leistungsaspekten des HTML Ihrer Website vertraut gemacht haben, können Sie dafür sorgen, dass es so schnell wie möglich geladen wird. Das ist jedoch erst der Anfang. Als Nächstes wird die Theorie hinter dem kritischen Renderingpfad behandelt. In diesem Modul werden wichtige Konzepte wie render- und parsing-blockierende Ressourcen beschrieben und es wird erläutert, welche Rolle sie dabei spielen, die erste Darstellung einer Seite im Browser so schnell wie möglich zu ermöglichen.