WordPress und HTTP2 – eine Einführung

Im Mai 2015 wur­de HTTP/2 als neu­er Standard ver­ab­schie­det und soll in abseh­ba­rer Zeit HTTP/1.1 ablö­sen. Die mög­li­chen Vorteile von HTTP/2 sind enorm, aller­dings ist die Nutzbarkeit noch nicht ganz so ein­fach, wie ange­dacht. In die­sem Artikel schau­en wir kurz auf die Vorteile, die die­ser Standard den Website-Besitzern bie­ten kann, und wel­che Voraussetzungen für eine Nutzung von WordPress und HTTP/2 erfüllt sein müs­sen.

Wie vie­le Artikel hast du schon zum Thema WordPress und die Ladegeschwindigkeit einer Website gele­sen? Wenn es dir wie mir geht, wahr­schein­lich sehr vie­le. Auch ich habe hier auf Dr. Web schon eini­ge Artikel dazu ver­öf­fent­licht. Ein wich­ti­ger Teil einer Performance-Optimierung ist der Server, ohne einen ver­nünf­ti­gen, mit einem moder­nen Betriebssystem aus­ge­stat­te­ten Server funk­tio­niert kei­ne Optimierung.

Das wäre wie gegen Windmühlen kämp­fen. Da wir alle nicht Don Quijote sind, soll­ten wir sol­che Dinge gar nicht erst anfan­gen.

Was ist HTTP und wofür braucht man es?

Grundsätzlich ist HTTP (Hypertext Transfer Protocol) ein Weg, wie ein Webserver und ein Browser mit­ein­an­der kom­mu­ni­zie­ren. HTTP ist also die Sprache, in sich Server und Browser mit­ein­an­der unter­hal­ten.

Ich wer­de in die­sem Artikel nicht tief in die Materie ein­tau­chen, wenn du mehr dar­über erfah­ren möch­test, schau dir den Artikel auf Wikipedia dazu an. Zum ers­ten Mal tauch­te HTTP im Jahre 1991 als Version 0.9 auf, sozu­sa­gen in der Jura des Internets.

Viel ist seit­dem gesche­hen. Früher bestan­den die Websites nur aus wenig mehr als etwas Hintergrundfarbe, ein bis zwei Grafiken, die im HTML ver­linkt waren und viel Text. Die Websites damals waren nur eini­ge KB groß, heu­te sind die Websites dage­gen Schwergewichte mit zum Teil eini­gen MBs.

Gut beob­ach­ten kann man die Entwicklung der Websites am Beispiel von Dr. Web.

Eine der ers­ten Versionen von Dr. Web in der Frühzeit des Internets.

Heute ist die tat­säch­li­che Anzahl von Dateien, die zusam­men eine Website bil­den, sehr stark ange­stie­gen. Früher waren nur eini­ge weni­ge Dateien zu laden, heu­te sind es dut­zen­de, die es zu laden gilt. Dieser Fortschritt ver­schärft die Einschränkungen, die das alte Protokoll HTTP/1 mit sich bringt. Das Resultat ist eine erhöh­te Latenz – oder auch Langsamkeit einer moder­nen Website.

Das wie­der­um erfor­der­te die Entwicklung von HTTP/2. HTTP/2 kann durch­aus als Evolution des alten Protokolls ange­se­hen wer­den, denn das Hauptziel war das Verringern der Latenz und damit eine erhöh­te Ladegeschwindigkeit mit moder­nen Web-Browsern.

Die Limitierung von HTTP/1

Heute müs­sen die Browser zur Darstellung einer Website dut­zen­de, manch­mal sogar hun­der­te von Dateien laden, damit eine Website dar­ge­stellt wer­den kann. Folgendes wird zur Darstellung gela­den:

• Das HTML der Website
• Die Stylesheets (CSS)
• Das JavaScript
• Die Bilder
• Die Videos
• Externe Dateien für Google Analytics, Werbung und ähn­li­ches
• Social-Sharing-Lösungen

Das gro­ße Problem bei HTTP/1 ist, dass der Browser für jede ein­zel­ne Datei, die im HTML, CSS und JavaScript erwähnt wird, eine Anfrage zu erstel­len. Das kön­nen durch­aus auch hun­der­te von Anfragen und Verbindungen sein. Hunderte von HTTP-Requests sind durch­zu­füh­ren, was eine Website ganz schön lang­sam machen kann.

Speed-Optimierung unter HTTP/1

Aus die­ser Limitierung her­aus wur­de ein spe­zi­el­les Konzept erschaf­fen, wie man Websites trotz die­ser Einschränkungen schnel­ler machen konn­te. Dateien wur­den gebün­delt, um Anfragen zu redu­zie­ren, die Größe wur­de durch Komprimierung redu­ziert und Grafiken zu einem Sprite zusam­men­ge­fasst. HTTP/2 soll die­se Probleme lösen und ande­re Wege anbie­ten.

Der Unterschied zwischen HTTP/1 und HTTP/2

Für die genaue Spezifikation von HTTP/2 besu­che bit­te das HTTP/2 GitHub FAQ. HTTP/2 wur­de ent­wi­ckelt, um von Maschinen und nicht von Menschen les­bar zu sein. Daher ist das neue Protokoll auch binär, denn das opti­miert den Prozess der Kommunikation zwi­schen dem Browser und dem Server.

Es ist zudem weni­ger Fehleranfällig und kann Dinge wie Leerzeichen, Leerzeilen, Zeilenenden, Großschreibung und ähn­li­ches bes­ser inter­pre­tie­ren.

Der gro­ße Unterschied zwi­schen den bei­den Protokollen sind jedoch die Verbindungen. HTTP/1 erlaubt nur eine ein­zi­ge Verbindung zur Zeit, HTTP/2 kann jedoch meh­re­re Verbindungen gleich­zei­tig bear­bei­ten, da es nach dem Multiplexverfahren arbei­tet.

• HTTP/1 muss für jede ein­zel­ne Datei eine Anfrage stel­len
• HTTP/1 lädt eine Datei nach der ande­ren
• HTTP/2 hin­ge­gen kann mit einer Verbindung vie­le Dateien laden
• HTTP/2 erlaubt meh­re­re Verbindungen gleich­zei­tig

Das Server-Push Verfahren von HTTP/2

Das Server-Push-Verfahren ist eine Funktion, bei der der Server in der Tat weiß, wel­che Dateien der Browser benö­tigt, bevor die­ser die Dateien tat­säch­lich anfragt. Der Server schiebt dann die Dateien an den Browser, ohne dar­auf zu war­ten, dass der Browser sie erbit­tet. Das gestal­tet den gesam­ten Prozess der Anzeige einer Website wesent­lich schnel­ler als bis­her.

Weitergehende Informationen unter Apache.org/Server Push

Wer mit dem Server-Push-Verfahren expe­ri­men­tie­ren möch­te, fin­det hier ein kos­ten­lo­ses WordPress Plugin. HTTP/2 Server Push.

Darum ist HTTP/2 wesentlich effizienter

• Es kann die Verbindung zwi­schen dem Client und dem Server schnel­ler erzeu­gen
• Die Verbindung zwi­schen Browser und Server ist effi­zi­en­ter und damit schnel­ler
• Dateien und Ressourcen wer­den gleich­zei­tig über­tra­gen
• Dateien kön­nen per Server-Push an den Browser gescho­ben wer­den
• Es kön­nen mehr Dateien gleich­zei­tig gela­den und ange­zeigt wer­den

Die Online-Demo: der Unterschied zwi­schen HTTP/1 und HTTP/2

Wie kann ich HTTP/2 mit meiner Website einsetzen?

Ob du HTTP/2 bereits nut­zen kannst, hängt ganz und gar von dei­nem Webhoster ab. Das neue Protokoll ist ein Teil des Server-Betriebssystems (Apache, NGINX oder ILS) und muss daher von dei­nem Hoster ein­ge­pflegt wer­den.

Solltest du einen eige­nen Server haben, dann kannst du jeder­zeit auf HTTP/2 upgra­den und selbst für Aktualität sor­gen.

Natürlich exis­tie­ren mitt­ler­wei­le eini­ge Hoster, die bereits HTTP/2 unter­stüt­zen und anbie­ten. Doch das erscheint noch eine Ausnahme zu sein. Du kannst selbst tes­ten, ob dein Webserver oder dein Hosting-Paket bereits das neue Turbo-HTTP zur Verfügung stellt. Nutze dafür das Online-Tool von KeyCDN:

HTTP/2 Test Tool

So nutzt du HTTP/2 mit deiner Website

Theoretisch soll­te HTTP/2 mit jedem Browser ohne spe­zi­el­le Konfigurationen nutz­bar sein. Soweit die Theorie. In der Praxis schaut das lei­der ganz anders aus, denn die gro­ßen Browser-Hersteller haben sich dazu ent­schlos­sen, den Support für das neue Protokoll nur über TLS (HTTPS) zu ermög­li­chen. Hier eine aktu­el­le Liste von Browsern, die bereits HTTP/2 unter­stüt­zen:

Browser-Support für HTTP/2. Grün bedeu­tet, das das Protokoll unter­stützt wird.

Ein Klick öff­net die inter­ak­ti­ve Liste auf Caniuse.com

Du benö­tigst also ein SSL-Zertifikat für dei­ne Domain, denn nur mit einer SSL-Verschlüsselung wirst du in den Genuss des High-Speed Protokolls kom­men.

Test: Welche Website hat HTTP/2 bereits im Einsatz

Für Google Chrome exis­tiert eine Erweiterung, mit der du auf einen Blick sehen kannst, wel­che Website bereits HTTP/2 im täg­li­chen Einsatz hat.

Die »HTTP/2 and SPDY indi­ca­tor« Erweiterung

Die Erweiterung setzt sich neben die Adresszeile des Browsers und gibt dir anhand der ver­wen­de­ten Farben Rückmeldung, ob das Protokoll ein­ge­setzt wird oder nicht. Ein blau­er Blitz bedeu­tet, das die Website HTTP/2 aktiv ein­setzt. Grau hin­ge­gen heißt, das kei­ne Unterstützung vor­han­den ist.

Der blaue Blitz steht für HTTP/2 im täg­li­chen Einsatz.

Neue Wege gehen bei der Optimierung auf Speed

Die alten Wege der Speed-Optimierung funk­tio­nie­ren bei Einsatz von HTTP/2 nicht mehr, du wür­dest Potenzial ver­schen­ken. Der täg­li­che Einsatz des Protokolls heißt jedoch nicht, dass kei­ne Dateien mehr zusam­men­ge­fasst wer­den soll­ten, son­dern nur, dass genau über­legt wer­den sol­le, wel­che Dateien nicht zusam­men­ge­fasst wer­den.

Der mög­li­che Vorteil des gleich­zei­ti­gen Ladens vie­ler Ressourcen kann auch zu einer lang­sa­me­ren Website füh­ren, wenn nun alle Dateien ein­fach nicht zusam­men­ge­fasst und kom­pri­miert wer­den. JavaScript in einer Datei kom­pri­miert von – zum Beispiel – Autoptimize aus­lie­fern zu las­sen resul­tiert in einer schnel­le­ren Ladezeit, weil die Datei durch opti­mier­tes Caching nur ein­mal gela­den wird, wenn eine ent­spre­chen­de .htac­cess-Datei vor­liegt.

Als Optimal hat sich nach extrem vie­len Tests mein Weg für fort­ge­schrit­te­ne User zur Speed-Optimierung erwie­sen. Hier die Links zur Serie:

• High Speed: Was WordPress-Websites wirk­lich schnell macht – [#1]
• High Speed: Was WordPress-Websites wirk­lich schnell macht – [#2]
• High Speed: Was WordPress-Websites wirk­lich schnell macht – [#3]
• High Speed: Was WordPress-Websites wirk­lich schnell macht – [#4]
• High Speed: Was WordPress-Websites wirk­lich schnell macht – [#5]

Fazit

Der Einsatz von HTTP/2 lohnt sich defi­ni­tiv, auch wenn man ein SSL-Zertifikat für die Website erwer­ben muss. Ein kos­ten­frei­es Zertifikat von Let’s Encrypt ist jedoch auch völ­lig aus­rei­chend. Der Geschwindigkeitszuwachs kann enorm sein, je nach bereits vor­han­de­nem Konzept für die Geschwindigkeits-Optimierung. Bei stark auf Performance getrimm­ten Websites, deren Server bereits PHP7 ein­set­zen, ist der Zuwachs an Speed jedoch nur mar­gi­nal, trotz Splitting von zu laden­den Dateien.