Wenn Sie eine schnell ladende Website erstellen möchten, müssen Sie als Erstes eine zeitnahe Antwort vom Server auf den HTML-Code einer Seite erhalten. Wenn Sie eine URL in die Adressleiste des Browsers eingeben, sendet der Browser eine GET-Anfrage an den Server, um sie abzurufen. Die erste Anfrage für eine Webseite bezieht sich auf eine HTML-Ressource. Ein wichtiges Leistungsziel besteht darin, sicherzustellen, dass HTML schnell und mit minimalen Verzögerungen eintrifft.
Diese erste HTML-Anfrage durchläuft mehrere Schritte, die jeweils einige Zeit in Anspruch nehmen. Wenn Sie die Zeit für die einzelnen Schritte reduzieren, erhalten Sie eine schnellere Time to First Byte (TTFB). TTFB ist zwar nicht der einzige Messwert, auf den Sie sich im Hinblick auf die Ladezeit von Seiten konzentrieren sollten, aber eine hohe TTFB erschwert es, die als „gut“ gekennzeichneten 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 (eine 301 Moved Permanently-Antwort) oder einer temporären Weiterleitung (einer 302 Found-Antwort).
Weiterleitungen verlangsamen den Seitenaufbau, da der Browser zum Abrufen der Ressource eine zusätzliche HTTP-Anfrage am neuen Speicherort senden muss. Es gibt zwei Arten von Weiterleitungen:
- Weiterleitungen zum selben Ursprung, die vollständig innerhalb Ihres Ursprungs stattfinden. Sie können diese Weiterleitungen vollständig steuern, da die Logik für die Verwaltung ausschließlich auf Ihrem Webserver erfolgt.
- Cross-Origin Weiterleitungen, die von einem anderen Ursprung initiiert werden. Sie haben normalerweise keine Kontrolle über diese Arten von Weiterleitungen.
Ursprungsübergreifende Weiterleitungen werden oft von Anzeigen, URL-Kürzungsdiensten und anderen Diensten von Drittanbietern verwendet. Obwohl ursprungsübergreifende Weiterleitungen nicht von dir gesteuert werden können, solltest du trotzdem darauf achten, dass du mehrere Weiterleitungen vermeidest. Dazu gehört z. B. eine Anzeige, die auf eine HTTP-Seite verweist, die wiederum auf ihre HTTPS-Seite weiterleitet, oder eine ursprungsübergreifende Weiterleitung, die zu deinem Ursprung gelangt, aber dann eine Weiterleitung vom selben Ursprung auslöst.
HTML-Antworten im Cache speichern
Das Caching von HTML-Antworten ist schwierig, da die Antwort Links zu anderen kritischen Ressourcen wie CSS, JavaScript, Bildern und anderen Ressourcentypen enthalten kann. Diese Ressourcen können im jeweiligen Dateinamen einen eindeutigen Fingerabdruck enthalten, der sich je nach Dateiinhalt ändert. Dies bedeutet, dass Ihr im Cache gespeichertes HTML-Dokument nach einer Bereitstellung veraltet sein kann, da es Verweise auf veraltete Unterressourcen enthalten würde.
Allerdings kann eine kurze Cache-Lebensdauer – anstatt kein Caching – Vorteile haben, z. B. dass eine Ressource in einem CDN im Cache gespeichert werden kann. Dadurch verringert sich die Anzahl der Anfragen, die vom Ursprungsserver bereitgestellt werden, und im Browser, sodass Ressourcen erneut validiert und nicht noch einmal heruntergeladen werden. Dieser Ansatz eignet sich am besten für statische Inhalte, die sich in keinem Kontext ändern. Für eine geeignete Zeit zum Caching der Ressourcen kann eine bestimmte Anzahl von Minuten festgelegt werden, die Sie für angemessen halten. Fünf Minuten für statische HTML-Ressourcen sind eine sichere Lösung, um dafür zu sorgen, dass regelmäßige Aktualisierungen nicht unbemerkt bleiben.
Wenn die HTML-Inhalte einer Seite auf irgendeine Weise personalisiert sind, z. B. für einen authentifizierten Nutzer, möchten Sie die Inhalte höchstwahrscheinlich aus verschiedenen Gründen wie Sicherheit und Aktualität gar nicht im Cache speichern. Wenn eine HTML-Antwort vom Browser des Nutzers im Cache gespeichert wird, kannst du den Cache nicht entwerten. In solchen Fällen ist es daher am besten, das Caching von HTML vollständig zu vermeiden.
Eine umsichtige Vorgehensweise beim Caching von HTML könnte darin bestehen, 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 darstellt. Dies geschieht häufig mithilfe eines Hashs der Ressourceninhalte:
ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"
Wenn sich die Ressource ändert, muss ein neuer ETag-Wert generiert werden. Bei nachfolgenden Anfragen sendet der Browser den Wert ETag über den Anfrageheader If-None-Match. Wenn das 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. Das führt zwar trotzdem zu Netzwerklatenz, aber eine 304 Not Modified-Antwort ist viel kleiner als eine gesamte HTML-Ressource.
Die Netzwerklatenz bei der erneuten Validierung der Aktualität einer Ressource ist jedoch immer noch ein Nachteil. Wie bei vielen anderen Aspekten der Webentwicklung sind Kompromisse und Kompromisse unvermeidlich. Sie entscheiden selbst, ob sich der zusätzliche Aufwand, HTML-Inhalte auf diese Weise im Cache zu speichern, lohnt oder ob Sie lieber auf Nummer sicher gehen und HTML-Inhalte überhaupt nicht im Cache speichern müssen.
Serverantwortzeiten messen
Wenn eine Antwort nicht im Cache gespeichert wird, hängt die Antwortzeit des Servers stark vom Hostanbieter und dem Back-End-Anwendungs-Stack ab. Eine Webseite, die eine dynamisch generierte Antwort bereitstellt, z. B. das Abrufen von Daten aus einer Datenbank, kann eine höhere TTFB haben als eine statische Webseite, die sofort und ohne nennenswerte Rechenzeit auf dem Back-End bereitgestellt werden kann. Wenn Sie ein rotierendes Ladesymbol anzeigen und dann alle Daten auf der Clientseite abrufen, verlagert sich der Aufwand von einer besser vorhersehbaren serverseitigen Umgebung in eine potenziell unvorhersehbare clientseitige Umgebung. Den clientseitigen Aufwand zu minimieren, führt in der Regel zu besseren nutzerorientierten Messwerten.
Wenn Nutzer eine langsame TTFB im Feld feststellen, kannst du mithilfe des Server-Timing-Antwortheaders Informationen darüber offenlegen, wo auf dem Server Zeit 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 enthalten. Diese Daten können dann mithilfe der Navigation Timing API von Nutzern vor Ort erfasst und analysiert werden, um festzustellen, ob es bei den Nutzern zu Verzögerungen kommt. Im vorherigen Code-Snippet enthält der Antwortheader zwei Zeitangaben:
- Die Authentifizierung eines Nutzers (
auth), die 55,5 Millisekunden dauerte. - Die Datenbankzugriffszeit (
db), die 220 Millisekunden dauerte.
Du kannst auch deine Hostinginfrastruktur überprüfen und sicherstellen, dass du über ausreichende Ressourcen für die Verarbeitung des Traffics auf deiner Website verfügst. Shared Hosting-Anbieter sind oft anfällig für eine hohe TTFB. Dedizierte Lösungen, die schnellere Antwortzeiten bieten, können kostspieliger sein.
Komprimierung
Textbasierte Antworten wie HTML-, JavaScript-, CSS- und SVG-Bilder sollten komprimiert werden, um ihre Übertragungsgröße über das Netzwerk zu reduzieren und so schneller herunterzuladen. Die am häufigsten verwendeten Komprimierungsalgorithmen sind gzip und Brotli. Mit Brotli lässt sich im Vergleich zu gzip eine Verbesserung um etwa 15 bis 20 % erzielen.
Die Komprimierung wird von den meisten Webhosting-Anbietern häufig automatisch eingerichtet. Wenn du die Komprimierungseinstellungen selbst konfigurieren oder optimieren möchtest, solltest du jedoch einige Dinge beachten:
- Verwenden Sie nach Möglichkeit Brotli. Wie bereits erwähnt, bietet Brotli eine deutliche Verbesserung gegenüber gzip und Brotli wird in allen gängigen Browsern unterstützt. Verwenden Sie nach Möglichkeit Brotli. Wenn Ihre Website jedoch von einer großen Anzahl von Nutzern in älteren Browsern verwendet wird, achten Sie darauf, dass gzip als Fallback verwendet wird, da jede Komprimierung besser als gar keine Komprimierung ist.
- Die Dateigröße spielt eine große Rolle. Sehr kleine Ressourcen – weniger als 1 KiB – werden nicht sehr gut komprimiert oder manchmal gar nicht. Die Effektivität jeder Art der Datenkomprimierung hängt davon ab, ob eine große Datenmenge vorliegt, mit der ein Komprimierungsalgorithmus arbeiten kann, um komprimierbarere Datenbits zu finden. Je größer eine Datei ist, desto besser funktioniert die Komprimierung. Sie sollten jedoch keine sehr großen Ressourcen versenden, nur weil sie effektiver komprimiert werden können. Große Ressourcen wie z. B. JavaScript und CSS benötigen deutlich mehr Zeit zum Parsen und Auswerten, nachdem der Browser sie dekomprimiert hat. Sie können sich häufiger ändern, selbst wenn sie nur geringfügig geändert wurden, da jede Änderung zu einem anderen Datei-Hash führt.
- Dynamische und statische Komprimierung im Vergleich Die dynamische und die statische Komprimierung unterscheiden sich darin, wann eine Ressource komprimiert werden sollte. Die dynamische Komprimierung komprimiert eine Ressource zu dem Zeitpunkt, an dem sie angefordert wird, und manchmal bei jeder Abfrage. Bei der statischen Komprimierung hingegen werden Dateien im Voraus komprimiert, sodass zum Zeitpunkt der Anfrage keine Komprimierung durchgeführt werden muss. Durch die statische Komprimierung wird die Latenz bei der Komprimierung selbst entfernt, die im Fall einer dynamischen Komprimierung die Serverantwortzeiten verlängern kann. Statische Ressourcen wie JavaScript-, CSS- und SVG-Bilder sollten statisch komprimiert werden. HTML-Ressourcen – insbesondere wenn sie für authentifizierte Nutzer dynamisch generiert werden, sollten dynamisch komprimiert werden.
Die Komprimierung selbst ist eine Herausforderung. Oft ist es am besten, ein Content Delivery Network (CDN), das im nächsten Abschnitt beschrieben wird, dies für Sie erledigen zu lassen. Mit diesen Konzepten können Sie jedoch feststellen, ob Ihr Hostanbieter die Komprimierung korrekt verwendet. Dieses Wissen kann Ihnen dabei helfen, Ihre Komprimierungseinstellungen so zu verbessern, dass Sie den größtmöglichen Nutzen für Ihre Website 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 wiederum von Edge-Servern bedienen, die sich physisch näher bei Ihren Nutzern befinden. Die physische Nähe zu Ihren Nutzern reduziert die Umlaufzeit (Round Trip Time, RTT), während Optimierungen wie HTTP/2 oder HTTP/3, Caching und Komprimierung dafür sorgen, dass das CDN Inhalte schneller bereitstellen würde, als wenn sie von Ihrem Ursprungsserver abgerufen werden würden. Die Verwendung eines CDN kann die TTFB Ihrer Website in einigen Fällen erheblich verbessern.
Wissen testen
Welche Art von Weiterleitung können Sie vollständig steuern?
Der Header „Server-Timing“ kann mehrere Messwerte enthalten.
Welcher Servertyp befindet sich am ehesten physisch am nächsten zu Ihren Endnutzern?
Nächster Schritt: Den kritischen Pfad verstehen
Da Sie nun einige der Leistungsaspekte im Zusammenhang mit dem HTML-Code Ihrer Website kennen, sind Sie bestens aufgestellt, um dafür zu sorgen, dass der HTML-Code Ihrer Website so schnell wie möglich geladen wird. Aber das ist erst der Anfang. Als Nächstes wird die Theorie hinter dem kritischen Rendering-Pfad behandelt. In diesem Modul werden Schlüsselkonzepte wie Ressourcen, die das Rendering und das Parsing blockieren, beschrieben. Außerdem erfahren Sie, welche Rolle sie dabei spielen, das anfängliche Rendering einer Seite so schnell wie möglich im Browser zu erhalten.