Webdesign

Bilder optimieren für Website & SEO: WebP, AVIF, Lazy Loading & Lighthouse 2026

Bilder sind in 80 % der Fälle der Grund für lahme Websites. So komprimieren Sie richtig, wählen das passende Format und holen sich saubere Lighthouse-Scores – ohne Qualitätsverlust.

Kurz gefasst

  • Liefern Sie Bilder in der Größe aus, in der sie auf dem jeweiligen Gerät gebraucht werden.
  • Laden Sie das größte sichtbare Bild früh und reservieren Sie Platz für nachladende Bilder.
  • Schreiben Sie Alt-Texte nach der Funktion des Bildes im jeweiligen Kontext.

Warum Bilder über Erfolg oder Misserfolg Ihrer Website entscheiden

Wenn eine Website langsam ist, liegt es selten am Code. In über 80 % der Fälle, die wir bei VisiBuilt analysieren, sind unoptimierte Bilder der Hauptverursacher. Eine typische Startseite hat 8–15 Bilder. Wenn jedes 800 KB statt 80 KB wiegt, summiert sich das schnell auf 6–10 MB Bildgewicht – auf einer 4G-Verbindung sind das mehrere Sekunden Wartezeit.

Das hat drei direkte Konsequenzen:

  1. Google-Ranking sinkt – seit 2021 sind Core Web Vitals (LCP, CLS, INP) ein offizieller Ranking-Faktor.
  2. Conversion-Rate sinkt – Studien von Google und Akamai zeigen, dass jede zusätzliche Sekunde Ladezeit die Conversion-Rate um 7–20 % drückt.
  3. Hosting-Kosten steigen – mehr Traffic = mehr Bandbreite = höhere Bills, vor allem bei Vercel/Netlify.

Die gute Nachricht: Bildoptimierung ist mit den richtigen Tools eine Sache von Minuten pro Bild – und sie lässt sich automatisieren.

Schritt 1: Das richtige Bildformat wählen

Die Format-Entscheidung ist der größte einzelne Hebel. Hier die wichtigsten Optionen im Vergleich:

FormatUse-CaseDateigröße (relativ)Browser-Support 2026Transparenz
JPEGFotos, Hero-Bilder (Fallback)100 % (Baseline)100 %Nein
PNGLogos, Icons, Screenshots mit Text200–400 %100 %Ja
WebPUniversalformat für Web65–75 %99 %+Ja
AVIFPremium-Performance, Hero-Bilder40–55 %95 %+Ja
SVGLogos, Icons, einfache Grafiken<5 % (vektorbasiert)100 %Ja

Unsere Faustregel: WebP für alles. AVIF für die 3–5 wichtigsten Bilder (Hero, Above-the-Fold). SVG für jedes Icon und Logo. PNG nur, wenn pixelgenaue Text-Screenshots gebraucht werden.

Schritt 2: Sinnvoll komprimieren

Komprimierung ist Abwägung zwischen Dateigröße und sichtbarer Qualität. Bei den meisten Web-Bildern sieht das Auge ab Qualitätsstufe 80 keinen Unterschied mehr – die Datei ist aber oft 60 % kleiner als bei 100 %.

BildtypEmpfohlene Qualität (WebP)Typische Größe nach Optimierung
Hero-Bild (1920×1080)80–8580–150 KB
Content-Bild (1200×800)75–8040–80 KB
Thumbnail (400×300)70–758–20 KB
Logo (SVG)–2–8 KB

Tools, die wir konkret einsetzen:

  • Squoosh – für einzelne Bilder direkt im Browser. Live-Vergleich, mehrere Formate parallel.
  • Sharp (Node.js) – im Build-Prozess. Wandelt im CI alle Bilder automatisch in WebP + AVIF.
  • ImageOptim – Drag-and-Drop auf dem Mac. Verlustfrei für PNG/JPEG.

Schritt 3: Responsive Bilder mit srcset und sizes

Ein einziges Hero-Bild für Desktop und Smartphone auszuliefern ist Verschwendung. Mobile Nutzer brauchen kein 1920-Pixel-Bild – ein 768-Pixel-Bild reicht. Hier kommt srcset ins Spiel:

html
<img
  src="hero-1200.webp"
  srcset="
    hero-480.webp 480w,
    hero-768.webp 768w,
    hero-1200.webp 1200w,
    hero-1920.webp 1920w
  "
  sizes="(max-width: 768px) 100vw, (max-width: 1200px) 80vw, 1200px"
  alt="Beispiel Hero-Bild"
  width="1200"
  height="800"
  loading="lazy"
  decoding="async"
/>

Was hier passiert: Der Browser wählt aus den vier Bildvarianten genau die aus, die zur aktuellen Bildschirmbreite passt. Das spart auf Mobilgeräten oft 70–80 % Bandbreite für ein einzelnes Bild.

Wichtig: width und height immer angeben. Sonst entsteht beim Nachladen ein Layout-Shift – und der CLS-Score (Cumulative Layout Shift) verschlechtert sich.

Schritt 4: Lazy Loading richtig nutzen

loading="lazy" weist den Browser an, ein Bild erst zu laden, wenn es kurz vor dem sichtbaren Bereich auftaucht. Das ist seit 2020 nativ in allen großen Browsern eingebaut – kein JavaScript nötig.

Bild-PositionAttribut
Hero / Above-the-Foldloading="eager" (Standard)
Alle anderen Bilderloading="lazy"
Bilder im Carousel/Sliderloading="lazy" ab Slide 2

Wichtig: Lazy Loading nicht beim LCP-Bild (Largest Contentful Paint) einsetzen. Sonst verzögert der Browser ausgerechnet das wichtigste Bild für die wahrgenommene Ladezeit.

Schritt 5: Modernes <picture>-Element für AVIF + WebP-Fallback

Wenn Sie AVIF einsetzen wollen, brauchen Sie einen Fallback für Browser, die es nicht unterstützen. Das geht elegant mit <picture>:

html
<picture>
  <source srcset="hero.avif" type="image/avif" />
  <source srcset="hero.webp" type="image/webp" />
  <img src="hero.jpg" alt="..." width="1200" height="800" loading="lazy" decoding="async" />
</picture>

Der Browser nimmt das erste Format, das er versteht. So bekommen moderne Browser die kleine AVIF-Datei, ältere die WebP, und ganz alte den JPEG-Fallback.

Schritt 6: Alt-Texte – Pflicht für SEO und Barrierefreiheit

Jedes inhaltsrelevante Bild braucht einen Alt-Text. Drei Grundregeln:

  1. Beschreibend, nicht stichwortartig. „Frau mit Laptop am Schreibtisch" statt „Frau Laptop Büro Arbeit Business".
  2. Keyword nur, wenn es passt. Google erkennt Keyword-Stuffing in Alt-Texten und straft es ab.
  3. Dekorative Bilder bekommen alt="" (leerer String, nicht weglassen) – damit Screenreader sie überspringen.

Beispiel:

html
<!-- Gut -->
<img src="webdesign-team.webp" alt="Drei Webdesigner besprechen ein Wireframe auf einem Tablet" />

<!-- Schlecht (Keyword-Stuffing) -->
<img src="webdesign-team.webp" alt="Webdesign Bonn Webdesigner Agentur Webseiten" />

<!-- Dekoratives Hintergrundbild -->
<img src="abstract-shape.webp" alt="" />

Häufige Fehler, die wir in Audits sehen

FehlerAuswirkungLösung
4-MB-JPEG im HeroLCP > 4s, Ranking-PenaltyAuf WebP 80 % komprimieren, mehrere Größen
PNG für FotosDatei 3× so groß wie nötigJPEG/WebP für Fotos, PNG nur für Grafiken mit Text
Kein width/heightCLS-Score schlecht, Layout springtImmer Originalmaße angeben
Lazy Loading beim HeroLCP-Bild lädt zu spätloading="eager" für Above-the-Fold
1920-Pixel-Bild auf Mobile5× zu groß, Bandbreite verschwendetsrcset mit mehreren Größen
Keine Alt-TexteBarrierefreiheit & SEO leidenBeschreibende Alt-Texte ergänzen
Inline-Base64 für große BilderBläht HTML auf, verzögert RenderNur für Icons unter ~1 KB sinnvoll

Lighthouse-Score: Realistische Zielwerte

Nach unserer Optimierungsstrategie sollten Sie auf einer typischen Business-Website folgende Werte erreichen:

MetrikZielwert (Lighthouse Mobile)Bedeutung
LCP< 2,5 sGrößtes Element sichtbar
CLS< 0,1Kein Layout-Springen
INP< 200 msReaktion auf Interaktion
Total Page Weight< 1,5 MBKomplette Seitengröße
Image Weight< 800 KBSumme aller Bilder

Diese Werte sind kein Selbstzweck – sie entscheiden direkt über Ranking, Absprungrate und Conversion.

Unser Workflow bei VisiBuilt

Wir nehmen Bildoptimierung nicht als nachträglichen Schritt, sondern bauen sie in den Build-Prozess ein:

  1. Original-Bilder im Repository liegen in einem /raw-Ordner – nie produktiv.
  2. Sharp generiert beim Build automatisch WebP + AVIF in 4 Größen pro Bild.
  3. Vite-Plugin ersetzt <img>-Tags durch <picture>-Elemente mit korrektem srcset.
  4. CI-Check scheitert, wenn ein Bild über 200 KB groß ist.

Ergebnis: Auf jeder unserer Websites liegen die Bilder im Schnitt bei < 500 KB Gesamtgewicht – bei voller visueller Qualität. Lighthouse-Scores liegen damit konstant zwischen 95 und 100.

Weiterführende Inhalte