Sprachen

Bildoptimierung

So optimieren Sie Bilder für SEO und Leistung: moderne Formate wie WebP und AVIF, Komprimierung, passende Abmessungen und Lazy Loading zur Verbesserung von Core Web Vitals und LCP.

Erstveröffentlicht: 2. Juli 2026 · Zuletzt aktualisiert: 13. Aug. 2026 · Fortgeschritten
Sprachen
AIVerfasst vonAI v2

Bildoptimierung dient der Ladegeschwindigkeit und ist kein direkter Rankinghebel. Formate wie WebP und AVIF, Komprimierung und passende Abmessungen reduzieren Bytes und können LCP verbessern; das Format selbst erhält keinen Rankingbonus. Die wichtigste Regel: Laden Sie das LCP-Bild – meist das Hero-Bild – niemals verzögert, weil dies genau die zu verbessernde Kennzahl verspätet. Dieses Bild erhält loading="eager" und fetchpriority="high". Natives loading="lazy" gehört zu Bildern außerhalb des anfänglichen Viewports, nicht hinter eine feste Falzlinie. Für die Komprimierung gibt es keine universell richtige Qualitätsstufe; testen Sie pro Bild. Die passende Größe entspricht der gerenderten Containergröße multipliziert mit dem Geräte-Pixelverhältnis. Da sich der Container im responsiven Layout verändert, liefern Sie mehrere Kandidaten über srcset und sizes. Keine dieser Maßnahmen garantiert bestandene Core Web Vitals, bessere Rankings oder mehr Traffic; messen Sie LCP und CLS vorher und nachher.

TL;DR — Bildoptimierung gehört zur Seitengeschwindigkeit und zu Core Web Vitals, nicht zu direkten Rankinghebeln. WebP und AVIF reduzieren Bytes, erhalten aber keinen unmittelbaren SEO-Vorteil. Berücksichtigen Sie neben der Kompression auch Transparenz, Animation und aktuelle Browserunterstützung. Die wichtigste Regel: Laden Sie das LCP-Bild niemals verzögert. Geben Sie ihm loading="eager" und fetchpriority="high"; Prioritätshinweise helfen allerdings nur bei einem Engpass in Erkennung oder Abruf. Natives loading="lazy" ist für Bilder außerhalb des anfänglichen Viewports gedacht. Eine universell richtige Kompressionsqualität gibt es nicht. Die passenden Abmessungen ergeben sich aus gerenderter Containergröße × Geräte-Pixelverhältnis; liefern Sie deshalb eine srcset-/sizes-Auswahl mit <picture>-Fallback. Keine dieser Maßnahmen garantiert bestandene Core Web Vitals, bessere Rankings oder mehr Traffic. Messen Sie vorher und nachher.

Das eigentliche Optimierungsziel

Zuerst der größte Mythos: Das Bildformat ist ein Geschwindigkeitshebel, kein Rankinghebel. Die Umwandlung in WebP oder AVIF bringt keinen Rankingbonus. Sie erzeugt kleinere Dateien, die eine schnellere Seite ermöglichen und dadurch Core Web Vitals beeinflussen können. Die Wirkungskette ist real, aber indirekt. Formate der nächsten Generation ranken nicht von sich aus besser.

Googles Dokumentation erklärt klar, warum Bilder für die Geschwindigkeit wichtig sind: Sie sind “often the largest contributor to overall page size, which can make pages slow and expensive to load,” (Übersetzung) „häufig der größte Beitrag zur gesamten Seitengröße, wodurch Seiten langsam und teuer zu laden sein können“, und empfiehlt, “apply the latest image optimization and responsive image techniques to provide a high quality and fast user experience” (Übersetzung) „aktuelle Verfahren zur Bildoptimierung und für responsive Bilder einzusetzen, um eine hochwertige und schnelle Nutzererfahrung zu bieten“ (Google Search Central — Images). Beachten Sie die Einordnung: schnelle Nutzererfahrung, keine Rankingbelohnung für das Dateiformat.

Evidence for this claim Images are often a major contributor to page weight, and Google recommends responsive image and optimization techniques for a fast user experience. Scope: Google Search image guidance about performance; no claim that a particular format directly improves rankings. Confidence: high · Verified: Google Search Central: Google Images SEO

Der übergeordnete Bild-SEO-Artikel behandelt Alternativtexte, Dateinamen, Bild-Sitemaps, strukturierte Daten und Rankings in der Bildersuche. Dieser Artikel liefert das Wie: Formate, Komprimierung, Abmessungen und Ladestrategie.

Die wichtigste Regel: Das LCP-Bild niemals verzögert laden

Wenn Sie nur eine Sache mitnehmen, dann diese: Das Largest-Contentful-Paint-Element (LCP) – das größte beim Laden im Viewport gezeichnete Element – ist laut web.dev “either an image or a web font” (Übersetzung) „entweder ein Bild oder eine Webschrift“ (Optimize LCP), und auf den meisten Seiten ein Hero-, Beitrags- oder Produktbild. web.dev formuliert die Regel unmissverständlich:

“Never lazy-load your LCP image, as that will always lead to unnecessary resource load delay, and will have a negative impact on LCP.” (Übersetzung) „Laden Sie Ihr LCP-Bild niemals verzögert, weil dies stets zu einer unnötigen Verzögerung beim Ressourcenabruf führt und LCP beeinträchtigt.“

Evidence for this claim Lazy-loading an LCP image adds resource load delay; web.dev recommends loading it eagerly and considering high fetch priority. Scope: web.dev guidance for image-based LCP elements. Confidence: high · Verified: web.dev: Optimize LCP

Genau diese Nuance fehlt in pauschalen Empfehlungen für Lazy Loading. Für Bilder außerhalb des anfänglichen Viewports ist es sinnvoll; beim LCP-Bild verzögert es die zu verbessernde Kennzahl. Der Lazy-Loading-Leitfaden von web.dev formuliert es umgekehrt: “Don’t lazy-load images that are likely to be in-viewport when the page loads, especially LCP images” (Übersetzung) „Laden Sie Bilder nicht verzögert, wenn sie beim Seitenaufruf wahrscheinlich im Viewport liegen, insbesondere LCP-Bilder.“ (Browser-level lazy loading).

In meinem LCP-Artikel bei Ahrefs argumentiere ich ebenso: Das größte Element ist “usually going to be a featured image or maybe the <h1> tag,” (Übersetzung) „meist ein Beitragsbild oder vielleicht das <h1>-Element“. Wenn das Bild nicht nötig ist, entfernt man es; andernfalls werden Größe und Qualität möglichst effizient optimiert. Bilder, die nicht sofort benötigt werden, dürfen verzögert laden. Die Gegenregel lautet jedoch: Bilder oberhalb der Falz niemals verzögert laden.

fetchpriority="high" für das LCP-Bild

Das Hero-Bild nicht verzögert zu laden ist notwendig, aber nicht immer ausreichend. Damit das LCP-Bild möglichst früh lädt, weisen Sie den Browser auf seine Priorität hin. web.dev schreibt:

“You can hint to the browser as to which resources are most important using the fetchpriority attribute… It’s a good idea to set fetchpriority=\"high\" on an <img> element if you think it’s likely to be your page’s LCP element.” (Übersetzung) „Mit dem Attribut fetchpriority können Sie dem Browser anzeigen, welche Ressourcen besonders wichtig sind. Für ein wahrscheinliches LCP-Bild ist fetchpriority=\"high\" sinnvoll.“

<img src="/hero.webp" alt="…" fetchpriority="high" width="1200" height="675">

In meinem LCP-Artikel beschreibe ich fetchpriority="high" genauso: Es “can be used on <img> or <link> tags and tells browsers to get the image early” (Übersetzung) „kann bei <img>- oder <link>-Elementen verwendet werden und weist Browser an, das Bild früh abzurufen“. Ergänzend können Early Hints – eine 103-Antwort – den Abruf bereits vor dem Eintreffen des Haupt-HTML anstoßen. Das LCP-Rezept lautet daher: sofort laden, fetchpriority="high" setzen und, sofern der Stack es unterstützt, Early Hints verwenden. Alle übrigen Bilder können verzögert laden.

Behandeln Sie fetchpriority und Preload als Werkzeuge für konkrete Engpässe, nicht als garantierte Lösung. Sie helfen, wenn das LCP-Bild zu spät entdeckt oder abgerufen wird, nicht aber bei einer langsamen Serverantwort, einer vorgeschalteten renderblockierenden Ressource oder einer tatsächlich übergroßen Datei. Prüfen Sie mit PageSpeed Insights oder Lighthouse, welcher LCP-Teilabschnitt den Engpass verursacht, bevor Sie allein von einem Prioritätshinweis eine Verbesserung erwarten.

Natives loading="lazy" – einfach und richtig außerhalb des anfänglichen Viewports

Für jedes Bild, das beim ersten Rendern nicht im Viewport liegt, ist natives Lazy Loading die einfachste Leistungsverbesserung. web.dev erklärt: “You can use the loading attribute to lazy-load images without the need to write custom lazy-loading code or use a separate JavaScript library.” (Übersetzung) „Mit dem Attribut loading können Bilder verzögert geladen werden, ohne eigenen Lazy-Loading-Code oder eine separate JavaScript-Bibliothek zu schreiben.“

<img src="/below-the-fold.webp" alt="…" loading="lazy" width="800" height="600">

Zwei Regeln halten die Umsetzung sicher:

  • Am anfänglichen Viewport ausrichten, nicht an einer festen Falzlinie. Die Falz liegt nicht bei einer festen Pixelzahl, sondern ändert sich mit Viewport und Layout. Entscheidend ist, ob das Bild beim ersten Rendern wahrscheinlich sichtbar ist. Sichtbare Bilder – vor allem das LCP-Bild – verwenden den Standard loading="eager", niemals lazy.
  • Das native Attribut JavaScript-Tricks vorziehen. Lazy Loader, welche die echte URL nur in data-src ablegen und nie ein src ausgeben, riskieren fehlende Indexierung. Natives loading="lazy" oder ein sauberer IntersectionObserver hält src für Crawler sichtbar. Der übergeordnete Bild-SEO-Artikel erläutert diese Indexierungsfrage ausführlich.

Moderne Formate: WebP, AVIF, JPEG und PNG

Bei Formaten ist Präzision besonders wichtig: Sie sparen Bytes, nicht Rankings.

  • WebP — “WebP often has better compression than JPEG, PNG, or GIF, offering both lossy and lossless compression.” (Übersetzung) „WebP komprimiert häufig besser als JPEG, PNG oder GIF und unterstützt verlustbehaftete sowie verlustfreie Komprimierung.“ Es ist etwa 25–35 % kleiner als JPEG und heute die sichere Standardwahl für Fotos (web.dev — Bildleistung).
  • AVIF — unterstützt verlustbehaftete und verlustfreie Komprimierung; Tests zeigen in manchen Fällen mehr als 50 % Ersparnis gegenüber JPEG. Verwenden Sie wegen der etwas geringeren Unterstützung einen WebP- oder JPEG-Fallback.
  • JPEG — universeller Fallback für Fotografien.
  • PNG — für Transparenz oder scharfkantige Grafiken.
  • SVG — für Logos und Symbole: vektorbasiert, beliebig skalierbar und klein.

Die Wahl hängt nicht nur von der stärksten Komprimierung ab. Transparenz, Animation und die Unterstützung der benötigten Kombination durch Browser und Werkzeuge gehören ebenfalls in die Entscheidung. Prüfen Sie insbesondere bei Animationen die aktuelle Unterstützung.

Google Search unterstützt “BMP, GIF, JPEG, PNG, WebP, SVG, and AVIF” (Übersetzung) „BMP, GIF, JPEG, PNG, WebP, SVG und AVIF“, wenn sie über das src eines <img> referenziert werden. Liefern Sie moderne Formate mit einem <picture>-Fallback aus:

<picture>
  <source srcset="/photo.avif" type="image/avif">
  <source srcset="/photo.webp" type="image/webp">
  <img src="/photo.jpg" alt="…" width="1200" height="800" loading="lazy">
</picture>

Das abschließende <img src> ist das Sicherheitsnetz für ältere Browser und Crawler sowie die URL, die Google tatsächlich indexiert.

Beeinflusst das Format Rankings? Nein

Drei voneinander unabhängige Aussagen von John Mueller führen zum selben Ergebnis: Das Format beeinflusst Abruf, Indexierungsmechanik und Seitengewicht, aber nie direkt das Ranking:

  1. AVIF bietet keinen SEO-Vorteil. Nach der nativen AVIF-Unterstützung bestätigte Mueller, dass AVIF gegenüber anderen unterstützten Formaten keinen “SEO boost” erhält (SE Roundtable coverage).
  2. WebP ist „in Ordnung“. “WebP images are fine for Image Search” (Übersetzung) „WebP-Bilder sind für die Bildersuche in Ordnung“ – nicht besser (Berichterstattung von SE Roundtable).
  3. WebP-Indexierungsbesonderheiten sind nicht formatspezifisch. Bei „Gecrawlt – derzeit nicht indexiert“ wies Mueller darauf hin, dass Bilddateien nicht wie HTML-Seiten indexiert werden und das Phänomen nicht auf WebP beschränkt sei (SEJ coverage).
Diese Aussagen stammen aus wortgetreuer Sekundärberichterstattung von Search Engine Roundtable und Search Engine Journal zu Sprechstunden und Social-Media-Beiträgen. Der SEJ-Artikel paraphrasiert Mueller, statt ihn als Blockzitat wiederzugeben.

Komprimierung und Qualität: keine universelle Einstellung

Der häufigste schlechte Rat in Bildleitfäden lautet pauschal „auf 80 % komprimieren“. web.dev stellt klar, dass es keine solche magische Zahl gibt:

“When compressing, there isn’t a universal setting suitable for all cases. The recommended approach would be to experiment with different compression levels until you find a good compromise between image quality and file size.” (Übersetzung) „Für die Komprimierung gibt es keine universell passende Einstellung. Testen Sie verschiedene Stufen, bis Sie einen guten Kompromiss zwischen Bildqualität und Dateigröße finden.“

Praktisch bedeutet das: pro Bildtyp testen. Fotografien vertragen stärkere verlustbehaftete Komprimierung; Grafiken, Logos und Screenshots mit Text zeigen schneller Artefakte. Exportieren Sie zwei oder drei Qualitätsstufen und vergleichen Sie die Ergebnisse in der tatsächlichen Anzeigegröße. Wählen Sie die kleinste Version, die sich visuell nicht vom Original unterscheiden lässt.

Richtige Abmessungen: Containergröße × Geräte-Pixelverhältnis

„Einfach kleiner machen“ ist nicht die Regel. Entscheidend ist die gerenderte Größe × Geräte-Pixelverhältnis (DPR). web.dev erklärt:

“An image displayed in a 500 pixel by 500 pixel container would be optimally sized at 500 pixels by 500 pixels.” (Übersetzung) „Ein Bild in einem 500 × 500 Pixel großen Container ist mit 500 × 500 Pixeln optimal dimensioniert.“

“If the device has a DPR of 2 and the image is displayed in a 500 pixel by 500 pixel container, then a square 1000 pixel image… is now the optimal size.” (Übersetzung) „Bei einem DPR von 2 und einem 500 × 500 Pixel großen Container ist ein quadratisches Bild mit 1 000 Pixeln die optimale Größe.“

Ein 500×500-Container auf einem Display mit DPR 2 benötigt also eine 1 000×1 000-Pixel-Quelle. Größere Dateien verschwenden Bytes ohne sichtbaren Gewinn; kleinere wirken auf hochauflösenden Displays unscharf. Deshalb liefern Sie mit srcset und sizes mehrere Größen aus und lassen den Browser wählen:

<img
  src="/photo-800.webp"
  srcset="/photo-400.webp 400w, /photo-800.webp 800w, /photo-1600.webp 1600w"
  sizes="(max-width: 600px) 100vw, 500px"
  alt="…" width="800" height="600" loading="lazy">

Der Browser liest die Containerbreite aus sizes, berücksichtigt sein DPR und wählt den passenden Kandidaten aus srcset. Google empfiehlt für responsive Bilder <picture> oder srcset und verlangt: “always specify a fallback URL using the src attribute.” (Übersetzung) „Geben Sie über das Attribut src immer eine Fallback-URL an.“

Ein falscher sizes-Wert erzeugt keine Warnung. Entspricht die angegebene Breite nach einer Layout- oder CSS-Änderung nicht mehr der tatsächlichen Darstellung, wählt der Browser anhand der falschen Zahl häufig eine unnötig große Datei. Damit gehen die Einsparungen aus Format und Komprimierung unbemerkt verloren. Prüfen Sie im Netzwerkbereich der Entwicklertools die Abmessungen der ausgelieferten Datei gegen die tatsächlich gerenderte Containerbreite.

Das Beispiel mit 500×500 Pixeln ist keine feste Vorgabe für die ganze Website. Dasselbe Hero-Bild kann mobil und auf dem Desktop unterschiedlich breit erscheinen. Genau deshalb liefern Sie eine srcset-Auswahl statt einer einzigen vermeintlich optimalen Datei aus.

Warum alles auf Core Web Vitals zurückführt

Der rote Faden aller Verfahren ist LCP. Bilder sind im Web das häufigste LCP-Element, und LCP gehört zu den drei Core Web Vitals. Google setzt das Ziel so: “LCP should occur within 2.5 seconds” (Übersetzung) „LCP sollte innerhalb von 2,5 Sekunden eintreten“ – gemessen am 75. Perzentil der Seitenaufrufe auf Mobilgeräten und Desktop (web.dev — Vitals). Core Web Vitals “apply to all web pages, should be measured by all site owners, and will be surfaced across all Google tools.” (Übersetzung) „gelten für alle Webseiten, sollten von allen Websitebetreibern gemessen werden und erscheinen in allen Google-Werkzeugen.“

Bildoptimierung ist daher kein eigenständiger Rankingfaktor, sondern kann zu einem Seitenerfahrungssignal beitragen, das Rankingsysteme verwenden. Deshalb gehört dieser Artikel sowohl zum Bild-SEO- als auch zum Web-Performance-Cluster. Die Kennzahlen selbst behandeln die Beiträge zu Core Web Vitals und LCP im Bereich Web Performance.

Keine Maßnahme auf dieser Seite garantiert ein bestimmtes Ergebnis. Bildbytes sind nur ein möglicher Bestandteil von LCP; auch Serverantwortzeit und vorgeschaltete renderblockierende Ressourcen zählen. Bildabmessungen sind wiederum nur einer von mehreren CLS-Einflüssen. Ein kleineres Hero-Bild kann deutlich helfen, kaum wirken oder wegen eines anderen Engpasses gar nichts verändern. Ebenso garantiert Bildoptimierung weder bestandene Core Web Vitals noch bessere Rankings, mehr Traffic, Conversions oder eine KI-Suchzitation. Behandeln Sie jede Änderung als Hypothese: Messen Sie LCP und CLS vorher und nachher, im Labor und im Feld, und entscheiden Sie anhand der Daten.

Häufige Implementierungsfehler

  • CSS-Hintergrundbilder werden nicht indexiert. Entwickler ersetzen ein <img> manchmal aus Layoutgründen durch background-image. Google “can find images in the src attribute of <img> element (even when it’s a child of other elements, such as the <picture> element)” (Übersetzung) „kann Bilder im src-Attribut eines <img> finden, auch innerhalb eines <picture>“, indexiert aber “doesn’t index CSS images” (Übersetzung) „keine CSS-Bilder“. Inhaltsbilder für die Bildersuche gehören daher in ein <img>.
  • Bestehende Dateien nicht pauschal umbenennen. Mueller zufolge dauert die erneute Verarbeitung umbenannter Bilder “a lot of time” (Übersetzung) „sehr lange“, während der Effekt bei bereits gutem Kontext gering ist. Der Bild-SEO-Artikel behandelt dies ausführlich.
  • Fehlende Breiten- und Höhenangaben. Setzen Sie intrinsische Werte für width und height oder CSS-aspect-ratio, damit der Browser vor dem Laden Platz reservieren kann. Das reduziert bildbedingte Layoutverschiebungen, garantiert aber keinen bestimmten CLS-Wert.

Kurzrezept

  • Hero- oder LCP-Bild: modernes Format, passende Größe, loading="eager", fetchpriority="high".
  • Bilder außerhalb des anfänglichen Viewports: loading="lazy".
  • WebP oder AVIF über <picture> mit src-Fallback ausliefern.
  • Größe an Container × DPR ausrichten und eine srcset-Auswahl mit sizes anbieten.
  • Pro Bildtyp zwei bis drei Qualitätsstufen testen, statt einem pauschalen Regler zu vertrauen.
  • width und height immer angeben.

Alternativtexte, Dateinamen, Bild-Sitemaps, strukturierte Daten und Rankings in der Bildersuche behandelt der übergeordnete Bild-SEO-Artikel.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.