Von Manuel Brückmann | Tipps | 15 Reaktionen

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

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

Manuel Brückmann

Manuel Brückmann ist als Mitglied der Geschäftsleitung bei konversionsKRAFT für den Bereich Technologie verantwortlich. Er beschäftigt sich neben der Beratung im Bereich Testing mit eCommerce-Entwicklung und -Optimierung.
Frage zum Artikel? Frag den Autor

15 Reaktionen auf „So verbrennen Ihre Website-Grafiken >1 Mio € Umsatz pro Jahr

  1. von 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.

    • 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

      • von 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.

        • 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)!

          • Toller Artikel, mal CRO aus nem anderen Blickwinkel! Danke

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

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

                • von 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.


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

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

                      • @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.

                        • 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/

                          • 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!

                            • 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

                              Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.