Wie man Bilder für eine Website komprimiert, ohne die Qualität zu ruinieren

Die praktische Antwort

Um Website-Bilder ohne Qualitätsverlust zu komprimieren, sollten Sie nicht damit anfangen, den Qualitätsregler auf die niedrigste noch akzeptable Zahl zu ziehen. Beginnen Sie stattdessen mit der eigentlichen Aufgabe des Bildes auf der Seite. Ein Hero-Bild, ein Produktfoto zum Heranzoomen, eine Blog-Illustration, ein Avatar, ein Screenshot und eine Hintergrundtextur brauchen jeweils andere Maße, Formate und Qualitätsstufen.

Die brauchbare Regel lautet: Zuerst auf die größte tatsächlich dargestellte Größe skalieren, danach gerade so weit komprimieren, dass das Bild im Layout unverändert aussieht. Wenn ein Blogbild mit 760 CSS-Pixeln Breite dargestellt wird, reicht eine Quelle von 1500–1600 px für hochauflösende Displays in der Regel aus. Ein 5000-px-Original aus der Kamera ist verschwendete Datenmenge. Ein 760-px-Export kann auf Retina-Displays weich wirken. Die richtige Datei liegt zwischen diesen Extremen.

„Ohne Qualitätsverlust" braucht ebenfalls eine nüchterne Definition. Bei Web-Arbeit heißt das üblicherweise kein sichtbarer Qualitätsverlust in der Größe, in der Besucher das Bild sehen, nicht mathematische Pixelperfektion. Ein komprimiertes WebP ist nicht identisch mit dem Original, kann in der Seite aber visuell nicht mehr davon zu unterscheiden sein.

Klären Sie zuerst, welche Art von Website-Bild vorliegt

Bevor Sie WebP, AVIF, JPEG, PNG oder einen Qualitätswert wählen, ordnen Sie das Asset ein:

Diese Tabelle ist bewusst meinungsstark. Die meiste schlechte Bildkompression im Web entsteht dadurch, dass jedes Asset gleich behandelt wird. Ein Startseiten-Hero kann den Largest Contentful Paint beeinflussen. Ein Produktdetailbild kann sich auf Vertrauen und Conversion auswirken. Ein dekorativer Hintergrund darf viel kleiner sein, weil niemand ihn im Detail betrachtet.

Zuerst skalieren: die Maße machen den Löwenanteil aus

Kompression senkt die Zahl der Bytes, mit denen ein festes Pixelraster gespeichert wird. Skalieren verändert das Pixelraster selbst. Hat die Quelle deutlich mehr Pixel als die Seite darstellen kann, ist Skalieren der sauberere Gewinn.

Eine einfache Faustformel für die Größe:

Zielbreite der Quelle = größte CSS-Anzeigebreite × Device Pixel Ratio

Zum Beispiel:

• Ein Card-Bild, das mit 320 CSS-px dargestellt wird, sollte für 2x-Displays eine Quelle von 640 px haben.
• Ein Blogbild mit 760 CSS-px Anzeigebreite braucht eine Quelle von 1500–1600 px.
• Ein vollflächiges Hero, das rund 1200 CSS-px breit ist, verlangt je nach Bildausschnitt und Zielgeräten eine Quelle von 2000–2400 px.

Verwenden Sie nicht blind 3x für jedes Bild. web.dev weist darauf hin, dass DPR und Layout gemeinsam zählen — und dass Nutzer den Vorteil sehr hoher DPR-Quellen häufig nicht wahrnehmen. Ein 2400-px-Hero kann sinnvoll sein. Ein 5000-px-Hero nach dem Motto „mehr Pixel schaden nie" verbrennt meist nur Bandbreite.

PhotoTools trennt diese beiden Aufgaben. Nutzen Sie Resize, wenn Sie exakte Pixelmaße oder eine kürzere lange Kante brauchen. Danach wählen Sie in Compress JPEG, WebP oder AVIF und feinjustieren die Qualität.

Format vor Qualität wählen

Das Format entscheidet, welche Art von Detail sauber weggenommen werden kann.

• Für die meisten Website-Fotos WebP nutzen. Es wird in modernen Browsern breit unterstützt und ist bei vergleichbarer sichtbarer Qualität meist kleiner als JPEG. Googles WebP-Dokumentation nennt 25–34 % Einsparung gegenüber gleichwertigen JPEG-Bildern.
• AVIF dort, wo jedes Byte zählt. AVIF kann WebP bei großen fotografischen Assets schlagen, ist aber langsamer beim Enkodieren und macht die Pipeline komplexer. Verwenden Sie es mit Fallbacks, nicht als einziges Format.
• JPEG als Kompatibilitäts-Fallback. Weiterhin nützlich für E-Mail, ältere CMS-Workflows, Downloads und Fallback-Quellen im <img>.
• PNG oder verlustfreies WebP für Screenshots und Text. Verlustbehaftetes JPEG/WebP kann kleinen UI-Text ausfransen und um harte Kanten Farbrauschen erzeugen.
• SVG für Logos und Icons. Ein Raster-Logo als WebP mag kleiner sein als PNG, ein sauberes SVG ist meist schärfer und leichter.

Wenn Sie <picture> verwenden, stellen Sie das effizienteste Format nach vorne und behalten Sie einen kompatiblen Fallback im verschachtelten img:

<picture>
  <source
    type="image/avif"
    srcset="/images/hero-1200.avif 1200w, /images/hero-2000.avif 2000w"
    sizes="100vw"
  />
  <source
    type="image/webp"
    srcset="/images/hero-1200.webp 1200w, /images/hero-2000.webp 2000w"
    sizes="100vw"
  />
  <img
    src="/images/hero-1200.jpg"
    width="1200"
    height="800"
    alt="Fertig umgebaute Küche mit Walnussschränken und viel Tageslicht"
  />
</picture>

Das img-Element bleibt wichtig. Es trägt die Fallback-Quelle, alt, width und height. Verstecken Sie Barrierefreiheits- oder Layoutinformationen nicht in source-Elementen.

Qualitätseinstellungen, die in der Praxis taugen

Qualitätszahlen sind nicht standardisiert. JPEG-Qualität 80 in einem Encoder muss nicht der Qualität 80 in einem anderen entsprechen. WebP 80, JPEG 80 und AVIF 50 sind ebenfalls nicht gleichwertig. Behandeln Sie die Qualität als Startpunkt und begutachten Sie danach die exportierte Datei.

Eine häufige Falle ist, alles bei Qualität 95 oder 100 zu exportieren, weil es sich sicherer anfühlt. Bei den meisten Web-Fotos sind die zusätzlichen Bytes im Netzwerk-Wasserfall sichtbar, aber nicht auf der Seite. Eine andere Falle ist, die Qualität unter 50 zu drücken, um ein beliebig gesetztes Ziel zu treffen. Wenn die Qualität so weit runter muss, skalieren Sie das Bild oder wechseln Sie das Format, bevor Sie es weiter verschlechtern.

Zieldateigrößen nach Seitenrolle

Das sind keine Google-Regeln und keine magischen Ranking-Schwellen. Es sind praktische Prüfziele, mit denen Sie offensichtlich zu schwere Bilder erkennen.

Wenn ein 760-px-Blogbild 900 KB wiegt, ist das ein Fall zum Nachbessern. Wenn ein vollbreites Portfolio-Bild 410 KB hat und großartig aussieht, ist es womöglich falsch, es auf 90 KB einzudampfen.

LCP- und Hero-Bilder komprimieren

Das Bild, dessen Optimierung sich am meisten lohnt, ist häufig das größte Bild oberhalb der Falz. In der Sprache der Core Web Vitals ist das oft das Bild für den Largest Contentful Paint. Es zu komprimieren hilft — aber nur, wenn es außerdem früh erkannt und geladen wird.

Für ein Hero-Bild:

1. Auf das tatsächliche Seitenverhältnis der Seite zuschneiden.
2. Responsive Breiten exportieren, z. B. 1200 px und 2000 px.
3. AVIF zuerst und WebP/JPEG als Fallback, sofern der Stack das unterstützt.
4. Das Hero (oder einen anderen LCP-Kandidaten über der Falz) nicht lazy-loaden.
5. width und height setzen, damit der Browser Layoutplatz reservieren kann.
6. fetchpriority="high" nur für das eine Bild verwenden, das wahrscheinlich das LCP-Element ist.

Beispiel für das Fallback-img:

<img
  src="/images/hero-1200.jpg"
  srcset="/images/hero-1200.jpg 1200w, /images/hero-2000.jpg 2000w"
  sizes="100vw"
  width="1200"
  height="800"
  fetchpriority="high"
  alt="Fertig umgebaute Küche mit Walnussschränken und viel Tageslicht"
/>

Setzen Sie fetchpriority="high" nicht auf eine ganze Galerie. Prioritäts-Hinweise sind scharfe Werkzeuge — reservieren Sie sie für das Bild, das wirklich zuerst ankommen muss.

Wie man Kompressionsergebnisse vergleicht

Der richtige Vergleich ist nicht Originaldatei gegen komprimierte Datei bei 100 % Zoom. So redet man sich das Ausliefern zu großer Bilder schön. Vergleichen Sie in der Größe und im Kontext, den Besucher zu sehen bekommen.

Nutzen Sie diesen Prüfdurchlauf:

1. Legen Sie das komprimierte Bild in die echte Seite oder ein Testlayout mit gleicher Breite.
2. Prüfen Sie es in Desktop- und Mobilbreite.
3. Schauen Sie auf die wahrscheinlichen Problemzonen: Gesichter, Haut, Himmel, Verläufe, Stoff, Produktbeschriftungen, kleiner Text und kontrastreiche Kanten.
4. Schalten Sie in gerenderter Größe zwischen Original und komprimierter Version hin und her.
5. Zoomen Sie kurz auf 100 %, um offensichtliche Artefakte zu erwischen — nicht, um eine Perfektion einzufordern, die niemand sieht.

Kompressionsartefakte haben ihre Eigenheiten. JPEG zeigt oft blockige Kanten, Ringing oder Farbrauschen. Übermäßig komprimiertes WebP kann Textur verschmieren. AVIF kann bei zu aggressiver Einstellung Banding oder plastikartiges Aussehen erzeugen. PNG-Screenshots scheitern typischerweise in die andere Richtung: perfekt aussehend, aber deutlich zu schwer.

Ein PhotoTools-Workflow für Website-Bilder

PhotoTools ist nützlich, bevor ein Bild in Ihr CMS, CDN oder Repository wandert. Es ersetzt keine vollständige Build-Pipeline, gibt Ihnen aber einen sauberen manuellen Workflow für kleine Websites, Blogbeiträge, Kundenvorschauen und einmalige Assets.

1. Die Originaldatei unangetastet lassen.
2. Rolle des Bildes festlegen: Hero, Inhaltsbild, Produktfoto, Screenshot, Thumbnail oder Hintergrund.
3. Wenn das Original deutlich größer ist als die Anzeigegröße, zuerst Resize verwenden.
4. Compress öffnen, JPEG, WebP oder AVIF wählen und für WebP/JPEG bei Qualität 80 starten.
5. „Compress all" klicken und in jeder Karte Originalgröße, Ausgabegröße und Einsparungsprozent lesen.
6. Das Ergebnis herunterladen und im Seitenkontext prüfen.
7. Sieht es schlecht aus, zurück zum Original oder zur skalierten Kopie und mit höherer Qualität neu exportieren.
8. Ist es immer noch zu schwer, Maße reduzieren, bevor die Qualität in den Artefaktbereich rutscht.

Komprimieren Sie nicht erneut den bereits komprimierten Download — das summiert Artefakte auf. Gehen Sie zurück zum Master oder zur sauberen skalierten Zwischenstufe.

Metadaten und Datenschutz

Kameradateien enthalten oft EXIF-Metadaten: GPS-Koordinaten, Aufnahmedatum, Kameramodell, Objektiv und Bearbeitungssoftware. Diese Metadaten helfen keinem Website-Besucher beim Betrachten des Bildes. Sie können außerdem private Informationen offenlegen.

PhotoTools komprimiert Bilder, indem die Datei dekodiert, die Pixel auf einen Browser-Canvas gezeichnet und eine neue Datei exportiert wird. MDN dokumentiert, dass OffscreenCanvas.convertToBlob() für Formate mit verlustbehafteter Kompression Bildtyp und Qualität festlegen kann. Da die Ausgabe aus den Canvas-Pixeln erzeugt wird, werden Kamera-Metadaten üblicherweise nicht in die neue Datei übernommen.

Prüfen Sie bei sensiblen Fotos vor der Veröffentlichung den fertigen Download mit einem Metadaten-Checker. Datenschutz ist nicht bloß Dateigröße.

Häufige Fehler, die Bilder schlecht aussehen lassen

• Komprimieren vor dem Skalieren: Sie versuchen, Bytes für Pixel einzusparen, die das Layout nie zeigen wird.
• PNG für Fotos: PNG ist bei Kamerabildern in der Regel riesig.
• JPEG für Screenshots mit Text: Die Datei mag kleiner sein, aber der Text sieht ausgefranst aus.
• Beurteilung in der falschen Größe: Ein Zoom auf die volle Auflösung lässt harmlose Artefakte dramatisch wirken.
• Ein einziges riesiges Hero für alle Geräte: Mobile Besucher laden Desktop-Pixel, die sie nicht brauchen.
• Das Hero lazy-loaden: Bilder unterhalb der Falz dürfen lazy geladen werden. Das LCP-Bild nicht.
• Keine width und height: Die Seite kann beim Laden springen.
• Die veröffentlichte Datei erneut komprimieren: Wenn möglich, mit der Quelldatei anfangen.

Eine kompakte Publikations-Checkliste

Bevor Sie ein Website-Bild hochladen, gehen Sie das hier durch:

1. Ist das das richtige Format für den Inhaltstyp?
2. Basiert die Quellbreite auf der tatsächlichen Anzeigebreite und dem plausiblen DPR?
3. Gibt es ggf. einen kleineren Mobil-Kandidaten, wenn sich der Hero-Ausschnitt mobil ändert?
4. Ist die Qualitätsstufe hoch genug für Gesichter, Beschriftungen, Verläufe und Produktdetail?
5. Ist die Dateigröße für ihre Rolle vernünftig?
6. Sind width, height, ein sinnvoller alt und wo nötig responsive srcset/sizes gesetzt?
7. Wird das LCP-Bild eager geladen und priorisiert, während Bilder unterhalb der Falz lazy laden?
8. Haben Sie das exportierte Bild im echten Layout geprüft?
9. Haben Sie die Originaldatei aufbewahrt?

Der beste Kompressions-Workflow ist auf die richtige Art langweilig: die richtigen Pixel wählen, das richtige Format wählen, in vernünftiger Qualität exportieren, in der echten Seite prüfen und aufhören, bevor das Bild „bearbeitet" wirkt.

Geprüfte technische Quellen

Dieser Artikel wurde gegen die aktuelle PhotoTools-Implementierung von Kompression und Resize sowie gegen den Image-Performance-Leitfaden von web.dev, Chromes „Improve image delivery"-Insight, Chromes „Properly size images"-Anleitung, die MDN-Dokumentation zu OffscreenCanvas.convertToBlob(), den MDN-Leitfaden zu Bilddateitypen und Googles WebP-Dokumentation überprüft.