Eine Einführung in HTTP/2 und Pagespeed

Veröffentlicht: 2020-01-03

Einführung

1991 wurde die erste dokumentierte Version des Request-Response-HTTP-Protokolls (HTTP 0.9) eingeführt. Seitdem hat sich das Web drastisch erweitert, und 24 Jahre später wurde 2015 die neueste Version des HyperText Transfer Protocol (HTTP/2) veröffentlicht, die bei richtiger Implementierung eine Vielzahl möglicher Vorteile für die Leistung der Website einführt.

Dieser Artikel richtet sich an SEOs, die HTTP/2 als Teil ihrer Initiativen zur Optimierung der Seitengeschwindigkeit implementieren möchten.

HTTP/2 ist ein äußerst reichhaltiges Thema, das ausführlich diskutiert werden könnte. Es gibt eine Fülle von Online-Informationen über HTTP/2 und seine weiteren Vorteile für Endbenutzer und Entwickler, aber bevor Sie in die Fülle von Informationen rund um HTTP/2 eintauchen, stellen Sie sicher, dass Sie die Informationen erhalten, die Sie benötigen. Das beginnt damit, die richtigen Fragen zu stellen:

  1. Wie wirkt sich dies direkt auf die Suchmaschinenoptimierung und/oder die Seitengeschwindigkeit aus?
  2. Kann aus der Erkenntnis eine Empfehlung abgeleitet werden?
  3. Ist die Empfehlung realistisch umsetzbar?

Diese Fragen helfen Ihnen zu fragen : „Ist das, was ich tue, effektiv und wertvoll?“ und versetzen Sie letztendlich in eine bessere Position, um zu bewerten, wie HTTP/2 zur Verbesserung einer Website beitragen kann.

Aufgrund der Breite des Themas gibt es eine große Menge an Wissen über HTTP/2, das nicht benötigt wird, wenn man versucht, die Bedeutung für SEO zu verstehen. Der Hauptvorteil von HTTP/2 für SEO ist die Seitengeschwindigkeit.

Um Ihnen bei der Navigation durch die Fülle von Online-Informationen zu helfen, finden Sie hier eine Einführung in HTTP/2, die die Entwicklung von HTTP 1.1 bis hin zu Googles HTTP-kompatiblem Spdy und schließlich zu HTTP/2 beschreibt.

Wenn Sie verstehen, wie sich das Web entwickelt hat, können Sie die Verbesserungen hervorheben, die als Folge der Hinzufügung des HTTP/2-Protokolls vorgenommen wurden.

Wie bewertet Google die Seitengeschwindigkeit?

Um zu sehen, wie Google die Seitengeschwindigkeit bewertet, sehen Sie sich die Chrome User Experience Reports an . Diese Berichte liefern Metriken zur Benutzererfahrung, wie Benutzer beliebte Ziele im Internet erleben. Dies wird durch wichtige Kennzahlen zur Benutzerinteraktion (First Paint, First Contentful Paint, First Meaningful Paint, Time to Interactive) unterstützt und durch gängige Tools wie Page Speed ​​Insights, Public Google Big Query Project, Lighthouse und Web Page Test unterstützt. Die Verwendung dieser Metriken und Tools kann dazu beitragen, mögliche Verbesserungen in Bezug auf die Seitengeschwindigkeit vorzunehmen.

Einführung in HTTP/2

HTTP 1.1

Bis 2015 war HTTP 1.1 veraltet. Vorbei sind die Zeiten, in denen Webseiten/Sites auf Basis von HTML, CSS und JavaScript sowie zahlreichen Ressourcen und verschiedenen Frameworks erstellt wurden. Die Ära vor 2015 basierte auf der Idee, dass Sie auf eine Anfrage pro TCP-Verbindung beschränkt waren. Dies führte zu Situationen, in denen Webclients mehrere Ressourcen für den Download in die Warteschlange stellten, was zu einer Überlastung des Netzwerks und langsamen Seitenladezeiten führte.

HTTP/2 wurde entwickelt, um auf drei Hauptverbesserungsbereiche abzuzielen, um die oben diskutierten Probleme zu lindern:

  • Einfachheit
  • Hochleistung
  • Robustheit

SEO-Vorteile für HTTP/2

Die Seitengeschwindigkeit ist wahrscheinlich der Hauptgrund, warum SEOs die Implementierung von HTTP/2 auf ihren eigenen oder den Websites ihrer Kunden in Betracht ziehen würden. Page Speed/Performance ist eine Reihe von Metriken, die seit 2010 ein Rankingfaktor für Desktop-Anfragen sind. Aufgrund der zunehmenden Nutzung mobiler Geräte gab Google im Juli 2018 offiziell bekannt , dass Page Speed ​​zu einem Rankingfaktor für Mobile wird.

HTTP/2 bietet 3 Hauptfunktionen, die bei der Optimierung von Websites für Page Speed ​​verwendet werden können:

  1. Multiplexing
  2. Server-Push
  3. Stream-Priorisierung

Multiplexing

Multiplexing ermöglicht es einem Webclient, mehrere Anfragen in eine einzige TCP-Verbindung aufzunehmen, was zu einer geringeren Serverlast und einer Verringerung der Netzwerküberlastung führt.

Moderne Webclients (Chrome, Firefox, Safari und Opera), die die älteren HTTP 1/1.1-Protokolle verwenden, haben eine Standardbegrenzung für die Anzahl gleichzeitiger TCP-Verbindungen pro Hostname. Daher kann ein Webclient, der HTTP 1/1.1 verwendet, leicht Schwierigkeiten mit TCP-Überlastung haben. Bei modernen Webclients wird dieses Problem mithilfe von Multiplexing gelöst, was einige der bedeutendsten Verbesserungen der Seitengeschwindigkeit bewirken kann.

Unten wird der Vorteil von Multiplexing anhand eines Vergleichs von HTTP/1.1 und HTTP/2 demonstriert, der typisches Verhalten zeigt, wenn HTTP/2-Multiplexing aktiviert und nicht aktiviert ist.

( WebpageTest, HTTP/1.1, kein Multiplexing demonstriert )

( WebpageTest, HTTP/2, Multiplexing demonstriert )

In den obigen Bildern wird ein leistungsbasierter Wasserfall verwendet, um das Laden von Ressourcen zwischen einem Benutzer (der die Ressourcen anfordert) und dem Server (der auf die Ressourcen antwortet) einer Webseite zu demonstrieren. Zu den Seitenressourcen gehören in der Regel HTML, JavaScript, CSS und Bilder. Der leistungsbasierte Wasserfall zeigt den genauen Zeitpunkt, an dem eine bestimmte Ressource aufgerufen, heruntergeladen und im Client gerendert wird, was für die Erkennung, Bewertung und Analyse von Seitengeschwindigkeitsproblemen auf einer Website von entscheidender Bedeutung ist. Wie das obige Bild „HTTP/2“ zeigt, beginnen alle Ressourcen gleichzeitig mit dem Herunterladen, ohne dass Ressourcen an einem anderen Punkt zu laden beginnen. Da HTTP/2 Multiplexing verwendet und nicht mehr darauf angewiesen ist, nur eine Anfrage über eine einzelne TCP-Verbindung zu senden, können mehrere Ressourcen gleichzeitig heruntergeladen werden, wie oben gezeigt. Im Gegensatz dazu werden, wie das Bild „HTTP/1.1“ zeigt, Ressourcen nicht gleichzeitig heruntergeladen, da sie die Multiplexing-Funktionalität nicht nutzen können. Der durchschnittliche moderne Browser unter HTTP/1.1 kann gleichzeitig 6 Verbindungen haben, aber der Vorteil der Implementierung von HTTP/2 besteht darin, dass nicht für jede Anfrage ein TCP-Handshake erforderlich ist, während mit HTTP/1.1 eine Initiale unabhängig davon, wie viele Verbindungen gleichzeitig ausgeführt werden können Verbindungsprozess muss jedes Mal abgeschlossen werden. Daher beginnen sie an unterschiedlichen Stellen mit dem Herunterladen und verursachen so eine längere Seitenlast für den Benutzer.

( Upwork HTTP/1.1 vs. HTTP/2-Diagramm )

Such-Crawler wie Google und Bing profitieren nicht direkt von der HTTP/2-Implementierung. Wie oben beschrieben, könnte der größte Vorteil dieser Optimierungen möglicherweise für die Seitengeschwindigkeit liegen. Obwohl sich die HTTP/2-Implementierung möglicherweise nicht direkt auf den Suchcrawler auswirkt, kann sie sich auf die Seitengeschwindigkeit auswirken, die seit 2010 ein direkter Rankingfaktor für Google für Desktop-Anfragen und seit Juli 2018 für mobile Anfragen ist. Daher ist es entscheidend, dass Websites nicht liefern ein langsames Erlebnis für die Nutzer, da Google die Leistung unter Umständen durch Beeinträchtigung des Rankings oder neuerdings durch das Warnen der Nutzer darüber, dass Ihre Website möglicherweise langsam ist, unterdrücken kann.

Server-Push

Server Push ermöglicht es dem spezifischen Server oder Edge-Netzwerk, Ressourcen an Webclients zu senden, wenn sie nicht vom Client angefordert wurden. Um zu verstehen, wie Server-Push funktioniert, ist es zunächst wichtig, das Anfrage-Antwort-Muster zu verstehen, dem eine Website folgt. Ein Benutzer fordert eine Seite von einer Website an und der Server antwortet mit dem angeforderten Inhalt/der angeforderten Ressource.

Stellen Sie sich hypothetisch eine Site vor, bei der alle Stile in einem externen Stylesheet namens styles.css definiert sind. Wenn der Benutzer das HTML-Skelett für die Seite anfordert (sagen wir in diesem Fall index.html), kann der Server-Push das CSS direkt nach Beginn der Antwort an index.html an den Benutzer „pushen“.

( Smashing Magazine, Server Push )

Bevor Sie verstehen, wie Server Push zur Verbesserung der Seitengeschwindigkeit beitragen kann, ist es wichtig zu verstehen, wie ein Browser mit verschiedenen Ressourcen wie Bildern, CSS und JavaScript arbeitet, die in Ihrem Browser angezeigt werden. Wie Sie sehen, sendet der Browser Anweisungen zum Herunterladen von Bildern, CSS- und JavaScript-Ressourcen. Wenn Sie eine Website zum ersten Mal besuchen, stellen Sie normalerweise eine GET-Anfrage, bei der es sich um die .html-Datei handelt. Sobald diese .html-Datei empfangen wurde, durchsucht der Browser sie, um sie zu verstehen, und kann dann je nach Inhalt der HTML-Datei zusätzliche GET-Anforderungen stellen.

Wie trägt Server Push zur Verbesserung der Seitengeschwindigkeit bei?

Durch die Verwendung von Server Push wird die Anzahl der vom Browser benötigten GET-Anfragen (Roundtrips) reduziert und Verzögerungen beim Rendern, die zu erhöhten Seitenladezeiten führen, vermieden. Dies kann erheblich dazu beitragen, die Renderzeit für den Webclient zu verkürzen, was dazu beiträgt, dass die Webseite für Benutzer schneller angezeigt wird, wodurch ihnen ein weitaus besseres Erlebnis geboten wird.

Während Server Push keinen direkten Einfluss darauf hat, wie der Googlebot Ihre Website oder andere Crawler crawlt, wird der SEO-Vorteil durch Verbesserungen an benutzerzentrierten Faktoren wie First Paint und First Meaningful Content erzielt.

Mithilfe von Web Page Test, Lighthouse, Page Speed ​​Insights und dem Chrome User Experience Report können Sie feststellen, wie eine Website/Seite im Vergleich zu Wettbewerbern in denselben Branchen abschneidet. Unten sind zwei Bilder, die die Implementierung ohne (Bild 1) und mit Server Push (Bild 2) demonstrieren.

(WebpageTest, ohne Server-Push)

(WebpageTest, HTTP/1.1, mit Server-Push)

Mit Server-Push kann der Server so konfiguriert werden, dass er immer alle zusätzlichen Seitenkomponenten (wie CSS-Dateien, JavaScript und Bilder) sendet, wenn er aufgefordert wird, die enthaltene .html-Datei zu senden.

In den obigen Wasserfällen können wir sehen, dass push.php vier CSS-Dateien verwendet.

Ohne Server-Push muss der Browser die push.php-Datei empfangen, den HTML-Code parsen und dann spezifische Anfragen für jede zusätzliche CSS-Datei stellen. Erst wenn es alle CSS-Dateien erhalten hat, kann es damit beginnen, sie im Rendering-Prozess zu verwenden.

Wenn Server-Push aktiviert ist, löst die Anfrage für push.php automatisch den Server aus, um die vier CSS-Dateien zu senden. Der Browser erhält sie und kann sie viel früher im Rendering-Prozess verwenden. Dies bedeutet, dass der Browser viel früher mit dem Rendern des Seiteninhalts beginnen kann, was zu besseren Messwerten für die Seitengeschwindigkeit führt.

HTTP/2-Priorisierung

Die HTTP/2-Priorisierung gibt die Kontrolle über die Reihenfolge, in der Ressourcen geladen werden, an die Websitebesitzer zurück. Richtig durchgeführt, fördert die Priorisierung das Benutzererlebnis und die Seiten-/Site-Geschwindigkeit, indem Seitenressourcen in einer optimierten Reihenfolge bereitgestellt werden, wodurch ein „schnelles“ Benutzererlebnis entsteht.

Wenn wir uns den Vorgänger HTTP/1.1 von HTTP/2 ansehen, steuerte der Webclient die Reihenfolge, in der Ressourcen geladen wurden. Wie oben besprochen, lag dies daran, dass jede TCP-Verbindung jeweils nur eine Ressource unterstützen konnte. Es ist Sache des Browsers, Anforderungen zu planen, indem er entscheidet, welche Ressourcen ausgewählt und wie viele Verbindungen parallel geöffnet werden sollen.

Bevor wir uns mit der Vorgehensweise befassen, ist es wichtig zu verstehen, warum wir die Priorisierung für unsere Ressourcen verwenden möchten.

Wenn wir ein Bild oben auf einer Seite und ein Bild unten auf der Seite haben, möchten wir logischerweise sicherstellen, dass das Bild oben vor dem Bild unten geladen wird. Dieses Konzept hilft dabei, die Bedeutung und Wirkung der HTTP/2-Priorisierung zu demonstrieren. Durch die HTTP/2-Priorisierung können wir angeben, welche Ressourcen zuerst bereitgestellt und vor anderen geladen werden sollen (ob JavaScript, CSS oder Bilder), wodurch die schnellste Ladezeit für die Seite sichergestellt wird.

Während der Browser jetzt mithilfe von Multiplexing mehrere Ressourcen gleichzeitig über eine einzige TCP-Verbindung anfordern kann, kann er jetzt auch Prioritätsinformationen bei jeder Anforderung angeben, um zu bestimmen, wann/wie die Ressource geliefert werden soll. Wenn sowohl der Server als auch der Browser die HTTP/2-Priorisierung unterstützen, sollte der Browser die Regeln für die Priorisierung unter Verwendung der vollen Bandbreite definieren, ohne dass Ressourcen miteinander konkurrieren. Um besser zu verstehen, wie der Priorisierungsprozess funktioniert, ist es wichtig, drei Parameter zu diskutieren, die für die HTTP/2-Priorisierung wichtig sind:

Stream: Dies ist ein bidirektionaler Fluss von Bytes innerhalb einer hergestellten Verbindung, der eine oder mehrere Nachrichten transportieren kann.

Übergeordneter Stream: Dies ist ein Stream, von dem die Ressourcen abhängig sind

Untergeordneter Stream: Dies ist ein abhängiger Stream des übergeordneten Streams. Sie haben denselben Elternteil und werden daher als Kindstrom bezeichnet

Gewichtung: Dies ist eine Zahl zwischen 1 und 256, die angibt, wie viel Bandbreite dem Stream zugewiesen werden soll, wenn mehrere Streams eine Verbindung teilen. Die Bandbreite wird relativ zu den Gewichtungen aller anderen aktiven Streams zugewiesen.

Exclusive Bit: Dies ist ein Flag, das angibt, dass der Stream heruntergeladen werden soll, ohne Bandbreite mit anderen Streams zu teilen.

Header Frame: Dies ist die Identifikation für den Stream, zu welchem ​​Frame er gehört

Binary Framing Layer: So werden HTTP-Nachrichten gekapselt und zwischen Client und Server übertragen

Ein Beispiel unten zeigt ein Beispiel für das Obige:

( Google Developers HTTP/2-Stream-Priorisierung )

Um die HTTP/2-Priorisierung durchzuführen, müssen Sie Priorisierungsinformationen innerhalb des Header-Frames hinzufügen, der sich innerhalb der neuen HTTP/2 Binary Framing Layer befindet. Der übergeordnete Strom und die Abhängigkeit/Nicht-Abhängigkeit von anderen untergeordneten Strömen bestimmen die Priorität/Gewichtung und somit die Lieferung der Ressource an den Webclient.

Obwohl die HTTP/2-Priorisierung mittlerweile auf zahlreichen Plattformen unterstützt wird, unterstützen viele CDNs und Hosting-Anbieter die HTTP/2-Priorisierung nicht. Es ist daher wichtig sicherzustellen, dass Sie einen CDN/Hosting-Anbieter verwenden, der die HTTP/2-Priorisierung unterstützt, wenn Sie diese Optimierungstechnik verwenden möchten. Nachfolgend finden Sie eine Tabelle, die beschreibt, welche CDN/Hosting/Server die HTTP/2-Priorisierung unterstützen können und welche nicht.

HTTP/2-Priorisierung – Gemeinsame Server-/Hosting-/CDNs-Kompatibilität

Dieser Vergleich war am 01.02.2020 korrekt, aber es lohnt sich zu prüfen, ob potenzielle Dienstanbieter ihre Kompatibilität verbessert haben, bevor Sie Ihre Entscheidung treffen.

Es ist auch wichtig, bestimmte Browser kritisch zu betrachten, da leider nicht alle Browser die HTTP/2-Priorisierung unterstützen und aufgrund unterschiedlicher Webclients unterschiedlich priorisieren. Nachfolgend finden Sie eine Tabelle, die beschreibt, welche Webclients die HTTP/2-Priorisierung unterstützen können.

Kompatibilität des Webclients mit HTTP/2-Priorisierung

Die HTTP/2-Priorisierung kann die Wahrnehmung der Seiten-/Site-Geschwindigkeit durch einen Benutzer erheblich verbessern und wirkt sich positiv auf die im Chrome-Benutzererfahrungsbericht gesammelten Daten aus. Während diese Optimierung keine Auswirkungen auf Such-Crawler wie Googlebot hat, helfen Ihnen Tools wie Lighthouse und Page Speed ​​Insights dabei, die Auswirkungen der HTTP/2-Priorisierung auf die Seitengeschwindigkeitsleistung aus der Sicht eines Benutzers zu beurteilen.

Durch die korrekte Konfiguration der Stream-Gewichtung mit Server und Client unter Verwendung eines HTTP/2-unterstützten CDN/Hosts können Sie Ihre Seitengeschwindigkeitsmetriken für Ihren Client drastisch verbessern.

Was sind die Voraussetzungen für HTTP/2

Bevor Sie die Geschwindigkeitsvorteile von HTTP/2 nutzen können, stellen Sie sicher, dass Sie es nutzen können. Dabei sind einige Voraussetzungen zu beachten:

  1. Es ist wichtig sicherzustellen, dass HTTPS aktiviert ist.
  2. Verwenden Sie ein TLS-Zertifikat von einer authentifizierten Stelle und aktivieren und installieren Sie das Zertifikat.
  3. Stellen Sie sicher, dass Ihre Webserver-Software wie Nginx, Apache und IIS HTTP/2 unterstützt. Eine vollständige authentifizierte Liste für die Unterstützung finden Sie unter http://ayi.ma/browsershttp2 , die die Browserunterstützung für HTTP/2 zeigt. Wenn Sie nach HTTP/2-Unterstützung für CDNs/Hosting suchen, besuchen Sie bitte http://ayi.ma/serverhosting .

Häufige Fallstricke / Dinge, die sich mit der Einführung von HTTP/2 ändern müssen

Aufgrund der Einschränkungen der früheren Protokolle HTTP 1.0 und HTTP 1.1 haben sich Entwickler und SEOs bemüht, Wege zu finden, um die Vielzahl von Problemen zu umgehen, die diese Einschränkungen für die Leistung und Sicherheit der Seitengeschwindigkeit darstellen.

Schließlich waren sie in der Lage, „Hacks“ zu finden, um einige dieser Einschränkungen zu umgehen, aber viele dieser Methoden verursachten den Entwicklern noch mehr Arbeit. Was sind einige dieser Hacks, die Sie vielleicht fragen? Hier sind einige der häufigsten Hacks, die Sie auf Websites sehen werden, die durch die korrekte Implementierung von HTTP/2 gelöst werden können.

Vermeiden Sie Domain-Sharding

Überraschenderweise verwenden immer noch eine Vielzahl von Websites diesen Hack, obwohl sie HTTP/2 korrekt implementiert haben. Wenn HTTP/2 aktiviert ist, ist es wichtig, die Verwendung von Domain-Sharding zu vermeiden. Domain Sharding ist die Technik, Ressourcen auf verschiedene Hostnamen aufzuteilen, wodurch mehr Ressourcen gleichzeitig bedient werden können.

Dank des aktualisierten HTTP/2-Protokolls wird Domain Sharding nicht mehr benötigt und verursacht tatsächlich mehr Probleme, als es löst. Wenn HTTP/2 für Ihre Website korrekt konfiguriert und aktiviert ist und Sie auch Domain Sharding verwenden, wirken Sie einigen der Vorteile von HTTP/2 entgegen, da der Browser nicht in der Lage sein wird, von Multiplexing und Downloads über mehrere Hostnamen hinweg zu profitieren.

Darüber hinaus brechen Sie durch Domain Sharding tatsächlich die Stream-Priorisierung und Ihre Ressourcen können nicht geladen werden, um das Beste aus der Seitengeschwindigkeit herauszuholen.

Server-Push richtig nutzen

Server Push hat einige Nachteile, die Sie kennen sollten. Server Push kann tatsächlich überstrapaziert werden und Sie sollten bei der Wahl des Einsatzes wählerisch sein. Sie möchten nicht unbedingt zu viele Ressourcen pushen, da dies dazu führen könnte, dass der Webclient nicht nur HTML herunterlädt, sondern alles, womit er „gepusht“ wird. Dies bedeutet, dass das Laden und Rendern der Seite tatsächlich länger dauern kann (was die nutzerzentrierten Metriken erhöht, auf die sich Google konzentriert, wie z. B. Time to Interactive).

Ein zweiter häufiger Fallstrick beim Server-Push ist herauszufinden, wie Ressourcen, die der Webclient bereits hat, nicht gepusht werden können. Dies kann durch zahlreiche Methoden gesteuert werden. Eine Methode besteht darin, sich dafür zu entscheiden, Ressourcen nicht an wiederkehrende Benutzer zu pushen und daher den zurückgekehrten Benutzern zu erlauben, ihre zwischengespeicherten Assets zu verwenden. Dies ist bei weitem die einfachste Implementierung. Dies kann einfach erfolgen, indem die Cache-Header auf die Ressourcen überprüft werden, um sicherzustellen, dass sich die Header nicht mit der Server-Push-Implementierung überschneiden.

Real-Life-Tests unter HTTP/2

Theoretisches Wissen ist immer wichtig, um die Grundlage zum Verständnis von HTTP/2 und seinen Vorteilen zu legen. Sobald die Konzepte erfasst und verstanden sind, ist es jedoch wichtig, diese Theorien zu testen, um die Auswirkungen zu messen, die HTTP/2 auf die Seitengeschwindigkeit haben kann.

Teil 2 dieser Page Speed-Reihe HTTP/2 im wirklichen Leben – Nutzung von Website-Tests und -Analysen wird die wahren Vorteile von HTTP/2 in Bezug auf Page Speed ​​und den Wert für SEO erörtern, also verpassen Sie es nicht!

Was ist mit HTTP/3?

Obwohl HTTP/3 ein klares Potenzial als Nachfolgeprotokoll von HTTP/2 aufweist, bedeutet es nicht und sollte nicht das Ende von HTTP/2 für SEOs im gesamten Web signalisieren. Wie bei jeder neuen großen Entwicklung im World Wide Web wird es eine normale Rollout-Phase durchlaufen und es wird wahrscheinlich einige Zeit dauern, bis eine Website das neue Protokoll übernimmt und bevor es zu einem De-facto-Standard in der SEO-Branche wird. Die HTTP/2-Implementierung stellt immer noch einen nützlichen und einfachen Gewinn dar, der bei korrekter Implementierung zur Verbesserung der Leistung Ihrer Website beitragen kann.