Wir kennen das alle: Man surft auf einer Website, die Unmengen von riesigen Bildern von köstlichem Essen oder vielleicht dem neuen Gadget, das man ins Auge gefasst hat, zeigt. Diese Bilder sprechen unsere Sinne an, und für Content-Autoren sind sie unerlässlich, um Menschen zum Handeln zu bewegen.
Nur sind diese Bilder geradezu riesig. Wirklich riesig. Bei einer schleppenden mobilen Verbindung kann man diese Bilder förmlich wie ein abrollendes Rolltor vor sich aufklappen sehen. Man wird sofort an die schlechten alten Zeiten des Dial-ups erinnert.
Das ist ein Problem, denn Bilder machen einen erheblichen Teil dessen aus, was auf einer typischen Website heruntergeladen wird, und das aus gutem Grund. Bilder sind ausdrucksstarke Werkzeuge und können mehr sagen als Text. Die Herausforderung besteht darin, den schmalen Grat zwischen visuell reichhaltigem Inhalt und dessen schneller Auslieferung zu meistern.
Die Lösung für dieses Dilemma ist nicht eindimensional. Es gibt viele Techniken, um unhandliche Bilder zu verschlanken und sie entsprechend den Fähigkeiten der Geräte, die sie anfordern, auszuliefern. Ein solches Thema könnte leicht ein eigenes Buch füllen, aber der Fokus dieses Beitrags wird sehr spezifisch sein: Googles WebP-Bildformat und wie Sie es nutzen können, um Bilder bereitzustellen, die die gleiche visuelle Wiedergabetreue wie Ihre aktuellen Bilder haben, aber bei einem Bruchteil der Dateigröße. Legen wir los!
Was ist WebP und warum sollte es mich überhaupt interessieren?
WebP ist ein Bildformat, das 2010 von Google entwickelt und erstmals veröffentlicht wurde. Es unterstützt die Kodierung von Bildern sowohl in verlustfreiem als auch in verlustbehaftetem Format, was es zu einem vielseitigen Format für jede Art von visuellen Medien und zu einer großartigen Alternative zu PNG oder JPEG macht. Die visuelle Qualität von WebP ist oft mit gängigeren Formaten vergleichbar. Unten sehen Sie einen Vergleich eines verlustbehafteten WebP-Bildes und eines JPEG-Bildes.

Im obigen Beispiel sind die visuellen Unterschiede kaum wahrnehmbar, während die Unterschiede in der Dateigröße erheblich sind. Die JPEG-Version links wiegt 56,7 KB, und die WebP-Version rechts ist mit 38 KB fast ein Drittel kleiner. Nicht schlecht, besonders wenn man bedenkt, dass die visuelle Qualität vergleichbar ist.
Die nächste Frage ist natürlich: „Wie sieht es mit der Browserunterstützung aus?“ Nicht so spärlich, wie man denken könnte. Da WebP eine Google-Technologie ist, ist die Unterstützung an Blink-basierte Browser gebunden. Diese Browser machen einen erheblichen Teil der weltweiten Nutzer aus, was bedeutet, dass zum Zeitpunkt des Schreibens fast 70 % der verwendeten Browser WebP unterstützen. Wenn Sie die Chance hätten, Ihre Website für über zwei Drittel Ihrer Nutzer schneller zu machen, würden Sie sie dann verstreichen lassen? Ich glaube nicht.
Es ist wichtig zu bedenken, dass WebP kein Ersatz für JPEG- und PNG-Bilder ist. Es ist ein Format, das Sie für Browser bereitstellen können, die es nutzen können, aber Sie sollten ältere Bildformate für andere Browser bereithalten. Das ist die Natur der Webentwicklung: Haben Sie Ihren Plan A für Browser bereit, die damit umgehen können, und Ihren Plan B (und vielleicht Plan C) für weniger fähige Browser.
Genug der Vorbehalte. Lasst uns optimieren!
Ihre Bilder nach WebP konvertieren
Wenn Sie mit Photoshop vertraut sind, ist der einfachste Weg, einen Eindruck von WebP zu bekommen, das WebP Photoshop Plugin auszuprobieren. Nachdem Sie es installiert haben, können Sie die Option Speichern unter (nicht für Web speichern!) verwenden und entweder WebP oder WebP verlustfrei aus dem Format-Dropdown auswählen.
Was ist der Unterschied zwischen den beiden? Denken Sie daran, dass es sehr ähnlich zu den Unterschieden zwischen JPEG- und PNG-Bildern ist. JPEGs sind verlustbehaftet, und PNG-Bilder sind verlustfrei. Verwenden Sie das normale WebP, wenn Sie Ihre JPEG-Bilder konvertieren möchten. Verwenden Sie WebP verlustfrei, wenn Sie Ihre PNGs konvertieren.
Wenn Sie Bilder mit dem WebP-Verlustfrei-Format mit dem Photoshop-Plugin speichern, erhalten Sie keine Eingabeaufforderungen. Es erledigt einfach alles. Wenn Sie normales WebP für Ihre verlustbehafteten Bilder wählen, erhalten Sie jedoch etwas wie dieses

Der Einstellungsdialog für verlustbehaftetes WebP bietet mehr Flexibilität bei der Konfiguration der Ausgabe. Sie können die Bildqualität mit einem Schieberegler von 0 bis 100 einstellen (ähnlich wie bei JPEG), die Stärke des Filterprofils festlegen, um kleinere Dateigrößen zu erzielen (natürlich auf Kosten der visuellen Qualität) und Rauschfilterung sowie Schärfe anpassen.
Meine Kritik am WebP Photoshop-Plugin ist zweigeteilt: Es gibt keine „Für Web speichern“-Oberfläche, damit Sie sehen können, wie ein Bild mit den gewählten Einstellungen aussehen wird. Wenn Sie viele Bilder speichern wollten, müssten Sie einen Stapelprozess erstellen. Meine zweite Kritik ist wahrscheinlich kein Hindernis für Sie, wenn Sie Stapelverarbeitung in Photoshop mögen, aber ich bin eher ein Programmierer, daher bevorzuge ich etwas wie Node, um viele Bilder gleichzeitig zu konvertieren.
Bilder mit Node nach WebP konvertieren
Node.js ist fantastisch, und für Alleskönner wie mich ist es weniger die Tatsache, dass es JavaScript auf den Server bringt, sondern vielmehr, dass es ein Produktivitätswerkzeug ist, das ich beim Erstellen von Websites nutzen kann. In diesem Artikel werden wir Node verwenden, um Ihre JPEGs und PNGs en masse in WebP-Bilder zu konvertieren, indem wir ein Node-Paket namens imagemin verwenden.
imagemin ist das Schweizer Taschenmesser der Bildprozessoren in Node, aber wir werden uns nur darauf konzentrieren, alle unsere JPEGs und PNGs in WebP-Bilder zu konvertieren. Keine Sorge! Selbst wenn Sie noch nie Node verwendet haben, wird dieser Artikel Sie durch alles führen. Wenn Sie die Idee, Node zu verwenden, stört, können Sie das WebP Photoshop-Plugin verwenden und überspringen.
Als Erstes sollten Sie Node.js herunterladen und installieren. Das sollte nur wenige Minuten dauern. Sobald es installiert ist, öffnen Sie ein Terminalfenster und navigieren Sie zu Ihrem Webprojekt-Stammordner. Von dort aus installieren Sie einfach imagemin und das imagemin-webp-Plugin mit Node Package Manager (npm).
npm install imagemin imagemin-webp
Die Installation kann bis zu einer Minute dauern. Wenn Sie fertig sind, öffnen Sie Ihren Texteditor und erstellen Sie eine neue Datei mit dem Namen webp.js in Ihrem Webprojekt-Stammordner.
Geben Sie das folgende Skript in die Datei ein (aktualisiert für modernes Node von Luke Berry)
EDIT: Beide Snippets wurden für frühere Versionen von imagemin-webp angewendet. Kürzlich wurde dieses Tool in 7.0 auf natives ESM umgestellt. Konsultieren Sie die README für die Implementierung. Möglicherweise müssen Sie require() durch import ersetzen. Und geben Sie type: module in Ihrer package.json an.
Ursprüngliches Skript
var imagemin = require("imagemin"), // The imagemin module.
webp = require("imagemin-webp"), // imagemin's WebP plugin.
outputFolder = "./img", // Output folder
PNGImages = "./img/*.png", // PNG images
JPEGImages = "./img/*.jpg"; // JPEG images
imagemin([PNGImages], outputFolder, {
plugins: [webp({
lossless: true // Losslessly encode images
})]
});
imagemin([JPEGImages], outputFolder, {
plugins: [webp({
quality: 65 // Quality setting from 0 to 100
})]
});
const imagemin = require('imagemin'),
webp = require('imagemin-webp')
const outputFolder = './images/webp'
const produceWebP = async () => {
await imagemin(['images/*.png'], {
destination: outputFolder,
plugins: [
webp({
lossless: true
})
]
})
console.log('PNGs processed')
await imagemin(['images/*.{jpg,jpeg}'], {
destination: outputFolder,
plugins: [
webp({
quality: 65
})
]
})
console.log('JPGs and JPEGs processed')
}
produceWebP()
Dieses Skript verarbeitet alle JPEG- und PNG-Bilder im img-Ordner und konvertiert sie in WebP. Beim Konvertieren von PNG-Bildern setzen wir die Option lossless auf true. Beim Konvertieren von JPEG-Bildern setzen wir die Option quality auf 65. Experimentieren Sie ruhig mit diesen Einstellungen, um unterschiedliche Ergebnisse zu erzielen. Sie können mit weiteren Einstellungen auf der imagemin-webp Plugin-Seite experimentieren.
Dieses Skript geht davon aus, dass alle Ihre JPEG- und PNG-Bilder in einem Ordner namens img liegen. Wenn das nicht der Fall ist, können Sie die Werte der Variablen PNGImages und JPEGImages ändern. Dieses Skript geht auch davon aus, dass die WebP-Ausgabe im img-Ordner erfolgen soll. Wenn Sie das nicht möchten, ändern Sie den Wert der Variablen outputFolder nach Bedarf. Wenn Sie bereit sind, führen Sie das Skript wie folgt aus:
node webp.js
Dadurch werden alle Bilder verarbeitet und ihre WebP-Gegenstücke im img-Ordner abgelegt. Die erzielten Vorteile hängen von den konvertierten Bildern ab. In meinem Fall wurde ein Ordner mit JPEGs im Gesamtwert von ca. 2,75 MB auf 1,04 MB reduziert, ohne wahrnehmbare Einbußen bei der visuellen Qualität. Das ist eine Reduzierung um 62 % ohne viel Aufwand! Jetzt, wo alle Ihre Bilder konvertiert sind, können Sie sie verwenden. Legen wir los und nutzen sie!
WebP in HTML verwenden
Ein WebP-Bild in HTML zu verwenden, ist wie jedes andere Bild, oder? Einfach das Ding in das src-Attribut des -Tags schmeißen und los geht's!
<!-- Nothing possibly can go wrong with this, right? -->
<img src="img/myAwesomeWebPImage.webp" alt="WebP rules.">
Das funktioniert gut, aber nur für Browser, die es unterstützen. Wehe den unglücklichen Nutzern, die an Ihrer Website vorbeikommen, wenn Sie nur WebP verwenden.

Es ist sicher nicht schön, aber so ist die Frontend-Entwicklung nun mal, also reiß dich zusammen. Manche Features funktionieren einfach nicht in jedem Browser, und das wird sich so schnell nicht ändern. Der einfachste Weg, das zum Laufen zu bringen, ist die Verwendung des -Elements, um eine Reihe von Fallbacks anzugeben, wie hier:
<picture>
<source srcset="img/awesomeWebPImage.webp" type="image/webp">
<source srcset="img/creakyOldJPEG.jpg" type="image/jpeg">
<img src="img/creakyOldJPEG.jpg" alt="Alt Text!">
</picture>
Das ist wahrscheinlich Ihre beste Wahl für die größtmögliche Kompatibilität, da es in jedem einzelnen Browser funktioniert, nicht nur in denen, die das Element unterstützen. Der Grund dafür ist, dass Browser, die es nicht unterstützen, einfach die im Tag angegebene Quelle anzeigen. Wenn Sie volle Unterstützung benötigen, können Sie jederzeit Scott Jehls super-cleveren Picturefill-Script einfügen.
WebP-Bilder in CSS verwenden
Die Sache wird komplizierter, wenn Sie WebP-Bilder in CSS verwenden müssen. Im Gegensatz zum -Element in HTML, das in allen Browsern elegant auf das -Element zurückfällt, bietet CSS keine eingebaute Lösung für Fallback-Bilder, die optimal ist. Lösungen wie mehrere Hintergründe laden in einigen Fällen beide Ressourcen herunter, was ein großes Optimierungs-No-Go ist. Die Lösung liegt in der Feature-Erkennung.
Modernizr ist eine bekannte Feature-Erkennungsbibliothek, die verfügbare Funktionen in Browsern erkennt. WebP-Unterstützung ist zufällig eine davon. Noch besser: Sie können einen benutzerdefinierten Modernizr-Build mit nur WebP-Erkennung unter https://modernizr.com/download erstellen, was es Ihnen ermöglicht, WebP-Unterstützung mit sehr geringem Overhead zu erkennen.
Wenn Sie diesen benutzerdefinierten Build über das <script> Tag zu Ihrer Website hinzufügen, fügt er automatisch eine von zwei Klassen zum <html> Element hinzu.
- Die
webpKlasse wird hinzugefügt, wenn der Browser WebP unterstützt. - Die
no-webpKlasse wird hinzugefügt, wenn der Browser WebP nicht unterstützt.
Mit diesen Klassen können Sie CSS verwenden, um Hintergrundbilder gemäß den Fähigkeiten eines Browsers zu laden, indem Sie die Klasse im Tag ansprechen.
.no-webp .elementWithBackgroundImage {
background-image: url("image.jpg");
}
.webp .elementWithBackgroundImage{
background-image: url("image.webp");
}
Das war's. Browser, die WebP nutzen können, erhalten WebP. Diejenigen, die es nicht können, greifen einfach auf unterstützte Bildtypen zurück. Eine Win-Win-Situation! Außer…
Was ist mit Nutzern mit deaktiviertem JavaScript?
Wenn Sie sich auf Modernizr verlassen, müssen Sie an die Benutzer denken, die JavaScript deaktiviert haben. Entschuldigung, aber so ist es nun mal. Wenn Sie Feature-Erkennung verwenden, die einige Ihrer Nutzer im Dunkeln lassen kann, müssen Sie mit deaktiviertem JavaScript testen. Mit den oben verwendeten Feature-Erkennungs-Klassen werden Browser ohne JavaScript nicht einmal ein Hintergrundbild anzeigen. Das liegt daran, dass das deaktivierte Skript nie die Erkennungsklassen zum <html> Element hinzufügt.
Um dies zu umgehen, fügen wir zunächst die Klasse no-js zum <html> Tag hinzu.
<html class="no-js">
Dann schreiben wir ein kleines Stück Inline-Skript, das wir vor allen anderen Skripten platzieren werden.
<script>
document.documentElement.classList.remove("no-js");
</script>
Dadurch wird die no-js Klasse vom <html> Element entfernt, wenn es geparst wird.
Was nützt uns das? Wenn JavaScript deaktiviert ist, wird dieses kleine Skript nie ausgeführt, sodass die no-js-Klasse auf dem Element bleibt. Das bedeutet, dass wir eine weitere Regel hinzufügen können, um einen Bildtyp bereitzustellen, der die breiteste Unterstützung hat.
.no-js .elementWithBackgroundImage {
background-image: url("image.jpg");
}
Damit decken wir alle Eventualitäten ab. Wenn JavaScript verfügbar ist, wird das Inline-Skript ausgeführt und entfernt die no-js-Klasse, bevor das CSS geparst wird, sodass das JPEG in einem WebP-fähigen Browser nie heruntergeladen wird. Wenn JavaScript tatsächlich deaktiviert ist, wird die Klasse nicht entfernt und das kompatiblere Bildformat verwendet.
Nachdem wir all dies getan haben, sind dies die zu erwartenden Anwendungsfälle:
- Diejenigen, die WebP verwenden können, erhalten WebP.
- Diejenigen, die WebP nicht verwenden können, erhalten PNG- oder JPEG-Bilder.
- Diejenigen mit deaktiviertem JavaScript erhalten PNG- oder JPEG-Bilder.
Klatschen Sie sich selbst auf die Schulter. Sie haben gerade gelernt, wie man WebP-Bilder progressiv verwendet.
Zum Abschluss
WebP ist ein vielseitiges Bildformat, das wir anstelle von PNG- und JPEG-Bildern bereitstellen können (wenn es unterstützt wird). Es kann zu einer erheblichen Reduzierung der Bildgröße auf Ihrer Website führen, und wie wir wissen, senkt alles, was zu weniger Datenübertragung führt, die Seitenladezeit.
Gibt es Nachteile? Ein paar. Der größte ist, dass Sie zwei Sätze von Bildern pflegen müssen, um die bestmögliche Unterstützung zu erreichen, was für Ihre Website möglicherweise nicht möglich ist, wenn eine riesige Menge an Bildern in WebP konvertiert werden muss. Eine weitere ist, dass Sie ein wenig JavaScript verwalten müssen, wenn Sie WebP-Bilder in CSS verwenden möchten. Eine weitere erwähnenswerte Sache ist, dass Benutzer, die Ihre Bilder auf ihre Festplatte speichern, möglicherweise kein Standardprogramm zum Anzeigen von WebP-Bildern haben.
Die Erkenntnis ist, dass der relativ geringe Aufwand die Ersparnisse wert ist, die Sie erzielen werden, Ersparnisse, die die Benutzererfahrung Ihrer Website verbessern, indem sie schneller lädt. Benutzer, die über mobile Netzwerke surfen, werden besonders davon profitieren. Jetzt gehen Sie vor und webp-en Sie nach Herzenslust!
Wäre es nicht möglich, @support zu verwenden, um das Standard-Hintergrundbild durch das WebP-Bild zu ersetzen, anstatt sich auf Modernizer zu verlassen?
Oder würde es erkennen, dass es unterstützt wird, und einfach das im url() angegebene Bild ignorieren?
Nein, @supports prüft nur, ob die CSS-Engine ein bestimmtes Eigenschaft/Wert-Paar unterstützt (und in einigen Fällen lügt sie sogar darüber).
Als ich versuchte, den Trick mit den mehreren Hintergründen anzuwenden, glaube ich, dass am Ende die WebP-Quelle trotzdem heruntergeladen wurde – und fehlgeschlagen ist. Es war also in gewisser Weise suboptimal. Ich müsste noch einmal nachsehen, aber es gab einen bestimmten Grund, warum ich diese Route nicht gewählt habe, als ich diesen Artikel ursprünglich im April auf meinem Blog geschrieben habe.
Danke fürs Lesen!
Stellen Sie außerdem sicher, dass der HTTP-Server WebP-Bilder unterstützt und korrekt image/webp als Inhaltstyp sendet.
Mir ist passiert, dass ich glücklich eine Website mit WebP-Bildern für Blink-basierte Browser entwickelt habe und beim Onlinegang nichts sehen konnte, weil sie als application/octet-stream ausgeliefert wurden.
Ja! Ich musste das selbst noch nicht tun, aber einige Konfigurationen erfordern es möglicherweise. Wenn Sie dies aus irgendeinem Grund in Apache tun müssten, sollte dies funktionieren.
Danke für den Hinweis! :)
Volle Offenlegung: Ich habe das geschrieben :)
Hier ist wie Sie Nginx verwenden können, um WebP- und JXR-Bilder für Microsoft Edge bereitzustellen. Auch wie man über Photoshop oder die Kommandozeile nach JXR konvertiert.
Es verwendet Content Negotiation, sodass Sie weiterhin normale Bild-Tags mit/ohne srcset verwenden können, und hat die ursprünglichen Lösungen für WebP-Bilder für Apache und Nginx, die Ilya Grigorik und Eugene Lazutkin entwickelt haben!
Wenn es jemandem hilft, habe ich ein WordPress-Plugin geschrieben, um die Konvertierung von Bildern in WebP während des Hochladens zu handhaben. Es lädt diese nicht im Frontend, Sie müssen dies in Ihrem Theme tun, aber es konvertiert alle Bilder, einschließlich benutzerdefinierter Bildgrößen.
https://github.com/randyjensen/rj-webp-converter
Ziemlich hilfreich! Aber seien Sie vorsichtig mit regulären Ausdrücken; sie können etwas knifflig sein. Sie sollten Instanzen von
/(.jpg|.png)/zu/\.(jpe?g|png)$/iumschreiben.— ein
.bedeutet nur „beliebiges Zeichen“, nicht unbedingt einen Punkt; Sie müssen es mit einem Backslash versehen, damit es buchstäblich genommen wird.—
jpe?gstimmt sowohl mitjpgals auch mitjpegüberein.— das
$stellt sicher, dass die Übereinstimmung nur am Ende erfolgt (andernfalls würdejpgofacat.jpgzuofacat.webwerden, wenn Siepreg_replaceausführen).— das
iam Ende macht es case-insensitiv.Ich empfehle auch, sich die nativen WebP-Funktionen von PHP anzusehen: http://php.net/manual/en/function.imagecreatefromwebp.php Sie sind nicht unbedingt so schnell wie die Ausführung von
cwebpvom Server aus, aberexec()ist eine unglaublich gefährliche PHP-Funktion, die aktiviert bleiben sollte, daher ist jede Chance, diese Abhängigkeit zu vermeiden, lohnenswert.Ausgezeichnete Punkte, Josh. Danke!
Ich habe seit über zwei Jahren nichts mehr mit diesem Plugin aktualisiert, daher denke ich, dass es ein guter Zeitpunkt ist, es noch einmal zu überdenken.
Ich übernehme keine Gewähr dafür, aber ich denke, Sie können den Zugriff auf andere Ordner im System einschränken, indem Sie die
open_basedirphp.ini-Direktive einstellen: http://php.net/manual/en/ini.core.php#ini.open-basedirSie könnten also immer noch einigermaßen sicher
execodershell_execverwenden, wenn Sie dies einstellen, aber verlassen Sie sich nicht auf mein Wort, testen Sie es aus. Ich deaktiviere beide Funktionen in meiner Konfiguration, nur zur Information.Ja, exec muss definitiv weg. Es sieht so aus, als ob http://php.net/manual/en/function.imagewebp.php das ist, was ich brauche. Dies wird es mir ermöglichen, die libwebp-Abhängigkeit zu entfernen und das Plugin in das offizielle WordPress-Repository aufzunehmen. Das passiert, wenn man eine Bibliothek 2 Jahre lang nicht anrührt.
open_basedir-Beschränkungen gelten nur für PHP.exec()geschieht außerhalb von PHP (deshalb ist es gefährlich). Diese Befehle unterliegen den üblichen Lese-/Schreib-/Ausführungsberechtigungsbeschränkungen des Dateisystems, aber das ist alles.Ein besserer Weg, PHP und System zu verbinden, sind die Funktionen der
proc-Familie (z. B. http://php.net/manual/en/function.proc-open.php). Hier ist PHP tatsächlich für den Start und die Verwaltung spezifischer Systemprozesse verantwortlich, sodassopen_basedir-Beschränkungen gelten. Anstatt die gesamte/usr/bin/oder Ähnliches auf die Whitelist zu setzen, können Sie einzelne Binärdateien wie/usr/bin/gpghinzufügen.procist die beste Lösung für einzelne Projekte oder PEAR/PECL-Pakete, ist aber für eine allgemeine WordPress-Funktion etwas zu viel. Natives PHP ist wahrscheinlich alles, was Sie in diesem Kontext durchbekommen. :)Hallo Jeremy – Haben Sie Daten, die darauf hindeuten, dass die Verwendung von WebP die Seitenladezeiten reduziert? Ich würde nicht davon ausgehen, dass dies der Fall ist, ohne es ausgiebig zu testen. WebP ist viel langsamer zu dekodieren als JPEG, daher bedeutet die Tatsache, dass die Bilder kleiner sind, nicht unbedingt, dass Sie schnellere Seitenladezeiten erzielen. Eine Webseite ist kein einheitlicher Datenblock, der mit einer einheitlichen Rate dekodiert und gerendert wird. Dies sind alles völlig unterschiedliche Formate mit unterschiedlichen Codecs. Ich habe versucht, reale WebP-Leistungsdaten von Google zu erhalten, aber bisher geben sie keine heraus. Es hat keinen Sinn, WebP zu verwenden, ohne detaillierte Leistungsdaten zu haben, die einen Vorteil zeigen, es sei denn, das Ziel ist einfach, Bandbreitenkosten unabhängig von der Seitenleistung zu senken.
Dekodierungszeiten sind trivial. Bei moderner Verarbeitung gibt es keinen Grund, warum die Dekodierung von Bildern, selbst von WebP-Bildern, so lange dauern sollte, dass eine erhebliche Reduzierung der über das Netz übertragenen Daten ein nutzloses Unterfangen wäre.
Ich habe in meinem Buch darüber geschrieben, und durch ein Beispiel konnte ich die Ladezeiten um etwa 20 % bis 35 % reduzieren, abhängig von der DPI des betreffenden Bildschirms. Wenn Sie an diesem Kapitel interessiert sind, kann ich Ihnen kostenlos eine Kopie zusenden, senden Sie mir einfach eine DM auf meinem Twitter-Account. Wenn nicht, lassen Sie mich wissen, wie Ihr Handle ist. Ich werde Ihnen folgen, damit Sie Kontakt aufnehmen können.
Der beste Weg, um reale Leistungsdaten zu erhalten, ist, diese selbst zu erstellen. In diesem Fall verwende ich auf meinem Blog WebP für alle Rasterbilder und würde es niemandem empfehlen, wenn ich nicht das Gefühl hätte, dass es nicht gut für die Leistung ist. Kann es zeitaufwendig sein, es für bestehende Inhalte zu implementieren? Sicher. Aber ich denke, das Ergebnis ist die Mühe wert, wenn Sie es rechtfertigen können.
Danke fürs Lesen!
Jeremy, dieser Teil scheint nicht ganz richtig zu sein.
„Dekodierungszeiten sind trivial. Bei moderner Verarbeitung gibt es keinen Grund, warum die Dekodierung von Bildern, selbst von WebP-Bildern, so lange dauern sollte, dass eine erhebliche Reduzierung der über das Netz übertragenen Daten ein nutzloses Unterfangen wäre.“
Wenn ich Sie richtig verstehe, sagen Sie, dass langsamere Dekodierung die kleinere Dateigröße in Bezug auf die kombinierte Zeit zum Herunterladen + Zeit zum Dekodieren/Rasterisieren nicht ausgleichen kann? Das wird definitiv nicht für alle Arten von Formaten und Szenarien gelten. Wenn dies ein weit verbreiteter Glaube ist, müssen wir die Leute aufklären. Die grundlegende Mathematik wird ähnlich sein wie das, was Cloudflare hier beim Analysieren von Brotli gepostet hat: https://blog.cloudflare.com/results-experimenting-brotli/
Wenn wir die Client-Seite betrachten, ist die Mathematik: Downloadzeit + Dekodierungszeit. Wenn die Basis ein 100 KiB JPEG ist, das 10 ms zum Dekodieren benötigt, wären es bei einer 10-Mibit/Sek.-Verbindung 80 ms zum Herunterladen + 10 ms zur Dekodierung = 90 ms insgesamt.
Wenn wir stattdessen ein WebP servieren, sagen wir, es ist jetzt nur 60 KiB groß, aber es dauert fünfmal so lange zum Dekodieren, dann sind es 48 ms Download + 50 ms zur Dekodierung = 98 ms insgesamt.
Ein solches Ergebnis kann leicht bei allen Arten von Codec-Änderungen auftreten. Wenn wir zum Beispiel von Gzip auf XZ wechseln würden (für alle Textdateien), hätten wir kleinere Downloadgrößen, aber die langsamere Dekompression würde die Download-Einsparungen leicht überwiegen, weshalb wir es nicht tun. WebP ist viel langsamer zu dekodieren als JPEG und PNG. Wie viel langsamer ist ein Rätsel, da Google keine gültigen Daten veröffentlicht. Tencent berichtet, dass es 4- oder 5-mal langsamer als PNG ist: https://isux.tencent.com/introduction-of-webp.html Beachten Sie, dass PNG auf fast jedem Gerät langsamer ist als JPEG (JPEG ist im Grunde Magie, und viele Geräte verfügen über hardwarebeschleunigte JPEG-Dekodierung oder sogar dedizierte „Fixed-Function“-JPEG-Decoder-Chips.
Da sie das Format bewerben und über so viele Ressourcen und Geldmittel verfügen, erwarte ich von Google, dass es das WebP-Format vollständig dokumentiert und aussagekräftige, valide Leistungsdaten liefert. Es ist sehr seltsam, dass sie sich geweigert haben, dies zu tun. WebP hat nicht einmal eine Spezifikation oder einen Standard, und es ist zu diesem Zeitpunkt ziemlich fehleranfällig. Es ist riskant, wertvolle Assets in ein Format zu stecken, das keine Spezifikation hat und bei dem eine neue Decoder-Version Dateien zerstören kann, die mit einer früheren Version kodiert wurden (das ist letztes Jahr mit WebP passiert). Es ist auch gut möglich, dass WebP die Ladezeit von Seiten verlangsamt – dass es so viel langsamer zu dekodieren ist, dass es die Komprimierungseinsparungen aufwiegt. Dies scheint bei ihren verlustbehafteten Modi wahrscheinlicher als bei ihren verlustfreien, aber niemand scheint es sicher zu wissen. Es gab einen Thread hier in der WebP-Liste, in dem ich die "Beweise" überprüfte, die Google vorzulegen versuchte (die Tencent-Studie von oben war die einzige Leistungsdatensatz in all ihren Links): https://groups.google.com/a/webmproject.org/forum/#!searchin/webp-discuss/useful$20performance$20data/webp-discuss/4r6frraRtkg/nNdTEitlMwAJ
Die Leute sollten Dinge nicht einfach benutzen, weil Google es ihnen sagt. Sie müssen Beweise liefern, und sie sollten aufhören, MozJPEG im ganzen Web so gruselig schlecht zu machen. Ihr Verhalten ist im Moment seltsam (https://blog.cloudflare.com/experimenting-with-mozjpeg-2-0/ https://medium.com/@duhroach/reducing-jpg-file-size-e5b27df3257c#.oj7an6ffs)
Hier ist, was ich bei meiner Analyse herausgefunden habe, wie Chrome zu reagieren scheint, wenn ich WebP verwende, und bedenken Sie, dies ist ein Testfall und keinesfalls erschöpfend.
Ich habe zwei Bilder auf einem Server
https://jeremywagner.me/img/global/stpaul-2x.jpg
https://jeremywagner.me/img/global/stpaul-2x.webp
Beide Bilder sind eine Aufnahme von Downtown Saint Paul (weil Minnesota). Die Quelle ist ein JPEG, das ich auf Google Bilder gefunden habe. Es wiegt 126 KB, und das, nachdem das JPEG mit imagemin-jpeg-recompress bearbeitet wurde. Die WebP-Version ist ein verlustbehaftetes WebP mit einer Qualitätseinstellung von 65 und wiegt 59,8 KB. Diese Zahlen stammen aus dem Netzwerk-Panel von Chrome, sodass sie angeblich die HTTP-Header in der endgültigen Größe enthalten. Diese Bilder sind in Bezug auf die visuelle Qualität ziemlich vergleichbar.
Lassen Sie uns also über die Dekodierungszeit sprechen. Wir können uns um Dekodierungszeiten drehen und wenden und wie trivial/wichtig sie sind. Für mich ist es trivial. Denn sobald ich ein alternatives Bildformat zur Hand habe und weiß, dass es vernünftigerweise kleiner ist, interessiert mich nur noch, wie lange der Browser braucht, um das Bild zu malen. Mit dem Timeline-Tool von Chrome sehe ich hier die Erstmal-Mal-Zeiten mit dem "Good 3G" Netzwerk-Drosselungsprofil von Google Chrome (1,5 Mbit/s) über zehn Versuche für jeden Bildtyp (mit deaktiviertem Cache).
JPEG: 455,85 ms
WebP: 320,63 ms
Dies ist eine Verbesserung von etwa 30 %. Natürlich ist dieser Test für ein einzelnes Bild, das direkt außerhalb des Kontexts einer Webseite aufgerufen wird. Aber ich denke, es ist eine einigermaßen gute Demonstration, dass die Dekodierungszeit einfach kein großer Faktor ist. Denken Sie daran, dass die Quelle Ihrer Dekodierungszeitdaten aus dem Jahr 2014 stammt – Browser-Interna können sich in zwei Jahren stark ändern. Wenn diese Zahlen heute noch korrekt sind, nimmt ihre Auswirkung mit langsameren Verbindungen ab. Internetinfrastruktur und Konnektivitätsqualität sind in Entwicklungsländern immer noch ein Problem. Wenn ich auf Geschwindigkeit teste, teste ich, wie Menschen mit den langsamsten Verbindungen betroffen sein könnten. Daher teste ich routinemäßig auf 2G- und 3G-Simulationen.
WebP ist kein Allheilmittel. Ebenso wenig wie JPEG, GIF, SVG oder PNG. Wir haben all diese verschiedenen Formate, und sie eignen sich für alle Arten von Inhalten. Es gibt einige Fälle, in denen ich PNGs verlustfrei nach WebP kodiert habe, und das WebP-Format ist tatsächlich größer. In diesen Fällen verwerfe ich sie und verwende das PNG-Bild. Meistens, wenn ich WebP verwende, ist das Ergebnis vergleichbare Bildqualität in einer deutlich kleineren Bilddatei. FWIW, ich arbeite nicht für Google und bin ihnen nicht verpflichtet. Ich denke, WebP ist ein großartiges Konkurrenzformat, und ich werde es empfehlen, wo es sinnvoll ist.
WebP kann unter realen Bedingungen wie einem CMS, wo der durchschnittliche Benutzer keinerlei Zeit mit der Optimierung von Grafiken für das Web verbringt, erstaunliche Auswirkungen auf die Ladezeiten haben. Ich habe kürzlich die WordPress-Site eines Kunden aktualisiert, um automatisch WebP-Bilder aus den hochgeladenen Quellen zu generieren und alles in ein
<picture>-Element eingepackt bereitzustellen (auch Hintergründe, mitobject-fitund einem Polyfill). Bei rund 4000 vorhandenen Bildern, einer Mischung aus JPEG, PNG und GIF, waren die WebP-Gegenstücke (generiert nur mit dem Flag-jpeg_like) 59 % kleiner. (Der Server komprimierte bereits verlustfrei die hochgeladenen Bilder, mit durchschnittlichen Einsparungen von etwa 10-15 % für JPEGs und 50-75 % für PNGs; die 59 % WebP-Zahl liegt zusätzlich dazu).Dies erhöhte natürlich die Dokumentengrößen etwas aufgrund des zusätzlichen
<picture>-Markups und desobject-fit-Polyfills, aber Gzip und HTTP/2-Optimierungen machen Text zu einer ziemlich kleinen Sache. Es gab auch zusätzlichen E/A-Overhead aufgrund der Dateisystemprüfungen auf WebP-Schwesterbilder (insbesondere bei srcsets, da es so viele Quellen mehr zu prüfen gibt), was die Kompilierungszeiten des Dokuments erhöhte. Aber selbst dann waren die Seitenladezeiten im Durchschnitt etwa 40 % schneller. Die WebP-Einsparungen übertrafen die Dokumentenaufblähung und E/A erheblich, so dass je mehr Bilder auf einer Seite waren, desto höher waren die Einsparungen.Niemand hat von Dekodierungsverzögerungen berichtet. Ich vermute, dass Maschinen, die dafür anfällig sind, sowieso keine unterstützten Browser ausführen werden.
@Josh
„(Der Server komprimierte bereits verlustfrei die hochgeladenen Bilder, mit durchschnittlichen Einsparungen von etwa 10-15 % für JPEGs und 50-75 % für PNGs; die 59 % WebP-Zahl liegt zusätzlich dazu).“
Diese Aussage wirft viele Fragen auf. Erstens gibt es keine verlustfreie Komprimierung von JPEGs. Ein JPEG ist immer verlustbehaftet. Selbst wenn Sie eines öffnen und ohne Änderungen speichern, ist es verlustbehaftet. Ich nehme an, Sie meinen, dass sie ohne sofortigen visuellen Qualitätsverlust komprimiert wurden, aber das ist nicht dasselbe wie verlustfrei. Es ist nur eine "sichere" Komprimierungsstufe.
Wenn ich weiter lese, ist meine Interpretation, dass Sie dann eine zusätzliche Einsparung von 59 % durch die Verwendung von WebP erzielt haben, zusätzlich zu JPEGs, die zu 15-20 % komprimiert wurden. Das kann vieles bedeuten.
Erstens kann die sogenannte "verlustfreie" Komprimierung von JPEGs bedeuten, dass sie überhaupt nicht gut komprimiert waren. Es könnte also bedeuten, dass Sie, wenn Sie die JPEG-Qualitätseinstellung auf 60-70 % (den Sweetspot) eingestellt hätten, tatsächlich bis zu 70 % Dateigröße einsparen könnten. In diesem Fall würden Sie das JPEG-Format bis an seine Grenzen treiben.
Ich glaube nicht, dass Sie es geschafft haben, darüber hinaus zusätzliche 59 % Einsparungen zu erzielen. WebP im Vergleich zur maximal nutzbaren JPEG-Komprimierung führt sicherlich nicht zu 59 % Gesamteinsparungen. Was Sie stattdessen geschafft haben, ist, 59 % eines JPEGs zu sparen, das kaum komprimiert war, was kein fairer Vergleich ist.
Ich sollte meinen letzten Kommentar ergänzen, um festzuhalten, dass E/A-bezogene Verzögerungen, sei es bei der erstmaligen Generierung der Bilder oder bei der Prüfung, ob sie existieren, stark vom Server abhängen. Ich würde keine platten- oder datenbankintensiven Optimierungen auf einem Shared-Hosting-Account ohne ernsthaften Cache versuchen, da die Chancen gut stehen, dass dieser bereits genug zu tun hat, um das einfache Theme darzustellen.
@Ferdy,
Die JPEG-Komprimierung besteht in diesem Fall fast ausschließlich aus dem Entfernen von Metadaten aus dem Bild (d. h. den Nicht-Bild-Teilen). Endbenutzer laden tendenziell Bilder direkt von der Kamera hoch, sozusagen, ohne jeglichen Aufwand vor dem Hochladen, um web-geeignetere Versionen zu erstellen. Metadaten haben zwar ihren Nutzen, aber für diese spezielle Website sind sie bestenfalls aufgebläht und schlimmstenfalls ein Sicherheitsrisiko, sodass der Server das tut, was der Benutzer nicht tut, und sie entfernt. Die relativen prozentualen Einsparungen durch diesen Vorgang hängen vom Verhältnis Metadaten:Bilddaten ab. Selbst eine sehr detailverliebte Person wird bei einem hochauflösenden Foto nicht viel relativ einsparen können, aber ein billiges, niedrigauflösendes Stockfoto von Getty? Die Metadaten machen einen größeren Prozentsatz der ursprünglichen Dateigröße aus. Die spezielle Website, die ich erwähnt habe, tendiert dazu, Bilder irgendwo zwischen den beiden Extremen hochzuladen, sodass das Entfernen von Metadaten im Durchschnitt etwa 10-15 % spart.
Aber Sie irren sich, wenn Sie sagen, dass das JPEG-Containerformat keinen Raum für verlustfreie Komprimierung lässt. Es stimmt, dass es nicht viel Spielraum gibt, aber es gibt dennoch Spielraum. Es gibt Tools wie jpegrescan, die zusätzliche 1-2 % Einsparungen erzielen können. Manchmal gibt es auch Raum für Verbesserungen, indem ein JPEG progressiv gemacht wird (wenn nichts anderes, dann haben sie eine freundlichere Anzeige beim Dekodieren).
Zu Ihrem anderen Kommentar, dass die Bilder anfangs nicht gut komprimiert waren: Natürlich waren sie das nicht. Wir sind uns zu 100 % einig. Ich habe den Ausdruck "reale Bedingungen" verwendet, um die reale Welt zu beschreiben. Der durchschnittliche Computerbenutzer hat kein Verständnis für die Unterschiede zwischen JPEG und PNG, geschweige denn für die Konfigurationsoptionen, die in jedem einzelnen Format eingebettet sind. Verlustfreie Komprimierung kann nur die Kodierung dessen optimieren, was bereits vorhanden ist; sie kann niemals mit dem Speichern eines Bildes mit geeigneten Konfigurationen von Anfang an konkurrieren. ;)
Um zu wiederholen, die in meinem Beitrag erwähnten Bilder waren solche, die bereits vorhanden waren, vom Kunden hochgeladen (plus die verschiedenen Thumbnails, die vom CMS generiert wurden) und von einem automatisierten Serverprozess verlustfrei bereinigt. In diesem "Realworld"-Anwendungsfall erzeugten die Dateien, die mit dem Flag
-jpeg_likeauf demcwebp-Binärprogramm erzeugt wurden (diesmal verlustbehaftet), Dateien, die 59 % kleiner waren als die komprimierte Quelle. Die WebP- und Quellgrafiken sind nicht 100% identisch aussehend. WebP hat einen leichten Glanz über bestimmten Texturtypen, den man erkennen kann, wenn man zwei Versionen nebeneinander sieht. Aber die Effekte berücksichtigen die Menschen und werden daher nicht so verwendet, dass wir sie wahrscheinlich bemerken würden, wenn wir keinen Vergleich hätten.Ich wollte nicht andeuten, dass WebP immer 59 % Einsparungen erzielt, nur dass es sogar noch besser abschneiden kann als andere, die es erwähnten, wenn man mit einer gängigeren (d. h. schlechteren) Quelle beginnt. Ich habe eine ähnliche WebP-Lösung auf einer meiner eigenen Websites implementiert, aber das Quellmaterial war von Anfang an besser optimiert, nur JPEG, und die Bilder waren qualitativ anders als die, die vom Kunden verwendet wurden (halftone-gefilterte fotografische Inhalte... ein Killer sowohl für WebP- als auch für WebM-Optimierung), sodass ich nur etwa 10 % einsparen konnte. Haha.
@Josh
59% erscheinen mir realistisch für unoptimierte Quellbilder.
Meinen Sie mit "verlustfrei" so etwas wie die Option "-quality 100" von imagemagick convert? Dies könnte die Quellgröße tatsächlich erhöhen... Oder war es eher wie "-quality 75" (kein großer visueller Unterschied)? (unter Berücksichtigung, dass jede App ihre eigene Qualitätsskala definieren kann, daher ist die Bedeutung von "Qualität 75" in GIMP, Photoshop, ImageMagick, ... unterschiedlich)
@Ferdy
Tatsächlich scheint es das zu geben: convert's "-quality 0" oder "-quality 100". Ich verstehe den Unterschied nicht wirklich. 100 erhöht normalerweise die Dateigröße; 0 scheint mir verlustfrei zu sein, reduziert die Dateigröße bei hochwertigen Bildern, erhöht die Größe von zuvor heruntergerechneten Bildern (-quality 35); 1 ist die schlechteste Qualitätseinstellung für JPG in ImageMagick.
@Valentin,
Nein, ich beziehe mich nicht auf die Qualitätseinstellung des JPEGs. Das fällt unter "verlustbehaftet", auch wenn das Endergebnis buchstäblich größer ist (wie bei der Konvertierung von 85 auf 100). Obwohl, wie @Ferdy und ich diskutierten, das Experimentieren mit einer JPEG-Qualitätseinstellung das Wichtigste ist, was man zur Web-Optimierung tun kann. Aber für WordPress im Besonderen ist die Qualitätseinstellung der Quellgrafik zweitrangig, da die Website normalerweise nur die automatisch generierten Thumbnails an die Besucher liefert, die mit einer bestimmten Qualität gespeichert werden und keinen wirklichen Nutzen aus der Festplattengröße der Quelle ziehen. Der einzige wirkliche Vorteil für WP beim Hochladen einer optimierten Quelle ist, dass es die Thumbnails schneller generieren kann.
Für verlustfreie JPEG-Komprimierung verwende ich zwei Programme: jpegoptim und jpegrescan.
jpegoptim entfernt Metadaten und macht das JPEG progressiv. Metadaten sind oft die größten Einsparungen, da Bildprogramme, Kameras und dergleichen dort viele Daten einfügen können. Progressivität kann auch zu einigen Dateigrößenersparnissen führen, wenn auch nicht immer.
jpegrescan sucht nach Ineffizienzen in der tatsächlichen Komprimierung und nimmt Verbesserungen vor, wo es kann. Seine Auswirkung hängt vom Programm ab, das das Bild ursprünglich gespeichert hat.
Guter Artikel, aber ich denke, er überspringt den wichtigsten Teil, nämlich Einsparungen vs. Qualität. Das Beispiel des kleinen Thumbnails ist sehr vorteilhaft für WebP, tatsächlich ist die Größe kleiner und man kann keinen wirklichen Unterschied erkennen.
Es ist jedoch ein Fehler, dies als Schlussfolgerung zu nehmen, dass man immer versuchen sollte, alle Bilder als WebP zu servieren, wo immer möglich, was impliziert wird.
Wenn man sich zum Beispiel größere Bildgrößen ansieht, werden Qualitätsunterschiede viel sichtbarer, ebenso wie Größenunterschiede. WebP schneidet bei großen Bildern tendenziell gut ab, hat aber auch riesige Probleme, wie z. B. die aggressive Glättung der Haut auf Personenbildern.
Nicht direkt an den Autor des Artikels gerichtet, aber die allgemeine Schlussfolgerung, die ich überall lese, dass WebP grob 30 % kleiner ist, ist absolut kein Minimum, sondern eher ein Maximum. Das Gleiche gilt für die Schlussfolgerung, dass sie ähnliche Qualität bieten; dies hängt stark vom tatsächlichen Inhalt ab.
In vielen Fällen ist der Vorteil also weitaus geringer als 30 %, was mich fragen lässt... warum sich die Mühe machen? Ich bin nicht gegen WebP, ich halte es nur für überbewertet.
Was ist mit WebPJS passiert? https://webpjs.appspot.com/ Es scheint verlassen zu sein. Gibt es noch eine bessere WebP JavaScript-Implementierung?
@Josh: Danke, das hat viel geklärt. Also, um Ihren Prozess zusammenzufassen
Benutzer lädt Original hoch (mit EXIF/Meta und typischerweise unkomprimiert)
Automatischer Prozess entfernt Metadaten und spart 15-20 %
Sie führen eine verlustbehaftete WebP-Komprimierung durch und sparen zusätzlich 59 %
Klingt gut, besonders wenn die Qualität des Ergebnisses akzeptabel ist. Aber es bleibt die Frage offen: Was wäre, wenn Schritt 3 eine verlustbehaftete JPEG-Komprimierung gewesen wäre? Wie viel hätten Sie dann gespart? Wäre es mehr oder weniger als 59 %, und was würde das bei verschiedenen Komprimierungsstufen für die visuelle Qualität bedeuten?
Sie müssen das nicht beantworten, aber ich denke, das ist die wahre Frage der WebP- vs. JPEG-Komprimierung. Und um die Sache noch komplizierter zu machen, stimmt es, dass die Art des Inhalts eine Rolle spielt :)
Ein Bild korrekt für das Web zu speichern ist eine gute Idee, aber es gibt nicht wirklich eine magische Qualitätseinstellung; es hängt stark vom subjektiven Auge und dem Inhalt des Bildes ab. Bilder mit scharfen kontrastierenden Farben können selbst bei 95 % wahrnehmbare Artefakte aufweisen (es sei denn, Sie deaktivieren die Chroma-Subsampling), während eine Wüstenlandschaft bei nur 50 % völlig in Ordnung sein kann. Alle ausgefallenen Bildtechniken, die bei diesem speziellen Projekt eingesetzt werden, sind solche, die gefahrlos unbeaufsichtigt ausgeführt werden können.
WordPress verwendet standardmäßig eine Qualitätseinstellung von 85 %, wenn Miniaturen erstellt werden. Das scheint ein guter Ausgangspunkt für die meisten Bildtypen zu sein. Die meisten Themes sollten benutzerdefinierte Thumbnail-Größen überall auf einer Website verwenden, in welchem Fall der Besucher immer von verlustbehafteter Komprimierung profitiert, unabhängig davon, was der Benutzer ursprünglich hochgeladen hat.
Aber ein Bereich, in dem diese Praxis scheinbar ignoriert wird, sind Situationen, in denen ein Bild sich unendlich ausdehnen muss, um einen Bereich abzudecken, wie z. B. einen großen Hero. Gutes altes
background-cover. Tatsächlich war der Austausch von CSS-Hintergründen durch responsiveobject-fit<picture>-Elemente auf der Website meines Kunden der größte Einfluss auf die Gesamtgröße der Seite. Dies wäre auch ohne WebP in diesem Teil der Fall gewesen, obwohl WebP es noch etwas weiter vorangetrieben hat. Das Markup ist etwas lästig und ein Polyfill musste neu geschrieben und getestet werden, aber die Auszahlung war es wert.@Josh.
Es ist absolut richtig, dass der Inhalt des Bildes bestimmt, mit welcher Qualitätseinstellung man davonkommt. Bei der Arbeit hatten wir jedoch nicht die Luxusoption, dies pro Bild zu tun, daher waren wir gezwungen, eine allgemeine Qualitätseinstellung festzulegen. Durch ausgiebige Tests an großen Bildersammlungen konnten wir diese auf 60-65 % senken. Das ist genau am absoluten Knackpunkt von Artefakten. Beachten Sie, dass die Bildtypen Fotografien von Menschen waren, die das Produkt verwenden. Dennoch verwenden wir diese ziemlich niedrige Qualitätseinstellung auch bei großen Masthead-Bildern ohne Beschwerden. Wenn man sich die Diagramme der JPEG-Qualitätseinstellung im Verhältnis zur Dateigröße ansieht, ist 60 % ziemlich optimal. Beachten Sie, dass diese Kurve weit davon entfernt ist, linear zu sein.
In diesem Licht betrachte ich 85 % als sehr konservativ. Besonders für Thumbnails, je nach Größe, wo man sogar mit unter 60 % experimentieren kann, da Artefakte oft zu klein sind, um sie zu bemerken.
Schließlich möchte ich auf eine Technik hinweisen, die ziemlich unterschätzt wird.
https://www.netvlies.nl/tips-updates/design-interactie/retina-revolution
Diese Technik verwendet sehr große Bilder (in Bezug auf die Auflösung) und komprimiert sie dann sehr stark. Anschließend lässt sie den Browser das Bild in der Größe ändern. Der Vorteil ist, dass in vielen Fällen ein einzelnes Bild für alle bereitgestellt werden kann, Retina-Unterstützung ohne Erhöhung der Dateigröße. Das Beste aus allen Welten?
Hauptkritikpunkt ist, dass dies zu einer Erhöhung des Speicherverbrauchs führt, wenn diese größeren als benötigten Bilder auf dem Client dekodiert werden. In der Praxis habe ich festgestellt, dass diese Behauptung keine wirklichen Probleme verursacht, da ich diese Technik seit Jahren auf einer meiner Websites verwende.
Wie wäre es mit dem Google Pagespeed Modul, um nur dann nach WebP zu konvertieren, wenn der Browser es unterstützt? :)
https://developers.google.com/speed/pagespeed/module/filter-image-optimize
@Jeremy, diese Zahlen sehen gut aus. Wenn Sie sagen: "Sobald ich ein alternatives Bildformat zur Hand habe und weiß, dass es vernünftigerweise kleiner ist, interessiert mich nur noch, wie lange der Browser braucht, um das Bild zu malen", dann ist das dem, was mich interessiert, sehr ähnlich. Sie haben es gegen die Dekodierungszeit gestellt, aber ich würde das alles zusammenfassen, daher hätte ich das klarstellen sollen.
Für mich ist das Endergebnis die Renderzeit der Seite, einschließlich aller Bilder, die wir rendern müssen. Mein einziger Einwand gegen Ihre Metrik ist, dass es mir nicht so sehr darum geht, wie lange der Browser braucht, um das Bild *zu beginnen*, sondern wie lange er braucht, um alle zu rendern und die Seite insgesamt fertig zu rendern. Das eine mag ein guter Stellvertreter für das andere sein – ich bin mir nicht sicher.
Die Tencent-Daten stammen aus dem Jahr 2014, aber die Google-Daten sind noch älter – 4 und 5 Jahre alt. Ich bin verblüfft, warum Google keine gültigen Daten veröffentlicht, und ich war schockiert über die Beweise, die sie vorzulegen versuchten, als ich nach Daten fragte (nur eine Menge CDN-Puff-Stücke, die nur über Dateigrößen sprachen), daher bin ich vielleicht voreingenommen von meiner Verärgerung über sie. WebP macht mich auch nervös, weil es keine Spezifikation gibt und Googles Entwicklungs- und Testprozess lässig und unsystematisch zu sein scheint – schlechte Bugs treten zufällig auf, sie veröffentlichen keine automatisierten Test-Suiten mit guten Testbildern. Im weiteren Sinne haben ihre Projekte normalerweise eine Mac-Monokultur, und sie testen am Ende nicht genug auf Windows-Rechnern, daher erwarte ich Überraschungen, wenn es um WebP und Windows geht. Die Tatsache, dass ihre verlustbehaftete Konvertierung und API so schlecht dokumentiert sind, macht mich vorsichtig, Assets in WebP zu konvertieren, selbst wenn die JPEGs und TIFFs *noch* existieren sollten – ich mag keine Assets in zwielichtigen Formaten haben.
Ein gesundes Maß an Skepsis ist gut, und ich weiß, dass dies ein Pro-WebP-Artikel ist, aber das resultiert aus meinem Erfolg bei der Anwendung. Wenn ein WebP-Bild erheblich kleiner ist als sein JPEG- oder PNG-Äquivalent, erhält es einen Vorsprung beim Malen, lange bevor die herkömmlichen Formate geladen werden, was meiner Erfahrung nach jeden Nachteil bei der Dekodierung ausgleicht. Dies gilt insbesondere für sehr langsame Verbindungen, wie sie in Entwicklungsländern zu finden sind. Apropos, WebP kann ein Vermögenswert für Internetnutzer sein, die auf begrenzte Datentarife angewiesen sind, sodass Geschwindigkeit nicht unbedingt der einzige Aspekt ist, der unsere Aufmerksamkeit wert ist.
Ich stimme zu, dass Google einige offizielle Metriken zu seiner Leistung bereitstellen *sollte*, aber andererseits ist das Format auch für jedermann frei verfügbar. Jeder, der bereit ist zu experimentieren, kann seine eigenen Schlussfolgerungen ziehen, vorausgesetzt, er verfügt über das Wissen und die Fähigkeit, rigoros zu testen (was ich freilich für unerfahrenere Entwickler eine Hürde sein kann.) Was Windows betrifft, bin ich auf keine Probleme in Bezug auf WebP gestoßen. Ich entwickle meine Nebenprojekte zu Hause auf einem Macbook Pro und benutze bei der Arbeit einen Windows-Rechner, sodass ich täglich eine gute Balance zwischen den beiden Umgebungen habe.
Darüber hinaus ist libwebp auch Open Source: https://chromium.googlesource.com/webm/libwebp Soweit ich sehen kann, ist der Encoder- und Decoder-Quellcode zur Durchsicht verfügbar. Ich glaube nicht unbedingt, dass sie unverhüllt ausweichend sind. Ich schreibe nicht beruflich C oder C++, daher kann ich nicht jeden Winkel des Quellcodes erklären, aber es ist nicht so, als würde Google WebP wie Soylent Green anbieten. Wahrscheinlicher (zumindest für mich) ist, dass sie zu jeder Zeit eine Reihe von hochkarätigen Projekten haben und WebP auf ihrer Prioritätenliste niedrig steht.
Es gibt auch eine Container-Spezifikation für WebP unter https://developers.google.com/speed/webp/docs/riff_container, die Sie interessieren könnte. Obwohl, wenn Sie Google ausreichend genervt haben, kann ich mir nicht vorstellen, dass sie Ihnen das nicht geschickt haben, also ist diese Spezifikation vielleicht nicht zu Ihrer Zufriedenheit.
Ich hoffe, das hilft. Danke, dass Sie meine Behauptungen in Frage gestellt haben. Ich denke, das Hin und Her bietet einige gute Lesestoff außerhalb des Rahmens des Artikels. :)
-j
@Ferdy, JPEGs können verlustfrei komprimiert werden. Die Tatsache, dass JPEG ein verlustbehaftetes Format ist, bedeutet nicht, dass jedes gegebene JPEG nicht verlustfrei komprimiert werden kann (über seine vorherige verlustbehaftete Komprimierung oder Erstellung hinaus). Abgesehen von den Metadaten können die Quantisierungstabellen optimiert werden, und das ist eine der Dinge, die MozJPEG tut. Es geht normalerweise darum, die vorhandene Kodierung (die verlustbehaftet war) zu nehmen und Wege zu finden, diese Kodierung zu optimieren.
@Josh, die E/A-bezogene Verzögerung könnte das größte Problem bei der Verwendung von WebP sein, laut diesen Daten aus einem Smashing-Artikel: http://mattshull.com/webptests.pdf
Ich war überrascht zu sehen, dass die iPhone-Zeiten nur durch die Verwendung von WebP für *andere* Browser schlechter wurden. Für das iPhone hätte sich nichts ändern dürfen, da es in den Tests C und D immer noch JPEGs erhielt (weil Safari WebP nicht unterstützt). Es könnte eine htaccess-bezogene Verzögerung gewesen sein. Ich denke, ein wichtiges Problem geht verloren, wenn Leute über WebP und andere verbesserte Komprimierungsformate sprechen. Die Einführung eines neuen Formats verändert nicht nur das Verhalten des Browsers – es verändert das Verhalten des Servers. Es fügt dem Server Code, Logik und Komplexität hinzu und möglicherweise Verzögerungszeit. Die meisten dieser Verzögerungen sollten beseitigt werden können, aber standardmäßig scheint es, dass Apache WebP-Dateien für einige Browser und JPEGs für andere bereitstellt, was die Dinge wirklich verlangsamt hat. Dies erfordert mehr Nachforschung und Recherche.
Wie Sie erwähnt haben, gibt es viel Spielraum für JPEG-Optimierung. Es ist mir nicht klar, dass WebP-äquivalente Größenreduktionen nicht durch die Verwendung besserer JPEG-Tools wie JPEG-Recompress und JPEGMin erzielt werden können, die beide den Smallfry-Algorithmus zu verwenden scheinen (siehe: https://github.com/danielgtaylor/jpeg-archive)
@Jeremy, wenn ich versuche, das imagemin-webp-Plugin mit node webp.js auszuführen, erhalte ich folgende Fehlermeldung
C:\work\webp\webp.js:7
new imagemin().src(PNGImages).dest(outputFolder).use(webp({
^
TypeError: (input, output, opts) => {
if (!Array.isArray(input)) {
return Promise.reject(new TypeError(‘Expected an arr……
} ist kein Konstruktor
at Object. (C:\work\webp\webp.js:7:1)
at Module._compile (module.js:409:26)
at Object.Module._extensions..js (module.js:416:10)
at Module.load (module.js:343:32)
at Function.Module._load (module.js:300:12)
at Function.Module.runMain (module.js:441:10)
at startup (node.js:139:18)
at node.js:974:3
Haben Sie eine Idee, was das Problem ist?
Dave, es tut mir leid! Ich habe das gesehen, wurde aber abgelenkt. Wenn Sie das noch nicht herausgefunden haben, senden Sie mir einfach eine E-Mail an [email protected] oder nerven Sie mich auf Twitter @malchata und senden Sie mir Ihren Code. Ich werde ihn mir ansehen. Mir scheint, dass es etwas Einfaches ist, das übersehen wird.
Danke fürs Lesen, Mann. :)
Hallo Jeremy. Danke für den Artikel, er ist ziemlich gut. Ich benutze bereits Webp-Bilder in meinen Projekten und sehe ein Problem bei der Verwendung von Webp als Hintergrund. Zum Beispiel habe ich header.png für .no-js und .no-webp und header.webp für .webp Klassen des HTML-Tags. Zuerst dachte ich, dass der Bild-Download genau so funktioniert, wie in deinem Artikel beschrieben, aber dann habe ich die Seite über mobiles Internet überprüft und bemerkt, dass Hintergrundbilder zweimal heruntergeladen werden – zuerst eine PNG-Version und danach Webp. Ich habe den Netzwerk-Tab in meinen Entwicklertools überprüft und meine Vermutung bestätigt – es wurden zwei Hintergrundbilder heruntergeladen. PNG beginnt als Hintergrund für .no-js herunterzuladen, dann wird die Klasse .webp zum HTML-Tag hinzugefügt und das Webp-Bild beginnt erneut herunterzuladen. Gibt es also vielleicht eine Problemumgehung / eine andere Möglichkeit, Webp als Hintergrund von CSS zu verwenden?