# Bilder fürs Web optimieren, ohne Qualität zu verlieren

[Canonical HTML page](https://gradiently.design/de/guide/lighthouse-image-performance)

Bilder sind meist der schwerste Teil einer Seite und der Grund, warum Lighthouse meckert. Hier ist eine Methode, die funktioniert: die richtigen Pixelgrößen, das richtige Format, responsives Markup und Ladehinweise, ohne sichtbaren Verlust.

## The short version

- Um Bilder fürs Web zu optimieren, exportierst du jedes Bild in der Größe, in der es angezeigt wird, für Bildschirme mit hoher Pixeldichte etwa verdoppelt, statt das Original hochzuladen.
- AVIF und WebP erzeugen bei ähnlicher sichtbarer Qualität deutlich kleinere Dateien als JPEG und PNG, und jeder aktuelle Browser unterstützt WebP.
- Mit den Attributen srcset und sizes lädt der Browser das kleinste Bild, das auf dem jeweiligen Bildschirm noch scharf aussieht.
- Lade Bilder unterhalb des sichtbaren Bereichs mit loading="lazy", aber das Hauptbild im Hero sofort mit fetchpriority="high", weil es meist über den Largest Contentful Paint entscheidet.
- Setz bei Bildern immer width und height, damit der Browser Platz reserviert und das Layout beim Laden nicht springt.

Um **Bilder fürs Web zu optimieren**, ohne sichtbaren Verlust, tust du fünf Dinge: Exportiere jedes Bild in der Pixelgröße, in der es angezeigt wird (für scharfe Bildschirme etwa doppelt so groß), wähle ein modernes Format wie AVIF oder WebP, komprimiere auf eine mittlere Qualität und vergleiche mit dem Auge, liefere mit `srcset` mehrere Größen aus und lade alles unterhalb des sichtbaren Bereichs per Lazy Loading. Diese Schritte beseitigen die meisten Bildwarnungen in Lighthouse und senken das Seitengewicht meist drastisch, denn das Originalfoto direkt aus Kamera oder Design-Tool ist um ein Vielfaches größer, als der Bildschirm braucht.

## Schritt 1: in der angezeigten Größe exportieren

Ein Bild, das 800 Pixel breit angezeigt wird, muss nicht 4.000 Pixel breit sein. Lighthouse markiert zu große Bilder, weil die zusätzlichen Pixel heruntergeladen, dekodiert und weggeworfen werden. Miss, wie breit das Bild in deinem Layout maximal erscheint, und exportiere dann in etwa der doppelten Breite für Handys und Laptops mit hoher Pixeldichte. Mehr als das Doppelte sieht selten schärfer aus und kostet immer Bytes.

| Bild | Angezeigt mit | Exportbreite |
| --- | --- | --- |
| Hero über die volle Breite | Bis 1920 px | 1920 px, plus kleinere Versionen |
| Artikelbild | Etwa 720 px | 1440 px |
| Karten-Thumbnail | Etwa 360 px | 720 px |
| Avatar | 48 px | 96 px |
| Open-Graph-Bild | Außerhalb der Seite | Genau 1200×630 |

Typische Zielwerte. Der Hero über die volle Breite ist die Ausnahme vom Verdoppeln: 1920 px decken die meisten Bildschirme ab, und sehr große Displays bekommen ein leicht weiches Bild zu vernünftigen Kosten.

- Website-Hero 1920×1080: 1920 × 1080
- Blog-Banner 1200×600: 1200 × 600
- Linkvorschau 1200×630: 1200 × 630

Drei gängige Bildgrößen fürs Web, maßstabsgetreu. Gestalte in der finalen Größe, damit nach dem Export nichts beschnitten oder skaliert wird.

## Schritt 2: das richtige Format wählen

Das Format zählt mehr als jeder Kompressionsregler. AVIF liefert meist die kleinste Datei, WebP kommt nah heran und wird überall aktuell unterstützt, JPEG und PNG bleiben die sicheren Rückfalloptionen. [WebP oder PNG](https://gradiently.design/de/guide/webp-images) und [PNG oder JPG](https://gradiently.design/de/guide/png-vs-jpeg) gehen bei jedem Paar tiefer.

| Format | Ideal für | Hinweise |
| --- | --- | --- |
| AVIF | Fotos, Verläufe, große Heros | Kleinste Dateien; langsamer zu kodieren |
| WebP | Fast alles | Verlustbehaftet und verlustfrei, Transparenz, breite Unterstützung |
| JPEG | Fotos, als Rückfalloption | Keine Transparenz; Streifen bei weichen Verläufen |
| PNG | Screenshots, flache Grafiken, Transparenz | Verlustfrei und groß bei Fotos |
| SVG | Logos, Icons, Illustrationen | Vektor, winzig wenn einfach; siehe [SVG oder PNG](https://gradiently.design/de/guide/svg-vs-png) |

Wähle nach Inhalt, nicht nach Gewohnheit. Weiche Verläufe sind der schwierigste Fall für JPEG, und genau dort helfen WebP und AVIF am meisten.

> **Verläufe komprimieren schlecht** Weiche Farbübergänge zeigen Kompression als sichtbare Stufen. Gib vor dem Export etwas Korn dazu, wie in [Streifen in Verläufen](https://gradiently.design/de/guide/gradient-banding) beschrieben, und der Encoder kann stärker arbeiten, ohne dass es jemand sieht. Noch besser: Zeichne Verläufe fürs Web in CSS.

Ein Hero-Verlauf in etwa 70 Bytes: `linear-gradient(160deg, #0f172a 0%, #1e3a8a 50%, #0ea5e9 100%)`

Dieser Verlauf kostet als CSS weniger als eine einzige Zeile der Seite. Als Bild in 1920×1080 exportiert, wöge dasselbe viele Kilobyte. Siehe [Performance von CSS-Verläufen](https://gradiently.design/de/guide/css-gradient-performance).

## Schritt 3: komprimieren, dann hinsehen

Verlustbehaftete Formate haben eine Qualitätseinstellung, und der richtige Wert hängt vom Bild ab. Beginne bei WebP um 75 bis 80 und bei AVIF um 50 bis 60, exportiere und vergleiche mit dem Original bei 100 % Zoom. Senke den Wert, bis du einen Unterschied siehst, und geh dann eine Stufe zurück. Gesichter, feiner Text und Verläufe brauchen mehr Qualität als unruhige Landschaften. [Bildkompression](https://gradiently.design/de/guide/image-compression) erklärt, was der Encoder weglässt.

Entferne bei der Gelegenheit Metadaten wie Kameradaten und eingebettete Vorschaubilder. Die meisten Exportwerkzeuge erledigen das mit einem Häkchen, und es entfernt Bytes, die niemand sieht.

## Schritt 4: responsives Markup mit srcset und sizes

Hast du mehrere Breiten exportiert, lass den Browser wählen. `srcset` listet die Dateien und ihre Breiten; `sizes` sagt dem Browser, wie breit das Bild erscheinen wird. Der Browser lädt dann die kleinste Datei, die für diesen Bildschirm scharf genug ist.

```html
<picture>
  <source type="image/avif"
    srcset="/img/hero-960.avif 960w, /img/hero-1440.avif 1440w, /img/hero-1920.avif 1920w"
    sizes="100vw" />
  <source type="image/webp"
    srcset="/img/hero-960.webp 960w, /img/hero-1440.webp 1440w, /img/hero-1920.webp 1920w"
    sizes="100vw" />
  <img src="/img/hero-1920.jpg" alt="Morning light over the harbour"
    width="1920" height="1080" fetchpriority="high" decoding="async" />
</picture>
```

Der Browser nutzt die erste Quelle, die er unterstützt. Das img-Element ist zugleich die Rückfalloption und der Ort für alt, width, height und Ladehinweise.

Für ein Bild in einer Spalte beschreibst du das Layout in `sizes`, zum Beispiel `sizes="(min-width: 1024px) 720px, 100vw"`. Ein falsches `sizes` ist der häufigste Grund, warum ein responsives Setup trotzdem die große Datei lädt.

## Schritt 5: Ladehinweise, die zählen

```html
<!-- Below the fold: let the browser wait -->
<img src="/img/team-720.webp" alt="The team at the spring workshop"
  width="720" height="480" loading="lazy" decoding="async" />

<!-- The hero: fetch first, never lazy -->
<img src="/img/hero-1920.webp" alt="Morning light over the harbour"
  width="1920" height="1080" fetchpriority="high" />
```

Mit Breite und Höhe reserviert der Browser Platz anhand des Seitenverhältnisses, sodass sich nichts verschiebt, wenn Bilder ankommen. Per CSS bleibt das Bild trotzdem flexibel mit max-width: 100% und height: auto.

### Häufige Fehler

- `loading="lazy"` am Hero-Bild
- Keine Breite und Höhe, die Seite springt
- Eine riesige Datei für jeden Bildschirm
- Ein JPEG von einem flachen Logo oder Screenshot
- Verlaufshintergründe als Bilder gespeichert

### Stattdessen

- Hero lädt sofort mit `fetchpriority="high"`
- Beide Attribute an jedem img setzen
- `srcset` mit drei oder vier Breiten
- SVG oder PNG für flache Grafiken
- CSS-Verläufe, bei Bedarf mit Korn

Diese Hinweise wirken direkt auf die Core Web Vitals. Das Hero-Bild ist oft das Element des Largest Contentful Paint, das laut [web.dev](https://web.dev/articles/lcp) innerhalb von 2,5 Sekunden gerendert sein sollte, und fehlende Maße sind eine klassische Ursache für Layoutverschiebungen. Ist dein Hero ein Video statt eines Bildes, gilt dasselbe Denken in [Videohintergründe für Websites](https://gradiently.design/de/guide/video-background-website).

## Eine Checkliste vor dem Veröffentlichen

1. **Den Platz messen** Finde die größte angezeigte Breite jedes Bildes in deinem Layout.
2. **In den richtigen Größen exportieren** Ein- bis zweimal die Platzbreite, plus kleinere Versionen für Handys.
3. **Das Format wählen** AVIF oder WebP für Fotos und Verläufe, SVG für Logos, PNG nur, wenn es gewinnt.
4. **Mit dem Auge komprimieren** Senk die Qualität, bis du eine Veränderung siehst, und heb sie dann eine Stufe an.
5. **Auszeichnen** `srcset`, `sizes`, `width`, `height`, `alt` und Lazy Loading unterhalb des sichtbaren Bereichs.
6. **Testen** Lass Lighthouse in einem Inkognito-Fenster laufen und prüf die Bild-Audits und das LCP-Element.

Vieles davon wird leichter, wenn das Bild von Anfang an in seiner finalen Größe entsteht. In Gradiently gestaltest du einmal, Pro bringt das Design in einem Schritt auf jede Größe und exportiert PNG, JPG oder SVG in exakten Maßen bis 4K, sodass Hero, Banner und [Open-Graph-Bild](https://gradiently.design/de/guide/open-graph-tags) jeweils in der Größe beginnen, die die Seite zeigt.

## FAQ

### Wie optimiere ich Bilder fürs Web, ohne Qualität zu verlieren?

Exportiere in der angezeigten Größe, nutze AVIF oder WebP, senke die Qualität nur, bis du einen Unterschied siehst, und liefere mit srcset mehrere Größen aus. Der meiste sichtbare Verlust kommt von starker Kompression, nicht vom Verkleinern.

### Welches Bildformat ist das beste für Websites?

WebP ist der sichere moderne Standard, und AVIF ist meist noch kleiner. Nutze SVG für Logos und Icons und behalte JPEG oder PNG als Rückfalloptionen.

### Sollte ich alle Bilder per Lazy Loading laden?

Nein. Lade Bilder unterhalb des sichtbaren Bereichs verzögert, aber das Haupt-Hero-Bild sofort, weil eine Verzögerung den Largest Contentful Paint bremst.

### Welche Größe sollten Bilder für Websites haben?

Etwa die doppelte Breite, in der sie angezeigt werden, für scharfe Bildschirme mit hoher Pixeldichte. Ein Hero über die volle Breite mit 1920 px deckt die meisten Displays ab.

### Warum sagt Lighthouse, meine Bilder hätten nicht die richtige Größe?

Die Datei hat mehr Pixel als der Platz, den sie auf der Seite füllt. Exportiere eine kleinere Version und nutze srcset und sizes, damit der Browser die richtige wählt.
