Ja, die Umstellung auf WebP lohnt sich für die meisten Webprojekte. Sie sparen im Schnitt 25 bis 35 Prozent Dateigröße gegenüber JPEG, verbessern damit messbar den Largest Contentful Paint und stärken indirekt Ihre SEO-Signale. Ausnahmen gibt es bei E-Mail-Clients und sehr alten Unternehmensumgebungen, dort brauchen Sie weiterhin ein JPEG- oder PNG-Fallback über das picture-Element.

Kurz gesagt:

  • WebP spart durchschnittlich 25 bis 35 Prozent Dateigröße im Vergleich zu JPEG und verbessert so die Ladezeit sowie den Largest Contentful Paint.
  • Die Unterstützung durch moderne Browser ist weitgehend, weshalb in der Regel kein Fallback mehr notwendig ist, außer bei E-Mail-Clienten und alten Unternehmenssystemen.
  • Für eine effektive Umstellung empfiehlt sich die Nutzung des picture-Elements, serverseitiger Inhalte-Negotiation oder CDN-Lösungen, um flexible Formatbereitstellung sicherzustellen.
  • Die Konvertierung erfolgt am besten mit cwebp oder automatisiert im Build-Prozess, wobei auf Backups geachtet werden sollte, da WebP verlustbehaftet ist.
  • Nach der Umstellung ist kontinuierliches Monitoring der Core Web Vitals und Implementierung von Cache-Optimierungen sowie responsive Bildgrößen entscheidend für nachhaltige Performance.
Neomarketing
Datenbasiert zu besserer Webperformance
Neomarketing verbindet Google-Tools und datengetriebenes Marketing, damit Shopbesitzer fundierte Entscheidungen für ihr digitales Wachstum treffen.

Neomarketing kennenlernen

Inhaltsverzeichnis

Was ist WebP? Technische Kurzübersicht

WebP ist ein von Google entwickeltes Bildformat, das auf dem VP8-Videocodec aufbaut und Bilddaten in einem RIFF-Container speichert. Die Dateiendung lautet .webp, der zugehörige MIME-Type ist image/webp, wie MDN Web Docs dokumentiert.

Das Format kennt zwei Grundmodi. Verlustbehaftete Kompression funktioniert ähnlich wie JPEG und eignet sich für Fotos. Verlustfreie Kompression bewahrt jedes Pixel, was bei Grafiken mit scharfen Kanten oder Text wichtig ist. Zusätzlich unterstützt WebP Transparenz über einen Alphakanal und einfache Animationen, womit es in vielen Fällen gleich zwei ältere Formate ersetzt.

Die Einsparungen sind dabei kein Marketingversprechen, sondern gut belegt:

  • Gegenüber JPEG spart WebP typischerweise 25 bis 35 Prozent Dateigröße bei vergleichbarer visueller Qualität.
  • Gegenüber verlustfreiem PNG liegt die Ersparnis bei etwa einem Viertel der Dateigröße.
  • Animierte WebP-Dateien fallen oft deutlich kleiner aus als vergleichbare GIFs, weil die Kompression moderner arbeitet.

Warum WebP? Performance-, SEO- und UX-Vorteile

Kleinere Bilder laden schneller, und schnellere Bilder verbessern den Largest Contentful Paint direkt, weil das größte sichtbare Element im Viewport meist ein Bild ist. Wer sein Hero-Bild von 400 KB auf 260 KB reduziert, sieht diesen Effekt oft schon im nächsten Lighthouse-Report.

Zur Einordnung: WebP spart gegenüber JPEG üblicherweise 25 bis 35 Prozent Dateigröße. Das ist ein Bereich, kein Fixwert, die tatsächliche Ersparnis hängt stark vom Bildinhalt ab.

Für Fotos mit vielen Details fällt die Ersparnis oft geringer aus als bei flächigen Grafiken oder Screenshots. Dennoch bleibt der Effekt auf die Core Web Vitals meist positiv, weil auch kleine LÖSS-Verbesserungen sich in Google-Rankings niederschlagen können.

Die Kehrseite betrifft vor allem zwei Szenarien:

  • Echtzeit-Bildverarbeitung, etwa bei dynamisch generierten Vorschaubildern, belastet die Server-CPU stärker als bei JPEG, weil das WebP-Encoding rechenintensiver ist.
  • E-Mail-Clients rendern WebP oft gar nicht oder nur unzuverlässig, weshalb Newsletter-Grafiken weiterhin klassische Formate brauchen.

Wer diese beiden Ausnahmen kennt, kann die Umstellung ohne böse Überraschungen planen.

Welche Browser unterstützen WebP?

Alle relevanten modernen Browser unterstützen WebP inzwischen nativ. Chrome, Edge, Firefox und Opera können das Format seit Jahren verarbeiten, und seit Safari 14 beziehungsweise iOS 14 ist auch das Apple-Ökosystem an Bord, wie MDN bestätigt. Für die große Mehrheit der Websites bedeutet das: Ein Fallback ist eher Vorsicht als Notwendigkeit.

Drei Fallback-Muster haben sich in der Praxis durchgesetzt:

  • Das picture-Element mit mehreren <source>-Tags, wobei der Browser selbst das beste unterstützte Format wählt.

  • Server-seitige Content-Negotiation über den Accept-Header, bei der der Server anhand der Browserangabe entscheidet, welches Format er ausliefert.

  • srcset-Fallback, der zusätzlich verschiedene Auflösungen je Format bereitstellt.

Ein klassisches JPEG- oder PNG-Fallback bleibt sinnvoll bei E-Mail-Templates, bei PDF-Exporten mit eingebetteten Bildern und bei älteren internen Unternehmenstools, die oft auf veralteten Browser-Engines laufen. Für den öffentlichen Webauftritt selbst reicht heute in den allermeisten Fällen WebP als primäres Format.

Wie wandle ich Bilder in WebP um?

Die Wahl des Werkzeugs hängt vor allem von der Menge der Bilder und Ihrer technischen Umgebung ab.

  1. Einzelbilder per Kommandozeile: Mit dem von Google bereitgestellten cwebp-Tool konvertieren Sie eine Datei mit cwebp -q 80 bild.jpg -o bild.webp. Die -q-Flag steuert die Qualität zwischen 0 und 100.
  2. Batch-Konvertierung: Für ganze Ordner reicht eine Schleife wie for f in *.jpg; do cwebp -q 80 "$f" -o "${f%.jpg}.webp"; done, damit müssen Sie nicht jedes Bild einzeln anfassen.
  3. Manuelle Tests im Browser: Squoosh eignet sich, wenn Sie vor der Serienkonvertierung erst die richtige Qualitätsstufe für ein bestimmtes Motiv austesten wollen, ganz ohne Installation.
  4. Automatisierung im Build-Prozess: Imagemin mit dem imagemin-webp-Plugin fügt die Konvertierung direkt in Ihre Build-Pipeline ein, sodass jedes neue Bild automatisch mit konvertiert wird.
  5. CMS-Integration: WordPress erlaubt seit Version 5.8 den direkten Upload von WebP-Dateien, doch die rückwirkende Konvertierung bestehender Bilder übernehmen meist Plugins wie ShortPixel, Imagify oder EWWW.

Profi-Tipp: Konvertieren Sie nie ohne Backup der Originaldateien. WebP ist verlustbehaftet, und aus einer bereits komprimierten WebP-Datei lässt sich keine höhere Qualität mehr zurückgewinnen.

Für Websites mit wenigen hundert Bildern reicht oft eine einmalige Batch-Konvertierung. Bei tausenden Produktbildern in einem Onlineshop lohnt sich dagegen ein automatisierter Workflow, der neue Uploads sofort mitverarbeitet, statt regelmäßig manuell nachzuziehen.

Bilder ausliefern: picture, Server-Negotiation oder CDN?

Beim picture-Element definieren Sie mehrere Quellen, aus denen der Browser wählt:

<picture>
  <source srcset="bild.webp" type="image/webp">
  <img src="bild.jpg" alt="Produktfoto" width="800" height="600" fetchpriority="high">
</picture>

Die Attribute width und height verhindern Layout-Verschiebungen und damit einen schlechteren Cumulative Layout Shift. fetchpriority="high" signalisiert dem Browser, das Bild als LCP-Kandidaten vorrangig zu laden, wie im Complete WebP Guide beschrieben.

Die serverseitige Alternative arbeitet mit Rewrite-Regeln. Bei Nginx prüft eine mapDirektive den Accept-Header und liefert bei Unterstützung automatisch die WebP-Variante aus, bei Apache erreichen Sie dasselbe über mod_rewrite in Kombination mit einem Vary: Accept-Header, der verhindert, dass Caches das falsche Format an den falschen Client ausliefern.

Methode Kontrolle Wartungsaufwand Cache-Risiko
picture-Element Vollständig clientseitig steuerbar Gering, einmal im Markup gesetzt Kein Vary-Header nötig
Server-Negotiation (Nginx/Apache) Serverseitig, transparent für Redakteure Mittel, Regeln müssen gepflegt werden Vary-Header zwingend erforderlich
CDN-Auto-Konvertierung Automatisch, wenig Eingriffsmöglichkeit Gering im Alltag, hoch bei Fehlersuche CDN-Cache kann veraltete Formate ausliefern

Viele CDNs erkennen den Accept-Header selbst und wandeln Bilder automatisch um, ohne dass Sie eigene Regeln pflegen müssen. Der Komfort hat einen Preis: Bei Problemen mit falsch ausgeliefertem Format haben Sie weniger direkten Zugriff auf die Fehlerursache als bei einer selbst gepflegten Nginx-Konfiguration.

Wie teste ich, dass die Umstellung funktioniert?

Für Fotos hat sich eine Quality-Range von 75 bis 85 als guter Kompromiss zwischen Dateigröße und sichtbarer Qualität etabliert. Bei textlastigen Grafiken, Logos oder Screenshots mit scharfen Kanten sollten Sie dagegen die verlustfreie Variante wählen, sonst entstehen sichtbare Artefakte an Kontrastkanten.

Lighthouse listet nicht konvertierte Bilder direkt in der Prüfung „Bilder in modernen Formaten bereitstellen“ auf. Das macht den Rollout messbar, statt sich auf ein Bauchgefühl zu verlassen.

Lighthouse zeigt nicht nur, welche Bilder fehlen, sondern schätzt auch die potenzielle Einsparung in Kilobyte je Bild, das ist der konkreteste Startpunkt für eine Priorisierungsliste.

Nach dem Lighthouse-Check gehört echtes Nutzerverhalten in die Beobachtung:

  • RUM-Daten (Real User Monitoring) zeigen, wie sich LCP und CLS bei echten Besuchern nach der Umstellung entwickeln, nicht nur im Labortest.
  • Core Web Vitals im 75. Perzentil sind die Kennzahl, die auch für Google-Rankingsignale relevant ist. Mehr dazu finden Sie in unserem Leitfaden zu Core Web Vitals.
  • Ein Canary-Rollout, bei dem zunächst nur ein Teil des Traffics die neuen Bilder sieht, deckt Probleme auf, bevor sie alle Nutzer betreffen.

Migrations-Checkliste für die WebP-Umstellung

  1. Bilder inventarisieren und nach Sichtbarkeit priorisieren, TCP-relevante Hero- und Produktbilder zuerst.
  2. Vollständiges Backup der Originaldateien anlegen, bevor irgendetwas konvertiert wird.
  3. Konvertierung in einer Testumgebung durchführen und visuell gegen die Originale prüfen.
  4. Auslieferung über picture-Element oder Server-Negotiation einrichten und Header korrekt setzen.
  5. Stufenweise live schalten, zuerst einzelne Seitenbereiche, dann die gesamte Website, mit laufendem Monitoring.

Profi-Tipp: Behalten Sie die Originaldateien mindestens so lange, bis Sie einen vollständigen Monitoring-Zyklus über die Core Web Vitals durchlaufen haben. Ein zu früher Löschvorgang macht Rollbacks unnötig kompliziert.

Rechte und Lizenzierung der eingesetzten WebP-Konverter-Tools

WebP selbst und die zugehörigen Referenz-Werkzeuge sind frei nutzbar. Google veröffentlicht die Bibliothek libwebp sowie die Kommandozeilentools cwebp und dwebp unter einer offenen Lizenz, sodass Sie sie ohne Lizenzgebühren in eigene Build-Prozesse, Server oder Produkte einbinden dürfen. Das gilt auch für den kommerziellen Einsatz in Agenturprojekten oder Shopsystemen.

Bei Drittanbieter-Werkzeugen sieht die Lage differenzierter aus. Squoosh ist ein offenes, browserbasiertes Projekt und kostenlos nutzbar, eignet sich aber eher für Einzelbilder als für Massenkonvertierung. Imagemin und das zugehörige WebP-Plugin sind Open-Source-Pakete und lassen sich frei in Build-Pipelines integrieren, unterliegen aber den jeweiligen Open-Source-Lizenzbedingungen der einzelnen Module, die Sie bei kommerzieller Weiterverteilung des eigenen Codes prüfen sollten.

WordPress-Plugins wie ShortPixel, Imagify oder EWWW arbeiten dagegen meist mit einem Freemium-Modell: Eine Basisversion mit begrenztem Kontingent ist kostenlos, größere Bildmengen oder zusätzliche Funktionen wie automatische AVIF-Konvertierung erfordern ein kostenpflichtiges Abonnement. Vor dem produktiven Einsatz lohnt sich ein Blick in die jeweiligen Nutzungsbedingungen, insbesondere wenn Bilder über einen externen Server des Plugin-Anbieters verarbeitet werden, das betrifft auch Datenschutzaspekte bei personenbezogenen Bildinhalten.

Performance-Optimierung nach der Umstellung

Die Umstellung auf WebP ist kein einmaliger Schritt, sondern der Anfang einer laufenden Optimierung. Caching-Header entscheiden mit darüber, wie oft Nutzer ein Bild überhaupt neu laden müssen. Ein langes Cache-Control: max-age, kombiniert mit versionierten Dateinamen bei Änderungen, verhindert unnötige erneute Downloads bei wiederkehrenden Besuchern.

Lazy Loading ergänzt WebP sinnvoll, sollte aber gezielt eingesetzt werden. Bilder oberhalb des ersten Viewports, insbesondere das LÖSS-Bild, sollten nicht lazy geladen werden, sonst verzögert sich genau die Metrik, die Sie eigentlich verbessern wollten. Alles, was erst beim Scrollen sichtbar wird, profitiert dagegen von loading="lazy". Praktische Umsetzungsdetails dazu finden Sie in unserem Beitrag zu Lazy Loading ohne LCP-Verlust.

Ein oft übersehener Punkt betrifft responsive Bildgrößen. WebP allein bringt wenig, wenn weiterhin ein 3.000 Pixel breites Bild an ein Smartphone-Display mit 400 Pixeln ausgeliefert wird. Kombinieren Sie WebP deshalb mit srcset und mehreren Auflösungsstufen, damit jedes Gerät wirklich nur die Bildgröße lädt, die es auch darstellen kann. Gerade im E-Commerce-Umfeld mit vielen Produktbildern macht diese Kombination oft mehr Unterschied als das Format allein, wie auch unser Leitfaden zur Performance-Steigerung für Shops zeigt.

Angepasste Bildgrößen für unterschiedliche Bildschirmgrößen

Neomarketing-Perspektive: Praxisfälle und bewährte Vorgehensweise

In vielen Projekten empfehlen wir inzwischen AVIF als primäres Format, WebP dient als Rückfallebene für die wenigen Fälle, in denen AVIF noch nicht greift. AVIF komprimiert oft stärker, WebP encodiert dafür schneller und ist praktisch überall unterstützt. Unser Ablauf bei Kundenprojekten folgt immer derselben Reihenfolge: Audit der bestehenden Bildlast, Priorisierung der TCP-relevanten Bilder, Automatisierung der Konvertierung im Build- oder CMS-Prozess, dann kontinuierliches Monitoring der Core Web Vitals. Diese Reihenfolge verhindert, dass Teams Wochen in die Konvertierung unwichtiger Bilder stecken, während das eigentliche Hero-Bild unangetastet bleibt.

— Patrick

Unterstützung bei der WebP-Umstellung durch Neomarketing

Ein externer Dienst kann die technische Seite der Bildumstellung übernehmen, damit Ihr Team sich nicht selbst durch Nginx-Konfigurationen und Plugin-Vergleiche arbeiten muss. Ein Performance-Audit zeigt zuerst, welche Bilder Ihre Ladezeit tatsächlich ausbremsen, danach folgt die Implementierung von picture-Markup, CDN-Anbindung und automatisierter Konvertierung direkt im Rahmen von NEO SEO.

Neomarketing

Wer zusätzlich eine technische Erneuerung des Frontends plant, findet passende Unterstützung bei NEO Webdesign, etwa wenn responsive Bildauslieferung gleich mit modernisiert werden soll. Nach dem Rollout bleibt die Arbeit nicht stehen: Core Web Vitals wollen dauerhaft beobachtet werden, damit spätere Content-Updates keine neuen LÖSS-Probleme einschleppen. Einen Überblick über passende Leistungspakete finden Sie unter unseren Angeboten. Fordern Sie ein kurzes Performance-Audit an und lassen Sie sich zeigen, wo Ihre Website aktuell Ladezeit verschenkt.

Quellen

Für den technischen Tiefgang lohnen sich die Entwickler-Dokumentation von Google zu WebP, die Praxisleitfäden auf web.dev sowie die Formatübersicht bei MDN. Für die tägliche Arbeit reichen meist cwebp für Batch-Jobs, Squoosh für schnelle Einzelbildtests und Imagemin für die Build-Integration.

FAQ

Wie wandelt man WebP in JPG um?

Mit dem Tool dwebp aus dem Google-Paket konvertieren Sie per Kommandozeile zurück, der Befehl lautet dwebp bild.webp -o bild.png. Für einzelne Bilder funktioniert auch Squoosh direkt im Browser ohne Installation.

Warum WebP statt JPG?

WebP spart gegenüber JPEG typischerweise 25 bis 35 Prozent Dateigröße bei vergleichbarer Bildqualität. Das verbessert Ladezeit und Largest Contentful Paint, was sich wiederum positiv auf Core Web Vitals und indirekt auf SEO auswirkt.

Welches Programm öffnet WebP-Dateien?

Alle modernen Browser wie Chrome, Firefox, Edge und Safari ab Version 14 zeigen WebP-Dateien direkt an. Zum Bearbeiten eignen sich gängige Bildbearbeitungsprogramme mit WebP-Unterstützung sowie das browserbasierte Tool Squoosh.

Wie kann ich Bilder in WebP umwandeln?

Für Einzelbilder reicht das Kommandozeilentool cwebp mit einem Befehl wie cwebp -q 80 bild.jpg -o bild.webp. Für größere Mengen oder CMS-Umgebungen wie WordPress übernehmen Plugins wie ShortPixel, Imagify oder EWWW die automatische Massenkonvertierung.

Brauche ich nach der WebP-Umstellung noch ein Fallback-Format?

In den meisten Fällen nicht mehr zwingend, da die native Browser-Unterstützung inzwischen sehr breit ist. Ausnahmen bleiben E-Mail-Clients und veraltete interne Unternehmensanwendungen, dort empfiehlt sich weiterhin ein JPEG- oder PNG-Fallback über das picture-Element.

Empfehlungen