Bilder: der größte Posten im Seitengewicht

Bilder sind auf den meisten Websites der größte Posten im Seitengewicht — und der, der sich am leichtesten verkleinern lässt. Vier Dinge entscheiden darüber: Ein Bild ist nicht breiter als der Bereich, in dem es angezeigt wird. Es liegt in einem modernen Format vor, also WebP oder AVIF. Der Browser lädt nur eine Fassung davon, nicht mehrere. Und das große Bild im sichtbaren Bereich wird bevorzugt geladen statt verzögert, mit festen Abmessungen, damit nichts springt.

Warum gerade die Bilder?

Das HTTP Archive misst jedes Jahr Millionen Websites. 2025 bestand die mittlere mobile Startseite aus 911 KB Bildern — mehr als jede andere Art von Inhalt, noch vor JavaScript und Schriften. Bei rund drei Vierteln der mobilen Seiten ist außerdem ein Bild das größte sichtbare Element beim Laden, also genau das Element, an dem die Ladezeit-Kennzahl LCP gemessen wird.

Wer eine langsame Seite schneller machen will, schaut deshalb zuerst auf die Bilder. Fast jedes Bildproblem ist eine Mischung aus vier Fehlern:

• Falsche Abmessungen. Das Bild ist 4000 Pixel breit und wird in einem 800 Pixel breiten Bereich gezeigt. Der Browser lädt alles und rechnet es herunter.
• Altes Format. JPEG und PNG statt WebP oder AVIF.
• Keine Komprimierung. Auch ein WebP kann unnötig schwer sein.
• Mehrere Fassungen gleichzeitig. Drei Varianten desselben Bildes stehen im HTML und werden per CSS ein- und ausgeblendet. Geladen werden alle drei.

Die richtigen Abmessungen

Ein Bild soll nicht breiter sein als der Bereich, in dem es angezeigt wird — für hochauflösende Bildschirme darf die Datei entsprechend mehr Pixel haben, aber nicht beliebig viele. Die sinnvollen Breiten ergeben sich aus deinem eigenen Layout: aus den Umbruchpunkten und der maximalen Inhaltsbreite deiner Seite, nicht aus einer allgemeinen Tabelle.

Für kleine Bilder gilt dasselbe im Kleinen. Ein Produktbild, das auf allen Geräten ungefähr gleich groß erscheint, braucht keine drei Fassungen.

Ein Hinweis für die Zusammenarbeit: Wer Bilder bei einer Fotografin oder einer Agentur bestellt, sollte die Zielbreiten gleich mitgeben. Sonst kommen Dateien direkt aus der Kamera, und jemand muss die Arbeit ein zweites Mal machen.

Das richtige Format

Format	Wofür	Was es bringt
WebP	Fotos und Grafiken, die Standardwahl	verlustbehaftet 25 bis 34 Prozent kleiner als JPEG, verlustfrei 26 Prozent kleiner als PNG
AVIF	Fotos, wo es auf jedes Kilobyte ankommt	laut MDN rund 50 Prozent kleiner als JPEG
SVG	Logos, Symbole, Diagramme	Vektorgrafik, verlustfrei skalierbar
JPEG, PNG	Dateien zum Herunterladen, Ausweichfassung	—

WebP ist die sichere Standardwahl: Es wird von allen aktuellen Browsern unterstützt. AVIF komprimiert noch stärker und läuft inzwischen ebenfalls in allen großen Browsern — Chrome seit Version 85, Firefox seit 93, Safari seit 16.1, Edge seit 121. Zwei Einschränkungen nennt MDN: Für ältere Browser ist eine Ausweichfassung sinnvoll, und AVIF wird nicht schrittweise aufgebaut, sondern erst angezeigt, wenn die Datei vollständig geladen ist.

Wie weit das Netz davon noch entfernt ist, zeigt der Web Almanac 2024: JPEG und PNG machen zusammen rund 61 Prozent aller Bildabrufe aus, WebP 12 Prozent, AVIF 1 Prozent. Gemessen an den Bits pro Bildpunkt ist WebP dabei mit 1,3 deutlich sparsamer als JPEG mit 2,0 und PNG mit 3,8.

Die Umwandlung erledigt in WordPress am besten ein Plugin, das beim Hochladen automatisch umwandelt und komprimiert. Das ist wichtiger als die einmalige Umstellung des Bestands — sonst lädt in drei Monaten jemand wieder ein Kamerafoto hoch, und das Problem ist zurück.

Wie schwer darf ein Bild sein?

Eine feste Grenze gibt es nicht, aber einen Maßstab. Laut Web Almanac 2024 wiegt das mittlere Bild im Netz 12 KB, und das größte Bild einer Seite im Mittel 135 KB. Ein großes Kopfbild darf darüber liegen, weil es die Darstellung beherrscht. Eine Datei im Megabyte-Bereich ist dagegen fast immer ein Zeichen dafür, dass Abmessungen, Format oder Komprimierung nicht stimmen.

Vergleich die Dateigröße nicht mit einer Faustregel, sondern mit der Anzeigegröße: Ein Bild, das 800 Pixel breit gezeigt wird, hat als 4000-Pixel-Datei keinen Grund.

Nur eine Fassung laden

Für Bilder, die auf verschiedenen Geräten unterschiedlich zugeschnitten sein sollen, gibt es das <picture>-Element. Der Browser prüft die <source>-Einträge der Reihe nach und nimmt den ersten, dessen Bedingung passt — geladen wird genau eine Datei:

<picture>
  <source media="(max-width: 576px)"
          srcset="werkstatt-576.webp"
          width="576" height="576">
  <source media="(max-width: 960px)"
          srcset="werkstatt-960.webp"
          width="960" height="770">
  <img src="werkstatt-1920.webp"
       width="1920" height="893"
       alt="Werkstatt mit zwei Arbeitsplätzen">
</picture>

Zwei Dinge, die man dabei falsch machen kann:

• Die Reihenfolge. Weil der erste Treffer zählt, gehört bei max-width-Bedingungen der kleinste Umbruchpunkt nach oben. Steht die breiteste Bedingung zuerst, passt sie auf fast jedes Gerät.
• Das <img> am Ende ist Pflicht. Es beschreibt das Bild, trägt den Alternativtext und ist die Ausweichfassung, wenn keine <source> passt.

Soll dasselbe Bild nur in verschiedenen Auflösungen ausgeliefert werden, ohne dass sich der Ausschnitt ändert, reicht srcset mit sizes direkt am <img>. WordPress erzeugt das seit Version 4.4 automatisch für Bilder aus der Mediathek — ein guter Grund, Bilder über die Mediathek einzubinden statt fest zu verlinken.

Verzögert laden — außer das Hauptbild

Bilder, die erst nach dem Scrollen sichtbar werden, müssen nicht sofort geladen werden:

<img src="referenz.webp" loading="lazy" width="800" height="600" alt="…">

Die Ausnahme ist wichtig: Das große Bild im sichtbaren Bereich darf nicht verzögert geladen werden. web.dev schreibt ausdrücklich, Bilder, die beim Laden wahrscheinlich im sichtbaren Bereich liegen, und besonders das LCP-Bild nicht verzögert zu laden. Trotzdem tun das laut Web Almanac 2025 16 bis 17 Prozent der Seiten.

Richtig ist dort das Gegenteil, die hohe Ladepriorität:

<img src="kopfbild.webp" fetchpriority="high" width="1920" height="893" alt="…">

Bei Google Flights sank der LCP-Wert damit von 2,6 auf 1,9 Sekunden. WordPress setzt fetchpriority="high" seit Version 6.3 selbst auf das Bild, das es für das LCP-Bild hält, und lässt dort das verzögerte Laden weg. Der Fehler entsteht meist durch Plugins oder Baukästen, die pauschal alle Bilder auf verzögertes Laden stellen. Prüf nach jeder solchen Installation, ob das Kopfbild ausgenommen ist.

Bilder und springende Layouts

Setz width und height an jedes Bild. Nicht als Gestaltungsangabe, sondern als Information für den Browser: Er berechnet daraus das Seitenverhältnis und reserviert den Platz, bevor das Bild da ist. Ohne diese Angaben springt alles darunter, sobald das Bild ankommt. Laut Web Almanac 2025 haben 62 Prozent der mobilen Seiten mindestens ein Bild ohne Abmessungen.

Damit das Bild trotzdem beweglich bleibt:

img {
  max-width: 100%;
  height: auto;
}

Die Attribute reservieren den Platz, das CSS macht das Bild anpassbar.

Ein verwandter Fall: Elemente, die mit display: none versteckt sind und später erscheinen — Hinweisleisten, Banner, nachgeladene Inhalte. Sie belegen vorher keinen Platz und schieben beim Erscheinen alles nach unten. Reserviere den Platz von Anfang an, etwa mit min-height, oder blende das Element mit opacity: 0 aus, dann behält es seinen Platz.

Der Sonderfall Hintergrundbilder

Bilder, die per CSS als Hintergrund eingebunden sind, verhalten sich anders:

• Sie stehen nicht im HTML und tragen keinen Alternativtext. Für Dekoration ist das richtig, für Bilder mit Inhalt falsch.
• Der Browser entdeckt sie erst, wenn er das CSS ausgewertet hat. Ist ein Hintergrundbild das LCP-Element, braucht es laut web.dev ein preload, am besten mit fetchpriority="high".
• loading="lazy" funktioniert dort nicht — das Attribut gehört an das <img>-Element, nicht ins CSS.

Als Regel: Dekoration darf Hintergrundbild sein. Inhalt gehört ins HTML.

Wie du das selbst prüfst

• Der Netzwerk-Reiter. Entwicklerwerkzeuge öffnen (F12), Reiter Netzwerk, Filter „Img", Seite neu laden, nach Größe sortieren. Ganz oben stehen deine Problembilder. Dort siehst du auch, ob mehrere Fassungen desselben Bildes geladen werden.
• Der Rechtsklick. „Bild in neuem Tab öffnen" zeigt die echten Abmessungen. Vergleich sie mit der Breite, in der das Bild auf der Seite erscheint.
• PageSpeed Insights. Seit Lighthouse 13 sind die früheren Einzelprüfungen zu Format, Größe und Komprimierung in einem Hinweis zusammengefasst, „Improve image delivery". Er listet die betroffenen Dateien mit der möglichen Ersparnis in Kilobyte.
• Der Drosselungstest. Im Netzwerk-Reiter eine langsame Verbindung einstellen und neu laden. In Zeitlupe siehst du, welches Bild nachlädt und was dabei verrutscht.
• Die Mediathek. In WordPress nach großen Dateien durchsehen. Alles im Megabyte-Bereich ist ein Kandidat.

Was zu tun ist

1. Richte die automatische Verarbeitung beim Hochladen ein: Umwandlung in WebP oder AVIF, Komprimierung, Größenvarianten. Das verhindert, dass das Problem wiederkommt.
2. Nimm dir die zehn größten Bilder vor, nicht alle. Meist machen wenige Dateien den größten Teil des Gewichts aus.
3. Prüf das Kopfbild gesondert: passende Größe, fetchpriority="high", kein loading="lazy", Abmessungen gesetzt.
4. Setz width und height überall — besonders bei Bildern aus Baukasten-Bausteinen und handgeschriebenem HTML.
5. Räum den Bestand auf: doppelte Uploads und Bilder von Seiten, die es nicht mehr gibt. Das macht die Mediathek und die Datensicherung kleiner.

Und eine Erwartung geraderücken: Bildoptimierung ist keine einmalige Aufgabe. Sie ist eine Einstellung, die einmal richtig gesetzt wird, plus eine Gewohnheit bei jedem neuen Bild. Ohne beides ist die Website nach einem Jahr Inhaltspflege wieder da, wo sie vorher war.

Quellen

• HTTP Archive, Web Almanac 2025, Page Weight — 911 KB Bilder auf der mittleren mobilen Startseite, Bilder als größter Posten: almanac.httparchive.org
• HTTP Archive, Web Almanac 2025, Performance — Bild als LCP-Element, 16 bis 17 Prozent verzögert geladene LCP-Bilder, 62 Prozent mit Bildern ohne Abmessungen: almanac.httparchive.org
• HTTP Archive, Web Almanac 2024, Media — Formatanteile, Bits pro Bildpunkt, 12 KB und 135 KB im Mittel: almanac.httparchive.org
• Google for Developers, An image format for the Web — WebP 25 bis 34 Prozent kleiner als JPEG, 26 Prozent kleiner als PNG: developers.google.com
• MDN, Image file type and format guide — AVIF rund 50 Prozent kleiner als JPEG, Browserunterstützung, kein schrittweiser Aufbau, SVG für Grafiken: developer.mozilla.org
• MDN, das <picture>-Element — Auswahl der Quelle, Rolle des <img>: developer.mozilla.org
• WordPress Core, Responsive Images in WordPress 4.4 — automatisches srcset und sizes: make.wordpress.org
• web.dev, Browser-level image lazy loading — kein verzögertes Laden für sichtbare und LCP-Bilder, kein loading für CSS-Hintergründe: web.dev
• web.dev, Optimize resource loading with the Fetch Priority API — Google Flights 2,6 auf 1,9 Sekunden, preload für Hintergrundbilder: web.dev
• WordPress Core, Image performance enhancements in WordPress 6.3 — automatisches fetchpriority für das LCP-Bild: make.wordpress.org
• web.dev, Optimize Cumulative Layout Shift — width und height, Platz für nachgeladene Inhalte reservieren: web.dev
• Chrome for Developers, Properly size images — seit Lighthouse 13 Teil von „Improve image delivery": developer.chrome.com