Reporting Center Login
×

SEO Whitepaper

HTTP/2

HTTP 2 ist ein Verfahren, um die Kommunikation zwischen Browser und Server zu beschleunigen und damit auch die Ladezeiten von Webseiten. Erfahren Sie in diesem Whitepaper alles Wissenswerte rund um das neue Netzwerkprotokoll.

HTTP/2 - das schnelle Web nimmt Gestalt an

Die Ladezeit einer Website bestimmt maßgeblich über deren Erfolg. Wie unterschiedliche Studien in der Vergangenheit nahelegen, verringert sich die Geduld eines Website-Besuchers stetig und der Großteil verlässt einen Internetauftritt wieder, wenn dieser länger als 3 Sekunden lädt. Doch das schnelle Web nimmt mehr und mehr Gestalt an. Bald soll der Entwurf für ein neues Übertragungsprotokoll, mit dem Daten effizienter als bisher über die Leitung vom Webserver zum Client transportiert werden, an den Start gehen. Die Neuerung war überfällig, da das aktuelle Netzwerkprotokoll HTTP/1.1 aus dem Jahre 1999 stammt und sich das Internet in der Zwischenzeit dramatisch verändert hat. Heutige Webseiten sind komplexe Anwendungen, die aus unzähligen Bildern, Skript- und Flash-Dateien, Stylesheets etc. bestehen, die vom Browser nach und nach abgearbeitet werden müssen. Das bleibt nicht ohne Auswirkung auf Ladezeit und damit die Gesamt-Performance einer Website.

Will man die Ladezeit effektiv reduzieren, spielen Latenz und Bandbreite eine bedeutende Rolle.  Während Bandbreite vor allem bei Bildern, Videos und anderen großen Content-Dateien wichtig ist, kommt es für Webseiten vor allem auf die Reduzierung der sogenannten „Round-Trips“ an (die Zeit für einen Round-Trip selbst sind nur schwer zu optimieren). Unter der Round-Trip-Time (RTT) bzw. Paketumlaufzeit versteht man die Zeit, die ein Datenpaket bei einer Anfrage in einem Rechnernetz benötigt, um vom Browser zum Server und zurück zu reisen. Jeder zusätzliche Verbindungsaufbau bei einer Anfrage benötigt mindestens diese RTT.

Wie Iliyan Peychev in seinem Blog richtig schreibt: „latency is the constraining factor for today’s applications.“ Das Ziel des neuen Protokolls HTTP/2 ist demnach die Eliminierung von Paketumlaufzeiten, um die Ladezeiten zu senken. Da die RTT insbesondere in Mobilfunknetzen sehr hoch ist und mobile Endgeräte heute am Markt dominieren, ist hier so schnell wie möglich eine nachhaltige Lösung zu finden.

HTTP/2 und Googles "SPDY"

Für HTTP/2 existiert ein Entwurf der Internet Engineering Task Force (IETF), der sich noch in Arbeit befindet und weitgehend auf dem von Google 2009 veröffentlichten Protokoll SPDY (Speedy) beruht. Die wesentlichen Bestandteile von HTTP sollen dabei weiter verwendet werden. Es ändert sich lediglich die Art und Weise, wie die Daten über das Netzwerk ausgetauscht werden. Für HTTP/2 sollen verschlüsselte Verbindungen, im Gegensatz zu SPDY, nicht obligatorisch sein. Die SPDY-Entwickler haben in ihren Tests bis zu 64 Prozent kürzere Seitenladezeiten festgestellt, das Ziel sind im Durchschnitt 50 Prozent. HTTP/2 wird aber vermutlich ein anderes Komprimierungsverfahren verwenden als SPDY.

In der Arbeitsgruppe arbeiten unter anderem die Internetfirmen Google, Apple und Microsoft zusammen, um dem Standard einmal größtmögliche Verbreitung zu verschaffen. (Link zum aktuellen IETF-Draft: http://tools.ietf.org/html/draft-ietf-httpbis-http2-16).

Etliche Hersteller arbeiten inzwischen an der Umsetzung der neuen Technik in ihren Produkten, obwohl sie noch nicht vollends standardisiert ist. Immerhin steckt die Vorläufertechnik SPDY schon in den Browsern Chrome, Firefox, Internet Explorer, Amazon Silk und Opera. In der aktuellen Version unterstützt auch Safari SPDY, auch unter iOS (iPhone/iPad). Chrome für Android kann auch SPDY, sodass auch mobile Webseiten profitieren.

Es gibt auch schon einige Webserver, die SPDY nutzen, darunter Apache mittels eines von Google entwickelten Moduls, der Jetty Web Server oder auch NGINX. Unter Webseiten-Anbietern findet die Technik ebenfalls Zuspruch. Neben Google haben zum Beispiel auch Twitter, Facebook und Word Press ihre Server mit SPDY bestückt. Ausgehend von dieser Basis kann man annehmen, dass HTTP 2.0 schnell umgesetzt wird, zumal es auch abwärtskompatibel ist.

Warum HTTP/2

Das Dilemma

Ein Grund, warum ein verbessertes Protokoll nötig wurde, ist das ständig wachsende Datenaufkommen und die ineffiziente Nutzung der Netzwerk-Ressourcen durch den momentanen Protokollstandard. Webseiten bestehen heute - wie bereits erwähnt - längst nicht mehr nur aus einer HTML-Datei, in die ein paar Bilder und Skripte eingebunden sind.


„Obwohl die Internetverbindungen heute um ein Vielfaches schneller sind als vor ein paar Jahren, hat sich die Ladezeit einer Webseite im Durchschnitt kaum verbessert, da sich fast linear zu der verfügbaren Bandbreite auch die Datenmenge der Webseiten vergrößert hat“, schreiben Daniel Kuhn und Michael Raith in ihrem Buch performante Webanwendungen. Folgende Grafik zeigt denn auch das Dilemma: 

    Entwicklung Datenaufkommen Internet

    Beispiel

    Nehmen wir eine durchschnittliche Webseite, zu deren vollständiger Darstellung neben der HTML-Datei noch 50 weitere Ressourcen vom Server heruntergeladen werden müssen.  Ein Browser kann aber nicht alle Ressourcen auf einmal anfordern, je nach Browserkonfiguration lassen sich nur 2 bis 6 Dateien gleichzeitig vom Server abrufen.

    Das bedeutet aber, um die Bilder, Skripte etc. vom Server zu erhalten, muss man mindestens 25-mal die RTT verstreichen lassen. Setzt man für eine RTT ca. 150 ms an, entspricht das bereits 3,75 Sekunden Ladezeit, ohne dass auch nur eine einzige Datei heruntergeladen wurde. Das ist lediglich die Zeit, die für die Netzwerkkommunikation zwischen Browser und Server benötigt wird.

    Ablauf der Kommunikation zwischen Browser und Server

    Ein weiterer Grund, warum eine gute Website-Performance heutzutage von Bedeutung ist: Sie hat Einfluss auf die Conversion-Rate und damit auf Umsatz und Gewinn eines Online-Shops. Die amerikanische Kaufhauskette Walmart fand in einer Untersuchung beispielsweise heraus, dass jede Sekunde Ladezeitverkürzung eine Erhöhung der Conversion-Rate um 2 % nach sich zog und eine Umsatzsteigerung von 1 % erzielt werden konnte. Jede Sekunde Ladezeitverzögerung hatte hingegen einen Rückgang der Conversion-Rate um 3,5 % zur Folge.

    Das aktuelle Übertragungsprotokoll ist in die Jahre gekommen. Sehen wir uns einfach mal an, wie die Kommunikation zwischen Webserver und Browser bei HTTP/1.1 bisher abläuft.

    Wenn ein Browser eine Webseite aufrufen will, muss jedes einzelne Element (wie z. B. ein Bild oder eine eingebundene Skript-Datei) über eine eigene TCP-Verbindung vom Server abgerufen werden. Bei jeder Anfrage muss der Browser dann eine Weile auf eine Antwort vom Server warten. Bei HTTP/1.1 kann über eine Verbindung immer nur eine Abfrage gleichzeitig gestartet werden. Allerdings hat ein Browser die Möglichkeit, mehrere Verbindungen parallel zum Server aufzubauen, um das Laden zu beschleunigen.
     
    Das führt aber wiederum zu unnötigem Datenverkehr und Staus bei der Abarbeitung der Datenpakete (Head-of-line-Blocking). Der Browser wartet weiterhin viel zu lange auf einen Download. Außerdem kann nur der Browser eine Verbindung zum Server aufbauen – nicht umgekehrt. So ist es Aufgabe des Browsers, fortwährend zu prüfen, ob eine Internetseite aktualisiert wurde oder nicht.

    Deshalb wurde bisher in Sachen Performance-Optimierung meist versucht, die Anzahl und Größe der Requests zu reduzieren, indem z. B. Javascript- oder CSS-Dateien zusammengelegt wurden (siehe weiter unten.). Aber eine echte Lösung war das auch nicht, weshalb HTTP/2 ins Spiel kam, um die Netzwerkverbindung besser zu nutzen.

    Bei HTTP/2 hingegen wird nur noch eine Verbindung zum Server aufgebaut, es werden mehrere Anfragen über das Multiplex-Verfahren über die Leitung  geschickt und mehrere Antworten vom Server gleichzeitig erhalten (siehe Schaubild). Der Browser frägt also nicht mehr nur eine Ressource nach der anderen ab.
     
    Stellen Sie sich Multiplexing anhand eines Beispiels aus dem Alltag wie folgt vor: Sie gehen in einen Supermarkt, haben aber die Einkaufsliste vergessen. Was machen Sie nun? Sie rufen zuhause bei Ihrer Frau oder Ihrem Mann an und fragen: „Schatz: Brauchen wir Butter? Ok, danke, tschüss“. „Hallo, ich bins wieder. Brauchen wir auch Mehl? Ok, alles klar. Und so weiter. Das wäre http 1.1. Mit http 2.0 rufen Sie nur noch einmal an und fragen alle Einkaufsgegenstände zur gleichen Zeit ab.

    Multiplexing HTTP/2

    Der Browser frägt also nicht mehr nur eine Ressource nach der anderen ab. Stellen Sie sich Multiplexing anhand eines Beispiels aus dem Alltag wie folgt vor: Sie gehen in einen Supermarkt, haben aber die Einkaufsliste vergessen. Was machen Sie nun? Sie rufen zuhause bei Ihrer Frau oder Ihrem Mann an und fragen: „Schatz: Brauchen wir Butter? Ok, danke, tschüss“. „Hallo, ich bins wieder. Brauchen wir auch Mehl? Ok, alles klar. Und so weiter. Das wäre http 1.1. Mit http 2.0 rufen Sie nur noch einmal an und fragen alle Einkaufsgegenstände zur gleichen Zeit ab.

    Bisherige Maßnahmen zur Optimierung der Ladezeiten

    Um die Ladezeiten in den Griff zu kriegen, setzt man derzeit auf vereinzelte Maßnahmen zur Reduzierung und Optimierung der anzuzeigenden Datenmenge, auch „Workarounds“ genannt, anstatt das Problem auf Protokoll-Ebene wie bei HTTP/2 zu lösen. Diese Workarounds werden durch das neue Protokoll denn nun auch größtenteils weniger relevant.

    Spriting

    Das bisherige Mantra der Performance-Optimierung lautete, die Anzahl an Server-Anfragen zu reduzieren, um die dem Protokoll inhärente Schwäche auszugleichen. Die große Zahl an Grafiken einer Website (z. B. Checkmarks etc.) werden in eine Grafik eingebunden. So spart man bei der Datenmenge, die übertragen werden muss und bei der Anzahl der Verbindungen.

    Direktes Einbetten von JavaScript, CSS und anderen Dateien

    Meist lagert man JavaScript- oder Stylesheet-Dateien, die für mehrere Seiten gelten, in externe Dateien aus, was auch die Wartbarkeit der Webseite erleichtert. Doch für Stilanweisungen oder JavaScript, das nur für eine Seite gilt, sollte man den Code inline integrieren, um zusätzliche HTTP-Anfragen einzusparen. Ein gutes Beispiel für diese Praxis ist Googles Startseite, die auch schnell lädt.

    Auslagerung statischen Contents auf Subdomains

    Die meiste Zeit beim Laden einer Webseite geht für Skript-Dateien, Stylesheets, Flash und Bilder drauf. Und da ein Browser nur eine bestimmte Anzahl an Anfragen gleichzeitig pro Domain absetzen kann, ist man dazu übergegangen, statischen Content auf Subdomains auszulagern, Bilder z. B. auf img.domain.de, um die Ladezeiten zu minimieren.

    Zusammenlegung von Dateien

    Die Kombination separater Skripte- und Stylesheet-Dateien in einer einzigen Skript- und einer einzigen Stylesheet-Datei reduziert die Anzahl der Serveranfragen und erhöht dadurch die Geschwindigkeit beim Laden einer Website.

    Features von HTTP/2

    Header-Kompression

    Bei jeder Anfrage an den Server und bei jeder Antwort werden neben dem eigentlichen Inhalt auch zahlreiche Header-Daten der IP-Pakete zur Kommunikationsabwicklung übertragen (Browser-Konfiguration, akzeptierte Dateiformate, Cookies etc.) – allerdings im Gegensatz zum eigentlichen Inhalt unkomprimiert. Bei HTTP/2 werden diese Daten komprimiert und in Binärcode übertragen bzw. nur einmal zu Beginn des Verbindungsaufbaus, was die Latenz deutlich verringert.

    Multiplexing

    Browser können mittels Multiplexing mehrere Nachrichten gleichzeitig über eine Verbindung beziehen, was die Auslastung des Servers, der zahlreiche Browser-Anfragen gleichzeitig abarbeiten muss, erheblich verringert. So blockiert z. B. ein 1 MB großes Hintergrundbild nicht den Download aller weiteren Ressourcen vom Server, diese können parallel heruntergeladen werden.

    Bytestrom

    Pro Server soll nur noch eine TCP-Verbindung aufgebaut werden. Das entlastet die TCP-Stacks der Server. Auf dieser einen Verbindung unterteilt HTTP 2.0 den Datenverkehr in Streams. Das wird möglich, weil HTTP 2.0 nicht mehr das Textformat verwendet, sondern ein Binärformat mit Frame-Headern. Jeder Frame enthält eine eigene Stream-ID. Dadurch kann HTTP 2.0 mehrere Ressourcen auf einmal verschicken. Parallel dazu können auf einem speziellen Stream Client und Server Kontroll-Informationen und Requests austauschen.

    Server-Push

    Bei HTTP/2 kann nicht nur der Client, sondern auch der Server Verbindungen einleiten (Push-Funktion).  Wenn der Webserver weiß, welche Ressourcen (z. B. Java-Script-Dateien oder Stylesheets) der Browser zur Darstellung eines Dokuments benötigt und diese bereits mitschickt, noch ehe der Browser davon überhaupt Kenntnis erhält, lässt sich dadurch beim Seitenaufbau eine Menge Zeit sparen. Durch Server-Push werden sogenannte „preloading“-Optimierungen überflüssig.

    Priorisierung von Datenströmen

    HTTP/2 setzt auf Abfrage-Priorisierung: Bestimmte Elemente können so vor allen anderen geladen werden. So kann z. B. JavaScript- und CSS-Dateien bspw. eine höhere Priorität als Bildern zugewiesen werden. Client und Server können beide eine Priorität für Streams festlegen und so dafür sorgen, dass wichtige Ressourcen schnell und vollständig beim Client ankommen. Das lässt sich zum Beispiel dafür verwenden, um Texte umgehend anzuzeigen, damit der Benutzer schon mal mit dem Lesen beginnen kann. Bilder werden dann mit kleinerer Priorität übertragen, weil sie meistens umfangreicher sind als die Textinhalte und daher ohnehin deutlich länger für die Übertragung brauchen.

    HTTP/2 in der Praxis

    Um HTTP/2 nutzen zu können, müssen Server und Browser lediglich das neue Protokoll unterstützen. Anpassungen an den Webseiten sind nicht notwendig. HTTP/2 macht viele bisherige Optimierungen wie beispielsweise CSS-Sprites obsolet, da das Protokoll alle Ressourcendateien in einem gemeinsamen Datenstream überträgt. Allerdings sollten jetzt nicht alle realisierten Performance-Optimierungen wieder rückgängig gemacht werden, da es wohl noch eine Weile dauern wird, bis alle Webseiten das neue Protokoll verwenden und bis dahin ein Fallback-Mechanismus vorgesehen werden kann. Außerdem würden die Vorteile, die HTTP/2 bietet, zum Teil wieder verpuffen, wenn die Datenmenge ansteigt – wie eingangs erwähnt wird im Schnitt nur eine Verbesserung um 50 % erreicht. Verzichtet man z.B. auf Minify von CSS und Javascript und die Dateigröße wächst um 80 %, würde man sogar gegenüber HTTP/1.1 verlieren.

    Fazit

    Ein Browser und ein Server, die alle Möglichkeiten der neuen Technik nutzen, erledigen die Übertragung derselben Webseite weitaus schneller als Browser und Server, die auf HTTP/1.1 basieren. Die einzelnen Komponenten wie Texte, Bilder oder Skript-Dateien sind zwar gleich lang unterwegs, aber die Anforderung und der Versand laufen umgehend ab und schöpfen Internet-Leitungen daher besser aus.

    Mit HTTP/2 lässt sich eine Verbindung also weit besser auslasten als mit HTTP/1.1; der Server sendet alle Ressourcen nacheinander, ohne Verzögerungen. Wenn man heute eine größere Webseite abruft, kann das ein paar Sekunden dauern, also gemessen an den technischen Möglichkeiten sehr lange. Dabei ist die Leitung immer nur vorübergehend ausgelastet. Mit HTTP/2 wird die Seite aus Sicht des Surfers fast umgehend da sein.

    Wer ein Managed-Hosting-Angebot oder sogar Shared-Hosting verwendet, ist jedoch darauf angewiesen, dass der jeweilige Anbieter möglichst bald auf die neue Technologie wechselt. Besser haben es User, die einen eigenen Server betreiben und alle Einstellungen selbst vornehmen können – sie können bei der Umstellung auf HTTP/2 eine Vorreiterrolle übernehmen und zuerst von den Neuerungen profitieren.

    Ihre Website lädt zu langsam?

    Lädt Ihre Website oder Ihr Online-Shop aktuell auch zu langsam? Dann sollten Sie Kontakt mit den Technik-Experten bei der OSG aufnehmen. Diese beraten Sie nicht nur bei Ladezeiten-Problemen, sondern auch bei anderen SEO-Fragen. Die OSG als SEO Agentur ist ihr professioneller Partner bei allen Themen rund um die Suchmaschinenoptimierung Ihrer Webseiten.

    Bei Interesse freuen wir uns auf Ihre Anfrage.
    Wir beraten Sie gerne persönlich und erstellen Ihnen ein maßgeschneidertes Angebot.

    Referenzen Angebote Kontakt