WebP vs PNG vs JPEG im Jahr 2026: Der Formatkrieg ist vorbei
Ich habe 5.000 Bilder in allen drei Formaten bei 12 Qualitätsstufen komprimiert. Die Unterschiede in der Dateigröße sind kleiner, als Sie denken. Die Qualitätsunterschiede sind größer. Nach drei Jahren der Optimierung von Bildern für über 200 Websites habe ich jede mögliche Kombination von Format, Qualitätseinstellung und Anwendungsfall gesehen. Ich habe debuggt, warum das Hero-Bild eines Kunden auf Mobilgeräten "verschwommen" aussah. Ich habe unzähligen Entwicklern erklärt, warum ihre PNG-Screenshots langsamer luden als ihre JPEG-Fotos. Und ich habe der Web-Performance-Community zugesehen, wie sie endlos darüber streitet, welches Format "am besten" ist, während sie die tatsächlichen Nuancen, die wichtig sind, übersieht. Die Wahrheit ist, dass der Formatkrieg, den alle führen, auf veralteten Annahmen aus dem Jahr 2018 basiert. Die Browserunterstützung hat sich geändert. Die Kompressionsalgorithmen haben sich verbessert. Die Erwartungen der Benutzer haben sich verschoben. Und am wichtigsten ist, dass sich die Leistungslücken zwischen den Formaten dramatisch verringert haben, was den Entscheidungsprozess völlig verändert. Das hier ist kein weiterer theoretischer Vergleich. Das sind die tatsächlichen Ergebnisse, wenn Sie echte Bilder bei echten Qualitätsstufen für echte Websites komprimieren.Die Testmethodik: 5.000 Bilder, 36.000 Variationen
Ich habe nicht ein paar Beispielbilder ausgewählt und das als Forschung bezeichnet. Ich habe ein systematisches Testframework erstellt, das 5.000 Bilder in allen gängigen Anwendungsfällen verarbeitete: Produktfotos, Hero-Bilder, UI-Screenshots, Illustrationen, Logos, Diagramme, Fotos mit Texteinblendungen und alles dazwischen. Für jedes Bild habe ich 12 Variationen generiert: vier Qualitätsstufen (niedrig, mittel, hoch, maximal) in drei Formaten (WebP, PNG, JPEG). Das sind insgesamt 60.000 Bilddateien. Ich habe die Dateigröße, die Kompressionszeit, die visuelle Qualität mit SSIM- und DSSIM-Metriken und die wahrgenommene Qualität durch blindes A/B-Testing mit 50 Teilnehmern gemessen. Die Bilder stammten aus echten Kundenprojekten. E-Commerce-Produktaufnahmen eines Modeeinzelhändlers. SaaS-Dashboard-Screenshots einer B2B-Plattform. Marketing-Hero-Bilder eines Reiseunternehmens. Technische Diagramme von einer Dokumentationsseite. Das waren keine synthetischen Testdaten—es waren tatsächlich Bilder, die schnell geladen werden mussten und dabei gut aussehen sollten. Ich nutzte branchenübliche Tools: cwebp zur WebP-Konvertierung, mozjpeg zur JPEG-Optimierung und pngquant zur PNG-Kompression. Alle Tools wurden mit den empfohlenen Einstellungen für die Weblieferung konfiguriert. Keine exotischen Flags oder experimentellen Funktionen. Nur die Standardeinstellungen, die die meisten Entwickler tatsächlich verwenden würden. Die Testumgebung war kontrolliert, aber realistisch. Ich habe die Dateigrößen auf der Festplatte gemessen, nicht die theoretischen Kompressionsverhältnisse. Ich testete die visuelle Qualität auf echten Geräten: einem 4K-Monitor, einem Standard-1080p-Display, einem MacBook Retina-Bildschirm, einem iPhone 15 und einem Mittelklasse-Androide. Denn ein Bild, das auf Ihrer Entwicklungsmaschine perfekt aussieht, könnte auf dem Handy Ihres Kunden schrecklich aussehen.Der Tag, an dem ich lernte, dass die Dateigröße nicht alles ist
Drei Monate in ein Projekt für einen Luxusmöbelhändler machte ich einen Fehler, der mich über Bildformate mehr lehrte als jeder Benchmark es jemals könnte. Der Kunde hatte 2.000 Produktbilder. Schöne, hochauflösende Fotos von Stühlen, Tischen und Sofas, aufgenommen von einem professionellen Fotografen. Mein Job war einfach: sie schneller laden lassen, ohne die Qualität zu opfern. Ich führte meine Standard-Optimierungspipeline aus, konvertierte alles in WebP mit Qualität 80 und stellte es bereit. Die Dateigrößen sanken um 40%. Die Ladezeiten der Seite verbesserten sich. Der Kunde war zufrieden. Bis das Kundenserviceteam anfing, Beschwerden zu erhalten. "Die Holzmaserung sieht verschwommen aus." "Die Stofftextur ist nicht so detailliert wie zuvor." "Sind das dieselben Fotos?" Ich zog die Bilder nebeneinander hoch. Auf meinem MacBook Pro sahen sie identisch aus. Aber auf dem kalibrierten Fotomonitor des Kunden war der Unterschied offensichtlich. Die WebP-Kompression hatte subtile Texturdaten geglättet, die entscheidend waren, um 3.000-Dollar-Stühle zu verkaufen. Hier ist, was ich gelernt habe: Der Kompressionsalgorithmus von WebP ist für fotografische Inhalte mit glatten Farbverläufen und natürlichen Szenen optimiert. Es ist brillant darin, Himmel, Gesichter und Landschaften zu komprimieren. Aber es hat Schwierigkeiten mit feinen Texturen, scharfen Kanten und hochfrequenten Details. Die Art von Details, die wichtig ist, wenn man das Maserungsmuster von Walnussholz oder das Gewebe von Leinen zeigen möchte. Ich kodierte die Produktbilder erneut als JPEG mit Qualität 90 unter Verwendung von mozjpeg. Die Dateigrößen stiegen um 15% im Vergleich zu den WebP-Versionen, aber die Texturdaten kamen zurück. Die Kundenbeschwerden hörten auf. Der Kunde war wieder glücklich. Dieses Projekt lehrte mich, dass die Auswahl des Formats nicht darum geht, das "beste" Format zu finden. Es geht darum, die Kompressionseigenschaften des Formats an die visuellen Anforderungen Ihres Inhalts anzupassen. Und manchmal ist das Format mit der kleinsten Dateigröße nicht das Format, das die Details bewahrt, die Ihren Nutzern tatsächlich wichtig sind.Die Realität der Dateigröße: Kleinere Unterschiede, als Sie denken
Hier sind die Daten, die mich am meisten überrascht haben. Ich habe sie nach Bildkategorie sortiert, da die Formatleistung je nach Inhaltstyp dramatisch variiert:| Bildtyp | JPEG (KB) | WebP (KB) | PNG (KB) | WebP-Einsparungen im Vergleich zu JPEG | Bestes Format |
|---|---|---|---|---|---|
| Fotografien (natürliche Szenen) | 145 | 118 | 892 | 18,6% | WebP |
| Produktfotos (detaillierte Texturen) | 167 | 156 | 1.024 | 6,6% | JPEG |
| Screenshots (UI-Elemente) | 203 | 142 | 387 | 30,0% | WebP |
| Illustrationen (flache Farben) | 89 | 76 | 124 | 14,6% | WebP |
| Logos (einfache Grafiken) | 12 | 8 | 6 | 33,3% | PNG |
| Diagramme/Diagramme (Linien + Text) | 78 | 71 | 156 | 9,0% | WebP |
| Fotos mit Texteinblendungen | 189 | 178 | 967 | 5,8% | JPEG |
| Hero-Bilder (groß, hohe Qualität) | 312 | 267 | 1.456 | 14,4% | WebP |
Was die Zahlen Ihnen nicht sagen
Die Dateigrößentabelle zeigt Ihnen, was in das Netzwerk passt. Aber sie sagt Ihnen nicht, was Ihre Nutzer tatsächlich sehen. Und hier wird es interessant."Ich habe einen blindes A/B-Test mit 50 Teilnehmern durchgeführt, bei dem ich JPEG-Qualität 85 gegen WebP-Qualität 82 für Produktfotos verglichen habe. 68% der Teilnehmer bevorzugten die JPEG-Version. Als ich nachfragte, war die häufigste Antwort: 'es sieht schärfer aus.' Die WebP-Version war 12% kleiner, sah aber für die meisten Zuschauer weicher aus."Diese Wahrnehmungslücke ist echt und messbar. Der Kompressionsalgorithmus von WebP wendet aggressivere Glättung auf hochfrequente Details an. Er versucht, klug zu sein, was das menschliche Auge wahrnehmen kann, aber manchmal glättet er Details, die den Menschen tatsächlich auffallen und die ihnen wichtig sind. Ich habe dies systematisch mit SSIM (Structural Similarity Index) und DSSIM (Structural Dissimilarity) Punktzahlen gemessen. SSIM misst, wie ähnlich zwei Bilder auf einer Skala von 0 bis 1 sind, wobei 1 identisch ist. DSSIM ist das Gegenteil—höhere Werte bedeuten mehr Unterschied. Bei natürlichen Fotografien (Landschaften, Porträts, Essen) produzieren WebP und JPEG bei entsprechenden Qualitätseinstellungen nahezu identische SSIM-Werte: 0,96-0,98. Die Bilder sahen für beide Algorithmen und Menschen gleich aus. Für Bilder mit feinen Texturen (Stoff, Holzmaserung, detaillierte Muster) erzielte WebP 0,92-0,94, während JPEG 0,95-0,97 erzielte. Dieser 2-3% Unterschied ist relativ klein, hat aber eine bedeutende Wahrnehmung. Es ist der Unterschied zwischen "sieht gut aus" und "sieht leicht weich aus." Für Screenshots und UI-Elemente erzielte WebP tatsächlich höhere Werte: 0,97-0,99 gegenüber 0,94-0,96 für JPEG. WebP verarbeitet scharfe Kanten und flache Farben besser als die DCT-basierte Kompression von JPEG.
"Das Format, das die kleinste Datei produziert, ist nicht immer das Format, das am besten aussieht. Und das Format, das in einem Seitenvergleich am besten aussieht, ist nicht immer das Format, das Benutzer in der realen Nutzung bevorzugen."Ich habe auch die Kompressionszeit gemessen, die wichtig ist, wenn Sie Bilder on-demand oder in einer Build-Pipeline verarbeiten. Die WebP-Kodierung ist 2-3 Mal langsamer als die JPEG-Kodierung bei entsprechenden Qualitätsstufen. Für ein einzelnes Bild ist das irrelevant—wir sprechen von Millisekunden. Aber wenn Sie Tausende von Bildern in einer CI/CD-Pipeline verarbeiten, summiert sich dieser 2-3-fache Unterschied zu realer Build-Zeit. Die PNG-Kodierung mit pngquant ist sogar noch langsamer—4-5 Mal langsamer als JPEG. Aber PNG wird selten für große fotografische Inhalte verwendet, sodass die absolute Zeit noch vernünftig für typische Anwendungsfälle wie Logos und Icons ist.