HTTP/2 & SEO: Was kann das neue Protokoll und wie funktioniert es?

Hallo Searchers,

heute möchte ich über das Thema HTTP/2 und dessen Einfluss auf das Ranking einer Website in den Suchmaschinen sprechen.

Folgende 3 Fragen werden in diesem Artikel bearbeitet:

  1. Wirkt sich der Einsatz von HTTP/2 positiv auf das Ranking einer Website innerhalb von Suchmaschinen aus?
  2. Was ist HTTP/2 und wie funktioniert das neue Protokoll?
  3. Wie muss die Struktur der Website aufgebaut sein, um die Funktionen dieser neuen Technik vollumfänglich nutzen zu können?

Das Thema HTTP/2 wird meiner Meinung nach von den meisten Verantwortlichen stark unterschätzt. Oft verwenden nur die großen Player in den SERPs wie z.B. Amazon, Wikipedia, Ebay etc. diese Technik. Ich kann den Grund, weshalb das neue Protokoll so selten genutzt wird zwar nicht wirklich nachvollziehen, aber ich nehme an, dass vielen bis dato einfach das nötige Know-How fehlt, um HTTP/2 sauber und fehlerfrei für aktuelle oder kommende Projekte einzusetzen.

Bevor wir jetzt aber in die Tiefe gehen, möchte ich euch ein paar Hintergrundinformationen zum Thema „Website Performance“ und dessen Wichtigkeit geben.

Einer der Hauptgründe weshalb sich Google als beliebteste Suchmaschine durchgesetzt hat, war unter anderem die sehr schnelle Auslieferung von Suchergebnissen.

Der Nutzer bekam also nach Eingabe einer Suchphrase sofort ein Ergebnis, ohne lange Wartezeit wie bei anderen Suchmaschinen der früheren Zeit. Der Fokus auf die Performance spielt schon seit Beginn der Entwicklung von Google eine entscheidende Rolle. Aber nicht nur für Suchmaschinen ist dieses Thema essentiell, sondern auch für alle anderen Webanwendungen, Websites und Webshops.

Vielleicht kennt Ihr das bekannte Beispiel von Amazon:

 Der E-Commerce-Gigant Amazon hat schon 2012 errechnet, dass eine Ladezeit länger als 100 Millisekunden den Umsatz um etwa 1% reduziert. Der Tagesumsatz von Amazon.com liegt bei ca. 67 Millionen Dollar. Das entspricht entgangenen Opportunitätskosten von 670.000 Dollar am Tag, die sich im Jahr auf 244,5 Millionen Dollar im Jahr summieren würden. https://de.ryte.com/wiki/Page_Speed

Was ist HTTP/2?

HTTP/2 ist der Nachfolger von HTTP 1.1 und wurde für ein schnelleres und sicheres World Wide Web entwickelt.

HTTP bedeutet ausgeschrieben Hyper Text Transfer Protocol. HTTP ist verantwortlich für den Austausch von Daten (Bilder, Stylesheets usw.) zwischen dem Client (Browser) und dem Server.

Die Funktionsweise von HTTP/2 basiert zum Großteil auf dem von Google ins Leben gerufene Projekt „SPDY“ – gesprochen: Speedy.

Bereits heute wird HTTP/2 von ca. 80% aller Browser und Web Hosting Provider unterstützt. In Kürze wird sich das neue Protokoll also zu großer Wahrscheinlichkeit als Standard etablieren.

Hier ist ein Screenshot von der Plattform „caniuse“, welcher anzeigt, welche Browser HTTP/2 bereits unterstützen:

HTTP/2 Browser Support - Weltweit
HTTP/2 Browser Support – Weltweit – https://caniuse.com/#feat=http2 

Voraussetzungen für HTTP/2

Eine wichtige Info vorab:
HTTP/2 ist abwärtskompatibel, d.h. dass durch die Umstellung oder durch das Upgrade keine Nachteile entstehen können, welche sich negativ auf die Ladezeit oder auf die Funktionsweise einer Website auswirken. Damit das neue Protokoll jedoch in voller Gänze eingesetzt werden kann, müsst ihr sicherstellen, dass die folgenden 4 Voraussetzungen gegeben sind:

  • HTTPS (TLS) verschlüsselte Datenübertragung
  • Server und- oder CDN müssen HTTP/2 unterstützen
  • HTTP/2 optimierte Seitenarchitektur (HTML, CSS, JS, IMG)
  • Implementierung der Server Push Technologie (Optional)

Was bringt HTTP/2?

Zunächst einmal sorgt HTTP/2 im Vergleich zu HTTP 1.1 für eine messbare Ladezeitreduzierung. Durch das sog. Multiplexing Verfahren, welches weiter unten erläutert wird, werden altbewährte Methoden zur Steigerung der Web Performance hinfällig.

Ein Beispiel für veraltete Methoden zur Performance Steigerung wäre z.B. das Zusammenfassen von Style oder JavaScript Dateien in eine Datei. Auch Image-Sprite-Sheets sind nach dem Einsatz von HTTP/2 nicht mehr notwendig.

Teure und zeitraubende Optimierungen um schnelle Ladezeiten zu erreichen, werden also zukünftig der Vergangenheit angehören, sofern HTTP/2 richtig eingesetzt bzw. implementiert wird. 😉

Viele meiner Kunden wissen nicht (oder schreiben diesem Thema einfach nicht die nötige Prio zu), dass sich die Performance einer Website grundlegend auf das Verhalten ihrer Nutzer auswirkt.

Aus meiner Sicht ist deshalb eine Sensibilisierung für das Thema Performance heute dringend notwendig.

Ich hole aufgrund dieser Tatsache etwas weiter aus.

Eine schnelle Ladezeit sollte vor allen anderen Dingen an erste Stelle stellen. Design, Funktionen etc. können noch so schön und komplex sein, wenn die Ladezeit nicht stimmt, bringt die schönste Website mit den besten Funktionen Garnichts.

In den letzten Jahren habe ich festgestellt, dass besonders in großen Unternehmen unglaublich viel Geld in Design und Funktion einer Webanwendung gesteckt wird. Auf die Performance selbst wird aber im Vergleich relativ wenig Wert gelegt.

Hauptsache es funktioniert… oder?

Häufig werde ich dann mit diesen Problemstellungen konfrontiert:

  • Niedrige Conversions
  • Zu hohe Absprungraten
  • Wenig wiederkehrende Nutzer
  • Etc.

Nach genauerer Untersuchung fällt mir ein sich wiederholendes Muster auf.

Nämlich? Genau, schlechte Ladezeiten!

An der aktuellen Website herumzudoktern, um irgendwie ein paar Millisekunden an Ladezeit zu verlieren, ist aus meiner Sicht sinnlos und ineffizient.

Den Server und die Struktur einer Website HTTP/2 konform zu gestalten ist hier definitiv die beste und langfristig intelligenteste Lösung.

Besonders im mobilen Bereich kann durch den korrekten Einsatz des neuen Protokolls, die Nutzererfahrung enorm gesteigert und dadurch das Ranking langfristig verbessert werden.

Der mobile Traffic steigt von Jahr zu Jahr, ebenso die Erwartungen der Nutzer an eine möglichst geringe Ladezeit. Warum? Wir kennen es alle. Weil wir unterwegs meistens nicht die schnellste Verbindung haben oder unser Datenvolumen verbraucht ist. Oft dauert das Laden eines Shops oder einer einfachen Information nach der man sucht zu lange.

HTTP/2 wirkt dieser Problematik entgegen.

Nochmals zusammengefasst kann man sagen, dass der Einsatz von HTTP/2 die folgenden Vorteile mit sich bringt:

  • Messbare Ladezeitreduzierung
  • Steigende Conversion Rates
  • Längere Verweildauer der Nutzer
  • Ablösung gängiger Performance-Steigerung-Methoden

Neben den positiven Auswirkungen auf das Nutzerverhalten, ermöglicht HTTP/2 den Suchmaschinen die jeweilige Website effizienter und schneller zu crawlen.

HTTP/2 sorgt also zusätzlich für eine bessere Crawlability.

Ein weiterer Vorteil den ich indirekt bereits erwähnt habe, ist der aktuelle Wettbewerbsvorteil. Die wenigsten haben diese neue Technologie auf dem Schirm und wissen demzufolge nicht, wie man sie korrekt, fehlerfrei und vollständig einsetzt.

Soweit so gut.

Sehen wir uns nun die Funktionsweise von HTTP/2 an.

Zu verstehen wie das Thema funktioniert, ist die Grundlage für alles Weitere das folgt.

Achja, hier habe ich noch für zwischendurch einen ganz interessanten HTTP/2 Test endeckt, mit dem Ihr euch von der Leistung des neuen Protokolls selbst überzeugen könnt.

HTTP/2 Leistungs-Test Demo

Wie funktioniert HTTP/2?

HTTP/1.1 verwendet beim Laden von Seitenelementen wie HTML, CSS, JavaScript und Bilddateien mehrere TCP (Transmission Control Protocol) Verbindungen. Bei HTTP/2 werden mit dem Multiplexing Verfahren mehrere Daten gleichzeitig, also parallel über eine TCP Verbindung übertragen. Die Ladezeit wird dadurch signifikant beschleunigt.

Bei HTTP/1.1 werden die Daten unkomprimiert an den Client (Browser) verschickt. HTTP/2 überträgt die Daten standardmäßig komprimiert im Binärcode, was die Verarbeitung der Daten zusätzlich stark beschleunigt.

Die Funktionsweise von HTTP/2

Generell unterscheidet sich das Protokoll HTTP/2 von HTTP/1.1 durch die Folgenden 3 neuen Funktionsweisen:

  1. Multiplexing Verfahren
  2. Priorisierung von Datenpaketen
  3. Server Push

Das Multiplexing Verfahren von HTTP/2

Wie weiter oben bereits beschrieben, verwendet der Vorgänger von HTTP/2 bei der Datenübertragung zwischen Client (Browser) und Server, mehrere bis ein dutzend TCP Verbindungen bzw. Segmente. Wenn bspw. ein Bild angefordert und geladen wird, benötigt diese Bilddatei eine eigene TCP Verbindung. Wir nehmen mal an, auf einer Website wurden 15 Bilder, 5 Stylesheets & 8 JavaScript Dateien eingebunden. Anschließend wird eine Anfrage an den Server gestellt, weil ein neuer Nutzer Ihre Website aufrufen möchte. Der Client (Browser) fordert die notwendigen Ressourcen beim Server an, und dieser sendet die jeweilige Antwort zurück. Der Browser wird nun 28 Datenpakete vom Server herunterladen, um dem Nutzer das Ergebnis auszuspielen welches er sehen soll.

Der Download dieser 28 Datenpakete benötigt natürlich Zeit, da der Browser HTML Dokumente standardmäßig von oben nach unten analysiert. Dementsprechend werden die hinterlegten Ressourcen einzeln nach einander heruntergeladen und gerendert.

Kurze Wiederholung: 
Bei HTTP/1.1 werden alle hinterlegten Dateien wie CSS, JS und- oder Bilder einzeln nach einander heruntergeladen.

Sollten also große Dateien, die für den Seitenaufbau nicht sonderlich wichtig sind, wie bspw. Bibliotheken für Widgets, Slider oder andere interaktive Elemente, vor den essentiell benötigten Ressourcen geladen werden, ist sicher klar, wie sich dieses Szenario auf die Website-Performance auswirken kann.

Mit dem Multiplexing Verfahren werden mehrere Daten / Ressourcen parallel über eine TCP Verbindung zwischen Browser und Server übertragen.

Wie bereits erwähnt, sinkt also mit dem Einsatz von HTTP/2 die Anzahl der ausgetauschten TCP Verbindungen / Segmente.

Hier eine nette Grafik die es auf den Punkt bringt:

HTTP 1.1 vs. HTTP/2
HTTP 1.1 vs. HTTP/2

Ich denke, das Resultat der beschriebenen Technik liegt auf der Hand 🙂

Kommen wir nun zu einem weiteren Benefit von HTTP/2: Priorisierung von Datenpaketen.

Priorisierung von Datenpaketen

Mit HTTP/2 kann die Reihenfolge der Datenpakete nach Wichtigkeit sortiert werden.

Vielleicht stellt Ihr euch jetzt die Frage, welche Vorteile die Möglichkeit einer solchen Sortierung mit sich bringt?

Stellen wir uns aber erst einmal die Frage, welchen Abschnitt einer Website oder Webanwendung der Nutzer beim Aufruf sehen kann. Sehr wahrscheinlich verwendet der User ein Smartphone, einen Laptop oder einen Desktop PC, richtig?

Den Abschnitt, welchen der Nutzer beim ersten Aufruf sieht, nennen wir den sichtbaren Bereich. Dieser sichtbare Bereich hat für uns zu Beginn also höchste Priorität. Alle notwendigen Texte, Styles, JavaScripts, Bilder und- oder Videos, die im sichtbaren Bereich liegen, müssen also logischerweise zuerst geladen werden. Ressourcen die weiter unten, womöglich erst nach einem initiierten Scrollen verwendet werden, sind für den ersten Aufruf also zweitrangig.

Durch die Möglichkeit der Priorisierung von Datenpaketen, können wir also mit HTTP/2 all die Website Ressourcen an den Browser übermitteln lassen, welche vom Nutzer beim initialen Aufruf der jeweiligen Page priorisiert genutzt werden möchten.

Server Push: Dateien mit HTTP/2 direkt in den Browser „pushen“

Abgesehen vom Multiplexing Verfahren ist der Server Push einer der großartigsten Erneuerungen von HTTP/2.

Durch diese Technik können Dateien in den Browser geladen werden, noch bevor dieser einen Request an den Server geschickt hat.

Wenn also bspw. der Browser eine HTML Page beim Server anfordert und in dieser HTML Page Stylesheets, JavaScript Dateien, Bilder etc. hinterlegt wurden, kann der Server diesen Content direkt in den Browser Cache laden, noch bevor der Request vollständig durchgeführt wurde.

Der Browser rendert anschließend die HTML Seiten, und wenn er die dort hinterlegten Ressourcen findet, liegen diese für ihn bereits im eigenen Browser Cache zum Abruf bereit.

Coole Sache oder? 🙂

Aber Vorsicht! Hier sollten wirklich nur notwendige Ressourcen hinterlegt werden und nicht alle Dateien die für den Seitenaufbau notwendig sind.

So, jetzt habt ihr das notwendige Grundwissen zum Thema HTTP/2.

Hört sich ja generell alles ganz nett an, aber wie könnt ihr das neue Protokoll nun für eure Webprojekte nutzen?

Im nächsten Abschnitt zeige ich euch wie Ihr HTTP/2 serverseitig aktiviert und wie eure Websitestruktur idealerweise aufgebaut sein sollte, um die bestmöglichsten Ergebnisse damit zu erzielen.

Der Einsatz von HTTP/2

Um HTTP/2 nutzen zu können, muss im ersten Schritt der Webserver für das neue Protokoll vorbereitet werden. Je nachdem welchen Webserver ihr verwendet, also z.B. Apache oder NGINX, ist die Vorgehensweise unterschiedlich.

Ich persönlich nutze für meine Projekte einen V-Server mit dem Betriebssystem Linux Ubuntu 14.04.5 LTS, in Kombination mit der Serververwaltungssoftware Plesk 12.5. Plesk bietet die Möglichkeit NGINX als Reverse Proxy vor Apache zu schalten. Die Ausspielung bzw. das Handling von Ressourcen wird damit zusätzlich extrem beschleunigt.

Schritt 1: Vorbereitung des Servers für HTTP/2

Standardmäßig wird bei Plesk das Protokoll HTTP/1.1 verwendet. Damit HTTP/2 serverseitig aktiviert wird, müsst ihr über die Commandozeile folgenden Befehl eingeben:

plesk bin http2_pref enable

Das wars auch schon.

Um sicherzugehen, dass unsere neuen Einstellungen übernommen wurden und HTTP/2 supportet wird, kann über die Website tools.keycdn.com ein kostenloser HTTP/2 Test vorgenommen werden:

https://tools.keycdn.com/http2-test

Gebt dort in das Formular einfach eure Website ein und klickt auf „Test“.

Wenn Ihr cURL auf eurem Webserver installiert habt, kann alternativ auch folgender Befehl in der Commandozeile für die Überprüfung eingegeben werden:

curl –http2

Solltet Ihr Hilfe bei der Aktivierung von HTTP/2 benötigen, kontaktiert mich einfach.

Kommen wir nun zum spannenden Teil der Vorbereitung: Ausspielung von Ressourcen.

Schritt 2: Ausspielung von Ressourcen

Im Vergleich zur herkömmlichen Ausspielung von CSS, JavaScript und Bilddateien, empfiehlt es sich beim Einsatz von HTTP/2, die komplette Website inkl. aller notwendigen Dateien „modular“ aufzubauen und auszuspielen.

Das Layout einer Website sollte also nicht mehr innerhalb einer einzelnen style.css hinterlegt werden, sondern in mehrere unterschiedliche CSS Dateien gesplittet werden.

Beispiel für HTTP/2 optimierte CSS Dateien:

Layout des Headers: Layout der Navigation: Layout des Sliders: Layout des Contents: Layout der Sidebar: Layout des Footers:
header.css navi.css slider.css content.css sidebar.css footer.css

Der Head-Bereich eurer Website kann dann wie folgt aussehen:


<!DOCTYPE html>
<html lang="de">
<head>
  <title>HTTP/2 optimierte Website</title>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  
  <link rel="stylesheet" href="css/header.css">
  <link rel="stylesheet" href="css/navi.css">
  <link rel="stylesheet" href="css/slider.css">
  <link rel="stylesheet" href="css/content.css">
  <link rel="stylesheet" href="css/sidebar.css">
  <link rel="stylesheet" href="css/footer.css">
  
...
</head>

Gleiches gilt für JavaScript.

Anstatt alle notwendigen Scripts bspw. in einer main.js zu hinterlegen, sollten sie in separate einzelne Files gesplittet, und in logischer Reihenfolge nacheinander im HTML Code platziert werden.

Beispiel für HTTP/2 optimierte JavaScript Dateien:

Slider: Scroll to Top Button: Popup: Kontakt: Google Maps: Analytics:
slider.js stp.js popup.js contact.js maps.js analytics.js

Der Footer eurer Website kann dann wie folgt aussehen:

	
<!-- Scripts -->
  <script async src="js/slider.js"></script>
  <script async src="js/stp.js"></script>
  <script async src="js/popup.js"></script>
  <script async src="js/contact.js"></script>
  <script async src="js/maps.js"></script>
  <script async src="js/analytics.js"></script>
</body>
</html>

und so weiter… ich denke die Vorgehensweise ist nun klar.

Schritt 3: Modular-aufgebauter Quellcode (HTML5-Konform)

Neben der modularen Ausspielung der Website-Ressourcen, ist es empfehlenswert den Quellcode ebenfalls modular aufzubauen. Der Großteil aller Websites die ich bisher untersucht habe, setzen schon teilweise eine kleine Handvoll neuer HTML5 Elemente für die Strukturierung des Quellcodes ein, aber eben nur eine kleine Handvoll.

HTML5 bietet neben den Tags, Header, Nav und Footer etliche weitere nützliche Auszeichnungselemente. Wer die Verantwortung für eine Website, Webshop oder Webanwendung trägt, sollte sich idealerweise in das Thema HTML5 einlesen, um die Möglichkeiten und das Potential der neuen Auszeichnungssprache zu kennen und für die eigenen Projekte zukunftsorientiert einsetzen zu können. Alternativ sollte eine auf HTML5 spezialisierte Agentur, oder ein Spezialist in diesem Gebiet mit ins Boot geholt werden.

Je nachdem welche Funktionen eine Website benötigt, welche Elemente sie beinhaltet, und für welche Zielgruppe sie entwickelt wurde, können unterschiedlichste HTML5 Elemente und- oder Funktionen zum Einsatz kommen, um die Website für den User und letztendlich auch für die Suchmaschinen bestmöglich zu optimieren.

Fazit

So, jetzt solltet Ihr das nötige Know-How besitzen, um euere Projekte für HTTP/2 vorzubereiten. Da das Thema Web Performance relativ komplex ist und die Ladezeit einer Website natürlich noch von vielen weiteren Faktoren abhängig ist oder sein kann, solltet Ihr je nach Projekt den Kosten / Nutzenfaktor im Auge behalten und wenn möglich, einen Spezialisten im Bereich Web Performance am jeweiligen Projekt teilhaben lassen.

Sollte euch in diesem Artikel eine wichtige Info zum Thema HTTP/2 fehlen, solltet Ihr Anmerkungen oder Verbesserungen haben, freue ich mich über eine Nachricht von euch.

In diesem Sinne, danke und bis bald!

Hier noch ein paar hilfreiche Links für euch zum Thema HTTP/2: