Notizen vom Team zu Handwerk, Formaten und den kleinen Entscheidungen hinter einem guten Ergebnis.
Wie ein einzelnes Bild im Browser umgewandelt wird, und was sich bei mehreren ändert
Wenn du ein JPEG auf die Seite ziehst, liest der Browser die Datei in den Speicher, dekodiert die komprimierten Daten mit seinem eingebauten JPEG-Leser zurück in rohe Pixel, zeichnet diese Pixel auf eine Fläche außerhalb des Bildschirms und bittet die Plattform, sie als WebP zurückzuschreiben. Jeder Schritt passiert im Browser, auf deiner eigenen Hardware, sodass kein Byte das Netz überquert. In unseren Läufen ist ein ein JPEG mit 1024 mal 768 in rund 54 Millisekunden fertig, ein ein JPEG mit 3840 mal 2160 braucht etwa 550 Millisekunden. Wandelst du mehrere Bilder auf einmal um, wandert die Arbeit stattdessen auf unseren Server, der sie gemeinsam kodiert und einen einzigen Download liefert, dessen Link nach etwa 2 Stunden gelöscht wird.
Was mit EXIF und Metadaten passiert
JPEG-Dateien können echte Metadaten-Lasten mit sich schleppen. EXIF hält Kameramodell, GPS-Koordinaten, Verschlusszeit und Ausrichtung fest. IPTC-Felder tragen Copyright und Bildunterschrift. XMP-Pakete verfolgen die Bearbeitungshistorie, und ICC-Profile decken farbverwaltete Arbeit ab. Die Umwandlung hier behält nichts davon. Das fertige WebP ist eine saubere Datei mit nur den sichtbaren Pixeln. Das ist das normale Verhalten für Bild-Tools, die durch den Browser zeichnen, über Chromium, Firefox und WebKit gleichermaßen. Fürs meiste Web-Publishing ist das Fallenlassen der Metadaten ein Plus: Es spart ein paar Bytes und verhindert, dass GPS oder persönliche Daten in ein öffentliches Bild durchsickern. Brauchst du ein bestimmtes Feld erhalten, üblich ist die Ausrichtung, dreh das Foto vorher oder nutz einen metadaten-bewussten Editor vor der Umwandlung. Verlass dich nicht auf dieses Tool für Archivarbeit, bei der die Originalmetadaten unversehrt bleiben müssen.
WebP gegen JPEG: wie sich die Kompression unterscheidet
JPEG zerlegt ein Bild in 8-mal-8-Blöcke und führt eine diskrete Kosinustransformation aus, um räumliches Detail in Frequenzdaten zu verwandeln, und quantisiert dann die höheren Frequenzen härter. WebP leiht sich ein Vorhersageschema von VP8-Video: Jeder Block wird aus seinen schon dekodierten Nachbarn geschätzt, und nur die übrige Differenz wird gespeichert. Das hinterlässt bei gleicher Dateigröße meist weniger blockige Artefakte, vor allem über sanften Verläufen und Hauttönen, wo JPEGs Raster als sichtbares Mosaik auftauchen kann. Auf Fotos bei hoher Qualität, über q80, erwischt das Auge den Unterschied selten, aber der Größenvorteil bleibt stabil. Bei niedrigerer Qualität, unter q60, wächst WebPs Vorsprung und der Charakter der Artefakte verschiebt sich: WebP verschmiert zu einem weicheren Unschärfe, während JPEG seine typischen Blöcke zeigt. Keins gewinnt bei jedem Bild. Stark strukturierte Motive wie Laub komprimieren manchmal in beiden Formaten etwa gleich.
Core Web Vitals und das Argument für WebP
Largest Contentful Paint, oder LCP, misst, wie schnell das größte sichtbare Element im Sichtfenster fertig lädt. Auf den meisten Marketing-Seiten ist dieses Element ein Hero-Foto. Google hat bestätigt, dass Core Web Vitals als Ranking-Faktor in der Suche wirken. Ist der Hero ein ein JPEG, kann er LCP auf einer mittelmäßigen Mobilverbindung über die 2,5-Sekunden-Schwelle drücken. Wandelst du dasselbe Foto in WebP mit rund um, kann LCP ohne weitere Änderung an der Seite zurück in den grünen Bereich rutschen. Die Ersparnis von 25 bis 34 Prozent summiert sich über jedes Bild der Seite. Eine Seite mit sechs JPEGs von insgesamt kann durch den Wechsel auf WebP 300 bis abwerfen, was den ersten bedeutsamen Bildaufbau auf langsamen Leitungen direkt beschleunigt. CDNs, die Content-Negotiation beherrschen, reichen kompatiblen Browsern von selbst WebP, also gibt es keine Kleinarbeit pro Bild, sobald die Originale existieren.
WebP-Unterstützung 2026 und die Lücken
Stand 2026 liest WebP in Chrome seit Version 17, Firefox seit 65, Edge seit 18, Opera seit 11.10 und Safari seit Version 14 auf iOS 14 und macOS Big Sur. Laut caniuse.com überschreitet die kombinierte globale Abdeckung fürs WebP-Dekodieren 97 Prozent des Browser-Verkehrs. Der verbleibende Rest ist meist Internet Explorer 11, Safari 13 auf macOS Catalina und ein langer Schwanz sehr alter Android-Browser. Für die meisten öffentlichen Projekte ist es sicher, allen WebP auszuliefern. Brauchst du volle Abdeckung, lässt das HTML-picture-Element dich eine WebP-Quelle und einen JPEG-Fallback in einem Tag auflisten, und der Browser nimmt das erste Format, das er lesen kann. CDNs mit Bildoptimierung verhandeln das Format automatisch über den Accept-Header, den der Browser sendet, also ist beim Ausliefern über sie kein manuelles Testen pro Browser nötig.
Wann man WebP nicht nutzen sollte
WebP ist die richtige Wahl fürs Web-Ausliefern an moderne Browser, aber die falsche an ein paar üblichen Stellen. Druckarbeit braucht CMYK-Farbe, die WebP nicht führt, also bleiben JPEG und TIFF Standard für die Presse. E-Mail-Programme sind uneinheitlich: Gmail und Apple Mail zeigen WebP, Outlook unter Windows nicht. Datei-Sharing und Marktplätze variieren ebenfalls. Google Drive, Dropbox und GitHub zeigen WebP problemlos, während viele soziale Plattformen, Stock-Agenturen und E-Commerce-Systeme eingehende Bilder intern zurück in JPEG pressen, was den WebP-Schritt sinnlos macht. Die Editor-Unterstützung ist noch lückenhaft: Lightroom, Capture One und Affinity Photo können WebP öffnen, doch viele Plugins und Export-Vorlagen greifen noch standardmäßig zu JPEG. Für jeden Workflow, der Bilder durch Fremdsysteme schickt, die du nicht kontrollierst, behalte ein JPEG-Master und wandle erst in der letzten Auslieferungsschicht in WebP um.
