Website-Bilder optimieren 2026: WebP, Komprimierung & Lazy Loading für schnelle Ladezeiten

Es gibt einen Fehler, den ich in fast jedem Performance-Audit sehe, und er ist immer derselbe: ein riesiges, unkomprimiertes Foto, das direkt aus der Handykamera in die Website gewandert ist – 4.000 Pixel breit, fünf Megabyte schwer, dargestellt auf 600 Pixel. Der Besucher lädt das Vielfache dessen herunter, was er je zu sehen bekommt. Bilder sind auf den meisten Websites mit Abstand der größte Datenposten – und damit der erste und billigste Hebel, um eine langsame Seite schnell zu machen.

Kurz gesagt: Website-Bilder optimieren heißt, drei Dinge in Ordnung zu bringen: Format (Fotos als WebP oder AVIF statt JPEG/PNG – laut Google sind WebP-Dateien 25–34 % kleiner als vergleichbare JPEGs), Größe (Bilder nur so groß hochladen, wie sie dargestellt werden, und mit einer Qualitätsstufe um 75–85 % komprimieren) und Auslieferung (feste width- und height-Angaben gegen springendes Layout, loading="lazy" für Bilder weiter unten auf der Seite). Diese drei Schritte verbessern direkt die Core Web Vitals – vor allem LCP (Ladezeit) und CLS (visuelle Stabilität) – und brauchen weder Programmierkenntnisse noch Budget. Ein einziges überdimensioniertes Titelbild kann eine ansonsten saubere Seite ausbremsen; ein paar Minuten Komprimierung machen den Unterschied zwischen „lädt sofort” und „der Besucher ist schon weg”.

Auf einen Blick

• Format vor allem anderen: Fotos als WebP/AVIF ausliefern – meist 25–34 % (WebP) bis über 50 % (AVIF) kleiner als JPEG bei gleicher sichtbarer Qualität.
• Nicht größer als nötig: Ein Bild, das 800 Pixel breit angezeigt wird, braucht keine 4.000 Pixel. Abmessungen reduzieren spart oft mehr als jede Komprimierung.
• Layout ruhig halten: Jedes Bild bekommt feste width- und height-Angaben – sonst springt der Text beim Nachladen (schlechter CLS).
• Lazy Loading – aber nicht überall: loading="lazy" für Bilder unterhalb des sichtbaren Bereichs; das wichtigste Bild oben lädt bewusst sofort.

Warum Bilder der wichtigste Performance-Hebel sind

Bildoptimierung ist die Summe aller Maßnahmen, die ein Bild bei gleichbleibender sichtbarer Qualität so klein und schnell ladbar wie möglich machen – durch das richtige Dateiformat, die passenden Pixel-Abmessungen, sinnvolle Komprimierung und eine browserfreundliche Einbindung. Sie ist der Bereich mit dem besten Verhältnis von Aufwand zu Wirkung.

Der Grund ist simpel: Über alle Websites hinweg sind Bilder typischerweise die Ressourcenart mit dem größten Datenvolumen – noch vor JavaScript und Schriften (siehe HTTP Archive Web Almanac, Kapitel Media). Und das größte Bild im sichtbaren Bereich ist auf den meisten Seiten genau das Element, das den LCP-Wert (Largest Contentful Paint) bestimmt – also den Core Web Vital, der misst, wann die Seite „gefühlt da” ist. Wer dieses eine Bild zähmt, verbessert oft mit einem Handgriff den wichtigsten Performance-Messwert.

Das ist die gute Nachricht für kleine Unternehmen ohne Technik-Team: Der wirksamste Hebel verlangt keine Programmierung, sondern Sorgfalt beim Hochladen.

Schritt 1: Das richtige Format wählen

Das Format entscheidet, wie effizient ein Bild überhaupt komprimiert werden kann. Die Wahl ist 2026 unkompliziert:

WebP ist ein von Google entwickeltes Bildformat, das Fotos bei vergleichbarer sichtbarer Qualität deutlich kleiner speichert als JPEG. Laut Google sind WebP-Dateien mit Qualitätsverlust 25–34 % kleiner als vergleichbare JPEGs und WebP-Dateien ohne Qualitätsverlust 26 % kleiner als PNGs. WebP wird heute von allen aktuellen Browsern unterstützt.

AVIF ist ein neueres, auf dem AV1-Videocodec basierendes Bildformat, das Fotos in vielen Fällen noch stärker komprimiert als WebP – oft um mehr als die Hälfte gegenüber JPEG. Die Browser-Unterstützung ist 2026 breit, aber noch nicht ganz so universell wie bei WebP. Deshalb gilt: AVIF mit WebP als Rückfallebene ausliefern, dann ist man auf der sicheren Seite.

SVG (Scalable Vector Graphics) ist ein vektorbasiertes Format, das Grafiken nicht als Pixelraster, sondern als mathematische Formen speichert – dadurch bleibt es bei jeder Größe gestochen scharf und meist nur wenige Kilobyte groß. Für Logos und Icons gibt es nichts Besseres; ein Foto lässt sich damit aber nicht darstellen.

Schritt 2: Auf die richtige Größe bringen

Bevor man komprimiert, kommt der Schritt, der am meisten spart und am häufigsten vergessen wird: die Pixel-Abmessungen reduzieren.

Ein Bild, das auf der Seite maximal 800 Pixel breit dargestellt wird, muss nicht 4.000 Pixel breit hochgeladen werden. Für hochauflösende „Retina”-Displays reicht die doppelte Anzeigebreite – also rund 1.600 Pixel – vollkommen aus. Alles darüber ist verschwendetes Datenvolumen, das niemand sieht.

Faustregeln für die Praxis:

• Großes Titelbild über die volle Breite: maximal ~2.000 Pixel breit, Ziel unter 250 KB.
• Normales Inhaltsbild: in der doppelten Anzeigebreite, Ziel unter 150–200 KB.
• Vorschaubilder / Logos: ein paar hundert Pixel, oft unter 30 KB.

Erst nach dem Verkleinern der Abmessungen kommt die Komprimierung. Beides zusammen verwandelt ein Fünf-Megabyte-Foto regelmäßig in eine Datei von unter 150 Kilobyte – also auf rund ein Dreißigstel – ohne sichtbaren Qualitätsverlust.

Komprimieren ohne Qualitätsverlust

Bei der Komprimierung stellt man eine Qualitätsstufe ein. Eine Stufe von 75–85 % ist fast immer der richtige Kompromiss: deutlich kleinere Datei, für das Auge kein Unterschied zum Original. Sichtbare Artefakte (matschige Flächen, Farbränder) entstehen erst darunter.

Kostenlose Werkzeuge, die das ohne Programmierkenntnisse erledigen:

Mein Tipp aus der Praxis: Squoosh zeigt beim Konvertieren live die neue Dateigröße und einen direkten Bildvergleich an. Damit findet man in Sekunden die niedrigste Qualitätsstufe, bei der das Bild noch perfekt aussieht – das ist die effizienteste Einstellung.

Schritt 3: Bilder richtig einbinden

Das beste komprimierte Bild bringt wenig, wenn es falsch eingebunden ist. Drei technische Details machen den Unterschied – und alle drei wirken direkt auf die Core Web Vitals.

width und height immer angeben (gegen Layout-Sprünge)

Jedes <img>-Element sollte feste Breiten- und Höhenangaben haben. Fehlen sie, weiß der Browser beim Aufbau nicht, wie viel Platz das Bild brauchen wird – der Text wird zunächst gesetzt und springt dann nach unten, sobald das Bild nachlädt. Genau das misst der CLS-Wert (Cumulative Layout Shift), und genau das ist das alltägliche Ärgernis, bei dem man im falschen Moment auf den falschen Button tippt. Mit width- und height-Angaben reserviert der Browser den Platz von Anfang an.

loading="lazy" – aber gezielt

Lazy Loading bezeichnet das verzögerte Laden von Bildern: Sie werden erst geladen, wenn der Besucher beim Scrollen in ihre Nähe kommt, statt alle Bilder sofort beim Seitenaufruf herunterzuladen. In modernen Browsern genügt dafür das Attribut loading="lazy" direkt am Bild – kein Plugin, kein Skript nötig.

Die wichtige Ausnahme: Das wichtigste Bild im sofort sichtbaren Bereich (meist das Titelbild) sollte nicht per Lazy Loading verzögert werden. Verzögert man es, verschlechtert sich der LCP-Wert, weil der Browser das Laden des wichtigsten Bildes künstlich nach hinten schiebt. Faustregel: Alles oberhalb der ersten Bildschirmkante lädt sofort, alles darunter lazy.

Responsive Bilder mit srcset

Wer es ganz richtig machen will, liefert über das srcset-Attribut mehrere Bildgrößen aus und überlässt dem Browser die Wahl: Ein Handy bekommt die kleine Version, ein großer Desktop-Bildschirm die große. So lädt niemand mehr Pixel als nötig. Viele moderne Systeme und Astro-basierte Seiten erzeugen diese Größen automatisch beim Build – bei einer Handarbeit lohnt sich der Aufwand vor allem für das große Titelbild.

Die häufigsten Fehler – und die schnelle Korrektur

First-Party-Beispiel: wie diese Website es macht

Aus meiner eigenen Praxis als belegbares Beispiel: Diese Website (fabian-reiter.com) ist mit dem Static-Site-Generator Astro gebaut. Bilder werden beim Build automatisch in moderne Formate konvertiert, in mehreren Größen erzeugt und mit width/height-Angaben sowie passendem Lazy Loading ausgeliefert – der Build-Prozess erzwingt also genau die Sorgfalt, die man von Hand leicht vergisst. Das Ergebnis ist die Architektur, mit der die Core Web Vitals fast von selbst im grünen Bereich landen. Warum diese Bauweise grundsätzlich so schnell ist, beschreibe ich im Beitrag Website in unter 2 Sekunden: Performance mit Astro.

Wer dagegen eine WordPress-Seite betreibt, auf der die Bilder bremsen, findet die übrigen typischen Ursachen langsamer Ladezeiten im Beitrag WordPress-Website langsam? 7 echte Ursachen – Bilder sind dort fast immer Ursache Nummer eins.

Ehrliche Grenze: Bilder sind nur ein Teil der Performance

Perfekt optimierte Bilder machen eine technisch überladene Seite nicht automatisch schnell. Wenn im Hintergrund ein Dutzend Tracking-Skripte, schwere Seitenbaukasten-Plugins und render-blockierende Schriften laden, bleibt die Seite träge, egal wie schlank die Bilder sind. Bildoptimierung ist der erste und billigste Schritt – und oft der mit dem größten Einzeleffekt –, aber sie ersetzt keine saubere technische Basis. Wenn die Bilder optimiert sind und PageSpeed Insights trotzdem Rot zeigt, liegt die Ursache meist im JavaScript oder beim Hosting. Dann lohnt der Blick auf die Architektur, nicht auf das nächste Foto.

Fazit

Bilder sind auf den meisten Websites der größte Datenposten und damit der wirksamste erste Hebel für Tempo. Drei Schritte genügen: ins moderne Format bringen (WebP/AVIF statt JPEG/PNG, 25–34 % und mehr kleiner), auf die tatsächlich benötigte Größe reduzieren und komprimieren (Qualität 75–85 %, ohne sichtbaren Verlust) und sauber einbinden (width/height gegen Layout-Sprünge, gezieltes loading="lazy"). Das alles geht ohne Programmierkenntnisse und ohne Budget – und verbessert direkt LCP und CLS, die beiden Core Web Vitals, die über Anfragen statt Absprünge entscheiden.

Nächster Schritt: PageSpeed Insights zeigt bei Ihnen Rot, oder Ihre Seite lädt spürbar zäh – und Sie wissen nicht, ob es an den Bildern oder am Unterbau liegt? Bei einem Performance-Fix ab 390 € messe ich Ihre echten Felddaten, identifiziere die größten Bremsen (sehr oft die Bilder) und behebe sie der Wirkung nach. Schreiben Sie mir kurz Ihre Domain – ich sage Ihnen ehrlich, wo bei Ihnen das meiste Tempo zu holen ist.

Quellen

• Google – WebP: Ein neues Bildformat fürs Web (Google) – WebP-Dateien 25–34 % kleiner als JPEG, 26 % kleiner als PNG
• web.dev – Bilder optimieren („Optimize images”) (Google) – Komprimierung, moderne Formate, responsive Bilder
• web.dev – Largest Contentful Paint (LCP) (Google) – das größte sichtbare Bild als LCP-Element
• web.dev – Cumulative Layout Shift (CLS) (Google) – Layout-Sprünge durch fehlende Größenangaben
• MDN Web Docs – Lazy loading (Mozilla) – natives loading="lazy"
• HTTP Archive Web Almanac – Media (HTTP Archive) – Bilder als größter Datenposten typischer Websites
• First-Party-Angabe: Bild-Pipeline von fabian-reiter.com (Astro, automatische Format-/Größen-Konvertierung), Stand Juni 2026