Bilder für Websites optimieren: Format, Pixelgröße und Einbindung

Auf vielen Seiten machen Bilder den größten Teil der übertragenen Daten aus. Drei Dinge entscheiden, wie viel davon nötig ist: das Format, die Größe in Pixeln und die Art, wie das Bild in die Seite eingebunden wird. Wir zeigen das an unserer eigenen Website, pixupmedia.com. Alle Zahlen hier stammen aus Messungen an dieser Seite und an unserem eigenen Repository, nicht an Kundenprojekten.

Dieselben Bilder, drei Formate

Beim Umzug unserer Website am 08.09.2026 mussten 134 Showcase-Bilder von Wix auf unseren eigenen Server. Dabei fiel etwas auf: Die Bildadressen von Wix liefern je nach Anfrage ein anderes Format. Ein Browser schickt im Accept-Header mit, welche Bildformate er kennt, und bekommt dann AVIF. Ein Download-Werkzeug ohne diese Angabe bekommt den PNG- oder JPEG-Rückfall.

Für ein einzelnes Bild waren das 777 KB ohne Formatangabe und 65 KB als AVIF, Faktor 12. Für alle 134 Bilder:

AVIF brauchte also rund ein Siebtel der Daten des Rückfalls. Hätten wir die Bilder einfach heruntergeladen, wären die Showcase-Seiten ein Vielfaches schwerer geworden. Geholt haben wir stattdessen die AVIF- und WebP-Fassungen, so wie ein Browser sie bekommt.

Am 11.11.2026 haben wir die Messung an einer früheren Wix-Bildadresse wiederholt, 1600 × 900 Pixel groß. Ohne Bildformat-Angabe kamen rund 152 KB JPEG, mit WebP-Angabe rund 114 KB WebP, mit AVIF-Angabe rund 46 KB AVIF. Das Verhältnis ist bei diesem Bild kleiner, die Richtung dieselbe.

Welches Format wofür

Laut der Entwicklerdokumentation MDN unterstützen Chrome, Edge, Opera, Safari und Firefox AVIF. MDN empfiehlt trotzdem einen Rückfall in WebP, JPEG oder PNG, weil die Unterstützung noch nicht lückenlos ist. Außerdem baut sich ein AVIF-Bild nicht schrittweise auf: Es erscheint erst, wenn es vollständig geladen ist. Bei kleinen Dateien fällt das kaum ins Gewicht, bei sehr großen schon.

Einbindung: Der Browser wählt

Auf pixupmedia.com binden wir Bilder über das Element <picture> ein. Vereinfacht sieht das so aus:

<picture>
  <source srcset="/artikel/bild.avif" type="image/avif">
  <source srcset="/artikel/bild.webp" type="image/webp">
  <img src="/artikel/bild.webp" alt="Beschreibung des Bildes"
       width="1600" height="900" loading="lazy" decoding="async">
</picture>

Der Browser geht die Quellen von oben nach unten durch und nimmt die erste, deren Format er kennt. Das img am Ende ist der Rückfall und trägt Alternativtext, Breite und Höhe.

Anders als bei Wix entscheidet hier nicht der Server. Jede Adresse liefert immer dieselbe Datei. Am 11.11.2026 gemessen: Unsere AVIF-Adresse einer Artikelgrafik lieferte mit und ohne Accept-Header dieselbe Datei mit 40622 Bytes und dem Typ image/avif. Das macht Zwischenspeicher und CDN einfach, weil es pro Adresse nur eine Fassung gibt.

Breite, Höhe und Ladezeitpunkt

• width und height sagen dem Browser vor dem Laden, wie viel Platz das Bild braucht. Ohne diese Angabe springt der Inhalt, sobald das Bild da ist. Das misst Google als Layoutverschiebung. Mehr dazu im Ratgeber Core Web Vitals im Onlineshop.
• loading="lazy" für Bilder weiter unten. Unsere Showcase-Galerien laden so erst, wenn man dorthin scrollt.
• Das große Bild oben sofort laden. Unser Startseitenbild hat kein lazy, dafür fetchpriority="high". Es ist oft das größte sichtbare Element und bestimmt damit, wann die Seite fertig wirkt.

Nicht mehr Pixel als nötig

Ein Bild mit 4000 Pixeln Breite, das auf der Seite 700 Pixel breit erscheint, überträgt viele Daten für nichts. Unser Skript für Screenshots begrenzt die Breite deshalb auf 1600 Pixel. Im Layout erscheinen Screenshots höchstens etwa 700 CSS-Pixel breit; 1600 Pixel reichen damit auch für Bildschirme mit doppelter Pixeldichte.

Ehrlich gesagt: Mit srcset und sizes könnte man Mobilgeräten zusätzlich kleinere Fassungen schicken. Auf pixupmedia.com nutzen wir srcset bisher nur zur Formatauswahl (AVIF, WebP, Rückfall), nicht zur Auswahl der Breite. Am 12.11.2026 haben wir alle 245 ausgelieferten Seiten aus unserer Sitemap geprüft: 886 srcset-Angaben, keine davon mit Breitenangabe (w). Jedes Bild kommt also in einer Breite, auf dem Smartphone wie am Desktop. Das ist kein Optimum.

Wie wir unsere Bilder erzeugen

Screenshots und Artikelgrafiken erzeugen wir per Skript mit der Bibliothek sharp, nicht von Hand:

• Screenshots werden aus PNG oder JPEG in AVIF (Qualität 55) und WebP (Qualität 82) umgewandelt, höchstens 1600 Pixel breit.
• Artikelgrafiken wie die über diesem Text zeichnen wir als SVG und rastern sie in AVIF (Qualität 62) und WebP (Qualität 88). Das SVG liegt versioniert im Repository, jede Grafik lässt sich neu erzeugen.

Was das bringt, haben wir am 11.11.2026 im Repository nachgezählt:

Bei den Showcase-Bildern schwankt der Wert je Bild zwischen 7 und 97 Prozent. Wie viel AVIF spart, hängt also stark vom Motiv ab. Die Qualitätseinstellungen von AVIF und WebP sind in unseren Skripten nicht gleich gewählt. Die Tabelle zeigt, was wir tatsächlich ausliefern, keinen Formatvergleich unter Laborbedingungen.

Ausgeliefert am 11.11.2026, gemessen auf pixupmedia.com:

Dateien, deren Name einen Prüfwert enthält, liefert unser Server mit einer Cache-Dauer von einem Jahr aus. Ändert sich das Bild, ändert sich der Name, und der Browser lädt es neu.

Das Format spart am meisten, die Pixelgröße am zweitmeisten. Mit <picture> wählt der Browser das beste Format, das er kennt. Und beim Umzug zählt, was tatsächlich geliefert wird, nicht was die Adresse verspricht.

Wenn Bilder Ihren Shop bremsen und Sie die Ursache genauer eingrenzen wollen, hilft unsere Performance-Optimierung. Wie wir Websites von Grund auf bauen, beschreibt die Seite Webseiten-Erstellung.