Bilder für die Website optimieren: WebP, AVIF und Größe

Bilder für deine Website optimierst du in vier Schritten: Du wählst ein modernes Format wie WebP oder AVIF mit Fallback, lieferst das Bild in der Größe aus, in der es tatsächlich angezeigt wird, komprimierst es mit Augenmaß und lädst es zum richtigen Zeitpunkt. Das Hauptbild kommt sofort, alles weiter unten erst beim Scrollen. Wie das im Detail geht, was WebP und AVIF wirklich bringen und wie du das Ergebnis überprüfst, erfährst du hier.

Warum Bilder die Ladezeit bestimmen

Auf vielen Content-Websites und in Onlineshops machen Bilder den größten Teil der Daten aus, die eine Seite lädt. Außerdem entscheiden sie über eine der drei Core Web Vitals mit: Auf vielen Seiten ist das Element für den Largest Contentful Paint ein Bild, meist ein Titelbanner oder ein Produktfoto. Der LCP-Artikel auf web.dev nennt die Downloadzeit dieses Bildes ausdrücklich als einen von vier Bestandteilen der Kennzahl.

Auch für ein stabiles Layout spielen Bilder eine Rolle. Hat ein Bild keinen reservierten Platz, schiebt es beim Laden den Text nach unten, und das verschlechtert den Cumulative Layout Shift. Wie die Kennzahlen zusammenhängen, erklärt unser Ratgeber Core Web Vitals verbessern.

Die gute Nachricht: Bildprobleme sind meist schnell gefunden und behoben, und an der eigentlichen Anwendung musst du dafür nichts ändern.

Das passende Format wählen

Jedes Format hat seinen Zweck. Wer das falsche nimmt, produziert schnell unnötig große Dateien.

Ein paar Faustregeln:

• Speichere Fotos nie als PNG. Ein Foto im PNG-Format ist oft deutlich größer als dasselbe Foto als JPEG, ohne dass man einen Unterschied sieht.
• Nutze SVG für Logos und Icons statt PNG-Sprites. Verwende aber nur SVGs aus vertrauenswürdigen Quellen, denn sie können Skripte enthalten.
• Ersetze animierte GIFs durch Videos. Eine kurze MP4- oder WebM-Schleife ist viel kleiner als dieselbe Animation als GIF.

Was WebP und AVIF wirklich bringen

WebP und AVIF sind neuere Kompressionsverfahren. Bei gleicher sichtbarer Qualität erzeugen sie in der Regel kleinere Dateien als JPEG und PNG, und AVIF holt oft noch etwas mehr heraus als WebP, vor allem bei Fotos mit weichen Farbverläufen. Wie viel du einsparst, hängt vom Motiv und von der Qualitätseinstellung ab. Eine seriöse Pauschalzahl gibt es deshalb nicht.

Was sich nicht ändert, sind die Abmessungen. Ein 4000 Pixel breites AVIF in einer 600 Pixel breiten Spalte bleibt Verschwendung. Format und Größe sind zwei getrennte Baustellen, und du musst dich um beide kümmern.

Ältere Browser, die ein Format nicht kennen, brauchen einen Fallback. Den kannst du im HTML mit <picture> lösen oder auf dem Server, der anhand des Accept-Headers pro Anfrage das passende Format wählt.

<picture>
  <source srcset="/images/team.avif" type="image/avif">
  <source srcset="/images/team.webp" type="image/webp">
  <img src="/images/team.jpg" alt="Unser Team im Büro" width="1200" height="800">
</picture>

Die richtige Größe ausliefern

Der Klassiker unter den Fehlern: Ein Foto wandert direkt von Kamera oder Smartphone auf die Website, und CSS verkleinert es auf die Spaltenbreite. Der Browser lädt trotzdem jedes einzelne Pixel herunter.

Auf die Anzeigegröße verkleinern

Finde heraus, wie breit das Bild tatsächlich dargestellt wird. Bei einem Desktop-Layout mit 1200 Pixel breiter Inhaltsspalte braucht ein Bild über die volle Breite selten mehr als etwa die doppelte Breite, damit es auch auf hochauflösenden Displays scharf bleibt. Vorschaubilder in einem Produktraster kommen mit viel weniger aus.

srcset und sizes nutzen

Mit responsiven Bildern sucht sich der Browser für jeden Bildschirm die passende Datei aus:

<img
  src="/images/schuh-800.jpg"
  srcset="/images/schuh-400.jpg 400w,
          /images/schuh-800.jpg 800w,
          /images/schuh-1600.jpg 1600w"
  sizes="(min-width: 1024px) 50vw, 100vw"
  alt="Blauer Laufschuh, Seitenansicht"
  width="800" height="800">

In srcset stehen die verfügbaren Breiten, sizes verrät dem Browser, wie breit das Bild im Layout wird. Daraus und aus der Pixeldichte des Displays berechnet der Browser, welche Datei er braucht, und lädt nur diese eine. Die meisten CMS, auch WordPress, erzeugen beim Hochladen automatisch mehrere Größen und geben srcset selbst aus, solange dein Theme die Standardfunktionen für Bilder verwendet.

Mit Augenmaß komprimieren

Bei verlustbehafteten Formaten ist eine Qualitätsstufe im mittleren bis oberen Bereich in normaler Betrachtungsgröße meist nicht vom Original zu unterscheiden. Vergleiche ein paar Einstellungen nebeneinander auf einem echten Bildschirm, statt dich blind auf einen Standardwert zu verlassen. Entferne außerdem Metadaten wie die EXIF-Daten der Kamera. Die kosten Bytes und verraten unter Umständen einen Aufnahmeort, den du gar nicht veröffentlichen wolltest.

Bilder zum richtigen Zeitpunkt laden

Nicht jedes Bild ist gleich dringend. Das Bild im sichtbaren Bereich soll der Browser sofort holen, den Rest erst, wenn jemand dorthin scrollt.

Bilder weiter unten per Lazy Loading laden

Natives Lazy Loading kommt ganz ohne JavaScript aus:

<img src="/images/galerie-3.webp" loading="lazy" alt="..." width="600" height="400">

Das LCP-Bild nie lazy laden

Dieser Fehler macht alle anderen Optimierungen zunichte. Trägt das Titelbild loading="lazy", wartet der Browser absichtlich mit dem Laden, und der LCP wird schlechter. Manche Plugins und Themes versehen standardmäßig jedes Bild mit Lazy Loading. Prüfe deshalb gezielt dein Titelbild.

Layoutverschiebungen vermeiden

Gib Bildern immer die Attribute width und height mit oder setze in CSS ein aspect-ratio. Moderne Browser reservieren damit den richtigen Platz, bevor die Datei ankommt, auch wenn das Bild per width: 100%; height: auto responsiv skaliert. Warum Bilder ohne Maße zu den häufigsten Auslösern von Layoutverschiebungen gehören, erklärt der CLS-Artikel auf web.dev.

Das gilt genauso für Bilder, die erst später dazukommen, etwa in Slidern oder Werbeflächen. Reserviere ihren Platz per CSS, dann springt der Rest der Seite nicht.

Bilder richtig cachen

Bilder ändern sich selten, also sollten Browser und CDN sie lange vorhalten. Sende langlebige Cache-Control-Header und ändere den Dateinamen (oder hänge eine Versionsnummer an), wenn du ein Bild austauschst. Was dein Server tatsächlich sendet, siehst du so:

curl -I https://www.example.com/images/hero.webp

Achte auf cache-control mit einem hohen max-age. Lieferst du unter derselben URL je nach Browser unterschiedliche Formate aus, muss die Antwort außerdem nach dem Accept-Header variieren. Sonst gibt ein Cache womöglich ein WebP an einen Browser weiter, der es nicht darstellen kann.

So hilft dir fast.site

fast.site arbeitet vor deinem bestehenden Hosting. Deine Bilder bleiben also, wo sie sind, und dein CMS läuft weiter wie bisher. Du stellst die Nameserver deiner Domain auf fast.site um, ab dann laufen die Anfragen über das Edge-Netzwerk.

Die Bildoptimierung wandelt JPEG und PNG für Browser, die das Format unterstützen, direkt in WebP um. AVIF ist je nach Tarif verfügbar. Browser ohne Unterstützung bekommen das Original, du musst also nicht für jedes Bild eigene <picture>-Fallbacks pflegen. Wie andere statische Dateien landen auch Bilder im Fast Edge Cache™. Bei einem Cache-HIT kommen sie vom nächstgelegenen Edge, ohne dass dein Server angefragt wird.

Die optionale HTML-Optimierung lädt das erkannte Titelbild per Preload vor und ergänzt fehlende Breiten- und Höhenangaben, damit weniger verrutscht.

Was fast.site nicht übernimmt: zu große Uploads verkleinern oder entscheiden, welche Bilder lazy geladen werden. Das bleibt Aufgabe deines Themes und deines Redaktionsablaufs.

Miss den Effekt auf deiner eigenen Website vorher und nachher: Vergleiche im Netzwerk-Tab deines Browsers die übertragenen Bilddaten und prüfe den LCP auf corewebvitals.page. Ausprobieren kannst du das mit einer kostenlosen 7-Tage-Testphase ohne Kreditkarte. Was in welchem Tarif enthalten ist, siehst du unter Preise.

Häufige Fragen

Ist WebP oder AVIF besser?

AVIF erzeugt bei ähnlicher Qualität oft kleinere Dateien als WebP, gerade bei Fotos, braucht aber länger zum Kodieren. WebP ist eine sichere Wahl mit breiter Unterstützung. Viele Websites liefern daher wenn möglich AVIF aus und greifen sonst auf WebP oder das Original zurück.

Wie groß sollten Bilder auf einer Website sein?

Orientiere dich an der größten Breite, in der das Bild angezeigt wird, und stelle für hochauflösende Displays etwa die doppelte Breite bereit. Mit srcset laden kleinere Bildschirme automatisch kleinere Dateien. Die volle Kameraauflösung brauchst du so gut wie nie.

Schadet Lazy Loading der SEO?

Natives Lazy Loading mit loading="lazy" wird von Google unterstützt und versteckt keine Bilder vor der Suche. Das eigentliche Risiko liegt in der Ladezeit: Wird das Hauptbild im sichtbaren Bereich lazy geladen, verzögert sich der LCP. Setze Lazy Loading deshalb nur für Bilder weiter unten ein.

Wie prüfe ich, ob meine Bilder optimiert sind?

Teste die Seite auf corewebvitals.page und prüfe den LCP für Mobilgeräte und Desktop. Welches Element das LCP-Element ist, zeigt dir das Panel „Performance“ in den Chrome DevTools. Im Netzwerk-Tab deines Browsers filterst du nach Bildern und vergleichst Dateigrößen und Formate. Wie du einen verlässlichen Vorher-nachher-Test aufsetzt, zeigt unser Ratgeber Ladezeit einer Website richtig messen.

Brauche ich in WordPress noch ein Plugin zur Bildoptimierung?

Das hängt von deinem Setup ab. Ein Plugin, das Uploads verkleinert und komprimiert, lohnt sich weiterhin, denn eine Formatumwandlung allein behebt keine überdimensionierten Bilder. Übernimmt dein CDN bereits die Umwandlung in WebP oder AVIF, kannst du diesen Teil im Plugin meist abschalten und sparst dir die doppelte Arbeit. Das große Ganze beschreibt unser Ratgeber WordPress schneller machen.