Dass auch heutzutage (in Zeiten von DSL und schnelleren Internetverbindungsarten) Datenlast eine gro\u00dfe Rolle spielt, sollte jedem klar sein, der schon mal mit dem Handy auf eine Webseite gelangt ist, die mehr als zehn Sekunden ben\u00f6tigt hat, um vollst\u00e4ndig zu laden. Es ist also nach wie vor eine wichtige Aufgabe von Web EntwicklerInnen, darauf zu achten, dass keine unn\u00f6tigen Bits und Bytes zum Anwender \u00fcbertragen werden.<\/p>\n
Bilder, Sounds und Videos komprimieren? Klar. Sprites und Iconfonts statt Grafiken einsetzen? Auch klar. HTTP-Requests auf ein Minimum beschr\u00e4nken? Logisch. <\/p>\n
Dass man auch Quelltext komprimieren kann, war mir seit den Sp\u00e4tneunzigern bewusst („HTML Tidy“), aber eingesetzt habe ich es bisher nie. Wahrscheinlich war es mir immer wichtiger, eine les- und editierbare HTML- oder PHP-Datei auf dem Kundenserver liegen zu haben, um bei einer sp\u00e4teren \u00c4nderung nicht erst die „un-minifizierte“ Version jeder zu \u00e4ndernden Datei heraussuchen zu m\u00fcssen.<\/p>\n
Wenn ich aber bedenke, wie viele Kilobytes man durch Kompression von HTML-, PHP-, JS-, CSS- und sonstigen Dateien, die Quelltext und somit in der Regel Kommentare, Wei\u00dfraum und weitere komprimierbare Elemente enthalten, sparen k\u00f6nnte und wie sehr es mich selbst nervt, wenn ich mobil surfe und die Webseiten mal wieder wie mit dem Akkustikkoppler empfangen hereintr\u00f6pfeln, sollte ich mir angew\u00f6hnen, diesen Schritt — Kompression von Quelltextdateien — ebenfalls noch zu gehen.<\/p>\n