Kategorien
Webentwicklung Werkzeuge

Was sich mit HTTP/2 ändern wird

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?

Kategorien
Betriebssystem Code Webentwicklung

Generische URLs für lokale Entwicklungsumgebungen

Als Webentwickler kennt man das vielleicht: Für das x-te Kundenprojekt legt man eine neuen Ordner in seinem WWW-Root an und fängt an, entweder „localhost/kundenprojekt.de“ zu nutzen oder lustige Spielereien mit VirtualHost-Konfigurationen und der Hosts-Datei zu veranstalten („127.0.0.1 kundenprojekt.de“).

Das muss nicht mehr sein! Zumindest unter Linux, BSD und vermutlich Mac OSX.

Der Apache-Part funktioniert ohne Probleme auch unter Windows, das Problem ist hier das generische Domain-Auflösen. Wenn jemand dafür eine Lösung hat, her damit!

Was brauchen wir?

  • Linux, BSD, Mac OSX, Windows
  • Als Entwicklungswebserver benutzen wir den Apachen
  • Unter Linux/Unix/BSD/OSX wird Dnsmasq installiert
    Unter Ubuntu oder Debian mit „apt-get install dnsmasq“ bzw. „aptitude install dnsmasq
  • Unter Windows gibt es das Tool „Acrylic DNS Proxy
  • Dnsmasq / Acrylic ist als primärer DNS-Server eingetragen.

Was macht dieses Dnsmasq eigentlich?

Dnsmasq is a lightweight, easy to configure DNS forwarder and DHCP server.

So weit, so gut. Dnsmasq kann einiges mehr und besonders interessieren wir uns für die Funktion, die in der Manpage mit „–address“ beschrieben ist. Sehr unscheinbar, aber das ElDorado für uns. Die Option besagt, dass jede Domain, die in das Muster passt, mit der definierten IP aufgelöst wird.

Dafür legen wir unter Debian/Ubuntu die Datei /etc/dnsmasq.d/localdev.conf an. In diese kommt folgender Inhalt:
address=/localdev/127.0.0.1

Unter Windows bearbeitet man die Datei „AcrylicHosts“ und fügt dort die Zeile „127.0.0.1 *.localdev“ ein.

Man könnte auch eine beliebige andere TLD nehmen („erfinden“), z.b. „.dev“ oder „.locales-netz-von-chris“.

Damit werden alle Domains, die auf „localdev“ enden, auf die lokale IP aufgelöst.

Okay, jetzt kann ich alles mit einer bestimmten Domain auf meinen Server umleiten. Und nun?

Dnsmasq löst nun Domains wie „kunde.localdev“ und „kunde2.localdev“, alle auf den lokalen Webserver um.

Normalerweise hätte man dann ja immer noch das Problem, dass man mit den VirtualHost-Konfigs basteln müsste. Hierfür hat Uberspace eine super Lösung präsentiert:

Die Apache-Config wird in der VirtualHost-Direktive erweitert. XAMPP/LAMPP/MAMPP-User müssen diese erst erzeugen.

RewriteEngine On

# If there is a host-specific pseudo-DocumentRoot, use it instead of the default one
RewriteCond %{REQUEST_URI} !^/f?cgi-bin/
RewriteCond /var/www/%{HTTP_HOST} -d
RewriteRule (.*) /var/www/%{HTTP_HOST}/$1

Dieser nette Trick erlaubt folgendes: Wenn ein Verzeichnis existiert, welches den gleichen Namen hat, wie die URL, die aufgerufen wird, wird es als „DocumentRoot“ verwendet. Bei der Verwendung von .htaccess-Rewrites innerhalb des Verzeichnisses muss allerdings ein „RewriteBase /“ stehen.

Was bedeutet das für die Praxis?

Ich muss in Zukunft nur noch ein Verzeichnis „kunde123.localdev“ anlegen und schon kann ich darin loslegen. Ich habe eine Top-Level-Domain und muss am Ende beim Umzug auf die Live-Seite nicht mehr soviel ändern. Im Falle von WordPress muss ich nur beispielsweise noch in der Datenbank das „.localdev“ durch „.de“ ersetzen und schon kann das Projekt live gehen.

Außerdem ist mein /var/www/ -Verzeichnis dann auch zwangsläufig gut organisiert.

Im Übrigen: eine spezifische Auflösung in der resolv.conf oder der Hosts-Datei hat Vorrang vor der Dnsmasq-Auflösung.

[green_box] Update

Ein Tool für Windows wurde nachgetragen

[/green_box]

[grey_box]
Dieser Eintrag entstand durch eine Verkettung von Inspirationen: Ich habe Alex zum testen von Uberspace inspiriert, deren VirtualHost-Konfiguration hat Alex zum testen von Dnsmasq (Wikipedia) auf seinem Notebook inspiriert und seine Demonstation davon hat mich zu diesem Eintrag inspiriert. Soviel zum Thema „geistiges Eigentum“.
[/grey_box]