Ich habe mir ein paar Gedanken über den Ressourcenverbrauch meiner Heimatseite im Zischennetz gemacht, um sie ein ganz klein wenig "grüner" zu gestalten...

Ich habe in letzter Zeit viel über Möglichkeiten nachgedacht, das Datenaufkommen meiner Präsenz im Zwischennetz zu reduzieren. Die erste und naheliegendste Idee war, die einzelnen HTML-Seiten zu komprimieren. Das funktioniert recht gut, da mein "Hoster" GitHub die Option anbietet, HTML-Seiten parallel nebeneinander komprimiert und umkomprimiert abzulegen - lässt ein Client dann erkennen, dass er mit komprimierten HTML-Seiten umgehen kann, liefert Pages die komprimierte Variante aus. Clients, die das nicht können oder wollen bekommen die unkomprimierte Rohform. Allerdings stimt die Aussage in diesem Artikel hier nicht mehr - GitHub stellt die Seiten inzwischen transparent komprimiert zur Verfügung - legt man eine Seite als ganz normales HTML ab, kümmert sich GitHub selbst um die Kompression - man muss dazu nichts selbst tun.

Um für meine eigene Seite grob auszurechnen, wieviel ich damit an Übertragungskanalkapazität spare habe ich das Kompressionspotential mit einer - zugegebenermaßen etwas hemdsärmeligen Methode - abgeschätzt - ich habe die Größen aller HTML-Seiten von elbosso.github.io zusammengerechnet - rund 35.6 MB kamen dabei heraus. Packt man diese Seiten alle in ein Tar-Archiv und komprimiert dieses anschließend mittels GZip, bleiben davon noch rund 3.4 MB übrig. Da es sich hier um reinen Text handelt, ist diese Kompressionsrate keine Überraschung.

Für Clients, die über genug Ressourcen verfügen, GZip on-the-fly dekomprimieren zu können ist das also schon einmal durchaus eine nicht zu verachtende Reduktion an benötigter Transmissionskapazität.

Das war aber noch nicht das Ende der Fahnenstange. Ich habe in den Strukturen der HTML-Seiten ebenfalls noch Verbesserungspotential gesehen - schließlich besteht eine HTML-Seite nicht nur aus dem Nutzinhalt - also dem Text - sondern auch noch aus Tags und deren Attributen.

Nach eingehender Nabelschau war ich gefühlsmäßig davon überzeugt, dass die class Attribute sehr viel mehr Platz einnehmen, als sie eigentlich müssten. Bevor ich mich aber daran machte, hier von Hand aus der Manufaktur herumzufeilen suchte ich nach anderen, einfacheren Möglichkeiten, den Umfang des HTML zu reduzieren - und ich wurde fündig!

Genau wie für JavaScript existieren auch für HTML Minifier. NAchdem ich das herausgefunden hatte, fand ich noch viele andere Ressourcen zu diesem Thema.

Ich entschied mich - auch wegen der unheimlichen Flexibilität beim Einsatz (diese Komponente arbeitet sogar als Add-on für Velocity!) - für htmlcompressor.

Jetzt wird die Webseite nach der Generierung der statischen Seiten nochmal komplett mittels htmlcompressor nachbearbeitet. Dadurch sinkt der Umfang unkomprimiert von rund 35.6 MB auf rund 25.7 MB - eine Einsparung von fast 18%!

Komprimiert sinkt das Datenvolumen von rund 3.4 MB auf nur noch rund 2.6 MB - hier wird eine Einsparung von immerhin noch rund 14% erreicht.

Mit diesem Ergebnis war ich zunächst zufrieden - ich kann aber nicht garantieren, dass ich nicht demnächst nochmal Hand an die Velocity-Templates lege, um das HTML selbst nochmals schlanker zu gestalten...

Kommentar hinzufügen (via ) Kommentare ansehen (via )

Kommentar hinzufügen (via ) Kommentare ansehen (via )