Allgemeine Hinweise zur HTML-Leistung

Der erste Schritt zur Erstellung einer schnell ladenden Website besteht darin, Antwort vom Server für den HTML-Code einer Seite. Wenn Sie eine URL in das Feld in die Adressleiste des Browsers ein, sendet der Browser eine GET-Anfrage an den Server, um abrufen können. Die erste Anfrage für eine Webseite ist eine HTML-Ressource – und dass HTML schnell und mit minimalen Verzögerungen ankommt, Ziel.

Diese erste HTML-Anforderung durchläuft mehrere Schritte, die jeweils einen etwas Zeit widmen. Wenn Sie weniger Zeit für die einzelnen Schritte aufwenden, können Sie die First Byte (TTFB). TTFB ist zwar nicht der einzige Messwert, auf den Sie sich in Bezug auf die Geschwindigkeit der Seiten. Eine hohe TTFB erschwert jedoch, die als „gut“ gekennzeichnete Grenzwerte für Messwerte wie Largest Contentful Paint (LCP) und First Contentful Paint (FCP).

Umleitungen minimieren

Wenn eine Ressource angefordert wird, antwortet der Server mit einer Weiterleitung, entweder mit einer permanenten Weiterleitung (301 Moved Permanently-Antwort) oder einer temporären Weiterleitung one (eine 302 Found-Antwort).

Weiterleitungen verlangsamen die Seitenladezeit, da der Browser zusätzliche HTTP-Anfrage an den neuen Speicherort senden, um die Ressource abzurufen. Es gibt zwei Arten von Weiterleitungen:

1. Weiterleitungen am selben Ursprung, die vollständig innerhalb Ihres Ursprungs erfolgen. Diese Typen der Weiterleitungen liegen vollständig in eurer Kontrolle, da die Logik zur Verwaltung befinden sie sich vollständig auf Ihrem Webserver.
2. Ursprungsübergreifende Weiterleitungen, die von einem anderen Ursprung initiiert werden. Diese Arten von haben Sie normalerweise keine Kontrolle.

Ursprungsübergreifende Weiterleitungen werden oft von Anzeigen, URL-Kürzungsdiensten und anderen von Drittanbietern. Auch wenn Sie ursprungsübergreifende Weiterleitungen nicht beeinflussen können, solltet ihr mehrere Weiterleitungen vermeiden, z. B. Anzeigen enthalten, die auf eine HTTP-Seite verweisen, die wiederum auf deren HTTPS-Seite verweist oder eine ursprungsübergreifende Weiterleitung an Ihren Ursprung, löst eine Weiterleitung am selben Ursprung aus.

HTML-Antworten im Cache speichern

Das Caching von HTML-Antworten ist schwierig, da die Antwort Links zu Andere wichtige Ressourcen wie CSS, JavaScript, Bilder und andere Ressourcen Typen. Diese Ressourcen können einen eindeutigen Fingerabdruck in ihrem jeweiligen Dateinamen, die sich je nach Dateiinhalt ändern. Das bedeutet, dass Ihre im Cache gespeicherten Das HTML-Dokument kann nach einer Bereitstellung veraltet sein, da es Verweise auf veraltete Unterressourcen.

Trotzdem kann eine kurze Cache-Lebensdauer statt kein Caching Vorteile haben. z. B. das Caching einer Ressource in einem CDN, wodurch sich die Anzahl der -Anfragen, die vom Ursprungsserver und im Browser bereitgestellt werden, nicht noch einmal heruntergeladen, sondern neu validiert werden. Dieser Ansatz funktioniert am besten für statische Inhalte, die sich in keinem Kontext ändern, und eine geeignete Zeit zum Zwischenspeichern der Ressourcen kann auf eine Anzahl von Minuten eingestellt werden, die Sie für angemessen sein. Fünf Minuten für statische HTML-Ressourcen sind sicher und dass regelmäßige Updates nicht unbemerkt bleiben.

Wenn der HTML-Inhalt einer Seite in irgendeiner Weise personalisiert ist, z. B. für eine authentifizierten Nutzer – Sie möchten höchstwahrscheinlich überhaupt keinen Inhalt für einen Sicherheit und Datenschutz und Aktualität. Wenn eine HTML-Antwort im Browser des Nutzers gespeichert wurde, können Sie den Cache nicht entwerten. Es ist Daher sollten Sie in solchen Fällen gänzlich vermeiden, HTML im Cache zu speichern.

Ein vorsichtiger Ansatz beim Caching von HTML-Code könnte in der Verwendung von ETag oder Last-Modified-Antwortheadern. Ein ETag, auch als Entität bezeichnet Tag: Der Header ist eine Kennung, die die angeforderte Ressource eindeutig darstellt. Häufig wird ein Hash des Ressourceninhalts verwendet:

ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"

Jedes Mal, wenn sich die Ressource ändert, muss ein neuer ETag-Wert generiert werden. An nachfolgende Anfragen sendet der Browser den ETag-Wert über die If-None-Match-Anfrageheader. Wenn ETag auf dem Server mit dem übereinstimmt vom Browser gesendet wird, antwortet der Server mit einer 304 Not Modified-Antwort, und der Browser verwendet die Ressource aus dem Cache. Auch wenn dies immer noch Netzwerklatenz ist die 304 Not Modified-Antwort deutlich kleiner als ein ganzes HTML-Ressource.

Die mit der erneuten Validierung der Aktualität einer Ressource verbundene Netzwerklatenz beträgt jedoch immer noch eine Art Nachteil. Wie bei vielen anderen Aspekten der Webentwicklung Kompromisse und Kompromisse sind unvermeidlich. Sie müssen herausfinden, dass sich zusätzlicher Aufwand, HTML auf diese Weise im Cache zu speichern, lohnt oder und sich nicht mit dem Caching von HTML-Inhalten im Cache beschäftigen.

Serverantwortzeiten messen

Wenn eine Antwort nicht im Cache gespeichert wird, hängt die Antwortzeit des Servers stark von Ihren Hostanbieter und Ihren Back-End-Anwendungs-Stack. Eine Webseite, die eine dynamisch generierte Antwort – wie das Abrufen von Daten aus einer Datenbank für Beispiel: Sie haben eine höhere TTFB als eine statische Webseite, ohne nennenswerte Rechenzeit am Back-End. Ein Rotierendes Ladesymbol und anschließendes Abrufen aller Daten auf der Clientseite verschiebt sich besser vorhersehbarer serverseitiger Umgebung zu einer potenziell unvorhersehbaren Umgebung wechseln, auf der Client-Seite. Das Minimieren des clientseitigen Aufwands führt in der Regel zu nutzerorientierte Messwerte nutzen können.

Wenn die TTFB im Feld langsam ist, kannst du Informationen danach, wo Zeit auf dem Server durch die Verwendung von Server-Timing verbracht wurde Antwortheader:

Server-Timing: auth;dur=55.5, db;dur=220

Der Wert eines Server-Timing-Headers kann mehrere Messwerte sowie einen Dauer der einzelnen Elemente. Diese Daten können dann von Nutzern vor Ort erfasst werden. mithilfe der Navigation Timing API ermittelt und analysiert, ob Nutzer Verzögerungen. Im vorherigen Code-Snippet enthält der Antwortheader zwei Timings:

• Die Authentifizierung eines Nutzers (auth), die 55,5 Millisekunden dauerte.
• Die Datenbankzugriffszeit (db), die 220 Millisekunden dauerte.

Sie können auch Ihre Hostinginfrastruktur überprüfen und bestätigen, dass Sie über ausreichende Ressourcen verfügen, um den Traffic, den Ihre Website erhält, zu bewältigen. Freigegeben Hostanbieter sind oft anfällig für eine hohe TTFB und spezielle Lösungen mit kürzeren Antwortzeiten, kann jedoch teurer sein.

Komprimierung

Textbasierte Antworten wie HTML-, JavaScript-, CSS- und SVG-Bilder sollten komprimiert, um die Übertragungsgröße über das Netzwerk zu reduzieren, damit sie schneller herunterladen können. Die am häufigsten verwendeten Komprimierungsalgorithmen sind gzip und Brotli. Brotli führt im Vergleich zu gzip zu einer Verbesserung von etwa 15 bis 20 %.

Die Komprimierung wird von den meisten Webhosting-Anbietern oft automatisch eingerichtet, aber gibt es einige wichtige Dinge zu beachten, wenn Sie in der Lage sind, oder die Komprimierungseinstellungen selbst anpassen:

1. Verwenden Sie nach Möglichkeit Brotli. Wie bereits erwähnt bietet Brotli eine spürbare Verbesserung gegenüber gzip. Brotli wird in allen großen Browser. Verwenden Sie nach Möglichkeit Brotli. Wenn Ihre Website jedoch von vielen mehr Nutzer älterer Browser verwenden, sollten Sie gzip als Fallback verwenden. da jede Komprimierung besser ist als gar keine.
2. Auf die Dateigröße kommt es an. Sehr kleine Ressourcen – weniger als 1 KiB – werden nicht komprimiert oder manchmal gar nicht komprimieren. Effektivität aller Art der Datenkomprimierung hängt von einer großen Datenmenge ab, Komprimierungsalgorithmus verwendet werden, um mehr komprimierbare Bits zu finden von Daten. Je größer eine Datei ist, desto besser funktioniert die Komprimierung. sehr große Ressourcen zu liefern, da sie lediglich stärker komprimiert werden können. effektiv einsetzen. Große Ressourcen wie z. B. JavaScript und CSS bedeutend mehr Zeit für die Analyse und Auswertung, nachdem der Browser dekomprimiert und können sich häufiger ändern, selbst wenn sie nur nur geringfügig geändert, da jede Änderung zu einem anderen Datei-Hash führt.
3. Informationen zur dynamischen und statischen Komprimierung Dynamisch und statisch sind unterschiedliche Ansätze bei der Komprimierung, wann eine Ressource komprimiert. Bei der dynamischen Komprimierung wird eine Ressource bei der Aufnahme angefordert und manchmal bei jeder Anfrage gesendet werden. Im Gegensatz dazu Bei der statischen Komprimierung werden die Dateien im Voraus ohne Komprimierung komprimiert. die zum Zeitpunkt der Anfrage durchgeführt werden müssen. Durch die statische Komprimierung wird Latenz der Komprimierung selbst, die die Serverantwort erhöhen kann bei dynamischer Komprimierung. Statische Ressourcen wie JavaScript-, CSS- und SVG-Bilder sollten statisch komprimiert sein, während HTML-Bilder komprimiert sein sollten. Ressourcen, insbesondere, wenn sie dynamisch für authentifizierte sollten dynamisch komprimiert werden.

Die richtige Kompression ist keine leichte Aufgabe. ein Content Delivery Network (CDN), das im nächsten Abschnitt erläutert wird, dies für Sie erledigen. Wenn Sie diese Konzepte kennengelernt haben, können Sie jedoch ob Ihr Hostanbieter die Komprimierung richtig einsetzt. Dieses Wissen kann können Sie die Komprimierungseinstellungen verbessern, den größtmöglichen Nutzen für Ihre Website zu erzielen.

Content Delivery Networks (CDNs)

Ein Content Delivery Network (CDN) ist ein verteiltes Netzwerk von Servern, Ressourcen des Ursprungsservers im Cache speichern und sie wiederum vom Edge aus bereitstellen die sich physisch näher bei den Nutzern befinden. Die physische Nähe zu Ihrem Nutzer reduzieren die Umlaufzeit (Roundtrip Time, RTT), während Optimierungen wie HTTP/2 oder HTTP/3, Caching und Komprimierung ermöglichen es dem CDN, Inhalte schneller bereitzustellen. als von Ihrem Ursprungsserver abgerufen. Die Nutzung eines CDN kann die TTFB Ihrer Website in einigen Fällen erheblich verbessern.

Wissen testen

Nächster Schritt: Den kritischen Pfad verstehen

Nachdem Sie nun mit einigen wichtigen Aspekten zur Leistung vertraut sind mit dem HTML-Code Ihrer Website, können Sie besser sicherstellen, so schnell wie möglich – aber das ist erst der Anfang die Leistung. Als Nächstes lautet die Theorie hinter dem kritischen Rendering-Pfad: gesprochen. In diesem Modul werden Schlüsselkonzepte wie das Ressourcen, die das Parsen blockieren, und welche Rolle sie bei der Entstehung der so schnell wie möglich im Browser gerendert werden.