Performanceoptimierung von Webseiten: Besser komprimieren mit Googels Brotli und Zopfli

Noch dem man das HTML und allen anderen Test-basierten Inhalte einer Website minifizioert hat, kann man auch bei der Kompression selbst auch noch ein paar Bytes rausholen. Und weil Google alle Probleme schon etwas früher als ich hatte, hat Google auch schon eine Lösung. Und die Lösung heisst: BROTLI und ZOPFLI anstelle von DEFATE und GZIP.

ZOPFLI ist ein GZIP kompatibles Kompressionsverfahren, das hat den Vorteil es musss nur durch den Web-Server unterstützt werden, alle gängigen Web-Browser sind GZIP fähig und damit auch ZOPFLI fähig.

BROTLI ist dagegen nicht kompatibel und versucht die Vorteile von LZMA oder BZIP2 (hohe) Kompression mit einem günstigeren Laufzeitverhalten zu kombinieren. LZMA und BZIP benötigen im Vergleich zu GZIP und verwandte wesentlich mehr Sei für die Kompression bzw. De-Kompression. Was sich negativ auf die Ladezeit einer Web-Seite auswirken kann, speziell auf die TTFB (Time to first byte). Lesenswert ist hier der Vergleich von den Google-Entwicklern (Link 2).

Aber jetzt mal einen eigenen Test. Zuerst müssen beide Programme mittels Paketmanager installiert werden. Dann geht es los. Alle Programme werden in der Standardkonfiguration benutzt, es gibt keine weitere Optimierungen. Weil die nur BROTLI, ZOPFLI und GZIP für Web-Server relevant sind werd nur die getestet. Alle Grössen-Angaben in Byte.

Datei	Original	Gzip	Komprssionsrate	Zopfli	Komprssionsrate	Brotli	Komprssionsrate
redirect_frame.html	431	300	1,4	274	1,6	194	2,2
runtasticOTTO.html	162730	35690	4,6	34091	4,8	30535	5,3
www.ebert-p.com.html	15134	3191	4,7	3064	4,9	2568	5,9

Ergebnisse

1. ZOPFLI schlägt GZIP, die Kompressionsrate verbessert sich um 0,2.
2. BROTLI schlägt ZOPFLI, die Kompressionsrate verbessert sich deutlich um mehr als 0,4.
3. Kleine und grosse Dateien profitieren von BROTLI und ZOPFLI.

Links

1. http://caniuse.com/#search=brotli
2. https://cran.r-project.org/web/packages/brotli/vignettes/brotli-2015-09-22.pdf
3. https://www.golem.de/news/datenkompression-auf-googles-zopfli-folgt-brotli-1509-116438.html
4. https://devcentral.f5.com/articles/ops-briefing-amp-html-and-brotli

Performanceoptimierung von Webseiten: HTML Minifizieren

Das nur minifixiertes CSS und JS ausgeliefert wir ist heute sicher Standard. So werden viele Bytes bei der Übertragung gespart, auch in den den Zeiten von GZIP und HTTP/2 ist das noch so. Nur ist der Effekt des Minifizierens geringer. Leider wird sehr oft vergessen auch das HTML selbst zu minifizieren. Auch ist hier die Tooluntzerstützuzng nicht so üppig wie beim Minifizieren von CSS und JS. Aber es gibt z.B. für Wordpress ein Plugin, das gut Ergebnisse liefert, bei mir spart es ca. 15% der zu übertragenen Bytes, bei eingeschalteter GZIP Kompression.

• Minify HTML von Tim Eckel

Wenn man HTML minifixiert kann Einsparungen zwischen 15 bis 33 % der zu übertragenen Bytes einsparen. Nach entsprechender Kompression ist immer noch mit einem einstelligen Prozentwert an Einsparung zu rechnen. Das klingt nicht viel, lohnt sich aber, weil der Aufwand relativ gering ist. Der Zeitlich Vorteil beim laden einen komplexen Seite kann zwischen 0,5 ms bei einem schnell angebunden Desktop Computer und 35 ms bei einem Samsung Galaxy S5 mit 3G (regular) liegen. Probieren kann man dies einfach mit den Chrome Developer Tools. Dazu kommt, dass das HTML sehr wichtig für den Seitenaufbau ist, auch wenn Bilder einen grösseren Byte-Beitrag zur Webseite leisten. Weitere positive Aspekte:

• Durch das geringere Datenvolumen verringert sich die Wahrscheinlichkeit für Re-Transmits, vor allem in überfüllten Netzen (Prime Time, Mobile Networks). 
• Auch die Menge der Ausreisser der Ladezeit verringern sich. 
• Die Connection kann früher für andere Daten genutzt werden. 

HTML Minifizierung ist nicht gleich HTML Minifizierung, hier gibt es verschiedene Aspekte:

1. Entfernen von allen Whitspace Chars
2. Minifizieren von Inline JS
3. Entfernen von Kommentaren
4. Entfernen von XHTML Closing Tags
5. Entfernen von Domains von internen URLs
6. Case sensitive Tags
7. HTML Entities zu Unicode umwandeln 6 byte -> 2 byte 
8. Leere Tags und Attribute entfernen

Links

• https://kangax.github.io/html-minifier/
• https://wordpress.org/plugins/minify-html-markup/

Performanceoptimierung von Webseiten: Prefetching

Neben den vielen Ideen zur Steigerung der Performance war das Prefetching eine. Das gab es schon seit sehr frühen HTML Versionen und war über die Jahre ein wenig in Verruf geraten. Danach wurde Prefetching mittels Selbstgebauten Loader via JS und CSS  realisiert. Soweit zur Vergangenheit. 

Es gibt heute wieder die Möglichkeit Dinge vorzuladen. Das führt nur zu einer Verbesserung der Performance auf den Folgeseiten einer Website, eventuell kann man auch Einstiegsseiten beschleunigen, das müsste man genau Testen. 

Mit HTML5 geht es wieder sehr einfach und man kann nicht nur einzelne Seiten oder Resource vorladen, sondern z.B. auch ein DNS Prefetching machen. Hier ein paar Links, ja Wikipedia aber die Englische:

1. https://en.wikipedia.org/wiki/Link_prefetching
2. http://caniuse.com/#search=prefetch
3. https://www.stevesouders.com/blog/2013/11/07/prebrowsing/

Buch: Ilya Grigorik High Performance Browser Networking

Jeder der professionell sich mit Webperformance auseinandersetzt sollte dieses Buch besitzen. Es beschäftigt sich sehr gut beschrieben mit dem Browser Networking. Es geht auf alle relevanten Aspekte wie Latenz, Übertragungsgeschwindigkeit, TCP, TLS (aka HTTPS), drahtlose Netzwerke, WLAN ein. Das Networking wir gut und umfangreich beschrieben und sollte Jedem vertraut sein, der über Performance nachdenkt. Der Teil zu HTTP ist gut und endet mit einer kurzen Einführung von HTTP 2.0, das hier nur relativ kurz angerissen wird. Abgerundet wird dieses empfehlenswerte Buch mit XMLHttpRequests, SSE, WebSockekts und WebRTC. Das Buch ist gelungen ist aus meiner Sicht ein Standardwerk für den Bereich Performance und Web, ach wenn der zweite Teil ein wenig schwächer ist.
Wer Themen sucht zur Optimierung der Browserperformance, der wird in diesem Buch leider nicht fündig. Dieser Zweite wichtige Themenkomplex bleibt aussen vor. Hier wünscht man sich ein zweites Buch zu diesem Thema vom Autor. Ilya Grigorik hat diese Dinge leider nicht zu einem Buch zusammengefasst, sondern man findet sie auf der Seite von Google, bei Google Developers unter Webfundamentals, Performance (Link). Auch diese Seiten sind wirklich lesenswert.

HTTP2

HTTP2 is the new, better, faster HTTP and it replaces Googles SPDY (http://programming-2.blogspot.de/search?q=SPDY). One really informative site to HTTP2 is https://http2-explained.readthedocs.org/en/latest/index.html

To use HTTP2, you need an client. CURL support it, but not as default. To use HTTP2 with CURL on MacOSX, you have to install CURL with brew:

brew install curl --with-nghttp2

Now you can check out HTTP2 with CURL

If you got following error:
curl: (1) Unsupported protocol
You use an CURL without compiled HTTP2 support. On MacOSX brew doesn't replace the existing CURL. You have to use the full path to the CURL from brew:

/usr/local/opt/curl/bin/curl --http2 -I -v https://google.com

Browser Fingerprinting

Mit Hilfe von Cookies lassen sich Browser und damit Benutzer im WWW sehr leicht wieder erkennen. Dabei hinterlässt der Web-Site Betreiber einen Datenkrümel beim Benutzer, also im Webbrowser. Somit ist auch für den Web-Surfer erkennbar, dass der Web-Site-Betreiber ihn trackt. Es bleiben eindeutige Spuren zurück. Daneben gibt es aber eine Form des Treckings, das keine Spuren beim Benutzer hinterlässt, das Browser Fingerprinting. Dabei werden diverse Informationen des Browsers abgefragt wie User Agent, bevorzugte Sprachen, unterstützte Mime Types und Plugins, Bildschirmauflösung und weitere Dinge. Damit ergibt sich ein möglicherweise eindeutiger Wert. Wer dies sich für seinen Browser sich ansehen möchte: Link.

Gegen Cookies helfen Adblocker, die Tracking Pixel und die damit verbundenen Cookies fern halten oder das gelegentliche Löschen der Cookies oder der Surfen im privaten Modus.

Aber was hilft gegen Browser Fingerprinting? Die vollständige Deaktivierung von JavaScript und Flash scheinen im Moment ein guter Weg zu sein oder die Nutzung von JonDo.

Es wäre sich auch ein interessanter Weg die Daten die fürs Browser Fingerprinting genutzt werden zu reduzieren. Aber dies ist bei den meisten Browsern schwierig. Die Option der Manipulation des User Agents wäre für die Browserhersteller ein einfache Option, vielleicht auch die Abschaltung einiger anderer Dinge wie die Font-Erkennung, die durch die Webfonts an Bedeutung verlieren. Eine Verringerung der potentiellen Datenmenge führt zu weniger eindeutigen Erkennbarkeit des Benutzers. Oder wie wäre es mit einer Sicherheitsabfrage: Erlauben sie dieser Website die technischen Daten ihres Browsers zu erfassen? Oder kann man statt Cookies zu vermeiden sie tauschen, vielleicht ein automatische Cookie-Tauschbörse?

Warum gibt es überhaupt diese Techniken wie Cookies oder Browser Fingerprinting, bzw. warum sind sie populär? Neben eineigen sinnvollen Anwendungen, wie die Sissionsmanagement z.B. beim Einkaufen im Internet geht es primär um das gezielt ausspielen von Werbung. Targeting und Retargeting sind hier die Schlüsselworte. Eins muss man klar sehen, das Internet ist nicht umsonst, wir bezahlen mit Werbekonsum oder wir bezahlen für Tools die die Werbung uns vom Hals hält.

Weiter Informationen zu Thema: Link

Kann ich SPDY nutzen?

SPDY ist ein HTTP Alternative, die Mängel von HTTP(S) kompensieren soll und besser den Anforderungen moderner, grosser Web-Applikationen entsprechen. Doch wie verbreitet ist SPDY bei den Benutzern? Dazu gibt es ein hilfreiche Übersicht, welcher Browser SPDY unterstützt (Link). Kombiniert man diese Daten mit der Webbrowserverbeitung von StatCounter kommt man auf eine Browserunterstützung von 65% für 09/2013. Damit kann man für 65% der heutigen Benutzer die Webaplikation zu beschleunigen. Die Browserunterstützung wird auch den IE erreichen und damit werden können fast alle Benutzer SPDY nutzen.
Übrigens gibt es nettes Firefox Addon SPDY indicator, das anzeigt ob die Site per SPDY ausgeliefert wird.

Wie surft Deutschland 2012/2013?

Jeder der eine Web-Projekt aufsetzt muss seine Kunden kennen. Dazu gehören auch die technischen Fragen: Welche Browser werden genutzt? Mit welcher Geschwindigkeit surfen die Kunden?

Bei den Webbrowsern ist die Frage relativ einfach zu beantworten, eine gute Quelle ist StatCounter. In Deutschland ist seit Jahren Firefox an der Spitze der Charts.
Aber mit welcher Geschwindigkeit welchem Zugang und welcher Latenz kommt der Kunde? Hier gibt es gute Quelle, die Bundesnetzagentur. Daraus ergibt sich folgende Verteilung: 93% der Haushalte in Deutschland verfügen über einen Breitbandanschluss. Diese splitten sich in 83% DSL, 13% Kabel und 3% LTE auf. Für die Latenz (Ping) bedeutet das: DSL 24msec, Kabel 15mesc und LTE 45msec. Dazu kommt, dass 40% der Haushalte in Deutschland WLAN einsetzen mit einer Latenz von 10msec. Ein typischer Benutzer setzt DSL6000 und Firefox ein. WLAN ist aber eine sehr häufige Option. Für Webtest wären ein sinnvoller Wert für Latenz (DSL + WLAN) 34msec.

Quellen:

Bundesnetzagentur, Jahresbericht 2012
Bundesnetzagentur, Abschlussbericht „Dienstequalität von Breitbandzugängen“, 2013

Software Agenten

Wer erinnert sich noch an den Hype um Softwareagenten. Und wie jeder Hype platzet auch diese Blase. Doch heute sind Softwareagent Alltag ohne das es jemand gemerkt hätte. Hadoop, MongoDB, BOINC und andere Software sind von ihren Eigenschaften her Softwareagenten, die zentral gesteuert werden. Merke, nicht der Hype ist wichtig, sondern die Kernidee. Selbst wenn der Hype schon vergessen ist, so leben die Ideen oft weiter, meist jedoch in geänderter Form.

SPDY vs. HTTP

Google hat mit SPDY (Link zum Projekt), gesprochen Speedy, ein alternatives Übertragungsprotokoll zu HTPP und HTTPS entworfen. Es soll die Probleme von HTTP beheben und erfreut sich zunehmender Beliebtheit bei vielen Big Playern (Link). Dem entsprechend gibt es verschiede Test. Google gibt eine Beschleunigung um bis zu 55% an (Link). Das wäre eine dramatische Verbesserung. Guy Podjarny hat in seinem Blog ein interessanten Test (Link) veröffentlicht. Dabei kommt heraus, das SPDY langsamer als HTTP ist und nur ein wenig schneller als HTTPS. Dieses Ergebnisse ist ernüchternd. Wichtig bei dem Test von handelt es sich um ein einen Real World Test, der den aktuelle Stand reflektiert. Sicher sind mit einigen Optimierungen bessere Ergebnisse für SPDY zu erzielen, aktuelle Seiten sind stark für HTTP optimiert. Die Frage ist ob dies den Unterschied von 5% (Guy Podjarny: SPDY vs. HTTPS) zu 55% (Google) erklärt? Ich bin gespannt.