Bildauslieferung: AVIF und WebP mit Fallbacks, Lazy Loading und Fetch Priority

Worum es geht

Drei Entscheidungen auf <img>-Ebene, die unabhängig von der responsiven Grössenwahl sind. Format: Der Format-Leitfaden von MDN beschreibt AVIF und WebP als stärker komprimierend als JPEG und PNG, weist darauf hin, dass ihre Unterstützung neuer ist (WebP breit, aber nicht historisch verfügbar, AVIF schmaler), und rät, über <picture> einen JPEG- oder PNG-Fallback einzubinden. In <picture> wird jede <source type="image/avif"> übersprungen, wenn der Browser diesen MIME-Typ nicht unterstützt, und das abschliessende <img> ist zugleich der Fallback und das Element, das alt, Grössen- und Loading-Attribute trägt. Laden: loading="lazy" verzögert den Abruf, bis sich das Bild innerhalb einer browserdefinierten Distanz zum Viewport befindet; fetchpriority="high" oder "low" gibt einen Hinweis darauf, wie das Bild im Vergleich zu anderen Bildern eingestuft wird; decoding="async" erlaubt es, dass der nächste Paint-Vorgang fortgesetzt wird, bevor die Dekodierung abgeschlossen ist.

Warum es wichtig ist

Bilder sind in der Regel die schwersten Bytes auf einer Seite und häufig der Largest Contentful Paint. Falsche Entscheidungen zeigen sich direkt in den Web Vitals: ein per Lazy Loading geladenes Hero-Bild verzögert den LCP, fehlende Abmessungen bei Lazy-Bildern verursachen Layout-Verschiebungen, und das Ausliefern von JPEG an einen Browser, der AVIF akzeptiert, verschwendet bei jedem Aufruf Bandbreite.

So wird es angewendet

• Jedes Bild einmal pro Format zur Build-Zeit oder in einem Bilddienst codieren und das JPEG oder PNG als <img src> beibehalten, damit Crawler, ältere Clients und Kopieren-und-Einfügen eine nutzbare Datei erhalten.
• <source>-Elemente von der besten zur schlechtesten Kompression ordnen; der erste unterstützte Typ gewinnt.
• Auf einem Server, der aushandeln kann, den Accept-Anfrage-Header nutzen und Vary: Accept ergänzen, damit Caches kein AVIF an einen Browser ausliefern, der es nicht darstellen kann. Für statisches Hosting bei <picture> bleiben.
• Das LCP-Bild oder alles im ersten Viewport niemals per Lazy Loading laden; diesem Bild fetchpriority="high" geben. Bilder und iframes unterhalb des sichtbaren Bereichs per Lazy Loading laden.
• width und height (oder aspect-ratio) bei jedem lazy geladenen Bild setzen. MDN weist darauf hin, dass nicht geladene Bilder die Grösse 0 haben und möglicherweise nie geladen werden, wenn sie keinen sichtbaren Bereich schneiden.
• alt beim <img> belassen; <source>-Elemente fügen keinen zugänglichen Namen hinzu.

Stolpersteine

loading="lazy", wahllos auf jedes Bild gestreut, einschliesslich des ersten Viewports, erzeugt eine Kaskade verspäteter Anfragen. Die Lazy-Loading-Distanz ist browserdefiniert und ändert sich zwischen Versionen; das Layout nicht darauf abstimmen. fetchpriority ist ein Hinweis, kein Befehl. Ein <picture>, dessen <img> kein srcset besitzt, liefert weiterhin eine einzige Grösse an alle Bildschirme aus; mit dem Artikel zu responsiven Bildern kombinieren.