Welches Bildformat sollte ich fürs Web verwenden?

Vergleichen Sie bei Fotos JPEG, WebP und AVIF bei ähnlicher sichtbarer Qualität und nehmen Sie das kleinste, das Ihre Kompatibilitätsanforderungen erfüllt – per picture mit einem Fallback, der die Eigenschaften des Bildes erhält, also JPEG für deckende Fotos, PNG, wo Transparenz oder verlustfreie Details zählen. SVG passt oft für einfache Logos, Icons und Strichzeichnungen. Testen Sie pro Bild; kein Format gewinnt immer.

Warum sollte ich bei Bildern width und height setzen?

Korrekte width- und height-Attribute verraten dem Browser das Seitenverhältnis des Bildes, bevor es lädt – so kann er den Platz reservieren, und das Laden des Bildes verursacht nicht diesen einen häufigen Layout-Sprung. Eine richtig dimensionierte CSS-Box mit aspect-ratio erreicht dasselbe; in beiden Fällen muss das angegebene Verhältnis zur echten Datei passen.

Sollte ich jedes Bild per Lazy Loading laden?

Nein. Nutzen Sie loading="lazy" für unkritische Bilder außerhalb des ersten Sichtbereichs – im Wissen, dass Browser selbst entscheiden, wie früh sie sie holen, und sie oft laden, bevor sie sichtbar werden. Laden Sie nie Bilder verzögert, die beim Start sichtbar sind, oder das wahrscheinliche LCP-Element (den größten sichtbaren Inhalt beim Laden); das muss im ersten HTML auffindbar bleiben.

Sind Ihre Bilder fürs Web optimiert?

Bilder gehören oft zu den größten Ressourcen einer Seite – ein einziges unoptimiertes Foto kann mehr wiegen als Ihr gesamtes HTML, CSS und JavaScript zusammen. Auf bildlastigen Websites sind passend dimensionierte, gut komprimierte Dateien einer der zuverlässigsten Wege, übertragene Bytes zu sparen und das Laden zu beschleunigen. Ob es Ihr größter Gewinn ist, sagt Ihnen die Messung.

Nutzen Sie moderne Formate

Alte JPEG- und GIF-Dateien sind oft viel größer, als sie sein müssten. Moderne Formate komprimieren dasselbe Bild bei sichtbar ähnlicher Qualität häufig kleiner – aber nicht immer: Die Ersparnis hängt vom Bild, vom Encoder und von der Qualitätseinstellung ab, und ein gut kodiertes JPEG oder PNG kann sie gelegentlich schlagen. Testen statt annehmen:

WebP und AVIF – bei Fotos oft deutlich kleiner; nutzen Sie sie, wo sie Ihre Anforderungen an Qualität und Kompatibilität erfüllen, mit einem Fallback über <picture>.
SVG – für einfache Logos, Icons und Strichzeichnungen: skaliert ohne Pixelbrei und ist meist winzig – komplexe Grafiken können allerdings groß werden, also Markup optimieren und vergleichen. Nutzen Sie nur vertrauenswürdige, optimierte SVGs und bereinigen Sie alles, was von Nutzern kommt, bevor Sie es inline einbetten (SVG ist aktives Markup, nicht bloß Pixel).

Geben Sie dem Fallback die Eigenschaften, die das Bild braucht – JPEG für deckende Fotos, PNG, wo Transparenz oder verlustfreie Kanten zählen:

<picture>
  <source srcset="hero.avif" type="image/avif">
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="Team at work" width="1200" height="630">
</picture>

Größe fürs Display – Pixeldichte eingerechnet – und responsiv

Schicken Sie kein 4000-Pixel-Foto in einen 400-Pixel-Platz – aber verkleinern Sie auch nicht allein auf die CSS-Breite: Ein 400-CSS-Pixel-Platz auf einem hochauflösenden Bildschirm will vielleicht eine 800-Pixel-Datei. Erzeugen Sie mehrere Breiten und lassen Sie den Browser wählen:

<img src="chair-800.webp"
     srcset="chair-400.webp 400w, chair-800.webp 800w, chair-1600.webp 1600w"
     sizes="(max-width: 600px) 100vw, 800px"
     alt="Ergonomic office chair" width="800" height="600">

sizes ist ein Auswahl-Hinweis, kein Styling: Es muss die Platzbreite beschreiben, die Ihr CSS wirklich erzeugt – sonst greift der Browser zum falschen Kandidaten. Prüfen Sie im Netzwerk-Panel der Entwicklertools, bei ein paar Fensterbreiten und Pixeldichten, welche Datei wirklich geladen wird.

Komprimieren, Maße setzen, verzögert laden

Komprimieren Sie jedes Bild mit einem Tool (Squoosh, ImageOptim, cwebp, jpegoptim). Qualitätsskalen sind zwischen Formaten und sogar Encodern nicht genormt – probieren Sie pro Bild ein paar Einstellungen und urteilen Sie mit dem Auge gegen die Dateigröße. Entfernen Sie dabei unnötige Metadaten – Fotodateien können GPS-Koordinaten und Zeitstempel tragen – und prüfen Sie, dass Ausrichtung und Farben überleben.
Setzen Sie korrekte width und height (oder reservieren Sie den Platz mit einer richtig dimensionierten CSS-Box und aspect-ratio), damit ladende Bilder nicht den klassischen Layout-Sprung auslösen können. Falsche Maße verschieben trotzdem; korrekte verhindern diese eine häufige Quelle von CLS (dem Springen des Layouts beim Laden).
Laden Sie unkritische Bilder verzögert, außerhalb des ersten Sichtbereichs, mit loading="lazy" – Browser holen sie nach eigenen Regeln etwas vor der Sichtbarkeit. Finden Sie das wahrscheinliche LCP-Bild (LCP: der größte sichtbare Inhalt beim Laden; oft, aber nicht immer, das große Aufmacherbild): Halten Sie es aus dem Lazy Loading heraus und im ersten HTML auffindbar – und erwägen Sie fetchpriority="high" nur mit Messung.
Barrierefreiheit bleibt: Beschreiben Sie informative Bilder nach ihrem Zweck, geben Sie dekorativen alt="" – und sperren Sie wesentlichen Text nie in ein Bild.

Optimieren Sie Ihre Bilder, und Sie beseitigen eines der häufigsten Performance-Probleme des Webs – auf bildlastigen Seiten oft das größte.

Was zu tun ist

Konvertieren Sie Fotos in das Format, das bei Ihrer Qualitätsgrenze am kleinsten testet, mit einem eigenschaftserhaltenden Fallback über <picture>.
Erzeugen Sie responsive Breiten (hochauflösende Kandidaten eingeschlossen), ergänzen Sie srcset und lassen Sie sizes zu Ihrem echten CSS passen.
Schicken Sie alles vor dem Hochladen durch einen Kompressor – mit dem Auge beurteilt, Metadaten entfernt.
Geben Sie jedem Bild korrekte width und height, unkritischen Bildern außerhalb des Sichtbereichs loading="lazy" – und schützen Sie das LCP-Bild vor Lazy Loading und vor später Entdeckung.
Messen Sie nach: übertragene Bild-Bytes, welcher srcset-Kandidat lädt, und LCP/CLS auf einem typischen Smartphone – und behalten Sie, was die Zahlen bestätigen.