Seit 1991 gibt es HTTP, das Protokoll, mit dem wir alle unsere Webseiten ausliefern. Und Version 1.1 ist auch schon seit 18 Jahren am Start. Allerdings waren vor zwei Jahrzehnten Webseiten wesentlich weniger komplex. Heutzutage gehen für eine durchschnittliche Seite immerhin knappe 2 MB durch die Leitung, werden mehr als 100 Ressourcen geladen. Dabei ist die Performance des Protokolls für diese Anwendungen her schlecht.
Viele der Workarounds - wie Content Delivery Networks oder Image-Sprites - sind dazu gedacht, die schlechte Leistung von HTTP 1.1 durch Tricks zu verbessern. Immer ging es darum, auf der einen Seite möglichst wenige Requests zu benötigen, um eine Webseite zu laden, diese gleichzeitig aber auf möglichst viele Verbindungen zu verteilen. Dafür werden dann beispielsweise Pseudo-Subdomains genutzt oder Dateien automatisch zusammengefasst.
HTTP/2 ist nun in der Lage, viele Ressourcen - wie HTML, Bilder, CSS, JavaScript oder Icons - gleichzeitig und ohne Verzug von einer Quelle zu laden. Damit werden sie bisherigen Ansätze nicht nur überflüssig, sondern sie schaden auch. Gleichzeitig erfordert HTTP/2 auch SSL-Verbindungen. Diese neuen Methoden erfordern also eine andere Herangehensweise.
Blick in die Technik
SPDY
Die ersten Vorzeichen von HTTP/2 gab es bereits 2009 zu sehen - mit dem Forschungsprojekt SDPY, das zwei Google-Techniker voranbrachten. Dabei war schon vieles zu sehen, was jetzt auch bei HTTP/2 zu sehen ist:
- HTTP-Header wurden komprimiert
- es gab gleichzeitig mehrere Requests über eine einzige (TCP-) Verbindung
- Browser konnten zum ersten mal Ressourcen priorisieren
- eine verschlüsselte Verbindung via HTTPS wurde benötigt
- Server-Push.
Allerdings hat SPDY das alte Protokoll HTTP 1.1 nicht ersetzt - man hat zwischen Server und Browsern, die damit umgehen konnten, einen Tunnel geöffnet, die Daten im SPDY-Protokoll hindurchgeschickt und war im besten Fall nicht nur mir einem Request (für die Tunnelverbindung) fertig, sondern auch noch kompatibel.
Damit war klar: SPDY ist nicht die beste aller Lösungen, aber mit Modulen für die Webserver Apache und Nginx sowie über die Jahre mehr Browsern mit Unterstützung auf einem sehr guten Weg.
HTTP/2
Was kann jetzt HTTP/2 im Vergleich zu SPDY? Die Liste ist erstaunlich ähnlich:
- Übertragungen sind binär, nicht mehr als Text
- der Tunnel ist daher nicht mehr nötig
- das Protokoll ist 'fully-multiplexed' - eine Verbindung reicht für den Download aller Ressourcen parallel
- der Header ist komprimiert
- Server können Inhalte pushen.
Auf den ersten Blick fällt auf, dass die Verschlüsselung keine Pflicht ist. Statt im Protokoll die HTTPS-Verbindungen festzuschreiben unterstützen die Browserhersteller einfach keine unverschlüsselten Verbindungen.
Die Konsequenzen
Zuerst einmal: Webseiten laden schneller über HTTP/2, und das nicht nur, weil alles komprimiert ist. Wesentlich ist, dass der Overhead beim Verbindungsaufbau jetzt wegfällt: Statt bis zu 10 gleichzeitigen Verbindungen bei mehreren Hosts, wie es beim Einsatz von Content-Delivry-Networks üblich war reicht es, eine Verbindung zum Server aufzumachen. Die Daten können dann komplett in einem Rutsch ausgeliefert werden. Können, nicht müssen - was Platz für Optimierungen lässt: Welche Dateien werden zwingend zum Seitenaufbau gebraucht? Das HTML, ein Basis-CSS ganz sicher. Aber ein Javascript, dass für die AJAX-Suche im unteren Seitenbereich gebraucht wird?
Gewiss nicht. HTTP/2 kann bestens mit Priorisierung umgehen, und mit Server-Push kann er zusätzliche Dateien senden, wenn er der Meinung ist, dass der Browser mit dem Rendern des Basisgerüsts fertig sein sollte. Die Verbindung besteht ja noch. Server-Push ist kein Allheilmittel, und es ist zur Zeit noch etwas experimentell, zu bestimmen, welche Daten lazy-loaded werden sollten. Komprimierung ist besonders wichtig, weil die Verbindung über TCP läuft, denn TCP braucht immer eine gewisse Zeit, um sich auf die optimale Paketgrösse einzuschiessen. Komprimiert passt der Header in eine Antwort.
Wichtig ist es jetzt besonders, so genanntes 'Domain sharding' zu unterlassen und die gesamte Webseite von einem Server und einer einzigen Domain aus auszuliefern. Während man früher Dateien zusammenfasste, um Requests zu sparen sollte man mit HTTP/2 Ressourcen splitten, um parallel auszuliefern und Server-Push für spät benötigte Daten nutzen zu können.
Und Contao?
Die Einstellungen für Assets, die man bisher von Sharded Domains ausgeliefert hat kann man sich mit HTTP/2 sparen - das schadet nur. Auch sollten CSS- und JavaScript-Dateien nicht mehr zusammengefasst werden, denn das verhindert, das man sich initial nur auf das Nötigste beschränken kann.
Schliesslich muss man das CMS auch nicht mehr damit belasten, Dateien zu minifizieren oder gar zu komprimieren - das kann der Webserver über das Protokoll besser.
Grundsätzlich sind das schon die wesentlichen Einstellungen in Contao. Was der Entwicklerin, dem Entwickler überlassen bleibt ist die sinnvolle Strukturierung von JS und CSS. Die wichtigen Dinge werden dann in den <head> eingebunden, der Rest folgt irgendwann im Footer, damit der Webserver daraus den Schluss ziehen kann, die Daten später zu pushen. Man kann das im Template prima unterstützen oder die Erweiterung Theme+ nutzen, die hier granulare Vorgaben ermöglicht.
Man kann Dateien nun auf zwei verschiedene Arten einbinden - entweder via Markup oder via HTTP-Header. Für beides liefert das W3C Beispiele:
<!-- preload stylesheet resource via declarative markup -->
<link rel="preload" href="/styles/other.css" as="style">
<!-- or, preload stylesheet resource via JavaScript -->
<script>
var res = document.createElement("link");
res.rel = "preload";
res.as = "style";
res.href = "styles/other.css";
document.head.appendChild(res);
</script>Oder auch so:
Link: <https://example.com/other/styles.css>; rel=preload; as=style
Einen Kommentar schreiben
Hast Du Fragen oder Anregungen? Dann nutze die Kommentarfunktion.