Mozilla mozjpeg 2.0 soll Bilder kleiner machen
von caschy | 15 Kommentare
Um das Web schneller zu machen, braucht es keine neuen Bildformate. Dies behauptet zumindest Mozilla. Je schneller Bilder geladen werden, desto besser. Google hat für sich 2010 das Format WebP erdacht und eine stärkere Kompression bei gleichbleibender Qualität gegenüber dem JPG-Format ausgesagt. Seit längerer Zeit arbeitet Mozilla daran, Bilder noch stärker komprimieren zu können, ohne dass der Betrachter auf Qualität verzichten muss.
Heute war es dann soweit, Mozilla veröffentlichte den JPEG Encoder mozjpeg in seiner Version 2.0. Durchschnittlich 5 Prozent besser arbeitet dieser bei Baseline und Progressive JPEGs. Als besonders großes Unternehmen konnte man Facebook nennen, die mozjpeg 2.0 nun testen wollen, um die angezeigten Bilder zu komprimieren. Zudem unterstützt Facebook die Entwicklung des Encoders mit 60.000 Dollar. Technische Details für alle Interessierten hält das Research Blog von Mozilla bereit. Es ist nicht nur Firefox, für den man Mozilla gerne haben muss – es sind auch diese Forschungen und Techniken, die helfen sollen, das Web besser zu machen.
Wird geladen ...
Schön dass auf so etwas wieder geachtet wird, allerdings sehe ich da jetzt nicht so das Optimierungspotential. Ob das Bild nun 200KB oder 195KB groß ist macht bei den heutigen Geschwindigkeiten nicht soo viel aus.
Wo ich viel mehr Optimierungspotential sehe wäre eine sinnvollere Einbindung von Bildern, css und js. Beispielsweise diese Seite. 187 Anfragen (1.96MB).
Nicht nur dass für jeden Request der http Header nebst ggf. relevanten Cookies mit gesendet werden muss welcher teilweise schon größer ist als die angefragte Datei, nicht zu vernachlässigen ist auch die roundtriptime welche je nach Internetanbindung stark variiert (bei mir 100 – 300ms). In vielen Fällen kann man die einzelnen css / js Dateien jeweils zusammen fügen sodass die Anzahl der Requests verringert wird. Genau das Selbe zählt für Bilder, hier ist das Stichwort css-Sprites. Beispielsweise können Social Bilder (Twitter, Facebook, …) in ein Bild zusammen kopiert werden und per css ausgerichtet werden.
Noch ein Stichwort wäre vernünftiges Caching. Manche Seiten cachen so gut wie garnichts, manche machen es einfach falsch. Wenn eh schon Versionsnummern im Dateinamen drin sind (wie jquery.atd.textarea.js?ver=5.0.36) denn kann der Server definieren dass der Browser immer die lokale Version nimmt (sofern vorhanden). Häufig ist es aber so dass der Browser trotzdem noch dazu verleitet wird beim Server anzufragen ob die Datei sich verändert hat, was wiederum ein Request ist mit Headern und Cookies und dem roundtrip. In diesem Fall ist die Zeit und Traffic einfach nur verschwendet.
da geb ich dir recht.
@Saenic:
Hab ich schon vorher so umgesetzt. Und klar wird es in solchen Tools auch angezeigt, weil es sehr relevant ist. Es wird doch heutzutage fast alles nur noch irgendwie zusammen geklatscht, Hauptsache funktioniert irgendwie. Auf Performance achtet ja keiner mehr. Merkt man deutlich wenn man mal an langsamere Internetverbindungen gebunden ist.
„Ich finde WebP dennoch besser, da es quasi die eierlegende Wollmilchsau unter den Formaten ist“
Naja… Dann wäre avi auch eine eierlegende Wollmilchsau. Kann auch alles drin sein, keiner weiß was für ein Format es wirklich ist und welcher Codec benötigt wird, ohne Einsatz von Zusatztools. Halte ich für suboptimal. (wobei ich gegen ein neues Bildformat nichts hätte. Vor allem wäre ein vektorbasiertes Format, was denn auch mal vernünftig unterstützt wird, nicht schlecht. Grade im Zeitalter von Handy, Tablets, … und den zig verschiedenen DPI Werten)
@Thomas Baumann: Für den „normalen“ User ist das jetzt sicher nichts, was überhaupt der Beachtung wert wäre. Aber ich glaube nicht, dass der Fokus bei dieser Entwicklung auf schnelleren Ladezeiten von Websites liegt, sondern an der Optimierung des Speicherplatzbedarfs.
Dass sich ein Unternehmen wie Facebook dafür interessiert, macht dann schon Sinn. Bei mehr als 350 Millionen neuen (!!!) Fotos pro Tag sind 5% dann nämlich schon wieder eine ganz andere Hausnummer. Da lassen sich die Kosten für Speicher und Backup sicherlich weit über die 60.000 investierten US$ senken.
Wobei die 60.000$ ja auch eher ein Tropfen auf den heißen Stein sind. Das ist ja nichtmal ein Jahresgehalt..
Hat sich erledigt, Michele war schneller
Also wirklich genial finde ich diese Engine: http://compressor.io/
DAS lohnt sich wirklich. Ich jage jedes Bild auf meinem Blog zuerst da durch, unfassbar wie klein die Bilder danach werden…
@Seanic: „Ich finde WebP dennoch besser, da es quasi die eierlegende Wollmilchsau unter den Formaten ist“
Naja, Mozilla hat sich mit dem Thema ja auch befasst und eine Studie zu verschiedenen JPEG-Alternativen veröffentlicht. Für Mozilla ging es dabei ausschließlich um die Kompressionseffizienz, nicht um das erweiterte Feature-Set, welches WebP bietet und das Format natürlich interessant macht. Aber was konkret Mozillas Schwerpunkt betrifft, hat WebP nicht wirklich überzeugt. Dazu kommt, dass es ein großer Vorteil ist, kein neues Format einzuführen. Ich habe außerdem schon öfter gelesen, dass viele Facebook-Nutzer mit dem WebP-Format überfordert sind, die können mit den Bildern nichts anfangen, wenn sie sie herunterladen. Auch das ist ein Problem bedingt dadurch, dass es ein neues Format ist. Ohne es jetzt überprüft zu haben, wenn der Download wirklich WebP-Bilder liefert, kann ich mir das mehr als gut vorstellen, damit können viele Anzeigeprogramme einfach nichts anfangen – und damit auch die Nutzer nicht, die es eben nicht nur im Browser anzeigen wollen. Generell sind eierlegende Wollmichsäue auch nicht wirklich immer das Beste, ich würde zum Beispiel jetzt auch kein SeaMonkey statt Firefox und Thunderbird nutzen wollen, das wäre ja auch eine Art eierlegende Wollmichsau, anderes Gebiet eben. Aber sowas kann natürlich jeder anders sehen.
WebP ist niemals vollkommen verlustfrei, weil das sog. Chroma-Subsampling (4:2:0) immer aktiv ist.
Zudem basiert WebP noch auf VP8, allerdings ist mittlerweile bereits VP9 verfügbar, und das komprimiert noch effizienter.
Doch, es gibt ein 100%ig verlustfreies WebP-Format (und somit auch ohne Chromasubsampling). Genauso wie flac verlustfrei ist und es manche Leute immer noch nicht glauben können…
Ok, Anon, stimmt. Ich habe mal nachgesehen. WeP wurde mittlerweile um verlustfreie Kompressionsmodi ergänzt. Der Nachteil: Das Format ist wesentlich komplexer im Vergleich zu PNG, da es mehr Kompressionsmodi beinhaltet.
WebP kann sich vermutlich nur zusammen mit einer Umstellung auf HTTP 2.0 durchsetzen, weil wir dafür dann ohnehin alle neue Browser benötigen.
WebP kann sich nur ernsthaft durchsetzen, wenn es Unterstützung von anderen Browserherstellern als Google erhält *und* wenn es von den gängigen Grafikprogrammen unterstützt wird. Ob das nun zusammen mit HTTP/2.0 passiert oder nicht, das ist wirklich ziemlich egal. Da wird halt die Unterstützung mit einem der alle paar Wochen erscheinenden Updates geliefert. Es gibt eigentlich keinen Grund, wieso das eine auf das jeweils andere warten sollte.
WebP ist deutlich besser, nur was nützt mir das wenn außer Chrome/Opera kein Programm damit was anfangen kann (nicht mal PS). Die Firefox Leute spielen Kindergarten, bei IE wird es wahrscheinlich nie, Safari ja bestimmt auch nicht. Somit jetzt schon durchgefallen wenn es nicht mal irgendwie als Standard zementiert wird.
„Die Firefox Leute spielen Kindergarten“ – Kindergarten sind höchsten solche Kommentare, mein guter „namerp“, welche jegliche sachliche Grundlage vermissen lassen. Informier dich mal ein bisschen über das Thema, bevor du solche Behauptungen aufstellst, Danke. 😉