Mittwoch, 15. Februar 2017

Welches Kompressionsverfahren ist das Beste?

Es gibt schon einige Verfahren um Daten Klei zu kriegen. Auf Wikipedia zähle ich mehr als 20, auch wenn da eher historische Verfahren dabei sind oder Verfahren, die fast gleich sind. Der inspiriert vom letzten Versuch zu BROTLI und ZOPFLI (Link) habe ich den Versuch um die beliebten Verfahren LZMA und BZIP2 ergänzt.


Datei Uncompressed Gzip Compression rate Zopfli Compression rate Brotli Compression rate LZMA Compression rate BZIP2 Compression rate
redirect_frame.html 431 300 1,4 274 1,6 194 2,2 294 1,5 312 1,4
runtasticOTTO.html 162730 35690 4,6 34091 4,8 30535 5,3 32182 5,1 34682 4,7
www.ebert-p.com.html 15134 3191 4,7 3064 4,9 2568 5,9 3099 4,9 3924 3,9

Ergebnisse

  1. Jede Kompression ist besser als Keine.
  2. BROTLI ist das Verfahren der Wahl und sollte auf den Web-Servern aktiviert werden.
  3. Wenn BROTLI nicht geht, dann sollte man ZOPFLI nehmen.
  4. LZMA ist wie ZOPFLI eine gute Wahl.
  5. BZIP2 kann kaum punkten ist auf einem ähnlichen Niveau die GZIP. Hier sollte man wegen seiner Verbreitung eher auf GZIP setzen.

Dienstag, 14. Februar 2017

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

Montag, 13. Februar 2017

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



Graphische Trendanalyse von stark schwankenden Messwerten mit R

Statistisch lässt sich das Problem recht einfach mit dem XX-Test und ähnliche Test lösen. Neben diese Aussage ist es notwendig die Rohdaten entsprechend graphisch aufzubereiten, weil man mit Grafiken wesentlich besser überzeugt als mit der Angabe von Wahrscheinlichkeit oder Koeffizienten.

Die graphische Aufbereitung von stark schwankenden (volatiler) Messwerten kann man einfach als Signalverarbeitungsproblem sehen. Zuerst muss man das Signal (Messwerte) glätten und danach schärfen.

Die mathematische Entsprechung einer einfachen Glättungsfunktion, bei der Bildverarbeitung spricht man auch von einem Weichzeichner, ist der gleitende Mittelwert mit einer Gauss-Verteilungs-Gewichtung.

In R sieht dass dann wie folgt aus:
library('smoother')
smth.gaussian(dtDateRange$duration_min, window = kSmoothingWindowSize, tails = T)


Hier ein Ergebnis in graphischer Form. Klar sind hier die unterschiedlichen Bereich erkennbar. Man kann das Ergebnis noch deutlich verbesser um alle hochfrequenten Schwingungen zu eliminieren.
Hier noch ein anderes Beispiel für die graphische Trendanalyse inclusive der originalen Werte.