Responsive Image Breakpoints: Praktischer WebP Leitfaden

Zuletzt aktualisiert: June 28, 2026

Responsive image breakpoints sind die Bildbreiten, die Sie generieren, damit Telefone, Tablets, Laptops und hochauflösende Bildschirme eine Datei herunterladen können, deren Größe der tatsächlichen Darstellung nahekommt. Wählen Sie zu wenige aus, und mobile Benutzer erhalten Desktop-Pixel. Wählen Sie zu viele, und Ihr Build-, Cache- und CDN füllen sich mit Varianten, die niemand braucht.

Dieser Leitfaden behandelt den praktischen Mittelweg: Messen Sie den Layout-Slot, generieren Sie eine kurze WebP-Treppe (WebP ladder), schreiben Sie srcset und sizes und verifizieren Sie dann, dass der Browser die richtige Datei vom CDN auswählt.

Kurzantwort: Welche responsive Image Breakpoints sollten Sie verwenden?

Verwenden Sie Breakpoints, die dem tatsächlichen gerenderten Bild-Slot entsprechen, und fügen Sie dann einen Puffer für Retina-Bildschirme hinzu. Für viele Artikelbilder ist eine nützliche WebP-Treppe 480w, 720w, 960w, 1200w und 1440w. Für Full-Width Hero-Bilder fügen Sie 1920w hinzu, wenn das Design diese Breite tatsächlich darstellen kann.

Kopieren Sie niemals CSS Breakpoints blindlings. Eine Seite kann einen 1280px Layout-Breakpoint haben, während sich das Bild selbst innerhalb einer 720px Artikelspalte rendert. In diesem Fall könnte ein 1440w Bild bereits eine 2x Anzeige abdecken, und eine 1920w Variante wäre verschwendet.

Die zuverlässige Methode ist einfach: Inspizieren Sie die größte CSS-Slot-Breite, multiplizieren Sie diese mit der höchsten Dichte, die Sie unterstützen möchten, runden Sie auf sinnvolle Breiten und entfernen Sie nahezu doppelte Werte. Paaren Sie diese Dateien dann mit einem wahrheitsgemäßen sizes-Attribut, damit der Browser korrekt wählen kann.

Was sind responsive Image Breakpoints?

Responsive Image Breakpoints sind generierte Dateibreiten, nicht unbedingt Design-Breakpoints. CSS Breakpoints ändern das Layout. Image Breakpoints geben dem Browser ein Menü von Dateien, wie z. B. 480w, 720w, 960w und 1440w.

MDN's responsive images guide erklärt das Kernproblem: Der Browser benötigt genügend Informationen, um vor Abschluss des Layouts ein entsprechend dimensioniertes Bild auszuwählen. Das srcset-Attribut listet Kandidaten auf, während sizes den Slot beschreibt, den das Bild einnehmen wird.

Diese Trennung ist wichtig. Wenn srcset korrekt, aber sizes falsch ist, kann der Browser immer noch eine größere Datei herunterladen als nötig. Ist sizes korrekt, aber die generierten Dateien überspringen nützliche Breiten, hat der Browser keine gute Wahl.

Für Formatwahl treffen Sie Breakpoints am besten mit einem modernen Webformat zusammen. WebP ist ein sicherer Standard für breite Unterstützung, und AVIF kann für große Fotobibliotheken lohnenswert sein. Der Format-Kompromiss wird in AVIF vs WebP Comparison behandelt.

Wie wählt man Breakpoint-Breiten?

Beginnen Sie mit dem gerenderten Slot, nicht mit der Quelldatei. Ein 4000px Produktfoto benötigt keine 4000px Web-Variante, wenn der größte sichtbare Slot 760px beträgt. Es benötigt genügend Pixel, um in diesem Slot auf den Bildschirmen, die Ihnen wichtig sind, scharf auszusehen.

Verwenden Sie diese Reihenfolge:

1. Öffnen Sie die Seite im engsten mobilen Layout, einer gängigen Tablet-Breite, der Laptop-Breite und der breiten Desktop-Breite.
2. Messen Sie den gerenderten Bildslot in CSS-Pixeln.
3. Multiplizieren Sie jeden Slot mit 1x und 2x, wenn Sie Hochdichte-Unterstützung wünschen.
4. Runden Sie auf eine kleine Treppe wie 480, 720, 960, 1200, 1440 und 1920.
5. Entfernen Sie Breiten, die weniger als etwa 15 Prozent voneinander entfernt sind.
6. Stoppen Sie bei der größten Breite, die das Design nutzen kann.

Ich habe die vier Grafiken in diesem Artikel lokal mit 1400 by 788 als WebP kodiert. Jede gemessene Datei wiegt unter 35 KB, da es sich um flache Anleitungsgrafiken handelt. Ein Kamerabild gleicher Dimensionen ist normalerweise viel größer, messen Sie daher Ihre eigene Ausgabe, bevor Sie Budgets festlegen.

Wenn ein ganzes Verzeichnis diese Breiten benötigt, verwenden Sie einen wiederholbaren Resize-Schritt. Der Batch Resize Guide behandelt das Kommandozeilenmuster zur Erzeugung abgeleiteter Bilder ohne Überschreiben der Masterdateien.

Wie sollten srcset und sizes aussehen?

Für die meisten responsiven Content-Bilder verwenden Sie Breitenbeschreibungen mit sizes. Breitenbeschreibungen teilen dem Browser die tatsächliche Pixelbreite jedes Kandidaten mit. Der sizes-Wert teilt dem Browser mit, wie breit das Bild im Layout gerendert wird.

<img
  src="https://cdn.example.com/blog/photo-960.webp"
  srcset="
    https://cdn.example.com/blog/photo-480.webp 480w,
    https://cdn.example.com/blog/photo-720.webp 720w,
    https://cdn.example.com/blog/photo-960.webp 960w,
    https://cdn.example.com/blog/photo-1440.webp 1440w"
  sizes="(min-width: 900px) 720px, 92vw"
  width="1440"
  height="810"
  alt="Produktfoto in einem responsiven Artikel-Layout dargestellt">

Das sizes-Beispiel besagt: Sobald der Viewport mindestens 900px breit ist, beträgt der Bildslot 720px; andernfalls beträgt der Slot 92 Prozent des Viewports. Ein Telefon mit 390px Breite kann eine Datei nahe 720w für einen 2x-Display wählen, anstatt eine 1440w Datei herunterzuladen.

Der web.dev Leitfaden zu responsive images zeigt dasselbe Prinzip der Browserauswahl: Geben Sie dem Browser genaue Kandidaten und Layout-Informationen, damit er wählen kann, bevor die Bildanforderung gestellt wird.

Verwenden Sie ein <picture> Element, wenn das Cropping oder Format geändert werden muss, nicht bei jeder normalen Größenänderung. Beispielsweise benötigen art-directed Hero-Bilder möglicherweise ein quadratisches mobiles Crop und ein breites Desktop-Crop. Reine Breitenänderungen sind in der Regel mit einem einzigen img und einem guten srcset einfacher.

Wie viele Image Breakpoints sind zu viele?

Mehr Varianten sind nicht automatisch besser. Jede zusätzliche Breite erhöht die Build-Zeit, den Speicherbedarf, die Cache-Einträge, die CDN-Invalidierungsfläche und die Überarbeitungsarbeit. Wenn zwei Kandidaten sehr nah beieinander liegen, kann die Einsparung von Bytes durch den Browser zu gering sein, um eine weitere Datei zu rechtfertigen.

Verwenden Sie einen kompakten Satz, es sei denn, Ihr Traffic und das Bildvolumen rechtfertigen eine feinere Abstimmung. Fünf Breiten pro Bild sind für Artikel- und Marketingseiten oft ausreichend. Produktseiten mit Zoom, Gitter und mehreren Crops benötigen möglicherweise mehr, aber sie sollten durch eine Pipeline und nicht von Hand generiert werden.

Achten Sie auf diese Anzeichen dafür, dass die Treppe zu dicht ist:

• 640w, 700w und 760w existieren alle für das gleiche Bild.
• CDN-Logs zeigen, dass einige Varianten fast nie angefordert werden.
• Die Build-Zeit wächst, weil jeder Upload zehn oder mehr Derivate erzeugt.
• Redakteure können nicht sagen, welche Datei in Frontmatter, Open Graph und Body Content gehört.
• Visual QA beginnt, Dateinamen zu überprüfen, anstatt gerenderte Seiten.

Achten Sie auf diese Anzeichen dafür, dass die Treppe zu spärlich ist:

• Telefone laden die 1440w oder 1920w Datei für gewöhnliche Body-Bilder herunter.
• Desktop Retina-Bildschirme wirken weich, weil der größte Kandidat zu klein ist.
• Der Browser wählt immer das gleiche Fallback src.
• PageSpeed oder Lighthouse melden überdimensionierte Bilder auf Mobilgeräten.

Google's image SEO best practices empfehlen crawlable Image URLs, nützlichen umgebenden Text und beschreibendes Alt text. Die responsive Bereitstellung sollte diese Grundlagen bewahren. Verstecken Sie wichtige Bilder nicht in CSS-Hintergründen, wenn sie indexiert oder als Seiteninhalt verstanden werden müssen.

Wie wirken sich Breakpoints auf Core Web Vitals aus?

Responsive Breakpoints beeinflussen die Leistung, weil Bildbytes oft das erste sichtbare Element dominieren. Wenn das Hero-Bild auch das Largest Contentful Paint Element ist, kann der falsche Breakpoint dazu führen, dass das wichtigste Paint auf einer Datei wartet, die doppelt so groß ist wie nötig.

Der web.dev Leitfaden zur optimizing Largest Contentful Paint empfiehlt, wahrscheinliche LCP-Bilder früh auffindbar zu machen und sie bei Bedarf zu priorisieren. Breakpoints ersetzen diese Arbeit nicht. Sie stellen lediglich sicher, dass die priorisierte Datei die richtige Größe hat.

Für above-the-fold Bilder:

1. Setzen Sie explizite width und height, um Platz zu reservieren.
2. Vermeiden Sie das Lazy Loading des wahrscheinlichen LCP-Bildes.
3. Verwenden Sie fetchpriority="high" nur für das Bild, das es wirklich braucht.
4. Halten Sie sizes für das anfängliche Layout präzise.
5. Verifizieren Sie das ausgewählte currentSrc in DevTools.

Für below-the-fold Bilder:

1. Laden Sie normale Galerie- und Artikelbilder lazy.
2. Verwenden Sie dieselbe Breakpoint-Treppe, es sei denn, ein kleineres Crop reicht aus.
3. Komprimieren Sie nach dem Resizing, nicht davor.
4. Halten Sie den Alt text spezifisch für das sichtbare Bild.
5. Überprüfen Sie mobile Netzwerk-Wasserfälle, nicht nur Desktop.

Wenn Ihr Problem hauptsächlich die verzögerte Entdeckung des Hero-Assets ist, lesen Sie Critical Image Extraction. Wenn die Dateien einfach zu schwer sind, führen Sie vor der Änderung des Markups den Image Compression Ratio Guide durch.

Welche CDN-Prüfungen sollten Sie vor der Veröffentlichung durchführen?

Breakpoints sind erst abgeschlossen, wenn die endgültigen URLs funktionieren. Ein sauberer Markdown-Entwurf kann immer noch fehlschlagen, wenn der CDN-Pfad falsch ist, das Objekt den falschen Inhaltstyp hat oder die Seite versehentlich auf eine lokale /blog/... Datei verweist.

Führen Sie diese Pre-Publish-Prüfung durch:

In Chrome DevTools inspizieren Sie das gerenderte Bild und überprüfen den currentSrc. Ändern Sie dann den Viewport und das Device Pixel Ratio. Die ausgewählte URL sollte durch die Treppe wandern. Wenn sie sich nie ändert, überschreibt möglicherweise das Markup oder das Framework-Image-Komponente Ihre Kandidaten.

Für einen umfassenderen Veröffentlichungsdurchlauf verwenden Sie den Complete Image Optimization Checklist. Für mobilspezifische Budgets kombinieren Sie dies mit dem Mobile Image Optimization Guide. Entscheidungen zum Lazy Loading werden separat in Lazy Load Images behandelt.

Responsive image breakpoint checklist

Verwenden Sie diese Kurzversion bei der Überprüfung eines Pull Requests:

• Das Master-Bild ist größer als die größte generierte Variante.
• Generierte Breiten stimmen mit den tatsächlichen gerenderten Slots überein.
• Die Breiten sind nicht in winzige, wenig wertvolle Inkremente gepackt.
• WebP Dateien werden nach dem Resizing komprimiert.
• srcset verwendet korrekte Breitenbeschreibungen.
• sizes stimmt mit dem Layout überein und nicht mit einem geschätzten 100vw.
• Das wahrscheinliche LCP-Bild wird nicht lazy geladen.
• Below-fold Bilder werden lazy geladen.
• Breite und Höhe sind vorhanden, um Layout Shift zu vermeiden.
• CDN URLs geben vor der Veröffentlichung HTTP 200 zurück.
• Interne Links verweisen die Leser auf Komprimierung, mobile und Lazy-Loading nächste Schritte.

Der nützliche Breakpoint-Satz ist der kleinste Satz, der Bilder scharf hält, ohne dass Telefone Desktop-Dateien herunterladen müssen. Messen Sie den Slot, generieren Sie die Treppe, veröffentlichen Sie die WebP-Dateien und bestätigen Sie, dass der Browser die erwartete Datei wählt.