In meinem letzten Artikel “So verbrennt Ihr HTML Code >1 Mio € Umsatz pro Jahr” bin ich auf den ersten Hebel für eine Reduzierung der Ladezeit eingegangen. Neben den dort beschriebenen Maßnahmen zur Reduktion lässt sich aber noch deutlich mehr Zeit beim Laden einer Seite sparen.

Ohne lange um den heißen Brei herum zu reden: Nicht nur das Reduzieren von unnötigen Dateien ergibt insbesondere bei einer heterogenen Plattformlandschaft und sehr unterschiedlichen Internetbandbreiten einen Sinn.

Das was geladen werden muss, sollte so groß wie unbedingt nötig, jedoch besser so klein wie irgendwie möglich sein!

Hebel Nr. 2: Minimierung & Komprimierung

Mit anderen Worten: Alles was an Daten vom Webserver zum Nutzer übertragen wird, sollte möglichst klein sein. Dies gilt gleichermaßen für alle Arten von Daten. Diese werden nach dem MIME-Type (Multipurpose Internet Mail Extensions) Schema kategorisiert. Das größte Potenzial – mit Fokus auf Reduktion der Dateigröße – bieten hier in erster Linie Bilddaten (MIME-Type image/*), direkt gefolgt von allen Textformaten (MIME-Type text/*).

Zu letzterem zählen neben dem HTML-Code der Seite vor allem JavaScript und CSS (Cascading Style Sheets). Aber auch andere Daten werden häufig in reiner Textform übertragen, beispielsweise XML (Extensible Markup Language) oder JSON (JavaScript Object Notation) um nur einige zu nennen.

Neben Bild- und Textinhalten können auch andere Formate optimiert werden, z. B. Multimedia (MIME-Type video/* oder audio/*). Um primär die Ladezeit – gerade mit Blick auf die Conversion Rate – zu reduzieren, konzentrieren wir uns hier vorerst auf die erstgenannten.

Unterschiedschliche Vorgehensweisen

Es gibt verschiedene Möglichkeiten, Daten zu minimieren. Dies hängt primär vom Datentyp ab, aber auch vom eingesetzten Verfahren. Bei einigen Typen sind diese verlustfrei oder aber verlustbehaftet. Außerdem spricht man von einer Minimierung und/oder Komprimierung. Beides hat im Ergebnis eine kleinere Datei zur Folge, kann in Kombination erfolgen, ist aber nicht immer sinnvoll.

Werden Informationen lediglich zusammengefasst, spricht man in der Regel von Minimierung (z. B. das Entfernen von unnötigen Inhalten). Wird allerdings ein Algorithmus eingesetzt, um Inhalte beispielsweise neu zu organisieren, so spricht man von Komprimierung.

Es lassen sich nicht nur “nachträglich” die Daten verkleinern. Oft kann die Wahl des “richtigen” Dateiformats gerade bei Bildern schon zu einer signifikanten Reduktion der Dateigröße führen.

1. Das richtige Dateiformat

Bevor wir also das Endprodukt verkleinern, sollten wir vorher schon mal das “optimale Quellformat” gewählt haben. Eigentlich klingt das banal, aber unserer Erfahrung nach wird häufig – insbesondere bei der Wahl der Dateiformate – viel Potenzial verschenkt.

Was ist also das richtige Dateiformat?

Layoutgrafiken sollten idealerweise in einem verlustfreien Rastergrafikformat wie z. B. PNG (Portable Network Graphics) gespeichert werden. Überall, wo Flächen, Farben und Formen Einsatz finden, eignet sich dieses Format sehr gut.

Es ist die Weiterentwicklung des etwas in die Jahre gekommenden GIF (Graphics Interchange Format). Bietet zwar nicht dessen Animationsmöglichkeiten, dafür aber eine höhere Qualität bei geringerer Dateigröße. PNGs lassen sich als 8Bit (analog zum GIF auf 256 Farben reduziert) oder aber mit 24/36Bit Farbtiefe, mit oder ohne Alphakanal (für Transparenz) speichern. Je höher die Farbtiefe und Transparenz, desto größer die Datei. Also auch hier sollte man darauf achten, ob die 24Bit nötig sind, oder das Bild nicht auch mit 8Bit “gut genug” aussieht.

Ein kleiner Tipp für bessere Optik:
Bilder bei 8Bit nicht rastern und beim Farbmodus “Selektiv” wählen. Hier ermittelt die Grafikanwendung unter der Limitierung die 256 am häufigsten vorkommenden Farben. Sind die Farbstufen zu groß (Treppenbildung), lieber die Farbtiefe erhöhen oder das Dateiformat wechseln.

Inhaltsgrafiken wie beispielsweise “natürliche” Bilder (z. B. Produktbilder) sollten dagegen möglichst mit einem Dateiformat wie JPEG (Joint Photographic Experts Group) oder TIFF (Tagged Image File Format) gespeichert werden. Letzteres ist etwas exotischer im Internet, hat aber in der Regel durch seine verlustfreie Komprimierung (z. B. LZW oder Lauflängenkodierung) eine höhere Qualität und Dateigröße. Am häufigsten werden die Bilder im JPEG Format abgelegt.

Die JPEG-Norm definiert 41 verschiedene Unterdateiformate zur JPEG Komprimierung. Die meisten sind verlustbehaftet. Auf die verschiedenen Kompressionen und Kodierungen einzugehen, würde den Rahmen sprengen. Die wesentlichen Schritte bei der Komprimierung sind die Einteilung der Pixel des Bildes in 8×8-Blöcke, anschließender diskrete Kosinustransformation (DCT) und Quantisierung.

Die meisten Grafikanwendungen nehmen dem Ganzen die “Komplexität”, so dass beim Speichern des Bildes lediglich der Komprimierungsgrad gewählt werden muss. Häufig steht noch die Wahl der Farbtiefe (8 Bit, 12 Bit) oder das Speicherverfahren (Sequentiell, Progressive) zur Auswahl. Letzteres hat Einfluss darauf, ob das Bild in verschiedenen Qualitätsstufen geladen werden soll (erst ganz grob, dann feiner, usw.).

Wann PNG oder JPEG zum Einsatz kommen ist nicht in Stein gemeißelt. Es gibt immer Ausnahmen und sollte von Fall zu Fall unterschieden werden. Das gilt insbesondere für die in meinem letzten Artikel angesprochenen Sprites. Hier sollte man transparente Grafiken in einer “Transparenz-Sprite”, detailreiche Elemente in einer entsprechend gut aufgelösten “Pixel-Sprite” usw. gruppieren. Auch das spart Übertragungszeit.

Tipp:
Bei Bildverarbeitungs-Software wie Adobe Photoshop oder Fireworks, lassen sich mit “Für Web und Geräte speichern” die Quelldatei im Vergleich mit bis zu 3 anderen Formaten vor dem speichern betrachten. So kann mit dem Zielformat, der Komprimierung und der Farbtiefe gespielt werden, bis Qualität und Dateigröße stimmen. Ein guter Erfahrungswert bei JPEG liegt zwischen 60 – 70% Kompression.

Nachdem die Wahl der Quellformate geklärt ist, kann es jetzt um die Minimierung der Dateien gehen.

2. Verlustfreie Komprimierung

Von einer verlustfreien Komprimierung spricht man, wenn die Datei im Ergebnis zwar kleiner, aber von der Qualität identisch zum Ursprung ist. Mit anderen Worten: Es gehen keine Information verloren. Die Daten werden nur anders als vorher organisiert, indem bestimmte Redundanzen erkannt und zusammengefasst werden.

In Form von Minimierung funktioniert das am besten bei Textformaten. Hier lassen sich z. B. durch das Entfernen von Leerraum (Whitespace Reduction), Kommentaren oder Zeilenumbrüchen Speicherplatz einsparen (siehe Screenshot). Bei bestimmten Dateitypen wie beispielsweise JavaScript Dateien, kann zusätzlich durch semantische Optimierungen die Dateigröße reduziert werden. Dies funktioniert unter anderem durch das entfernen von Zeichen, die nach Spezifikation nicht zwingend erforderlich sind oder durch das Umbenennen/Kürzen von Methoden und Variablen (Symbol Obfuscation).

Bei Grafikformaten dagegen findet eine Komprimierung durch eine Umsortierung, Entropiekodierung oder Stringersatzverfahren statt. Dazu zählen unter anderem die Lauflängenkodierung, LZW, LZ77 (LZ78), Huffman- oder prädiktiver Kodierung sowie Kombinationen daraus, wie beispielsweise Deflate (Kombination aus LZ77 und Huffman-Kodierung, wird bei PNGs eingesetzt).

Mit Stringersatzverfahren lassen sich auch Textformate wie JavaScript komprimieren. Hiebei werden alle Texte (Strings) in einer Art Wörterbuch zusammengefasst und an ihrer Ursprungsstelle lediglich gekennzeichnet. Somit besteht der Quellcode nur noch aus Abkürzungen.

Auch wenn dies eine deutliche Reduktion der Dateigröße zur Folge hat, so geht das Interpretieren dieser komprimierten JavaScripts sehr zu Lasten des Browsers. Dieser muss bei jedem Aufruf das gesamte Script “dekodieren”. Gerade bei älteren Browsern und/oder PCs führt dies zu deutlich langsameren Interpretationszeiten, weshalb wir hier von abraten!

Tipp:
Sofern man bei Textformaten nicht schon während der Programmierung auf eine Minimierung achtet, würde diese Optimierung “händisch” einen großen Aufwand bedeuten. Außerdem ist ein auf eine Zeile “zusammengekürzter” Quellcode nicht wirklich gut lesbar. Deshalb gibt es hier Frameworks wie beispielsweise das YUI (Yahoo User Interface) welches diese Aufgaben übernimmt.

Eine Onlineversion des YUI-Compressors für JavaScript und CSS gibt es z. B. hier.

Was das nachträgliche Komprimieren von Bildformaten angeht: Auch hier gibt es Tools, die beispielsweise in einer Stapelverarbeitung oder als Dienst im Hintergrund die Grafiken automatisiert (je nach Dateityp) optimieren.

Für Mac haben wir dazu sehr gute Erfahrungen mit CodeKit gemacht, welches neben Grafikdateien vor allem sehr gut CSS und JavaScript minimieren kann.

3. Verlustbehaftete Komprimierung

Die verlustbehaftete Komprimierung wird, wie bereits bei den Dateiformaten angesprochen, in der Regel bei Multimedia wie Video, Audio und Bildern eingesetzt. Bei letzterem wird so versucht, den (Bild)Informationsverlust unmerklich oder zumindest ästhetisch erträglich zu gestalten.

Dabei wird die eingeschränkte Farbwahrnehmung des menschlichen Auges ausgenutzt, da hier kleine Farbänderungen nicht direkt sichtbar sind. So soll der Komprimierungsalgorithmus bevorzugt die Bildinformationen entfernen, die über die Aufnahmefähigkeit der menschlichen Bildwahrnehmung hinausgehen. Im Gegensatz zur Audiokompression ist das Wahrnehmungsmodell jedoch nicht explizit formuliert sondern eher intuitiv.

Jede Reduzierung der Dateigröße geht somit mit einem gewissen Qualitätsverlust einher. Die Frage dabei ist, wie weit man mit der Qualität runter geht, um ein in der Größe signifikant reduziertes Produkt zu erhalten, ohne aber zu viele Bildinformationen zu verlieren. Der Grat kann hier sehr schmal sein.

Tipp:
Ähnlich wie bei der verlustfreien Komprimierung gibt es auch hier Tools, die bei der Reduktion unterstützen. Oft können diese selbst aus einem bereits “optimal” gewählten Dateigrößen/Qualitäts-Verhätnis ein paar KB entlocken.

Neben CodeKit haben wir für Mac gute Erfahrungen mit ImageOptim gemacht.

4. Client- und Serverseitige-Komprimierung

Bisher betrafen die Optimierungstipps ausschließlich die Dateien selbst. Damit ist der Client-Bereich abgedeckt. Sehr viel Potenzial bietet auch der Webserver. Hier kann – teilweise mit wenigen einfachen Eingriffen – viel Performance herausgeholt werden.

Um vorerst beim Thema Komprimierung zu bleiben (in späteren Artikeln gibt es mehr zur Server-Performance), hier der wichtigste Hebel: Die gzip-Komprimierung.

Eigentlich handelt es sich hierbei um die Unix-Version des Komprimierungsverfahren ZIP. Da die meisten Webserver auf Unix basieren und alle Browser ebenso das Format interpretieren können, bietet sich diese verlustfreie Komprimierung besonders für Textformate an. Im Prinzip handelt es sich bei gzip um ein – z. B. bei PNGs eingesetztes – modifiziertes Deflate (s.o.).

Hiermit lassen sich Textformate also für den Transport vom Webserver zum Nutzer zusätzlich komprimieren. Der Vorteil dabei ist, dass der erforderliche Datentransfer damit kleiner ist, dadurch aber keine Interpretations-Probleme beim Browser auftreten. Dieser legt die unkomprimierte Datei einfach im Zwischenspeicher (Cache) ab. Diese Vorgehensweise eignet sich besonders für HTML, JavaScript und CSS.

5. Responsive Web: Mobile und Desktop

War es früher noch einfacher, für die Endgeräte die richtigen Bildformate zu treffen, muss heute doch einiges mehr berücksichtig werden.

Die wichtigsten Faktoren sind Bildgröße, Auflösung und Kompression.

Bei einem responsive Layout lassen sich die Inhalte passend zur Auflösung des Endgerätes umsortieren und/oder skalieren bzw. Inhalte die nicht relevant sind ausblenden. Hier sollte sich die Frage gestellt werden, ob nicht die Auslieferung eines bereits optimalen Bildformates z.B. bei einem Mobile Layout sinnvoller ist, anstatt dieses “lediglich” zu skalieren.

Das gleiche gilt für die Auflösung der Bilder. Bisher konnten alle Bilder in der Standard Bildschirmauflösung von 72dpi ausgeliefert werden. Durch die höheren Pixeldichten bei Smartphones, Tabletts und Desktops (z. B. Retinas) ist das leider nicht mehr so einfach.

Um beim Retina-Beispiel zu bleiben, hier können Endgeräte übergreifend zwischen 227 – 326 dpi (dots per inch) – also Anzahl der Pixel pro Zoll – vorliegen. Das treibt entsprechend wieder die Dateigröße der Bilder hoch. Zum Vergleich: Ein in 72dpi abgespeichertes Bild kann als 326dpi 4,5 mal so groß sein.

Die Herausforderung besteht also darin, für solche Endgeräte den besten Kompromiss für Bildqualität und Kompression zu finden und gezielt auszuliefern. Es würde keinen Sinn machen, per se jetzt alle Bilder in der höchsten Auflösung auszuliefern.

Tipp:
Es gibt viele Möglichkeiten, die Endgeräte und deren Pixelverhältnis zu ermitteln. Der einfachste Weg ist über die CSS/Media Queries. Hier lassen sich für verschiedene Ausgabemedien, Bildschirmauflösungen und Pixelverhältnisse Styles definieren. Aber auch per JavaScript oder im Webserver können diese Informationen direkt ausgewertet werden.

Fazit zur Reduzierung der Ladezeit

In diesem zweiten Artikel der Performance-Serie soll klar werden, wie viel Potenzial in der Wahl des richtigen Bildformates, der Kompression und Minimierung von Textdokumenten wie HTML, JavaScript und CSS liegt.

Alles was für die Übertragung vom Webserver zum Nutzer eingespart werden kann, verbessert die Ladezeit deutlich. Oft sind es nur wenige Anpassungen die am Webserver, dem CMS oder Shopsystem gemacht werden müssen, um Verbesserungen zu erzielen.

Letztlich muss auch hier nicht alles manuell erfolgen. Die meisten CMS und Shopsysteme haben diese Features bereits oder können durch PlugIns oder Module erweitert werden. Gerade bei der Massenverarbeitung von Inhaltsgrafiken (z. B. Produktbilder) kommt man in der Regel um eine Systemerweiterung nicht herum.

Welche Erfahrungen haben Sie mit der Minimierung und Komprimierung von Daten gemacht? Über Ihre Kommentare würde ich mich freuen!

Weiterführende Links

• Hintergründe zur Bildkompression
• Funktionsweise von JPEG im Detail
• Funktionsweise von PNG im Detail
• Dokumentation zur gzip-Komprimierung bei Apache Webserver

Ähnliche Artikel

• So verbrennt Ihr HTML Code >1 Mio € Umsatz pro Jahr