eBizTalk - Berichten, Unterhalten, Weiterbilden
Ob Branchendiskurs, Fachartikel oder ein Blick hinter die Unternehmenskulissen: eBizTalk ist die Plattform, die uns auffordert, unsere Leser über Events und Projekte auf dem Laufenden zu halten. Und uns gegenseitig natürlich auch.

Seitenladezeit optimieren? HTTP/2 aktivieren!

Veröffentlicht am 02.07.2018 von Alexander Müller , Web , Cloud

Das World Wide Web und wie wir es nutzen hat sich im Laufe seines Daseins verändert. Von einzelnen, statischen Hypertext-Dokumenten hin zu komplexen, interaktiven Seiten voller multimedialer Inhalte. Dies zeigt sich auch in den Statistiken: Seit 2010 hat sich die durchschnittliche Website-Größe (in Desktop-Darstellung) mehr als verdreifacht. Die durchschnittliche Anzahl an Requests pro Seite liegt mittlerweile bei über 80. Dies hat vor allem Auswirkungen auf die Seitenladezeit, aber HTTP/2 schafft Abhilfe!

Mehr Bandbreite, mehr Bandbreite!

Eine höhere Bandbreite wirkt sich auch immer positiv auf die Seitenladezeit aus. Das möchte man meinen, doch die Seitenladezeit (PLT, Page Load time) hat sich in den letzten Jahren, trotz höherer Bandbreiten, kaum verändert hat. Woran liegt das?
Untersuchungen haben gezeigt, dass sich ab einer Bandbreite von 5 Mbit/s nur minimale Verbesserungen der Seitenladezeit feststellen lassen. So resultiert aus einer Verdoppelung der Bandbreite von 5 auf 10 Mbit/s, eine nur um 5% bessere PLT. Einen viel größeren Einfluss hat die Latenz, auf die nur schwer und mit hohem Aufwand Einfluss genommen werden kann. Eine Verringerung der Latenz spiegelte sich also unmittelbar in einer verbesserten PLT wider. Wieso?
Websites und ihre Bestandteile werden über das Hypertext Transfer Protocol (HTTP) geladen, welches das Transmission Control Protocol (TCP) als Transportprotokoll nutzt. Auf Grund verschiedener Eigenschaften von TCP (Reliable Transmission, Retransmission, Congestion Control) ist dessen Performance unmittelbar abhängig von der Latenz des Netzes. Noch deutlicher spürbar in mobilen Netzen, in denen die Latenz stärker schwankt und deutlich höher liegt als über Kabel. Eine Möglichkeit der Abhilfe in Bezug auf die PLT kann also eine optimierte Nutzung der TCP-Verbindungen sein – HTTP/2 macht das möglich!

Von HTTP/1.1 zu 2.0 in „nur“ 20 Jahren

Im Jahr 1997 wurde HTTP/1.1 (RFC2068) als Update der nur ein Jahr zuvor erschienenen Version 1.0 veröffentlicht. Denn es gab Nachbesserungsbedarf: Wie in HTTP/1.0 beschrieben, muss für jeden Request eine neue TCP-Verbindung (short-lived connection) geöffnet werden. Durch den zeitintensiven TCP Three-Way-Handshake und der Nutzung als „Cold Connection“ (TCP Slow Start) führte dies zu starken Performance-Einbußen. In HTTP/1.1 wurde deshalb der keep-alive-Header eingeführt, wodurch eine geöffnete TCP-Verbindung nicht mehr sofort geschlossen wird, sondern für einen bestimmten Zeitraum geöffnet bleibt (persistent connection), sodass sie für weitere Request/Responses genutzt werden kann.

Seitdem hat sich das Web weiterentwickelt, das HTTP-Protokoll erfuhr jedoch für über 20 Jahre hinweg nur wenige Änderungen. Vielleicht war es der Vorstoß von Google mit dem Protokoll SPDY (gesprochen „Spidi“), der neue Bewegung in das Thema brachte. In jedem Fall sind große Teile des Protokolls in die neue Version des HTTP-Protokolls (RFC 7540) eingeflossen. SPDY selbst wurde von Google in Hinblick auf den neuen, kommenden Standard HTTP/2 zurückgezogen und der Support eingestellt.

Was ist neu in HTTP/2?

HTTP/2 ermöglicht eine effizientere Nutzung der Netzwerkressourcen und merzt somit einige Mängel von HTTP/1.1 aus, ohne dabei die Semantik des Vorgängers zu verändern. Dabei sind die folgenden drei Neuerungen ausschlaggebend.

Multiplexing

Ein Problem, das mit HTTP/2 adressiert wird, ist Head-of-line blocking. Dabei stauen sich die ausgehenden Request in einer Warteschlange an, da eine Verbindung immer nur für einen Request/Response gleichzeitig genutzt werden kann. Die Verarbeitung erfolgt also pro Verbindung sequentiell. In HTTP/1.1 wurde bereits versucht mittels HTTP Pipelining dieses Problem zu lösen, leider erfolglos. Stattdessen hilft der Browser, denn dieser verarbeitet Requests durch das Öffnen mehrerer Verbindungen parallel (je nach Browser bis zu 8 pro Hostname). Dennoch erfordern heutige Websites häufig ein Vielfaches der zur Verfügung stehenden gleichzeitigen Verbindungen zum vollständigen Laden.

In HTTP/2 können durch Multiplexing mehrere Request- und Response-Nachrichten parallel über dieselbe TCP Verbindung übertragen werden, wodurch das Öffnen mehrerer Verbindungen nicht mehr notwendig ist. Dadurch werden einige etablierte Workarounds wie Concatenation, CSS-Sprites oder Domain Sharding obsolet.

Header Compression

Durch die Zustandslosigkeit des HTTP-Protokolls ist es notwendig bei jedem Request alle für die Verarbeitung benötigten Informationen mitzusenden. Werden viele Ressourcen desselben Host abgefragt, werden vielfach redundante Header-Informationen übertragen, obwohl der Server diese möglicherweise durch vorangegangenen Requests bereits erhalten hat.
Um dieses Problem zu adressieren, wird ein speziell für HTTP/2 entwickeltes Kompressionsformat namens HPACK angewandt. Vereinfacht sieht dieses vor, dass sowohl Server als auch Client pro Verbindung eine dynamische Lookup-Table für die Header-Informationen halten. Der Client kann den Server dazu anweisen die empfangenen Header-Informationen in seiner Tabelle zu speichern. Muss der Client denselben Header nochmal schicken, sendet er nur den Index des Tabelleneintrags. Zusätzlich sind die Header-Informationen Huffman-kodiert.

Server Push

Fordert der Client eine Seite beim Server an, folgen nach der Analyse der Seite weitere Requests des Clients zur Anforderung benötigter Ressourcen, wie JavaScript-, CSS- oder Bilddateien. Um die Zeit bis alle Ressourcen vorliegen zu verkürzen, kann der Server diese Ressourcen bereits bei Anfrage der Seite mit an den Client schicken, sodass diese dann bereits im Cache des Clients vorliegen und kein weiterer Round-Trip notwendig ist.

Unterstützt mein Browser HTTP/2?

Die meisten Browser-Hersteller haben bereits seit längerem den Support für HTTP/2 implementiert. Eine detaillierte Übersicht findet sich bei caniuse.com. Da HTTP/2 abwärtskompatibel ist, gibt es nichts zu beachten. Das Protokoll wird im Rahmen des ersten Request „ausgehandelt“ (ALPN, Application-Layer Protocol Negotiation).

image

Kann ich HTTP/2 mit meinem Webserver verwenden?

Ein klares: „It depends!“ Konkret kommt es darauf an, ob der genutzte Webserver bereits HTTP/2 implementiert und die Seitenzugriffe verschlüsselt erfolgen. Die Spezifikation sieht zwar keinen Zwang für Verschlüsselungen wie TLS vor, trotzdem erfordern es die meisten Implementierungen. Eine Liste mit Implementierungen findet sich auf der Github-Seite für HTTP/2 der HTTP Working Group. In der Microsoft-Welt bietet IIS 10 die Unterstützung. Dieser ist allerdings an Windows Server 2016 geknüpft, weshalb sich der ein oder andere bis zum nächsten OS-Update gedulden muss.

Fazit

Mit HTTP/2 wurde die Basis für das Protokoll des WWWs erneuert und es wurde auch Zeit.
In Hinblick auf die Performance lohnt sich die Aktivierung von HTTP/2 vor allem dann, wenn zum Laden der Seiten eine Vielzahl an Ressourcen vom Server abfragt werden muss. Auf Grund der Abwärtskompatibilität zu HTTP/1.1 hat eine Aktivierung aber auch keine negativen Aspekte. Zu berücksichtigen ist die Unterstützung des eingesetzten Webservers. Wir selbst hosten unsere Website als Azure App Service in der Cloud. Eine Umstellung bedeutet hier nicht mehr Aufwand als das Umlegen eines Schalters in der Administrationsoberfläche. Vielleicht auch für Sie ein Anreiz über einen Cloud Move nachzudenken!

image

google_about_ebiz fb_about_ebiztwitter_about_ebizxing_about_ebiz
ebiz_consulting_expertise