WebP und AVIF: Bereitstellung guter Bilder, ohne alte Browser zu beschädigen

Durch die Neugestaltung werden alle Banner auf AVIF umgestellt – ein spektakulärer Lighthouse-Gewinn. Abgesehen davon, dass das interne CRM des Kunden weiterhin auf Safari 14 auf Enterprise-MacOS abzielt: Ein einfaches „<img src="hero.avif">` zeigt ein graues Quadrat an. Der Support spricht von einer „kaputten Seite“; Marketing spricht von „Modernisierung“. Beide liegen direkt an ihrem Umfang.

WebP und AVIF reduzieren das Gewicht ohne die wahrgenommene Qualität zu beeinträchtigen – wenn die Bereitstellung progressiv bleibt: besseres Format für leistungsfähige Browser, universeller Fallback für andere. Die Modernisierung des Seitenverhältnisses ist kein anzukreuzendes Kästchen; Es handelt sich um einen Liefervertrag mit Ihrem echten Publikum.

Browserunterstützung und Bildstrategie

Das Element „<picture>“ bleibt der vorhersehbarste Ansatz auf der Ursprungsseite:

<Bild>

  <source srcset="hero.avif" type="image/avif">

  <source srcset="hero.webp" type="image/webp">

  <img src="hero.jpg" alt="Beschreibung" width="1200" height="630">

</Bild>

Geben Sie immer Breite und Höhe im „img“-Tag ein – dies vermeidet Layout-Shift (CLS). Das Attribut „alt“ muss auf dem Fallback-Bild verbleiben; Dies nutzen Crawler und Screenreader als letzten Ausweg.

Nur AVIF bereitzustellen bedeutet, für Lighthouse zu optimieren und dabei die eigentliche Browserflotte zu vergessen – oft B2B-Kunden mit einem hohen durchschnittlichen Warenkorb.

CDN, Verhandlung akzeptieren und variieren

Ein CDN, das das Format über den Header „Accept: image/avif,image/webp,/“ aushandelt, vereinfacht den HTML-Code – erzwingt aber Vary: Accept und einen korrekten Cache-Schlüssel. Ohne Vary kann das CDN ein AVIF an einen inkompatiblen Browser bereitstellen.

Auf einem CDN-losen Ursprung bleibt „<picture>“ vorhersehbarer als eine undurchsichtige serverseitige Umschreibung. Unter WordPress generieren die Plugins ShortPixel oder Imagify die Variationen – prüfen Sie, ob der Fallback in der Admin-Vorschau und auf einem alten Safari angezeigt wird.

Richten Sie diese Richtlinie an Ihren Cache-Headern aus: Von Accept ausgehandelte Bilder erfordern eine konsistente Vary-Richtlinie zwischen Ursprung und Kante.

Qualität, Abmessungen und Quelle

Stellen Sie mehrere Auflösungen über „srcset“ und „sizes“ für Mobilgeräte bereit. Die AVIF-Qualität bei 50 entspricht optisch oft der JPEG-Qualität bei 80 – passen Sie sie pro Asset an, nicht mit einer globalen Einstellung.

Vergrößerung vermeiden: Ändern Sie die Größe der Quelle, komprimieren Sie eine 4000-Pixel-Datei nicht, die über CSS in 400 Pixel angezeigt wird. Logos bleiben im SVG-Format – nicht im AVIF-Format.

Bei Bannern mit unterschiedlichem Mobil-/Desktop-Zuschnitt ermöglicht das „Medien“-Attribut auf „<Quelle>“ die Art Direction, ohne dass die gesamte Seite dupliziert wird.

Conversion-Pipeline: Erstellen oder spontan

Static Build (Sharp, Squoosh, ImageMagick in CI) eignet sich für bekannte Assets: Helden, Symbole, Marketing-Visuals. Generieren Sie AVIF, WebP und JPEG aus einem PNG- oder TIFF-Master. Name mit Hash + Cache-Control long.

Konvertierung im laufenden Betrieb (imgproxy, Cloudflare Polish, dedizierter Bilddienst) passt sich an Benutzer-Uploads im E-Commerce oder CMS an. Asynchron kodieren – ein Upload muss nicht dreißig Sekunden auf die AVIF-Konvertierung warten. Das Ergebnis aggressiv zwischenspeichern.

Barrierefreiheit und SEO-Bilder

Das beschreibende „alt“-Attribut verbleibt im „img“-Fallback-Tag. Für dekorative Bilder ist alt="" explizit. Stabile URLs und eine Bild-Sitemap helfen bei der Indexierung – Google liest WebP und AVIF, aber der JPEG-Fallback beruhigt konservative Crawler.

Löschen Sie das JPEG nicht, „weil es niemand verwendet“, ohne es zu messen: Analysen und Serverprotokolle zeigen oft eine unterschätzte Legacy-Warteschlange.

Der Gipfel: modernes Format, Publikum ausgeschlossen

Folgendes misst der Lighthouse-Score nicht.

Gute Bilder = Formataushandlung plus Fallback plus Dimensionen – kein einziger MIME-Typ, der jedem auferlegt wird.

Entscheide dich und gehe ohne blinden Fleck voran

Vor der nächsten optischen Überarbeitung:

1. Implementieren „<Bild>“ mit AVIF-, WebP- und JPEG-Fallback auf Hero-Visuals.
2. Konfigurieren „srcset“ und „sizes“ für Responsive – Breite/Höhe auf jedem „img“.
3. Wählen Sie je nach Quelle der Bilder (Marketing oder CMS-Uploads) statischen Build oder spontane Konvertierung.
4. Überprüfen Variieren: Akzeptieren, wenn das CDN das Format aushandelt – Querverweis mit der Cache-Richtlinie.
5. Test auf Safari 14, Edge Legacy und mit deaktiviertem JavaScript: Bleiben Heldenbilder sichtbar?
6. Vergleichen Image-CDN und Hosting über das Verzeichnis und den Vergleicher.

Für statische Assets gehen Sie zu HTTP/2: Eine geringere Gewichtung pro Bild vervielfacht den Effekt des Multiplexings.

Häufig gestellte Fragen

AVIF oder WebP als Priorität?

AVIF komprimiert besser (oft 20–50 % weniger als WebP), kodiert jedoch langsamer und bietet etwas neuere Unterstützung. WebP bleibt ein hervorragender Kompromiss. Stellen Sie AVIF als erste Quelle, WebP als zweite und JPEG als Fallback über „<picture>“ bereit.

Wie wird das richtige Format bereitgestellt?

Über „<picture>“ mit „<source type="image/avif">- und „<source type="image/webp">-Tags sowie einem „<img src="...jpg">`-Fallback. Alternative: CDN verhandelt den Accept-Header – mit „Vary: Accept“ und angepasstem Cache-Schlüssel.

Und Bild-SEO?

Behalten Sie ein beschreibendes „Alt“ für das Fallback-Bild, stabile URLs und eine Bild-Sitemap bei. Google indiziert WebP und AVIF; Der JPEG-Fallback beruhigt die konservativsten Crawler.

Konvertierung auf der Build-Seite oder im laufenden Betrieb?

Erstellen Sie für bekannte Marketingressourcen (CI + Sharp). Asynchrone Konvertierung im laufenden Betrieb für CMS-Uploads – mit aggressivem Caching des Ergebnisses. Blockieren Sie niemals eine Benutzeranfrage bei langsamer AVIF-Kodierung.

Das Format ohne Rückgriff zu modernisieren bedeutet, graue Quadrate zu akzeptieren, bei denen es immer noch auf das Geschäft ankommt.