Tipps

So verbrennen Ihre Website-Grafiken >1 Mio € Umsatz pro Jahr

Manuel Brückmann
 Lesezeit: 11 Minuten    
14
arrow_down
14

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?

Reduzierung der Ladezeit: Amazon Navigations Sprite als 8Bit transparentes PNG
Beispiel zeigt eine Amazon Navigations Sprite als 8Bit transparentes PNG

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.

Amazon Produktbild JPEG bei 70% Kompression
Beispiel zeigt Amazon Produktbild als JPEG bei 70% Kompression

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.

Beispiel: Für Web und Geräte speichern
Beispiel: Für Web und Geräte speichern, Original (586KB), PNG8 (8,8KB), PNG24 (20KB), JPEG 70% (22KB)

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

2. Verlustfreie Komprimierung

Reduzierung der Ladezeit: Vergleich normaler Quellcode mit Minimierung
Vergleich normaler Quellcode mit verlustfreier Minimierung

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

Beispiel für die JPEG Blockbildung bei hoher Kompression
Beispiel für die JPEG Blockbildung bei hoher Kompression (70%|50%|20%)

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.).

Reduzierung der Ladezeit: Vergleich Unkomprimiert vs. Minimiert vs. GZIP
Vergleich Unkomprimiert vs. Minimiert vs. GZIP

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

konversionsKRAFT-Plattform-Mashup-610War 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

Ähnliche Artikel

Über den Autor

manu-brueckmann

Manuel Brückmann

Principal Technology Consultant

Manuel Brückmann, Jahrgang 1982, ist als Principal Technology Consulting bei konversionsKRAFT – Deutschlands führende Agentur für Conversion Optimierung – für den Bereich Technologie Beratung verantwortlich.

Sein Werdegang begann 2007 im Bereich Design & Usability. Mit dem Abschluss als Dipl. Ing. (FH) Medieninformatik sammelte er als Consultant und Projektmanager in den darauf folgenden 2 Jahren Erfahrungen, bis er 2009 in den Bereich Interaction Design & Interface Development wechselte. Zwei Jahre später sammelte er in der Rolle des Senior User Experience Engineer Erfahrungen im UX-Bereich. In den folgenden Jahren übernahm er seit Anfang 2012 die Verantwortung für den Bereich Conversion Engineering bei konversionsKRAFT und führte eine interdisziplinäre Business Unit. Seit Anfang 2016 gehörte er zur Geschäftsleitung und übernahm dort die Führung der Technologie im Unternehmen. Seit 2019 konzentriert er sich als Principal Technology Consultant auf die technischen Beratungsthemen im Unternehmen.

Neben umfangreichen Kenntnissen aus dem Bereich Technologie und Webentwicklung (Web Oberflächentechnologien, Medien, User Experience, Mobile, SEO) weist er 15 Jahre Erfahrung in den Bereichen Conversion Optimierung, E-Commerce, Lead-Generierung, Konsumpsychologie, Usability, Projekt-, Account -und Team-Management vor.

Frage zum Artikel? Frag den Autor!

14 Kommentare

  1. Gravatar

    Chili Conversion – Heiko,

    Klasse Artikel Manuel! Unsere Erfahrungen in Bezug Minimierung und Komprimierung von Daten sind durch weg positiv. Leider wird bei Conversion-Optimierung zu meist von der Veränderung von Größen, Positionen, Formen und Farben gesprochen, der technische Aspekt der Performance allerdings noch allzu häufig nicht gebührend beachtet.

  2. Gravatar

    Roland Schäfer,

    Prima Aufzählung!
    Allerdings sollte nicht unerwähnt bleiben, das all diese Optimierung an Code und Mediendateien (und noch mehr) automatisiert von diverse cloudservices/CDNs zur Laufzeit erledigt werden. Gewissermaßen verlagert sich solche Optimierungen von der Produktion hin zur Auslieferung.

    Als Beispiel Google Page Speed Services:
    https://developers.google.com/speed/pagespeed/service

    • Gravatar

      Manuel Brückmann,

      Hallo Roland,

      vielen Dank für Dein Feedback.

      Völlig richtig, Cloudservices bieten teilweise umfassende Optimierungen zur Laufzeit. Letztlich spielt es keine Rolle, ob diese Optimierung zur Laufzeit am eigenen Webserver (z. B. über PlugIns, Module etc.) oder über einen Dienstleister laufen. Zumindest wenn es vorerst nur um die Reduzierung des Datenvolumens geht. Hauptsache es wird überhaupt gemacht. Auf die anderen Vorteile eines solchen Services komme ich in späteren Artikeln noch mal genauer zu sprechen. Was der Service allerdings in der Regel nicht abdeckt, sind die im Artikel angesprochenen Basics. Beispielsweise die Wahl der richtigen Quellformates, Zusammenfassung in geeignete Sprites etc.

  3. Gravatar

    Sven Möller,

    Hallo,

    guter Artikel! Ich denke aber es ist wirklich schwer zu differenzieren. Wie schon angeschnitten, spielt die Traffic-Art eine große Rolle.
    Aber auch hier muss man weiter differenzieren.

    Auf unserer Seite haben wir viel SEO-Traffic, der ja gefühlt eine höhere Conversionrate haben sollte, jedoch kommen die Nutzer von vielen Long-Tails bzw. keine Kauf bezogenen Keywords. Unsere Conversionrate liegt bei unter 0,5%. Wir beschäftigen uns aber selbst viel mit Conversionoptimierung und gefühlt bekommt man bei so einem Traffic, nie eine Conversionrate von 1-2% hin.

    Aber großes Lob, solche Zahlen aus Studien suchen viele(einschließlich mir)!

  4. Gravatar

    Markus Kehrer,

    Toller Artikel, mal CRO aus nem anderen Blickwinkel! Danke

  5. Gravatar

    Michael Klöpzig,

    Inzwischen kommt man von Spritegrafiken wieder ab, weil die Produktion und Aktualisierung zu aufwendig ist und auch mehr Browserfunktionen zur Verfügung stehen. Im Fall des Amazon-Beispiels lässt sich die Grafik (mit Ausnahme der Logos / Icons) direkt in CSS realisieren, komplett mit Verläufen etc.
    Icons können als Inline-Grafik ebenfalls direkt ins CSS eingebettet werden (http://www.base64-image.de) bzw. werden als SVG oder gar mit Icon-Fonts verwendet (was den zusätzlichen Vorteil hat, dass sie frei skaliert werden können).

    • Gravatar

      Manuel Brückmann,

      Hallo Michael,

      vielen Dank für Dein Feedback.
      Du erklärst damit im Prinzip genau meinen letzten Artikel! 😉
      Ich stimme Dir voll zu. Dies sollte hier aber auch kein Plädoyer für die Verwendung von Sprites sein, sondern für Komprimierung von Daten. Die Sprites waren nur ein Beispiel.

  6. Gravatar

    Vincent Lammers,

    Sehr spannender Artikel!
    Ich bin immer wieder beeindruckt, wie effektiv das Webtool TinyPNG ohne sichtbaren Qualitätsverlust komprimiert. Es ist aber nicht nur gute Software, sondern sogar gratis. Kann http://tinypng.org aus eigener Erfahrung nur empfehlen.

  7. Gravatar

    Roland Schäfer,


    Was der Service allerdings in der Regel nicht abdeckt, sind die im Artikel angesprochenen Basics. Beispielsweise die Wahl der richtigen Quellformates, Zusammenfassung in geeignete Sprites etc.

    Die Optimierungen im Bereich Bilddateien sind recht umfassend und feingranular konfigurierbar (rewrite rules): https://developers.google.com/speed/pagespeed/service/OptimizeImages

    Konkret werden alle in Punkt 1-4 beschriebenen Maßnahmen und diverse andere Methoden zur Laufzeit angewendet. Der Punkt ist, dass die Produktion von Code und Mediendateien durch Einsatz solcher Services einfacher/billiger wird, da die manuellen Optimierungen in der beschriebenen Form nicht mehr notwendig ist.

    • Gravatar

      Manuel Brückmann,

      @Roland Schäfer
      Danke für das Beispiel. Dieser CloudService bietet neben den Bildoptimierungen tatsächlich auch für HTML, CSS und JavaScript umfangreiche Verbesserungen an und deckt damit viele Basics ab.
      Dazu folgt in einem späteren Artikel mehr.

      @Stefan Habring
      Vielen Dank für die Anmerkung. Der Artikel von Daan Jobsis hierzu ist sehr interessant. Bisher haben wir sehr gute Erfahrungen mit der Endgeräte spezifischen Auslieferung gemacht. Wenn sich ein Kompromiss aus Auflösung und Dateigröße finden lässt, um so besser. Das reduziert ggf. den technischen Aufwand.

  8. Gravatar

    Stefan Habring,

    Anmerkung zur verlustbehafteten Komprimierung: Es macht durchaus Sinn Bilder in größerer Auflösung und höherer Kompression auszuliefern. Hierzu kann ich einen auf einen sehr interessanten Artikel von Daan Jobsis empfehlen: http://www.netvlies.nl/blog/design-interactie/retina-revolution
    Allerdings sollte bei der Komprimierung Vorsicht geboten sein, wenn das Bild roten Bereichen enthält. Die Komprimierung wird an diesen sehr deutlich sichtbar.

  9. Gravatar

    Ralf,

    Sehr spannender Artikel!Überrascht bin ich über das f e h l e n von WebP

    Vor allem bei JPEG ist dies meiner Meinung nach eine sinnvolle Alternatvie
    Mehr über WebP Wikipedia
    http://de.wikipedia.org/wiki/WebP
    und beim Entwickler Google
    https://developers.google.com/speed/webp/

    Des weiteren fehlt mir in dem Artikel der Hinweis auf den optimalen Speicherort für Bilder. Ein Apache mit x Modulen der auch noch PHP Scripte auslierfern kann ist viel zu träge.
    Des weiteren sollte nach einem Yahoo Test, Bilder perse nur über eine Cookie freie Domain ausgeliefert werden.
    Siehe auch: http://developer.yahoo.com/performance/rules.html#cookie_free

    Auch die Optimierung der Bilder mit
    pngcrush: to strip unneeded chunks from PNGs. We are also experimenting with other PNG reduction tools such as pngout, optipng, pngrewrite.
    Hopefully these tools will provide improved optimization of PNG files.

    jpegtran: to strip all metadata from JPEGs (currently disabled) and try progressive JPEGs.

    gifsicle: to optimize GIF animations by stripping repeating pixels in different frames.

    fehlte mir.
    http://developer.yahoo.com/performance/rules.html#opt_images
    pp

    Yahoo Smush.it
    http://www.smushit.com/

  10. Gravatar

    Tom Conrad,

    Super Artikel! Danke dafür. Ich habe bis jetzt noch keinen Artikel gefunden, der die Optimierung von Bildern so ausführlich erklärt. Der Artikel ist gebookmarkt!

  11. Gravatar

    Anja Höpfner,

    Super toller Artikel! Vielen Dank!

    Unsere Passion ist die Kompression von Bildern, Ton und Video .. wir sind mit unserer Technologie soweit, dass wir jpeg ablösen können. Wir glauben – wie in dem Artikel beschrieben – , dass sich hierin ein enormes Potenzial für alle Player im Bereich eCommerce befindet.

    Viele Grüße
    Anja

Schreibe einen Kommentar

Teile diesen Artikel

Kostenlos anmelden