Schnellere Websites mit HTTP/2
WWW-Beschleuniger
HTTP/2, der neue Standard zur Datenübertragung im Web, optimiert die Datenübertragung zwischen Webserver und Browser. Damit Websites wirklich schneller laden, müssen Webentwickler und Admins allerdings einiges beachten.
Ladezeiten von unter einer Sekunde sind der Heilige Gral, nach dem alle News-Sites, Onlineshops, Portale, Blogs und Landingpages suchen. Denn an der Ladezeit hängen sowohl Nutzerzufriedenheit als auch Konversionsraten und deshalb letztlich Traffic und Umsatz einer Seite. Der Einfluss ist so immens, dass beispielsweise Amazon bei einem Anstieg der Ladezeit um 0,1 Sekunden bereits ein Prozent an Umsatz verlieren würde. Kein Wunder also, dass Unternehmen wie Google seit Jahren das Thema Webperformance vorantreiben und sich die Ladezeit einer Seite sogar auf ihre Platzierung in den Google-Suchergebnissen auswirkt.
Technisch gesehen hängt die Ladezeit einer Seite an drei zentralen Faktoren: an der Verarbeitung im Server, an der Übertragung über das Netzwerk und an der Darstellung im Browser. Alle drei können einen starken Einfluss auf die Performance haben und die Ladezeitoptimierung zu einem langen und komplexen Prozess machen.
Einen dieser drei Aspekte – die Übertragung der Webseite vom Server zum Browser – konnten Entwickler bislang kaum beeinflussen. Seit 1999 ist das Hypertext Transfer Protocol HTTP in der Version 1.1 der Standard zur Datenübermittlung im Web. Nach über 15 Jahren gibt es nun mit Version 2 (auch HTTP/2 oder kurz h2 genannt) den langersehnten Nachfolger. HTTP/2 ist ein Binärprotokoll, setzt einen klaren Fokus auf Performance und gibt Entwicklern verschiedene Möglichkeiten zur Optimierung der Seitenladezeit an die Hand. Dieser Artikel gibt einen Überblick über die zentralen Ideen und Techniken von HTTP/2 und setzt sie in Bezug zu anderen Techniken zur Steigerung der Webperformance.
Die Semantik des HTTP-Protokolls bleibt mit Version 2 unberührt, es handelt sich bei HTTP/2 vielmehr um ein weitreichendes Performance-Update mit 4 zentralen Optimierungen: Multiplexing, Header Compression, Resource Prioritization und Server Push. Dabei verbessern das Multiplexing und die Kompression der Header die Ladezeit sofort. Um die anderen beiden Optimierungen zu nutzen, ist ein gewisser Entwicklungsaufwand erforderlich.
Verschachtelt geht schneller
Die zentrale Limitierung von HTTP/1.1 ist, dass sich pro TCP-Verbindung zum Server nur eine Anfrage (ein Request) gleichzeitig stellen lässt. Browser öffnen üblicherweise sechs parallele Verbindungen, sodass maximal sechs Ressourcen gleichzeitig übertragen werden können. Alle übrigen Requests müssen auf eine freie Verbindung warten: Dieser Flaschenhals wird Head of Line Blocking genannt.
Bei HTTP/2 gibt es diese Limitierung nicht mehr. Alle Ressourcen werden über eine einzige Verbindung geladen und der Browser kann beliebig viele Requests parallel stellen. Dieses Multiplexing umgeht mehrere Probleme: Erstens wird die anfängliche Durchsatzbegrenzung einer neuen TCP-Verbindung durch den Slow-Start-Algorithmus schneller überwunden. Zweitens fällt bei nur einer Verbindung der langsame Verbindungsaufbau per SSL weniger ins Gewicht. Indem HTTP/2 alle Requests in einer Verbindung bündelt, wird so schnell die maximale Bandbreite des Netzwerks genutzt.
Im Wasserfalldiagramm einer Webseite ist der Unterschied zwischen HTTP/1.1 und HTTP/2 dadurch besonders gut zu erkennen. Der Ladezeitrückgang durch Multiplexing variiert von Seite zu Seite, ist aber in vielen Fällen substanziell.
Komprimieren spart Bandbreite
Bei jedem Request des Browsers werden Metainformationen wie Version und Größe der Ressource als HTTP-Header übertragen. Besonders viele dieser Metainformationen senden Seiten, auf denen Cookies zum Einsatz kommen.
Bei HTTP/1.1 werden diese Header bei jedem Request vollständig und unkomprimiert übertragen. Insbesondere bei Cookies ist die Datenübertragung massiv redundant. Mithilfe des HPACK-Algorithmus komprimiert HTTP/2 die übertragenen Header durch ein einfaches Wörterbuchverfahren im Schnitt um 88 %. Der Einfluss auf die Ladezeit macht sich vor allem bei geringer Bandbreite bemerkbar, sodass mobile Nutzer besonders stark profitieren.
Manche Ressourcen sind wichtiger für die Darstellung einer Webseite als andere. So müssen Style-Informationen in Form von CSS-Dateien schneller geladen werden als Bilder, die sich weit unten auf der Seite befinden. Die Priorisierung von Ressourcen hat daher einen erheblichen Einfluss darauf, wie schnell der Browser beginnen kann, die Seite anzuzeigen.
Browser sind bereits sehr gut darin, HTML-Dateien zu analysieren und die dort referenzierten Ressourcen zu priorisieren. Zusätzlich kann der Entwickler beispielsweise mit Preload-Tags dem Browser eine Reihenfolge zum Laden der Ressourcen vorgeben. Allerdings stellt sich dabei die Frage: Wie kann der Browser sicherstellen, dass die Ressourcen auch in der priorisierten Reihenfolge bei ihm ankommen?
Das Wichtigste zuerst
Bei HTTP/1.1 ist das einfach: Da der Browser lediglich sechs Ressourcen gleichzeitig laden kann, genügt es, die Ressourcen in der Reihenfolge ihrer Priorität anzufragen. Das Verfahren ist etwas grob, weil unter den sechs parallelen Verbindungen keine Priorisierung vorgenommen wird. Im Großen und Ganzen ist aber sichergestellt, dass die wichtigen Daten als Erstes beim Browser ankommen.