Kategorien
Linklove Wochenbericht

Wochenbericht 2015.08

Entwicklung

Netzpolitsches

Kategorien
Webentwicklung Werkzeuge

Was sich mit HTTP/2 ändern wird

Tools

Gerrit van Aaken beschrieb neulich den Toolchain-Wahn, der die Aufrüstung im Frontend-Development befallen hat. Einige dieser Toolchains nutze ich auch, zum Beispiel das Precompiling von Frontend-Templates in eine Datei, das kompilieren von mehreren LESS- und CSS-Files in eine einzige Datei. Alles, weil HTTP/1.1 teilweise nur einen Request parallalel verarbeitet. Aktuell ist das sinnvoll und notwendig, um überflüssige Header (Overhead) zu verringern und den Übertragungs-Payload möglich hoch zu halten.

Nachdem die Seitenperfomance immer größeren Stellenwert bei Google Rankings bekommt und Amazon mal durchgerechnet hat, wie dramatisch 100 Millisekunden zwischen Bounce und Conversion unterscheiden können, gehört es nicht nur zum guten Ton, sondern zur Pflicht, solche Dinge in seinen Workflow zu integrieren, wenn eine Internetseite für den Unternehmenserfolg ausschlaggeben sein sollte.

Aber was würde Sich ändern wenn unter anderem:

  1. Header komprimiert würden?
  2. Mehrere Requests parallel laufen könnten?
  3. Was, wenn die Site dem Browser Daten ungefragt rüberschiebt?

Dann wäre vieles (nicht alles) dieser Dinge überflüssig. Am Ende muss man die Rechnung Header vs. Payload neu auslegen, wenn Header komprimiert sind und die Dateien parallel geladen werden können. Zusammenfügen der Stylesheets und Javascript-Dateien wäre weniger wichtig als heute. Teilweise könnte das sogar kontraproduktiv sein.

Damit wird die Übergangszeit von HTTP/1.1 auf HTTP/2 für die Frontend-Developer noch eine sehr spannende Zeit werden. (Wer sich den englischen Wikipedia-Artikel über HTTP/2 durchliest, der wird deutlich besser informiert, wo HTTP/2 herkommt (SPDY von Google) und was es so im einzelnen für Änderungen gibt. Der deutsche Artikel ist da eher kurz angebunden.

Wer heute schon testen will, wie sich HTTP/2 in etwa auswirken könnte, der kann sich mal auf einem Apachen mod_spdy installieren und eine Perfomance-Messung vorher-nachher machen. Firefox und Chrome können in den aktuellen Stable-Versionen SPDY von Hause aus, Opera vermutlich auch und der IE wird mit Version 11 nachziehen.

Seid ihr auf die Zukunft vorbereitet? Habt ihr eure Grunt- / Gulp- / $BUILDTOOL-Chains schon vorbereitet? Macht ihr euch noch Gedanken um die aktuelle Optimierungs-Praktik oder lebt ihr schon mit vielen kleinen Dateien in der Zukunft der Webentwicklung? Werdet ihr verschiedene Versionen für HTTP/1.1 und HTTP/2 erstellen müssen?