Fotos für Webseiten sollten nicht einfach mit maximaler Auflösung hochgeladen werden. Entscheidend sind das passende Dateiformat, die tatsächlich benötigten Abmessungen und eine Komprimierung, bei der sichtbare Details erhalten bleiben. Richtig optimierte Dateien übertragen weniger Daten und können dadurch Seiten schneller erscheinen lassen. Besonders bei umfangreichen Fotogalerien mit vielen Bildern summiert sich jedes unnötige Kilobyte.
Inhaltsverzeichnis
- JPEG, WebP und AVIF richtig auswählen
- Bildabmessungen vor der Komprimierung reduzieren
- Kompressionsqualität ohne sichtbare Schäden einstellen
- Responsive Bilder mit srcset und sizes ausliefern
- Google, LCP und Lazy Loading richtig berücksichtigen
- Ein sicherer Workflow für neue Webbilder
- FAQ
JPEG, WebP und AVIF richtig auswählen
Für klassische Fotografien kommen heute vor allem JPEG, WebP und AVIF infrage. PNG bleibt wichtig, wenn verlustfreie Darstellung oder Transparenz benötigt wird. Wer bereits bei der Aufnahme und Bearbeitung mit unterschiedlichen Dateitypen arbeitet, sollte außerdem wissen, wann RAW oder JPEG sinnvoll ist. Die große RAW-Datei gehört normalerweise nicht direkt auf eine Webseite. Für die Veröffentlichung wird eine optimierte Ausgabe erzeugt.
Auch die Organisation spielt eine Rolle. Ein komprimiertes Bild sollte einen verständlichen Dateinamen behalten und nicht als kryptische Exportdatei im CMS landen. Sinnvolle Regeln zum Benennen von Fotodateien erleichtern die Pflege größerer Bildbestände. Die beste Webdatei ist deshalb nicht einfach die kleinste Datei, sondern die kleinste Variante, die in ihrer vorgesehenen Darstellung noch sauber und scharf aussieht.
Das Dateiformat entscheidet wesentlich darüber, wie effizient ein Bild gespeichert werden kann. JPEG ist weiterhin für Fotos geeignet und besitzt eine sehr breite Unterstützung. WebP und AVIF wurden dagegen für eine effizientere Bildübertragung entwickelt. MDN und web.dev empfehlen beide Formate für moderne Webseiten, weil sie bei vergleichbarer visueller Darstellung häufig kleinere Dateien als ältere Rasterformate ermöglichen.
Welches Bildformat passt?
Die Auswahl hängt vor allem vom Bildtyp und vom gewünschten Einsatzzweck ab.
| Situation | Passende Wahl | Warum? | Darauf achten |
|---|---|---|---|
| Normales Foto | WebP oder AVIF | Moderne Kompression bei guter Bildqualität | Ergebnis am Originalmotiv prüfen |
| Breite Kompatibilität wichtig | JPEG | Sehr weit verbreitet | Kompression nicht zu stark einstellen |
| Foto mit Transparenz | WebP oder AVIF | Transparenz mit moderner Kompression möglich | Browser und CMS testen |
| Grafik ohne Qualitätsverlust | PNG oder verlustfreies WebP | Pixelinformationen bleiben erhalten | Dateigröße vergleichen |
| Logo oder Symbol | SVG | Vektorgrafik bleibt in verschiedenen Größen scharf | Nur für geeignete Grafiken verwenden |
WebP und AVIF sind besonders interessant für Fotos, bei denen eine deutliche Reduzierung der Dateigröße wichtiger ist als die Beibehaltung eines älteren Dateiformats. WebP unterstützt sowohl verlustbehaftete als auch verlustfreie Kompression und kann Transparenz speichern. AVIF unterstützt ebenfalls verlustbehaftete und verlustfreie Varianten, Transparenz sowie höhere Farbtiefen.
JPEG bleibt dennoch praktisch. Das Format funktioniert praktisch überall und eignet sich gut als Rückfalllösung. Bei einem bestehenden Bildarchiv muss deshalb nicht jede Datei sofort ersetzt werden. Größere Einsparungen entstehen häufig zuerst dort, wo große Titelbilder, Galerien und regelmäßig aufgerufene Artikelfotos optimiert werden.
PNG sollte bei normalen Fotografien nicht automatisch die erste Wahl sein. Die verlustfreie Speicherung kann zu deutlich größeren Dateien führen. Das Format ist sinnvoller für Inhalte, bei denen exakte Pixelwerte oder Transparenz benötigt werden. Logos und einfache grafische Elemente lassen sich je nach Aufbau oft noch effizienter als SVG bereitstellen.
| Format | Geeignet für | Kompression | Wichtiger Punkt |
|---|---|---|---|
| JPEG | Fotos und klassische Webinhalte | Verlustbehaftet | Sehr breite Unterstützung |
| WebP | Fotos, Grafiken und transparente Bilder | Verlustbehaftet oder verlustfrei | Gute Kombination aus Effizienz und Browser-Unterstützung |
| AVIF | Stark komprimierte moderne Webbilder | Verlustbehaftet oder verlustfrei | Sehr effiziente Kompression möglich |
| PNG | Grafiken und Inhalte mit Transparenz | Verlustfrei | Für gewöhnliche Fotos oft unnötig groß |
| SVG | Logos, Symbole und Vektorgrafiken | Vektorbasiert | Bleibt bei unterschiedlichen Größen scharf |
Bildabmessungen vor der Komprimierung reduzieren
Ein häufiger Fehler beginnt bereits vor der eigentlichen Kompression. Eine Kamera oder ein Smartphone erzeugt Bilder, deren Pixelmaße wesentlich größer sein können als die Darstellung im Artikel. Wird eine solche Originaldatei unverändert hochgeladen, muss der Browser Daten herunterladen, die er anschließend nur verkleinert darstellt.
Ein Bild sollte deshalb in einer Auflösung bereitgestellt werden, die zu seiner tatsächlichen Darstellung auf der Webseite passt. Ein kleines Vorschaubild benötigt nicht dieselbe Quelldatei wie ein großflächiges Titelmotiv. Bei responsiven Layouts ist es sinnvoll, mehrere Breiten desselben Motivs bereitzustellen.
Das bedeutet nicht, dass jede Datei exakt die sichtbare CSS-Breite besitzen muss. Displays mit höherer Pixeldichte können von größeren Bildvarianten profitieren. Genau dafür wurden Mechanismen wie srcset und sizes entwickelt. Der Browser kann damit eine geeignete Version auswählen, anstatt jedem Gerät dieselbe große Datei zu schicken.
Das Herunterskalieren sollte möglichst vor der endgültigen Kompression erfolgen. Zuerst werden Ausschnitt und benötigte Abmessungen festgelegt. Danach wird die Webdatei komprimiert. Wird eine bereits stark komprimierte JPEG-Datei mehrfach geöffnet, verändert und erneut mit verlustbehafteter Kompression gespeichert, können sich sichtbare Artefakte verstärken.
Die Originaldatei bleibt getrennt
Das hochauflösende Ausgangsfoto sollte weiterhin separat archiviert werden. Die Webversion ist eine Veröffentlichungskopie. Dadurch kann später eine neue Größe oder ein moderneres Format erzeugt werden, ohne auf eine bereits verkleinerte und komprimierte Datei zurückgreifen zu müssen.
- Originalbild unverändert archivieren
- benötigten Ausschnitt festlegen
- Bild auf die erforderlichen Ausgabegrößen skalieren
- passendes Webformat wählen
- Kompression visuell kontrollieren
- Webversion separat speichern
Kompressionsqualität ohne sichtbare Schäden einstellen
Bei verlustbehafteten Formaten gibt es keine universelle Qualitätseinstellung, die für jedes Motiv optimal ist. Ein Porträt mit ruhigem Hintergrund reagiert anders auf starke Kompression als eine Landschaft mit feinen Blättern, Haaren, Strukturen oder vielen kleinen Kontrasten. Deshalb sollte die Qualitätsstufe nicht nur anhand einer Zahl gewählt werden.
Entscheidend ist die visuelle Kontrolle in der Größe, in der das Foto später tatsächlich gezeigt wird. Wer nur stark in das Bild hineinzoomt, entdeckt möglicherweise Veränderungen, die bei normaler Darstellung unsichtbar bleiben. Umgekehrt können an Kanten, Haaren, Texturen und feinen Farbverläufen schnell störende Kompressionsspuren auftreten.
Bei JPEG können typische Artefakte als blockartige Strukturen, ausgefranste Kanten oder unruhige Flächen sichtbar werden. Bei moderneren Verfahren sehen Fehler anders aus, doch das Grundprinzip bleibt gleich. Die Kompression wird so weit erhöht, bis die Dateigröße deutlich sinkt, ohne dass das Motiv in der vorgesehenen Darstellung sichtbar leidet.
Eine verlustfreie Kompression verändert die Bildinformationen nicht. Das ist technisch die sicherste Variante, erreicht bei Fotografien aber nicht immer die kleinsten Dateien. Für viele redaktionelle Fotos ist daher eine kontrollierte verlustbehaftete Ausgabe sinnvoller. Die hochwertige Originaldatei bleibt gleichzeitig erhalten.
Diese Bildbereiche zuerst prüfen
- Gesichter und Augen
- Haare und Fell
- Blätter, Gras und feine Texturen
- Schrift und harte Kanten
- gleichmäßige Himmel und Farbverläufe
- dunkle Bereiche mit wenig Kontrast
Bei Motiven mit eingebauter Schrift ist besondere Vorsicht nötig. Stark komprimierte Fotografien können rund um Buchstaben sichtbare Säume erzeugen. Für reine Schriftgrafiken, Logos oder Illustrationen können PNG, WebP in einer verlustfreien Variante oder SVG geeigneter sein.
Responsive Bilder mit srcset und sizes ausliefern
Die Kompression allein löst das Problem übergroßer Bilder nicht. Eine Datei kann hervorragend komprimiert sein und trotzdem unnötig viele Pixel enthalten. Responsive Images sorgen dafür, dass Browser aus mehreren angebotenen Dateien eine passende Variante auswählen können.
Das HTML-Attribut srcset kann mehrere Bildbreiten anbieten. sizes informiert den Browser darüber, wie groß die Darstellung unter verschiedenen Layoutbedingungen voraussichtlich sein wird. Der Browser berücksichtigt diese Angaben zusammen mit Eigenschaften des Geräts und entscheidet selbst, welche Datei geladen wird.
Damit erhält ein Smartphone nicht automatisch dieselbe Bilddatei wie ein großer Desktop-Bildschirm. Gerade bei langen Artikeln und Galerien kann dieses Prinzip die übertragene Datenmenge deutlich reduzieren.
Das Element picture ermöglicht zusätzlich die Bereitstellung verschiedener Dateiformate. Eine Webseite kann beispielsweise AVIF und WebP anbieten und eine klassische JPEG-Datei als Rückfalllösung behalten. Der Browser verwendet die erste unterstützte geeignete Quelle.
Auch Google Search Central empfiehlt standardmäßige HTML-Bildelemente. Bilder, die über das img-Element eingebunden sind, können von Google gefunden und verarbeitet werden. Ein ausschließlich als CSS-Hintergrund eingebundenes Motiv wird von Google Images dagegen nicht wie ein normales HTML-Bild indexiert.
Google, LCP und Lazy Loading richtig berücksichtigen
Große Bilder wirken sich nicht nur auf den Datenverbrauch aus. Sie können auch die Ladezeit des wichtigsten sichtbaren Seiteninhalts beeinflussen. Das ist besonders relevant, wenn ein großes Artikelbild das Largest Contentful Paint Element einer Seite bildet.
Nach den aktuellen Empfehlungen von web.dev gilt ein Largest Contentful Paint von höchstens 2,5 Sekunden am 75. Perzentil als guter Wert. Bilder sind nicht der einzige Einflussfaktor. Serverantwort, Netzverbindung, CSS, JavaScript und Priorisierung von Ressourcen spielen ebenfalls eine Rolle. Eine unnötig große Titelgrafik kann die Situation jedoch zusätzlich verschlechtern.
Das wichtigste Bild im direkt sichtbaren Bereich sollte nicht mit Lazy Loading verzögert werden. web.dev warnt ausdrücklich davor, ein LCP-Bild mit loading="lazy" zu laden. Für ein wichtiges Bild kann fetchpriority="high" dem Browser stattdessen signalisieren, dass diese Ressource eine hohe Ladepriorität besitzt.
Lazy Loading ist dagegen für weiter unten liegende Bilder sinnvoll. Mit loading="lazy" können solche Dateien später geladen werden, wenn sie sich dem sichtbaren Bereich nähern. Das verringert die Datenmenge beim ersten Seitenaufruf, ohne dass sämtliche Bilder eines langen Artikels sofort übertragen werden müssen.
Bildbreite und Bildhöhe sollten im HTML ebenfalls angegeben werden. Die Attribute width und height helfen dem Browser, bereits vor dem Download den benötigten Platz zu reservieren. Dadurch lassen sich unerwartete Layoutverschiebungen vermeiden. web.dev empfiehlt einen CLS-Wert von höchstens 0,1 am 75. Perzentil.
Wie viel Daten spart die Bildkomprimierung?
Originalgröße und optimierte Dateigröße eintragen. Der Rechner zeigt die Ersparnis pro Bild und bei mehreren Seitenaufrufen.
Werte eingeben und Berechnung starten.
Bildqualität bleibt auch für die Suche relevant
Kompression darf nicht dazu führen, dass ein wichtiges Motiv sichtbar unscharf wird. Google Search Central empfiehlt klare und hochwertige Bilder und weist für die mobile Indexierung ausdrücklich darauf hin, keine zu kleinen oder niedrig aufgelösten wichtigen Bilder auszuliefern. Geschwindigkeit und ausreichende visuelle Qualität müssen deshalb zusammen betrachtet werden.
Ein guter technischer Test kombiniert mehrere Werkzeuge. Chrome DevTools zeigt die tatsächlich geladene Ressource und ihre Übertragungsgröße. Lighthouse und PageSpeed Insights helfen bei der Suche nach Leistungsproblemen. Search Console liefert ergänzend Daten zur tatsächlichen Seitenerfahrung aus der Google-Perspektive.
Ein sicherer Workflow für neue Webbilder
Am effizientesten ist eine feste Reihenfolge. Sie verhindert, dass Bilder zunächst stark komprimiert und später erneut verkleinert oder konvertiert werden. Gleichzeitig bleibt nachvollziehbar, welche Datei das hochwertige Ausgangsmaterial ist.
- Das Originalbild unverändert sichern.
- Den endgültigen Bildausschnitt bestimmen.
- Die benötigten Darstellungsgrößen der Webseite prüfen.
- Passende Pixelvarianten erzeugen.
- Für Fotografien WebP oder AVIF testen und bei Bedarf JPEG als Rückfalllösung behalten.
- Die Kompression anhand kritischer Bildbereiche visuell vergleichen.
- Dateinamen und Alt-Text passend zum tatsächlichen Motiv festlegen.
- Breite und Höhe im HTML hinterlegen.
- Für unterschiedliche Bildschirmgrößen passende Quellen bereitstellen.
- Die veröffentlichte Seite mit real geladenen Dateien kontrollieren.
| Prüfschritt | Gute Lösung | Problematische Lösung | Nutzen |
|---|---|---|---|
| Abmessungen | Mehrere passende Bildgrößen | Ein großes Original für jedes Gerät | Weniger unnötige Bilddaten |
| Dateiformat | WebP oder AVIF testen | Format unabhängig vom Motiv wählen | Effizientere Speicherung |
| Qualität | Datei bei realer Darstellung prüfen | Nur eine Exportzahl betrachten | Weniger sichtbare Artefakte |
| Auslieferung | srcset und sizes verwenden | Für jedes Display dieselbe Datei laden | Browser kann eine passende Quelle auswählen |
| Bilder unterhalb des sichtbaren Bereichs | Lazy Loading gezielt einsetzen | Alle Bilder sofort übertragen | Weniger Daten beim ersten Laden |
| Titelbild | Früh laden und passend dimensionieren | LCP-Bild verzögert laden | Bessere Voraussetzungen für schnelles LCP |
Dateigröße allein reicht nicht als Maßstab
Zwei Dateien mit identischer Größe können unterschiedlich aussehen. Ebenso kann ein modernes Format bei kleinerer Datei mehr Details bewahren als eine ungünstig komprimierte ältere Variante. Deshalb sollte eine Redaktion nicht mit einer starren maximalen Dateigröße arbeiten und dabei Motiv, Pixelabmessungen und Nutzung ignorieren.
Die sinnvollere Kontrolle betrachtet mehrere Faktoren gemeinsam. Dazu gehören Dateigröße, dargestellte Breite, sichtbare Artefakte, verwendetes Format und die tatsächlich übertragene Ressource im Browser. Erst diese Kombination zeigt, ob ein Bild wirklich effizient ausgeliefert wird.
Besonders bei automatischen CMS-Prozessen sollte nach dem Upload geprüft werden, was im Frontend passiert. Ein System kann zusätzliche Vorschaubilder erzeugen, Bilder konvertieren oder eigene Qualitätsstufen verwenden. Der Blick auf die tatsächlich geladene Datei ist deshalb aussagekräftiger als allein die Datei, die ursprünglich hochgeladen wurde.
Wichtigste Punkte zum Merken
- Originalbilder nicht direkt als Webversion verwenden.
- Fotos vor der endgültigen Kompression auf passende Abmessungen bringen.
- WebP und AVIF für moderne Fotoauslieferung prüfen.
- JPEG kann als breit unterstützte Alternative sinnvoll bleiben.
- PNG vor allem dort einsetzen, wo verlustfreie Darstellung oder Transparenz benötigt wird.
- Kompressionsqualität immer am tatsächlichen Motiv kontrollieren.
- Mit srcset und sizes mehrere geeignete Bildgrößen anbieten.
- Bilder außerhalb des sichtbaren Bereichs können verzögert geladen werden.
- Das wichtige LCP-Bild nicht mit Lazy Loading verzögern.
- Breite und Höhe der Bilder im HTML festlegen.
Bilder fürs Web komprimieren und richtig verkleinern
Das Video erklärt Schritt für Schritt, wie große Bilddateien verkleinert und für Webseiten komprimiert werden können, ohne dass die sichtbare Bildqualität unnötig leidet.
Im Video wird gezeigt, wie Bildgröße und Dateigröße reduziert werden können und worauf bei der Komprimierung für die Webnutzung zu achten ist.
Film: YouTube / Kanal Oliver Pfeil
FAQ
Welches Bildformat ist für Webseiten am besten?
Für Fotografien sind WebP und AVIF häufig besonders effizient. JPEG bleibt eine solide und breit unterstützte Alternative. PNG eignet sich eher für verlustfreie Grafiken und Transparenz. Das passende Format hängt immer vom Bildinhalt und den technischen Anforderungen ab.
Kann man Fotos ohne jeden Qualitätsverlust verkleinern?
Bei verlustfreier Kompression bleiben die Bildinformationen erhalten. Bei verlustbehafteter Kompression werden dagegen Informationen entfernt. Ziel einer guten Weboptimierung ist häufig, die Datei so stark zu verkleinern, dass in der vorgesehenen Darstellung kein störender Qualitätsverlust sichtbar wird.
Ist WebP besser als JPEG?
WebP bietet bei vielen Webbildern eine effizientere Kompression und unterstützt zusätzlich Transparenz. JPEG besitzt jedoch eine sehr lange und breite Unterstützung. Welche Variante sinnvoller ist, sollte anhand des konkreten Fotos und der resultierenden Datei geprüft werden.
Ist AVIF immer die beste Wahl?
Nein. AVIF kann sehr effizient komprimieren, ist aber nicht automatisch für jedes Motiv und jeden technischen Ablauf optimal. Encoding-Aufwand, vorhandene Software, gewünschte Kompatibilität und das konkrete Bildergebnis müssen berücksichtigt werden.
Sollte jedes Bild mit loading="lazy" geladen werden?
Nein. Bilder weiter unten auf einer Seite können davon profitieren. Das wichtige Bild im direkt sichtbaren Bereich und insbesondere ein LCP-Bild sollte nach den Empfehlungen von web.dev nicht durch Lazy Loading verzögert werden.
Warum sind width und height bei Bildern wichtig?
Die Angaben ermöglichen dem Browser, den benötigten Platz bereits vor dem vollständigen Laden des Bildes zu reservieren. Dadurch lassen sich unerwartete Verschiebungen des Seiteninhalts reduzieren.
Gute Bildkomprimierung beginnt mit den richtigen Abmessungen und nicht erst mit dem Qualitätsregler. WebP und AVIF können Fotografien häufig effizienter speichern als ältere Rasterformate. Responsive Quellen verhindern zusätzlich, dass kleine Geräte unnötig große Dateien laden. Das wichtigste sichtbare Bild sollte früh geladen werden, während weiter unten liegende Fotos gezielt verzögert werden können.
Wer diese Schritte konsequent kombiniert, muss zwischen Ladezeit und sauberer Bildwirkung nicht pauschal wählen. Die Originaldatei bleibt erhalten, während für die Webseite genau die Varianten erzeugt werden, die Browser tatsächlich benötigen. So bleibt die visuelle Qualität kontrollierbar und unnötige Datenübertragung wird vermieden.
Quelle: Google Search Central, web.dev und MDN Web Docs.
