< BACK 35mm-Filmspule und Negative auf einem Dunkelkammertisch unter bernsteinfarbenem Sicherheitslicht, redaktionaler Fotografie-Stil

WebP vs JPEG 2026: Das richtige Bildformat wählen

Zurück in 2021 hatte ich einen WooCommerce-Kunden in Birmingham, einen Haushaltswarenladen mit etwa 4.000 Produktfotos, alle riesige JPEGs aufgenommen mit einer Canon DSLR und ohne jede Verarbeitung hochgeladen. Sein Largest Contentful Paint lag bei 7,2 Sekunden. Furchtbar. Ich konvertierte alles zu WebP mit Squoosh CLI, führte Lighthouse erneut aus und bekam LCP an einem einzelnen Nachmittag auf 2,8 Sekunden herunter. Der Kunde weinte. Echt.Squoosh CLI, re-ran Lighthouse, and got LCP down to 2.8 seconds in a single afternoon. The client cried. Genuinely.

Aber hier ist der Haken: derselbe Trick hätte für einen anderen Kunden, mit dem ich im folgenden Monat arbeitete, sehr wenig bewirkt – eine Photojournalismus-Portfolio-Website, wo Farbgenauigkeit und druckqualitäts-Exporte tatsächlich wichtig waren. WebP war dort die falsche Wahl. Ich nutzte stattdessen JPEG mit aggressiven Lightroom-Exporteinstellungen, und der Performance-Unterschied war vernachlässigbar, weil die Bilder bereits richtig dimensioniert waren.

Lassen Sie uns das ordentlich besprechen. Nicht „WebP ist immer besser" und nicht „JPEG ist ein Klassiker aus gutem Grund." Die echte Antwort ist situativer, als beide Lager zugeben.

---

Was unterscheidet sich eigentlich unter der Haube

JPEG existiert seit 1992. Es nutzt diskrete Kosinus-Transformations-Kompression, was für Fotografien hervorragend ist, aber bei hohen Kompressionsraten zusammenbricht, weil es diese bekannten blockigen Artefakte einführt. Die meisten Web-Entwickler wissen das.

WebP wurde 2010 von Google veröffentlicht und nutzt ein Vorhersage-Kodierungsmodell, das vom VP8-Video-Codec entlehnt ist. Kurz gesagt: Es modelliert räumliche Beziehungen zwischen Pixeln cleverer, was bedeutet, dass es mehr Qualität in weniger Bytes packen kann. Nach Googles eigener Forschung sind WebP-Bilder ohne Verlust 26% kleiner als PNGs, und verlustbehaftetes WebP ist 25-34% kleiner als vergleichbare JPEGs bei gleichwertiger Qualität.Google's own research, WebP lossless images are 26% smaller than PNGs, and lossy WebP is 25-34% smaller than comparable JPEGs at equivalent quality.

Diese Zahlen halten sich in der Praxis. Größtenteils.

Wo die Differenz wirklich sichtbar wird

Die 25-34%-Ersparnis zeigen sich üblicherweise bei natürlichen Fotografien mit sanften Verläufen, Produktfotos auf weißem Hintergrund und Lifestyle-Bildern. Die Differenz wird bei hohen Details erheblich kleiner: enge Stofftexturen, dichtes Laub, Architekturmuster mit viel Wiederholung. Ich habe das mit ImageMagick schon oft Seite-an-Seite verglichen. Bei bestimmten hochdetaillierten Aufnahmen fällt die Größendifferenz unter 10%, und manchmal verliert WebP sogar bei der gleichen Qualitätseinstellung.ImageMagick side-by-side comparisons plenty of times. On certain highly detailed shots, the size difference drops to under 10%, and sometimes WebP even loses at the same quality setting.

---

Browser-Unterstützung 2026: Ist das noch eine Diskussion?

Ehrlich gesagt war Browser-Unterstützung das echte Argument, um 2018 bei JPEG zu bleiben. Internet Explorer. Safari, das langsam adoptierte. All das.

Das ist vorbei. Can I Use gibt globale WebP-Unterstützung mit über 97% an. Safari hat volle Unterstützung in Version 14 2020 hinzugefügt. IE ist tot und begraben. Es gibt kein sinnvolles Zielgruppensegment, das 2026 kein WebP-Bild empfangen kann.Can I Use puts global WebP support at over 97% at this point. Safari added full support in version 14 back in 2020. IE is dead and buried. There's no meaningful audience segment that can't receive a WebP image in 2026.

Der einzige Sonderfall, dem ich noch begegne: Wenn du Bilder als E-Mail-Anhänge servierst oder sie in PDF-Exporte einbettest, die server-seitig generiert werden, ersticken einige ältere Rendering-Pipelines an WebP. Das war's. Für alles Browser-gestützte ist die Support-Debatte vorbei.

---

Core Web Vitals: Wo die Formatwahl wirklich einen Unterschied macht

LCP (Largest Contentful Paint) ist die Core-Web-Vitals-Metrik, die am direktesten vom Bildformat beeinflusst wird. Sie misst, wie lange es dauert, bis das größte sichtbare Element geladen ist. Wenn dieses Element ein Bild ist (und das ist auf Marketing- und E-Commerce-Seiten meist der Fall), dann spielen Format, Größe und Auslieferungsmethode eine enorm wichtige Rolle.

Hier ist eine praktische Übersicht, wo ich gesehen habe, dass die Formatwahl einen echten Unterschied macht:

  • Hero-Bilder: Das sind fast immer das LCP-Element. Wenn dein Hero-Bild ein 1,2-MB-JPEG bei 1920px Breite ist, wird die Konvertierung zu WebP bei Qualität 82 dir routinemäßig 380–450 KB bringen, ohne sichtbaren Qualitätsverlust. These are almost always the LCP element. If your hero is a 1.2MB JPEG at 1920px wide, converting to WebP at quality 82 will routinely get you to 380-450KB without visible quality loss.
  • Produktbildraster: Viele kleine Bilder laden gleichzeitig. WebPs konsistente Ersparnis von über 25 % addiert sich hier auf. Schnelleres Raster = geringere Gesamtblockierung auf dem Mobilgerät. Lots of small images loading simultaneously. WebP's consistent 25%+ savings compound here. Faster grid = lower total blocking on mobile.
  • Bilder im Blog-Text: Praktisch ohne Auswirkung. Ein 200-KB-JPEG versus ein 140-KB-WebP mitten in einem 3.000-Wort-Artikel bewegt dein LCP nicht. Genuinely low impact. A 200KB JPEG versus a 140KB WebP in the middle of a 3,000-word article isn't moving your LCP.
  • Icons und Logos: Weder noch. Verwende SVG. Das muss ich jedes Mal sagen. Neither. Use SVG. I have to say this every single time.
  • Thumbnails auf Archivseiten: WebP gewinnt hier, besonders wenn du 20–30 Thumbnails in einem Raster lädst. Dort addieren sich Byte-Ersparnis schnell auf. WebP wins here, especially when you're loading 20-30 thumbnails in a grid. That's where byte savings stack up fast.

Seahawk hatte letztes Jahr ein Fintech-Projekt, bei dem die Marketing-Site 14 oberhalb der Falte angeordnete Bilder in einem rotierenden Hero-Carousel hatte. Wahnsinn, aber der Kunde bestand darauf. Die Konvertierung aller 14 von JPEG zu WebP bei Qualität 80 und deren Auslieferung über Cloudflare CDN senkte das LCP auf dem Mobilgerät von 4,1 auf 2,3 Sekunden. Das Carousel war immer noch eine schreckliche Idee, aber wenigstens lud es schnell.

---

Die AVIF-Frage

Jedes Mal, wenn ich über WebP schreibe, fragt jemand nach AVIF. Berechtigt.

AVIF ist der nächste Schritt. Es basiert auf dem AV1-Video-Codec, erzeugt noch kleinere Dateien als WebP (bei Fotografien oft 20–30% kleiner), und behandelt HDR-Inhalte ordnungsgemäß. Die Browser-Unterstützung ist nun solide für Chrome, Firefox und Safari. Das Problem ist die Codierungsgeschwindigkeit. AVIF ist langsam beim Codieren, bedeutsam langsam. Eine Batch-Konvertierung von 4.000 Produktbildern durch AVIF auf einem VPS wird lange dauern. WebP ist deutlich schneller zu produzieren.Browser support is now solid for Chrome, Firefox, and Safari. The problem is encoding speed. AVIF is slow to encode, meaningfully slow. Running a batch conversion of 4,000 product images through AVIF on a VPS will take you a long time. WebP is significantly faster to produce.

Mein aktuelles Denken: Nutze WebP als dein Standard-Lieferformat. Wenn du eine hochfrequentierte Website aufbaust, wo die zusätzlichen AVIF-Kompressionsggewinne den Codierungs-Overhead rechtfertigen, serve AVIF an Browser, die es unterstützen, mit WebP-Fallback. Das <picture>-Element mit <source type="image/avif"> erledigt das ohne JavaScript.<picture> element with <source type="image/avif"> handles this without any JavaScript.

Lass dich nicht von AVIF-Lähmung auf JPEG festhalten. WebP ist derzeit das richtige pragmatische Standard-Format.

---

Mein eigentlicher Workflow zur Formatwahl

Nach 9 Jahren und weit über 12.000 Websites überlege ich mir das in etwa so:

  1. Ist es eine Fotografie oder ein fotorealistisches Bild? Starte mit WebP lossy bei Qualität 80–85. Vergleiche gegen JPEG bei Qualität 75. Nimm das kleinere, das den Squint-Test besteht. Start with WebP lossy at quality 80-85. Compare against JPEG at quality 75. Take the smaller one that passes the squint test.
  2. Ist es eine Grafik, ein Logo oder eine Illustration mit Flächenfarben? SVG wenn möglich, PNG wenn nicht. WebP verlustfrei ist eine Option, aber selten die beste. SVG if possible, PNG if not. WebP lossless is an option but rarely the best one.
  3. Ist es ein Screenshot mit Text? PNG. Immer PNG. JPEG und WebP führen beide zu Artefakten an den Textkanten ein, die schrecklich aussehen. PNG. Always PNG. JPEG and WebP both introduce artefacts around text edges that look terrible.
  4. Wird es über ein modernes CDN bereitgestellt, das automatisch Formataushandlung durchführt? Falls du Cloudflare mit Polish aktiviert nutzt oder Cloudinary oder Imgix verwendest, musst du dir ehrlich gesagt nicht viel Gedanken machen. Sie erkennen den Browser und stellen das optimale Format bereit. Lass die Tools die Arbeit machen. If you're on Cloudflare with Polish enabled, or using Cloudinary, or Imgix, then honestly you don't need to worry much. They'll detect the browser and serve the optimal format. Let the tooling handle it.
  5. Ist es eine WordPress-Site? Installiere ShortPixel oder Imagify und konfiguriere sie so, dass sie beim Upload konvertieren. Fertig. Du musst das nicht manuell verwalten. Install ShortPixel or Imagify and configure them to convert on upload. Done. You don't need to manually manage this at all.

Ein Wort zu den Qualitätseinstellungen

Qualität 80 ist nicht Qualität 60. Ich sehe Entwickler, die WebP-Qualität auf 60 setzen, weil „es immer noch besser als JPEG ist" und sich dann wundern, warum Kunden sich über matschige Produktfotos beschweren. Führe ordentlich visuelles QA durch. Ich durchlaufe jede Formatentscheidung mit Squoosh im Browser und wechsle mit dem Split-View-Tool zwischen Original und Ausgabe. Das dauert 3 Minuten pro Bildtyp und spart Diskussionen mit Kunden.

---

Wann JPEG Immer noch die richtige Antwort ist

Ich sage es klar, weil ich nicht genug Leute das sagen sehe: JPEG ist nicht überholt.

Wenn du eine Site aufbaust, auf der Bilder heruntergeladen und neu bearbeitet werden (Fotografie-Portfolios, Stock-Bilder, Press-Asset-Bibliotheken), ist JPEG immer noch sinnvoll. Es wird in jeder Bildbearbeitungsanwendung auf der Welt universell unterstützt. Die WebP-Exportqualität in Tools wie Photoshop hat sich dramatisch verbessert, aber das Ökosystem rund um JPEG für Nachbearbeitungs-Workflows ist einfach ausgereifter.

Wenn deine Bilder bereits gut optimierte JPEGs sind (sagen wir, unter 100KB für ein 800px breites Bild), bringt die Konvertierung zu WebP vielleicht 15-20KB Ersparnis. Das ist nicht nichts, aber es ist nicht die Ingenieurzeit wert, wenn du die Konvertierung von Hand machst. Wähle deine Kämpfe weise.

Und wenn du druckst. Offensichtlich. WebP ist ein Web-Format. Nutze es nicht für irgendetwas, das am Ende auf Papier landet.

---

Praktische Tools, die du kennen solltest

Das sind die Tools, die ich tatsächlich nutze, keine aufgeblasene Liste:

  • [Squoosh](https://squoosh.app/): Browser-basiert, keine Installation, brillant für einmalige Vergleiche und um die richtige Qualitätseinstellung zu finden, bevor du etwas automatisierst. Browser-based, no install, brilliant for one-off comparisons and finding the right quality setting before automating anything.
  • Squoosh CLI: Batch-Konvertierung vom Terminal aus. Ich nutze das für projektweite Migrationen. Batch conversion from the terminal. I use this for project-level migrations.
  • ShortPixel: Das beste WordPress-Plugin für automatisierte Konvertierung beim Hochladen. Die Lossy-Einstellung ist ab Werk sinnvoll. Best WordPress plugin for automated conversion on upload. The lossy setting is sensible out of the box.
  • Cloudflare Polish: Wenn du bereits auf Cloudflare Pro bist, schalte das ein. Es konvertiert und komprimiert am Edge automatisch. Kein Code nötig. If you're already on Cloudflare Pro, turn this on. It converts and compresses at the edge automatically. Zero code required.
  • Cloudinary: Die Wahl für größere redaktionelle oder E-Commerce-Operationen, wo du Format-Verhandlung, responsive Größenanpassung und CDN-Bereitstellung als verwalteten Service brauchst. The choice for larger editorial or e-commerce operations where you need format negotiation, responsive sizing, and CDN delivery as a managed service.
  • ImageMagick: Kommandozeilen-Konvertierung für serverseitige Workflows. Langsamer als Squoosh CLI, aber flexibler für geskriptete Pipelines. Command-line conversion for server-side workflows. Slower than Squoosh CLI but more flexible for scripted pipelines.

---

FAQ

Ist WebP immer kleiner als JPEG?

Nein. Ich wünsche mir, dass Menschen das aufhören zu sagen. Bei hochdetaillierten, hochfrequenten Bildern (denken Sie an: Makrofotografie von rauen Texturen, dicht detaillierte Architekturaufnahmen) kann der Größenunterschied vernachlässigbar oder sogar umgekehrt sein, je nach Encoder-Einstellungen. Testen Sie Ihre spezifischen Bilder, anstatt anzunehmen.

Muss ich die Original-JPEG behalten, wenn ich zu WebP konvertiere?

Ja. Behalten Sie Ihre Originale immer. WebP ist ein Lieferformat, kein Archivformat. Wenn Sie eine WordPress-Site mit ShortPixel betreiben, behält das Plugin das Original standardmäßig. Ändern Sie diese Einstellung nicht.

Schadet die Konvertierung zu WebP meinem Bild-SEO?

Nein. Google indiziert WebP-Bilder ohne Probleme. Stellen Sie sicher, dass Ihr Alt-Text aussagekräftig ist und Ihre Dateinamen sinnvoll sind. Das Format hat keine Auswirkung auf das Ranking in der Bildersuche.

Was ist mit dem `<picture>`-Element gegenüber dem direkten Bereitstellen von WebP?

Wenn 97%+ deiner Nutzer WebP unterstützen, ist es in Ordnung, WebP direkt über ein <img> Tag auszuliefern. Das <picture> Element mit Source-Fallbacks hatte Sinn, als Safari die Ausnahme war. Jetzt ist es hauptsächlich für das AVIF-mit-WebP-Fallback-Muster nützlich, das ich vorhin erwähnt habe.<img> tag is fine. The <picture> element with source fallbacks made sense when Safari was the holdout. Now it's mainly useful for the AVIF-with-WebP-fallback pattern I mentioned earlier.

Beeinflusst das Bildformat CLS (Cumulative Layout Shift)?

Das Format selbst nicht. Aber wenn du Bilder konvertierst und keine expliziten width- und height-Attribute setzt (oder aspect-ratio in CSS verwendest), bekommst du Layout Shift unabhängig vom Format. Das ist einer der häufigsten Fehler, die ich bei Leuten sehe, die Bilder massenweise konvertieren. Behebe deine Dimensionen.width and height attributes (or using aspect-ratio in CSS), you'll get layout shift regardless of format. This is one of the most common mistakes I see when people do bulk format migrations. Fix your dimensions.

---

Format-Entscheidungen wirken klein. Das sind sie nicht. Ich habe gesehen, wie eine einzelne Nachmittags-Session Bildoptimierung eine Website von „Core Web Vitals fehlgeschlagen" zu „bestanden" gebracht und die Conversion-Raten für E-Commerce-Kunden sinnvoll erhöht hat. WebP ist 2026 für fast jeden Browser-gelieferten Photograph die richtige Voreinstellung. Aber es ist eine Voreinstellung, keine Regel. Wisse, warum du diese Entscheidung triffst, teste vor der Automatisierung und bewahre deine Original-Dateien.

< BACK