Praxisleitfaden zu Bilddateigrößen und -formaten fürs Web

Jedes Bild konkurriert um Netzwerk-, Decodier-, Speicher- und Rendering-Ressourcen. Ein nützliches Budget ist seitenspezifisch und berücksichtigt Rolle, Zielgruppe, Cache, Viewport und Qualitätsanforderung. Die folgenden Bereiche sind Ausgangspunkte für Tests, keine universellen Bestehensgrenzen.

Ausgangsbudgets nach Einsatzzweck

Diese Bereiche veranschaulichen ein zurückhaltendes Budget für die Webauslieferung. Deine JPEG-, WebP- oder AVIF-Ergebnisse können darüber oder darunter liegen; passe sie an Quelle, Encoder, gerenderte Größe, Feldleistung und Sichtprüfung an.

Aus Ausgangsbereichen ein eigenes Budget ableiten

Der HTTP-Archive-Bericht zum Seitengewicht liefert aktuelle Verteilungsdaten, doch ein globaler Median ist nicht deine Zielgruppe. Googles veröffentlichter „guter“ LCP-Schwellenwert beträgt 2,5 Sekunden beim 75. Perzentil der Besuche. Teile mit Felddaten und einem Wasserfalldiagramm die verfügbare Zeit auf Serverantwort, Ressourcenerkennung, Transfer, Decodierung und Rendering-Verzögerung auf.

Beginne mit einem Transferbudget für die gesamte Seite und weise Bildern mit dem größten Nutzerwert mehr davon zu. Prüfe die Tabellenbereiche neu, wenn sich Layout, Bildanzahl, Zielgruppe oder Qualitätsanforderung ändern.

Das Format ist eine wichtige Variable

Dieselbe Quelle kann je nach Encoder und Qualitätsziel sehr unterschiedliche Größen erzeugen. Diese Tabelle zeigt Vergleichsverhalten, keine universellen Benchmark-Ergebnisse für ein Foto mit 1200 Pixeln:

WebP oder AVIF können eine JPEG-Ausgabe in manchen Vergleichen schlagen, aber kein fester Prozentsatz gilt für alle Quellen und Encoder. Beide modernen Formate unterstützen Transparenz. Einzelheiten bietet unser WebP-AVIF-Leitfaden.

Erzeuge Kandidaten mit JPG zu WebP, In AVIF konvertieren für die dort aufgeführten Eingabeformate oder der Stapelkonvertierung für die in diesem Werkzeug gezeigten Formate.

Pixelabmessungen: Der versteckte Multiplikator

Pixelanzahl, Bildinhalt, Bittiefe, Metadaten, Format, Encoder und Einstellungen beeinflussen die Größe. Das Entfernen unnötiger Abmessungen gibt dem Encoder oft deutlich weniger Daten zum Darstellen.

Ein Bild mit 4000 × 3000 hat 12 Millionen Pixel; 1200 × 900 hat 1,08 Millionen und damit 91% weniger Pixel. Bei gleicher Kanalzahl und Präzision reduziert das die unkomprimierten Rasterdaten für den Encoder erheblich, obwohl die endgültige Byte-Einsparung weiterhin von Inhalt und Einstellungen abhängt.

Faustregel für responsive Bilder: Biete Kandidaten nahe den möglichen gerenderten Breiten und Dichten an. Ist eine Inhaltsfläche 720 CSS-Pixel breit, kann ein 1440-Pixel-Kandidat für ein 2×-Display passen; Zoom, Zuschnitt, Layoutänderungen und höhere Dichten können die Wahl aber verändern. Beschreibe die Optionen mit srcset und sizes.

Erstelle mit Vizuas Werkzeug Bildgröße ändern einen Kandidaten in den vom Layout benötigten Abmessungen. Teste danach den passenden JPEG- oder PNG-Kompressor; eine bereits optimierte Quelle wird möglicherweise nicht kleiner.

Komprimierungsqualität: Den optimalen Bereich finden

Wenn Ihr Bild die richtige Größe und das richtige Format hat, ist die Komprimierungsqualität der letzte Stellhebel. Ein praktisches Beispiel zeigt, wie alle drei zusammenwirken:

Beispielablauf: Beginne mit einer Masterdatei von 4000 × 3000 und halte sie aus dem Auslieferungssatz heraus.

1. Skaliere auf einen Kandidaten wie 1200 × 900, wenn das zur Fläche und Zieldichte passt
2. Exportiere einen WebP-Kandidaten mit einer gewählten Ausgangsqualität und prüfe die tatsächliche Datei
3. Exportiere einen AVIF-Kandidaten, wenn dein Stack ihn unterstützt, und vergleiche Größe, Aussehen und Codieraufwand

Wähle den kleinsten Kandidaten, der den Einsatzzweck erfüllt. Endgültige Einsparung und sichtbarer Unterschied ergeben sich aus deinen tatsächlichen Quellen und Ausgaben, nicht allein aus den Beispielabmessungen.

Detaillierte Qualitätsempfehlungen je Format finden Sie in unserem Leitfaden: Bilder komprimieren ohne Qualitätsverlust.

Sonderfälle

E-Commerce-Produktseiten

Produktfotos müssen beim vom Shop unterstützten Zoom nutzbar bleiben. Erzeuge responsive Kandidaten aus einer geschützten Masterdatei, prüfe feine Details und lege getrennte Budgets für Raster, Hauptansicht und Zoom fest. Upload-Anforderungen von Marktplätzen können von der Auslieferung des Shops abweichen.

Fotografie-Portfolios

Portfolios können responsive Vorschauen ausliefern und gegebenenfalls bewusst eine hochauflösende Ansicht anbieten. Leite Abmessungen und Byte-Budgets aus Layout und erwarteten Bildschirmen ab und prüfe anschließend Textur, Verläufe und Farbprofile.

Social Sharing (Open Graph)

Open-Graph-Bildempfehlungen und akzeptierte Formate unterscheiden sich nach Plattform und können sich ändern. JPEG oder PNG mit 1200 × 630 ist ein verbreiteter plattformübergreifender Ausgangspunkt; prüfe jedoch aktuelle Zielvorgaben und Vorschau. Crawler laden diese Dateien unabhängig vom Lazy Loading der Seite.

Gesamtes Bildbudget pro Seite

Erstelle das Seitenbudget aus deinem Leistungsziel. Eine mögliche anfängliche Aufteilung zum Testen ist:

• 1 Hero-Bild: ~150 KB
• 3–4 Inhaltsbilder: ~100 KB pro Stück, zusammen ~300–400 KB
• Vorschaubilder, Avatare, Icons: ~50 KB gesamt

Dieses Beispiel ist keine Geschwindigkeitsgarantie. Galerien und Produktraster können geeignete Bilder außerhalb des sichtbaren Bereichs zurückstellen, doch Lazy-Load-Ressourcen verbrauchen beim Abruf weiterhin Daten und können das Scrollen beeinflussen. Miss Start- und Interaktionsleistung auf repräsentativen Geräten und Netzen.

Häufig gestellte Fragen