Was man über HTTP/2 wissen sollte

HTTP/2 ist seit Februar 2015 standardisiert und wird von immer mehr Servern und Browsern unterstützt. Dieser Blogbeitrag soll einen kurzen Überblick über die Erweiterungen geben und zeigen worauf man zukünftig bei der Entwicklung einer Webseite mit HTTP/2 achten sollte.

Erweiterungen durch HTTP/2 im Überblick
HTTP/2 baut auf HTTP/1.1 auf und ist rückwärtskompatibel, weshalb bei einer Anfrage des Clients mit HTTP/2 bei fehlender Kompatibilität des Servers auf HTTP/1.1 zurückgegriffen werden kann. Trotz des Ursprungs in HTTP/1.1 ändern sich durch HTTP/2 einige wichtige Elemente in der Art der Kommunikationsabläufe.

Request/Responsemultiplexing
Hierbei werden die Daten nicht wie zuvor über mehrere TCP Verbindungen verschickt. Stattdessen ist es möglich, eine Einteilung in Header und Data Frames vorzunehmen und diese über Streams in einer einzigen Verbindung zu verschicken. Somit können Anfragen gespart und nicht blockierend versendet werden.

http2 requestmultiplexing

Priorisierung
Da das „Head of line blocking“ unterbunden ist, wird neu durch Priorisierung der Streams zu garantieren versucht, dass die Daten in der richtigen Reihenfolge bearbeitet werden. Diese werden anhand von Gewichtungen eingeteilt.

Server Push
Zusätzlich können mittels Server Push die Daten vom Server gesendet werden, welche dieser als relevant ansieht. Der Client muss diese also nicht mehr explizit Anfragen. . Zum Beispiel könnte der Server bei der Anfrage einer index.html Seite, bereits die dazugehörigen CSS und JavaScript Dateien mitgeben, sofern Server Push vom Client aktiviert wurde.

Header Compression
Darüber hinaus werden durch Header Compression zusätzliche Daten eingespart.
Unter HTTP/1.1 werden die Metadaten in Klartext versendet und bei jedem Request mitgeschickt. Das führt zu Redundanzen und einer Vergrößerung der Datenmengen. Zudem werden die Metadaten durch die vermehrte Verwendung von Cookies in Webanwendungen, wie Google Analytics, zusätzlich vergrößert.
Header Compression komprimiert die Metadaten in Binärzahlen. Diese werden anschließend sowohl serverseitig als auch clientseitig gespeichert. Somit kann das Verschicken redundanter Metadaten verhindert werden.

Was ändert sich für die Entwicklung im Frontend?
Es existieren heutzutage einige Performance Optimierungen um die Probleme, die durch HTTP/1.1 verursacht werden, zu überbrücken. Jedoch können sich auch diese nachteilig auf die Webseite auswirken, weshalb die Anwendung dieser gut überlegt sein sollte. Die Bedeutung folgender Optimierungsziele könnte sich im Hinblick auf die Einführung von HTTP/2 verändern:

  • Reduzierung von Requests: Während unter HTTP/1.1 jede Anfrage den Aufbau einer zusätzlichen TCP-Verbindung benötigt, können mittels Request-/ Responsemultiplexing die TCP-Verbindungen auf eine reduziert werden. Performance Optimierungen, die dies zum Ziel haben, verlieren an Bedeutung und können sogar zu einer Verschlechterung der Performance führen. Beispiele sind hier die Verkettung von Dateien oder die Verwendung von Image Sprites, sowie Inline Styles. Ein genereller Nachteil dieser Optimierungen ist, dass umso mehr Dateien verkettet werden, umso unflexibler das Caching einer Seite wird. Beim Laden einer Unterseite kann diese zum Beispiel nicht auf Daten der Hauptseite zurückgreifen, selbst wenn sich nur wenige Dateien verändern. Zur Folge kommt es zu einem Laden von redundanten Daten. Zusätzlich kommt es durch die Zusammenfassung zu einem verzögerten Ausführen der Dateien.
  • Parallelisierung: Durch Request/ Responsemultiplexing werden Anfragen bereits parallelisiert. So kann und sollte auf Domain Sharding verzichtet werden. Insbesondere unter HTTP/2 kann dies zu Nachteilen führen, da das Öffnen vieler paralleler TCP-Verbindungen die Priorisierung von Streams durcheinander bringen kann.
  • Inline Ressourcen: Sollen einen Roundtrip einsparen, da durch das Laden des Dokuments gleichzeitig die benötigten CSS und JavaScript Dateien mitgeschickt werden. Durch die Einführung von Server Push kann dies von HTTP/2 automatisch übernommen werden. Dazu kann unter Server Push ein optimiertes Caching gewährleistet werden, da er die Daten einzeln im Cache gespeichert werden. Bei Inline Ressourcen ist jedoch keine seperate Speicherung der einzelnen Inline Styles möglich.
  • Lazy Loading: Das Nachladen von Dateien zur Laufzeit wird durch HTTP/2 besser. Lazy Loading optimiert die Ladezeit der Webseite, da Ressourcen erst dann geladen werden, wenn sie tatsächlich benötigt werden. Jedoch führt dies zu einer Erhöhung der Anzahl an Requests. Unter HTTP/2 ist aber eben diese Anzahl nicht mehr von großer Bedeutung, sodass die Verwendung von Lazy Loading gerade unter HTTP/2 von Vorteil ist.

In Zukunft sollte deshalb bei der Entwicklung einer Webseite nicht nur an die verschiedenen Anforderungen der Browser gedacht werden, sondern bei der Anwendung von Performance Optimierungen auch an das verwendete Protokoll gedacht werden, um Nachteilen durch falsche Anwendung zu entgehen.

Die aktuelle Browser Komptabilität von HTTP/2 kann in folgender Grafik von caniuse nachvollzogen werden:

caniuse

Mehr zu HTTP/2:

[Bildquelle: Ilya Grigoriks Buch „High Performance Browser Networking“ ]

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

*

*

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>