HTTP/2 – Ein Praxistest und eine Analyse der Performance

Vielleicht haben Sie schon von HTTP/2 gehört? Es ist nicht nur eine Idee, es ist eine echte Technologie und langsam, aber sicher, stellen Hosting-Unternehmen und CDN-Dienste sie ihren Servern zur Verfügung. Es wurde viel über die Vorteile von HTTP/2 gegenüber HTTP1.x gesagt, aber der Beweis liegt im Geschmack.

Heute werden wir einige Praxistests durchführen, einige Zeitmessungen vornehmen und sehen, welche Ergebnisse wir daraus ableiten können.

Warum HTTP/2?

Wenn Sie noch nichts über HTTP/2 gelesen haben, empfehle ich Ihnen, sich einige Artikel anzusehen. Es gibt die HTTP/2 FAQ, die Ihnen alle technischen Details liefert, und ich habe auch einige Artikel über HTTP/2 selbst geschrieben, in denen ich versuche, die Technik abzuschwächen und mich hauptsächlich auf das Warum und Wie von HTTP/2 zu konzentrieren.

Kurz gesagt, HTTP/2 wurde veröffentlicht, um die inhärenten Probleme von HTTP1.x zu lösen.

1. HTTP/2 ist binär und nicht textbasiert wie HTTP1.x – das macht die Übertragung und das Parsen von Daten über HTTP/2 von Natur aus maschinenfreundlicher, also schneller, effizienter und weniger fehleranfällig.
2. HTTP/2 ist vollständig multiplexed, was die gleichzeitige Übertragung mehrerer Dateien und Anfragen ermöglicht, im Gegensatz zu HTTP1.x, das nur eine einzige Anfrage/Verbindung gleichzeitig akzeptierte.
3. HTTP/2 verwendet dieselbe Verbindung für die Übertragung unterschiedlicher Dateien und Anfragen und vermeidet den aufwendigen Vorgang, für jede zu übertragende Datei eine neue Verbindung zwischen Client und Server zu öffnen.
4. HTTP/2 verfügt über eine integrierte Header-Komprimierung, die eine weitere Möglichkeit ist, mehrere der Overheads zu entfernen, die mit HTTP1.x verbunden sind, wenn mehrere verschiedene Ressourcen vom selben oder von mehreren Webservern abgerufen werden müssen.
5. HTTP/2 ermöglicht es Servern, benötigte Ressourcen proaktiv zu pushen, anstatt darauf zu warten, dass der Client-Browser Dateien anfordert, wenn er glaubt, sie zu benötigen.

Dies sind die besten (wenn auch vereinfachten) Darstellungen, wie HTTP/2 besser ist als HTTP1.x. Anstatt dass der Browser immer wieder zum Server zurückkehren muss, um jede einzelne Ressource abzurufen, werden alle Ressourcen auf einmal abgerufen und übertragen.

Ein semi-wissenschaftlicher Test der HTTP/2-Performance

Theorie ist großartig, aber es ist überzeugender, wenn wir einige reale Daten und reale Leistungsverbesserungen von HTTP/2 gegenüber HTTP1.x sehen können. Wir werden einige Tests durchführen, um festzustellen, ob wir eine deutliche Leistungssteigerung feststellen.

Warum nennen wir das einen semi-wissenschaftlichen Test?

Wenn dies ein Labor oder gar eine Entwicklungsumgebung wäre, in der wir exakte Ergebnisse demonstrieren wollten, würden wir alle Variablen eliminieren und nur die Leistung desselben HTML-Inhalts testen, einmal mit HTTP1.x und einmal mit HTTP/2.

Doch (die meisten von uns) leben nicht in einer Entwicklungsumgebung. Unsere Webanwendungen und Websites agieren in der realen Welt, in Umgebungen, in denen aus allen möglichen gültigen Gründen Schwankungen auftreten. Labortests sind also großartig und definitiv erforderlich, aber für diesen Test gehen wir in die reale Welt und führen einige Tests auf einer (simulierten) echten Website durch und vergleichen ihre Leistung.

Wir werden eine standardmäßige Einzelseiten-Bootstrap-Vorlage (Zebre) aus mehreren Gründen verwenden.

1. Es ist ein sehr realistisches Beispiel dafür, wie moderne Websites heute aussehen.
2. Es verfügt über eine recht vielfältige Sammlung von Ressourcen, die typisch für heutige Websites sind und die normalerweise eine Reihe von Optimierungen für die Leistung unter HTTP1.x-Bedingungen durchlaufen würden.
   • 25 Bilder
   • 6 JS-Skripte
   • 7 CSS-Dateien
3. Es basiert auf WordPress, sodass wir eine Reihe von HTTP1.x-basierten Optimierungen durchführen können, um seine Leistung so weit wie möglich zu steigern.
4. Es wurde im Januar kostenlos von ThemeForest verschenkt. Das war eine großartige Zeit, was für ein besserer Praxistest als die Verwendung eines Premium-Themes von einem Elite-Autor auf ThemeForest?

Wir werden diese Tests auf einem brandneuen Konto durchführen, das von Kinsta Managed WordPress Hosting betrieben wird, das wir in letzter Zeit entdeckt haben und dessen Leistung wir wirklich großartig finden. Wir tun dies, weil wir die überlasteten Umgebungen von Shared-Hosting-Konten vermeiden wollen. Um den externen Einfluss anderer Websites, die gleichzeitig auf demselben Konto laufen, zu reduzieren, wird diese Umgebung ausschließlich für diesen Test verwendet.

Wir haben die Tests auf dem niedrigsten Plan durchgeführt, da wir nur eine einzige WordPress-Site testen müssen. In Wirklichkeit gibt es im Gegensatz zu den meisten Hosting-Diensten keinen Unterschied in der Geschwindigkeit/Leistung der Pläne. Die größeren Pläne bieten lediglich Kapazität für mehr Websites. Anschließend haben wir eine der Domains eingerichtet, die wir horten (iwantovisit.com), und darauf WordPress installiert.

Wir haben uns auch entschieden, diese Tests auf WordPress durchzuführen.

Der Grund dafür ist eher Bequemlichkeit als alles andere. Alle diese Tests auf manuellem HTML würden ziemlich viel Zeit in Anspruch nehmen. Wir würden diese Zeit lieber für umfangreichere und konstruktivere Tests verwenden.

Mit WordPress können wir Plugins wie z.B. aktivieren

• Ein Caching-Plugin (um Diskrepanzen bei der Generierungszeit so weit wie möglich zu beseitigen)
• Kombinations- und Minifizierungs-Plugin zur Durchführung von Optimierungen auf Basis von HTTP1.x
• CDN-Plugin zur einfachen Integration mit einem CDN, während HTTP/2-Tests integriert mit einem CDN durchgeführt werden.

Wir haben das Zebre-Theme eingerichtet und mehrere Plugins installiert. Auch das macht den Test sehr realistisch. Sie werden kaum eine WordPress-Website ohne eine Reihe von installierten Plugins finden. Wir haben Folgendes installiert.

Wir haben auch die Demodaten des Zebre-Themes importiert, um ein schön befülltes Theme mit vielen Bildern zu erhalten, was diese Website zu einem idealen Kandidaten für HTTP/2-Tests macht.

Das Letzte, was wir getan haben, war sicherzustellen, dass ein Seiten-Caching vorhanden ist. Wir wollen einfach sicherstellen, dass wir aufgrund von Seiten-Generierungszeiten keine drastischen Schwankungen erleiden. Das Tolle ist, dass mit Kinsta kein Caching-Plugin benötigt wird, da das Seiten-Caching vollständig auf Server-Ebene in den Dienst integriert ist.

Die finale Seite sah ungefähr so aus.

Und das ist unter dem "Fold".

Wir sind bereit für die ersten Tests.

Test 1 – HTTP1 – Caching, aber keine anderen Optimierungen

Beginnen wir mit einigen Tests, um sicherzustellen, dass wir eine gute Testumgebung haben und einige Basiswerte erhalten.

Wir führen diese Tests nur mit WordPress-Caching durch – keine anderen Optimierungen.

Test-Website	Standort	Seitenladezeit	Gesamtseitengröße	Anfragen
GTMetrix	Vancouver	3,3s	7,3 MB	82
Pingdom Tools	New York	1,25s	7,3 MB	82

Es gibt eindeutig etwas Seltsames. Die Ladezeiten sind viel zu unterschiedlich. Oh ja: Google Cloud Platform, zentralamerikanische Server im Osten befinden sich in Iowa, wodurch der Teststandort von Pingdom Tools New York viel näher ist als Vancouver, was die Ergebnisse zugunsten von New York verzerrt.

Sie wissen wahrscheinlich, dass es eine sehr einfache Lösung gibt, um die Leistung Ihrer Website zu verbessern: Hosten Sie Ihre Website oder Anwendung so nah wie möglich am Standort Ihrer Besucher. Dies ist dasselbe Konzept, das CDNs zur Leistungssteigerung nutzen. Je näher die Besucher am Serverstandort der Website sind, desto besser ist die Ladezeit.

Aus diesem Grund werden wir zwei Arten von Tests durchführen. Einer wird einen sehr nahen Standort zwischen dem Hosting-Dienst und dem Teststandort haben. Für den anderen werden wir uns entscheiden, das Problem der Entfernung zu verstärken. Wir werden also eine transatlantische Reise mit unseren Tests unternehmen, von den USA nach Europa, und sehen, ob die HTTP/2-Optimierungen zu einer besseren Leistung führen oder nicht.

Versuchen wir, ähnliche Teststandorte bei beiden Testdiensten zu finden. Dallas, Texas ist ein gängiger Testort, also werden wir ihn für den physisch nahen Standort verwenden. Für den zweiten Standort werden wir London und Stockholm verwenden, da es keinen gemeinsamen europäischen Standort gibt.

Test-Website	Standort	Seitenladezeit	Gesamtseitengröße	Anfragen
Pingdom Tools	Dallas	2,15s	7,3 MB	82

Das ist besser. Führen wir noch ein paar Tests durch.

Test-Website	Standort	Seitenladezeit	Gesamtseitengröße	Anfragen
GTMetrix	Dallas	1,6s	7,3 MB	83
Pingdom Tools	Dallas	1,74s	7,3 MB	82
GTMetrix	London	2,6s	7,3 MB	82
Pingdom Tools	Stockholm	2,4s	7,3 MB	82

Sie bemerken vielleicht einige Schwankungen bei den Anfragen. Wir glauben, dass diese von externen Skripten stammen, die manchmal in der Anzahl der generierten Anfragen variieren. Tatsächlich, obwohl die Ladezeiten um etwa eine Sekunde variieren zu können scheinen, können wir bei Betrachtung des Wasserfalldiagramms sehen, dass die Assets auf der Website ziemlich konsistent geliefert werden. Es sind die externen Assets (insbesondere: Schriftarten), die stark schwanken.

Wir können auch deutlich sehen, wie die Entfernung die Ladezeit signifikant um etwa eine Sekunde beeinflusst.

Bevor wir fortfahren, werden Sie auch feststellen, dass unsere Score für Geschwindigkeitsoptimierung miserabel ist. Deshalb werden wir für unsere zweite Testrunde eine Reihe von Geschwindigkeitsoptimierungen durchführen.

Test 2 – HTTP1 mit Performance-Optimierungen und Caching

Da wir wissen, dass HTTP1.x sehr ineffizient im Umgang mit Anfragen ist, werden wir eine Runde von Performance-Optimierungen durchführen.

Wir werden HummingBird von WPMUDEV auf der WordPress-Installation installieren. Dies ist ein Plugin, das die Ladezeiten von Seiten optimiert, ohne zu cachen. Genau das, was wir brauchen.

Wir werden die meisten Optimierungen aktivieren, die sich auf die Reduzierung von Anfragen und die möglichst häufige Zusammenfassung von Dateien konzentrieren.

• Minifizierung von CSS- und JS-Dateien
• Kombination von CSS- und JS-Dateien
• Aktivierung der GZIP-Kompression
• Aktivierung des Browser-Cachings

Wir werden die Bilder nicht optimieren, da dies die Ergebnisse völlig verfälschen würde.

Wie Sie unten sehen können, haben wir nach unserer Optimierung fast perfekte Werte für alles außer Bildern. Wir werden die Bilder absichtlich unoptimiert lassen, damit sie ihre große Größe behalten und eine gute "Last" zu tragen haben.

Leeren wir die Caches und führen eine zweite Testrunde durch. Sofort sehen wir eine drastische Verbesserung.

Machen Sie sich keine Sorgen über das C bei YSlow. Das liegt daran, dass wir kein CDN verwenden und einige der externen Ressourcen (die Schriftarten) nicht im Browser-Cache gespeichert werden können.

Test-Website	Standort	Seitenladezeit	Gesamtseitengröße	Anfragen
GTMetrix	Dallas	1,9s	7,25 MB	56
Pingdom Tools	Dallas	1,6s	7,2 MB	56
GTMetrix	London	2,7s	7,25 MB	56
Pingdom Tools	Stockholm	2,28s	7,3 MB	56

Wir sehen eine ziemlich schöne Verbesserung auf der Website. Als Nächstes werden wir HTTPS auf der Website aktivieren. Dies ist eine Voraussetzung für die Einrichtung von HTTP/2.

Test 3 – HTTP/2 ohne Optimierungen und Caching

Wir werden die Let's Encrypt-Funktionalität verwenden, um ein kostenloses SSL-Zertifikat zu erstellen. Dies ist in Kinsta integriert, was bedeutet, dass die Einrichtung von HTTPS ziemlich einfach sein sollte.

Nachdem wir ein HTTPS-Zertifikat generiert haben, werden wir das Really Simple SSL WordPress Plugin verwenden, um HTTPS auf der gesamten Website zu erzwingen.

Dieses Plugin prüft, ob ein sicheres Zertifikat für die Domain auf Ihrem Server vorhanden ist. Wenn ja, erzwingt es HTTPS auf Ihrer WordPress-Website. Dieses Plugin macht die Implementierung von HTTPS auf Ihrer Website wirklich zum Kinderspiel. Wenn Sie eine Migration von HTTP zu HTTPS durchführen, vergessen Sie nicht, eine vollständige 301-Weiterleitung von HTTP zu HTTPS durchzuführen, damit Sie während des Erzwingens von HTTPS auf Ihrer Website keine Besucher oder Suchmaschinen-Rankings verlieren.

Nachdem wir HTTPS auf unserer Website vollständig aktiviert und getestet haben, müssen Sie möglicherweise etwas Magie anwenden, um Ressourcen über HTTP/2 zu servieren. Obwohl die meisten Server heute Sie direkt zu HTTP/2 wechseln, wenn Sie eine SSL-Seite betreiben.

Kinsta läuft auf Nginx und aktiviert HTTP/2 standardmäßig auf SSL-Sites. Daher reicht die Aktivierung von SSL aus, um die gesamte Website auf HTTP/2 umzustellen.

Sobald wir die Konfiguration durchgeführt haben, sollte unsere Website nun über HTTP/2 ausgeliefert werden. Um zu bestätigen, dass die Website über HTTP/2 läuft, haben wir diese nette Chrome-Erweiterung installiert, die prüft, welche Protokolle von unserer Website unterstützt werden.

Sobald wir bestätigt haben, dass HTTP/2 einwandfrei funktioniert, können wir eine weitere Testrunde durchführen.

Test-Website	Standort	Seitenladezeit	Gesamtseitengröße	Anfragen
GTMetrix	Dallas	2,7s	7,24 MB	82
Pingdom Tools*	Dallas	2,04s	7,3 MB	82
GTMetrix	London	2,4s	7,24 MB	82
Pingdom Tools*	Stockholm	2,69s	7,3 MB	82

*Leider verwendet Pingdom Tools Chrome 39, um die Tests durchzuführen. Diese Version von Chrome hat keine HTTP/2-Unterstützung, daher können wir die Geschwindigkeitsverbesserungen nicht realistisch berechnen. Wir führen die Tests trotzdem durch, da wir einen Benchmark zum Vergleichen haben.

Test 4 – HTTP/2 mit Performance-Optimierungen und Caching

Nachdem wir nun HTTP/2 ohne Performance-Optimierungen gesehen haben, ist es auch eine gute Idee, tatsächlich zu prüfen, ob HTTP1-basierte Performance-Optimierungen einen Unterschied machen können und werden, wenn HTTP/2 aktiviert ist.

Es gibt zwei Denkweisen hierzu.

• Dagegen: Um Optimierungen zur Reduzierung von Verbindungen und Größe durchzuführen, fügen wir der Website einen Performance-Overhead hinzu (während der Server Minifizierung und Kombination von Dateien durchführt), daher gibt es eine negative Auswirkung auf die Leistung.
• Dafür: Die Durchführung solcher Minifizierungen und Kombinationen von Dateien und anderer Optimierungen wird unabhängig vom Protokoll eine Leistungsverbesserung bringen, insbesondere die Minifizierung, die im Wesentlichen die Größe der zu liefernden Ressourcen reduziert. Jeder Performance-Overhead kann durch Caching gemildert werden.

Test-Website	Standort	Seitenladezeit	Gesamtseitengröße	Anfragen
GTMetrix	Dallas	1,0s	6,94 MB	42
Pingdom Tools**	Dallas	1,45s	7,3 MB	56
GTMetrix	London	2,5s	7,21 MB	56
Pingdom Tools**	Stockholm	2,46s	7,3 MB	56

**HTTP/2 wird nicht unterstützt

Test 5 – CDN mit Performance-Optimierungen und Caching (kein HTTP/2)

Sie haben wahrscheinlich immer wieder gesehen, wie eine der wichtigsten Möglichkeiten zur Verbesserung der Leistung einer Website die Implementierung eines CDN (Content Delivery Network) ist.

Aber warum sollte ein CDN *immer noch* erforderlich sein, wenn wir jetzt HTTP/2 verwenden?

Ein CDN wird weiterhin benötigt, auch wenn HTTP/2 vorhanden ist. Der Grund dafür ist, dass ein CDN nicht nur die Leistung aus Infrastruktursicht verbessert (leistungsfähigere Server zur Bewältigung des Verkehrsaufkommens), sondern auch die Entfernung reduziert, die die schwersten Ressourcen Ihrer Website zurücklegen müssen.

Durch die Verwendung eines CDN werden Ressourcen wie Bilder, CSS und JS-Dateien von einem Standort aus bereitgestellt, der (typischerweise) physisch näher an Ihrem Endbenutzer liegt als der Hosting-Server Ihrer Website.

Dies hat einen impliziten Leistungsvorteil: Je weniger Inhalt reisen muss, desto schneller lädt Ihre Website. Dies ist etwas, dem wir in unseren anfänglichen Tests bereits begegnet sind. Physisch nähere Teststandorte schneiden bei den Ladezeiten deutlich besser ab.

Für unsere Tests werden wir unsere Website auf einem Incapsula CDN-Server ausführen, einem der CDN-Dienste, die wir in letzter Zeit für unsere Websites verwenden. Natürlich wird jedes CDN die gleichen oder ähnliche Vorteile haben.

Es gibt ein paar Möglichkeiten, wie ein typisches CDN funktioniert.

• URL-Rewrite: Sie installieren ein Plugin oder schreiben Code, so dass die Adresse von Ressourcen umgeschrieben wird, damit sie vom CDN statt von der URL Ihrer Website geliefert werden.
• Reverse Proxy: Sie nehmen DNS-Änderungen vor, so dass das CDN den Großteil Ihres Datenverkehrs abwickelt. Der CDN-Dienst leitet dann die Anfragen nach dynamischen Inhalten an Ihren Webserver weiter.

Test-Website	Standort	Seitenladezeit	Gesamtseitengröße	Anfragen
GTMetrix	Dallas	1,5s	7,21 MB	61
Pingdom Tools	Dallas	1,65s	7,3 MB	61
GTMetrix	London	2,2s	7,21 MB	61
Pingdom Tools	Stockholm	1,24s	7,3 MB	61

Test 6 – CDN mit Performance-Optimierungen und Caching und HTTP/2

Der letzte Test, den wir durchführen werden, ist die Implementierung aller möglichen Optimierungen. Das bedeutet, wir betreiben ein CDN mit HTTP/2 auf einer Website, die mit HTTP/2 läuft und bei der alle Seitenladeoptimierungen durchgeführt wurden.

Test-Website	Standort	Seitenladezeit	Gesamtseitengröße	Anfragen
GTMetrix	Dallas	0,9s	6,91 MB	44
Pingdom Tools**	Dallas	1,6s	7,3 MB	61
GTMetrix	London	1,9s	6,90 MB	44
Pingdom Tools**	Stockholm	1,41s	7,3 MB	61

**HTTP/2 wird nicht unterstützt

Sehr gut! Wir haben eine Ladezeit von unter einer Sekunde für eine 7-MB-Website! Das ist ein beeindruckendes Ergebnis, wenn Sie mich fragen!

Wir sehen deutlich, welchen positiven Einfluss HTTP/2 auf die Website hat – wenn man die Ladezeiten vergleicht, sieht man, dass es einen Unterschied von 0,5 Sekunden bei den Ladezeiten gibt. Da wir in einer Umgebung arbeiten, die im schlimmsten Fall in weniger als 2 Sekunden lädt, ist ein Unterschied von 0,5 Sekunden eine RIESIGE Verbesserung.

Dies ist das Ergebnis, das wir uns tatsächlich erhofft haben.

Ja, HTTP/2 macht wirklich einen Unterschied.

Fazit – Analyse der HTTP/2-Performance

Obwohl wir versucht haben, Schwankungen so gut wie möglich zu eliminieren, wird es in unserem Setup einige Ungenauigkeiten geben, aber es gibt einen sehr klaren Trend. HTTP/2 ist schneller und ist der empfohlene Weg nach vorn. Es gleicht den Performance-Overhead aus, der bei HTTPS-Websites entsteht.

Unsere Schlussfolgerungen sind daher:

1. HTTP/2 ist in Bezug auf Performance und Seitenladezeit schneller als HTTP1.x.
2. Minifizierung und andere Wege zur Reduzierung der Größe der ausgelieferten Webseite werden immer mehr Vorteile bringen als der Overhead, der für diese "Minifizierung" erforderlich ist.
3. Die Reduzierung der Entfernung zwischen Server und Client wird immer Leistungsvorteile bei der Seitenladezeit bringen. Die Verwendung eines CDN ist daher weiterhin notwendig, wenn Sie die Leistung Ihrer Website maximieren möchten, unabhängig davon, ob Sie HTTP/2 aktiviert haben oder nicht.

Was halten Sie von unseren Ergebnissen? Haben Sie HTTP/2 bereits implementiert? Haben Sie auch bessere Ladezeiten gesehen?