Leitfaden zur mobilen Bildoptimierung für schnellere Webseiten

Zuletzt aktualisiert: June 28, 2026

Die mobile Bildoptimierung beginnt mit einer Einschränkung: Ein Telefon sollte keine Pixel herunterladen, die es nicht anzeigen kann. Verkleinern Sie die Quelle, liefern Sie responsive Varianten, halten Sie das größte Above-the-Fold-Bild aus dem Lazy Loading heraus und veröffentlichen Sie crawlable WebP oder AVIF Dateien über einen CDN.

Kurzantwort: Wie optimiere ich Bilder für Mobilgeräte?

Verwenden Sie diese Reihenfolge: zuerst verkleinern, dann kodieren, danach liefern, zuletzt messen. Ein 4000 px Produktfoto, das bei 390 px Breite angezeigt wird, ist verschwenderisch, selbst wenn es komprimiert ist. Der Browser muss es trotzdem abrufen, dekodieren und skalieren, bevor die Seite bereit erscheint.

Für die meisten mobilen Seiten sollten Sie einen WebP oder AVIF Quellsatz mit Breiten von etwa 400, 800 und 1200 px verwenden. Behalten Sie einen JPEG Fallback bei, falls Ihr Publikum ältere Browser, E-Mail-Clients oder Partner-Feeds umfasst. Für eine tiefere Formatentscheidung nutzen Sie den AVIF vs WebP comparison.

Googles LCP Leitlinien besagen, dass Seiten ein Largest Contentful Paint von 2,5 Sekunden oder weniger beim 75. Perzentil anstreben sollten, getrennt nach Mobil- und Desktop-Geräten. Bilder sind oft das LCP Element, daher verdient das Hero-Bild eine besondere Behandlung: es sollte vorgeladen (preload) oder priorisiert werden, echte Dimensionen erhalten und nicht lazy-geladen werden.

Was ändert sich tatsächlich auf einem Telefon?

Ein Telefon ändert gleichzeitig drei Dinge: die Viewport-Breite, die Netzwerkqualität und die Layout-Dichte. Desktop-Bilder funktionieren oft schlecht auf Mobilgeräten, weil die Seite dasselbe 1600 px Asset beibehält, das Motiv schlecht zuschneidet oder das Hero hinter JavaScript verzögert lädt.

Ich habe ein 1600 x 1000 Quellgrafik generiert und es als WebP q82 bei drei Breiten kodiert. Das Ergebnis zeigt, warum Verkleinern besser ist als Qualitätsanpassung:

Diese Zahlen sind illustrativ und nicht universell. Ein detailliertes Foto wird größer sein als diese saubere Grafik, und ein flaches Logo wird kleiner sein. Die nützliche Regel ist stabil: Lassen Sie den Browser aus echten Breitenkandidaten wählen, anstatt eine überdimensionierte Datei zu verwenden.

Welche mobilen Bildgrößen sollten Sie erstellen?

Beginnen Sie mit dem gerenderten Slot, nicht mit der Kameradatei. Überprüfen Sie Ihr Template bei gängigen Breakpoints und notieren Sie die maximale CSS-Breite für jede Bildart.

Verwenden Sie Breitenbeschreibungen, wenn sich die Layout-Breite ändert:

<img
  src="/images/hero-800.webp"
  srcset="/images/hero-400.webp 400w, /images/hero-800.webp 800w, /images/hero-1200.webp 1200w"
  sizes="(max-width: 640px) 100vw, 720px"
  width="800"
  height="500"
  alt="Reusable water bottle on a kitchen counter"
>

MDN's responsive images guide erklärt das srcset und sizes Auswahlmodell. Die Kurzfassung: srcset listet Kandidaten auf, und sizes teilt dem Browser mit, wie breit der gerenderte Slot sein wird, bevor das Layout abgeschlossen ist.

Für einen Stapel-Workflow generieren Sie Breiten aus derselben Masterdatei. Der batch resize guide behandelt das Kommandozeilenmuster, und der image compression deep dive erklärt, warum Verkleinern vor der endgültigen Komprimierung erfolgen sollte.

Wann sollten Sie <picture> für mobile Crops verwenden?

Verwenden Sie <picture>, wenn das mobile Bild einen anderen Zuschnitt benötigt und nicht nur eine kleinere Datei. Ein breites Desktop-Hero kann auf einem Telefon nutzlos werden, wenn sich das Motiv weit links befindet oder der Textbereich das Produkt verdeckt.

<picture>
  <source
    media="(max-width: 640px)"
    srcset="/images/shoe-mobile.webp 720w"
    sizes="100vw"
    type="image/webp"
  >
  <source
    srcset="/images/shoe-desktop.webp 1440w"
    sizes="min(100vw, 1440px)"
    type="image/webp"
  >
  <img
    src="/images/shoe-desktop.jpg"
    width="1440"
    height="700"
    alt="Trail running shoe with the sole tread visible"
  >
</picture>

Verwenden Sie Art Direction für:

1. Produkt-Hero-Bilder, bei denen das Produkt auf Mobilgeräten winzig wird.
2. Redaktionelle Banner, bei denen ein Gesicht oder Objekt zentriert bleiben muss.
3. Marktplatz-Listings, die quadratische Thumbnails und breite Detailbilder benötigen.
4. Vorher/Nachher-Bilder, bei denen beide Seiten lesbar bleiben müssen.
5. Screenshots mit kleinem Text, der einen engeren Zuschnitt benötigt.

Verwenden Sie <picture> nicht als Ersatz für normale responsive Breiten. Wenn die Komposition gleich ist, ist srcset plus sizes einfacher.

Wie passen WebP, AVIF und JPEG zur mobilen Performance?

Nutzen Sie WebP als Basis-Format für Mobilgeräte, wenn Sie ein modernes Format benötigen, das breit funktioniert. Nutzen Sie AVIF, wenn Ihre Pipeline es generieren kann und Sie einen WebP oder JPEG Fallback beibehalten können. Behalten Sie JPEG für E-Mails, alte Partnersysteme und Quellarchive bei, die andere Tools öffnen müssen.

Die complete image optimization checklist behandelt die umfassendere Veröffentlichungssequenz. Wenn Sie Tools vergleichen müssen, die WebP und AVIF ausgeben, sehen Sie sich TinyPNG alternatives an.

Verwenden Sie einen <picture> Stack, wenn Sie:

<picture>
  <source srcset="/images/card-480.avif 480w, /images/card-800.avif 800w" type="image/avif">
  <source srcset="/images/card-480.webp 480w, /images/card-800.webp 800w" type="image/webp">
  <img src="/images/card-800.jpg" width="800" height="600" alt="Blue ceramic mug beside a notebook">
</picture>

Wie sollte Lazy Loading auf Mobilgeräten funktionieren?

Laden Sie Bilder, die unterhalb des ersten Viewports beginnen, lazy. Laden Sie das LCP Bild nicht lazy. Browser-Level Lazy Loading ist nützlich, aber es ist an sich kein Performance-Plan.

Googles browser-level lazy loading guide empfiehlt das native loading="lazy" für außerhalb des Bildschirms liegende Bilder. Die gleiche Anleitung warnt davor, sofort sichtbare Bilder zu lazy-laden, da dies die Inhalte verzögern kann, auf die Benutzer warten.

Verwenden Sie diese Checkliste:

1. Geben Sie dem Hero-Bild loading="eager" oder lassen Sie das Attribut weg.
2. Fügen Sie dem wahrscheinlichsten LCP Bild fetchpriority="high" hinzu.
3. Fügen Sie Bildern nach dem ersten Bildschirm loading="lazy" hinzu.
4. Setzen Sie width und height auf jedes Bild.
5. Verwenden Sie CSS aspect-ratio, wenn sich das gerenderte Verhältnis bei einem Breakpoint ändert.
6. Vermeiden Sie JavaScript-only Image Injection für den Hero.
7. Überprüfen Sie, ob CDN-Bild-URLs lange Cache-Header enthalten.
8. Testen Sie auf einem gedrosselten mobilen Profil und nicht nur auf Desktop Wi-Fi.
9. Beobachten Sie das LCP Element in PageSpeed Insights.
10. Führen Sie nach Designänderungen erneut aus, da sich das LCP Element ändern kann.

Googles LCP documentation listet Bildelemente, Video-Poster und Hintergrundbilder unter den möglichen LCP Kandidaten auf. Deshalb kann auch ein Hintergrund-Hero das LCP beeinträchtigen, selbst wenn es kein <img> ist.

Was sollte ein Image CDN für Mobilgeräte tun?

Ein Image CDN sollte repetitive manuelle Arbeit eliminieren: Verkleinern am Edge, Format verhandeln, Varianten cachen und öffentliche URLs stabil halten. Das CDN ersetzt nicht die Quellhygiene. Das Hochladen eines unscharfen 900 px Produktfotos auf ein Image CDN erzeugt keine echte 1600 px Detailauflösung.

Achten Sie auf diese Steuerelemente:

• Width transforms für gängige mobile und Desktop Slots.
• WebP und AVIF Ausgabe mit dem korrekten Content-Type.
• Cache Keys, die Breite, Qualität und Format enthalten.
• Eine Möglichkeit, Original-Uploads getrennt von öffentlichen Derivaten zu bewahren.
• Stabile öffentliche URLs, die Google Images crawlen kann.
• Überwachung auf 404er nach Deployments und Migrationen.

Für SEO betonen Googles image SEO best practices nützliche, sichtbare Bilder in der Nähe relevanter Texte, beschreibende Dateinamen und Alt-Texte sowie crawlable Bild-URLs. Eine CDN URL ist in Ordnung, wenn sie indexierbar, stabil und von der Seite referenziert ist.

Was sollten Sie vor der Veröffentlichung testen?

Testen Sie die Seite so, wie ein mobiler Besucher sie erhält. Ein sauberer Lighthouse-Lauf ist hilfreich, kann aber CDN-Fehler, überdimensionierte responsive Kandidaten und Layout-Verschiebungen verbergen, die nur in echten Templates auftreten.

Ein praktisches Kommando für ein lokales Audit:

curl -I https://cdn.example.com/images/product-card-480.webp

Überprüfen Sie dann die gerenderte Seite bei einem schmalen Viewport. Wenn eine Tabelle oder ein Bild über den Bildschirm hinausläuft, beheben Sie das Layout, bevor Sie die Byte-Einsparungen feiern.

Mobile Image SEO und GEO Checkliste

Suchmaschinen und Antwort-Engines benötigen dasselbe wie ein Mensch: direkten Kontext. Vergraben Sie Bilder nicht in einem Karussell ohne nahegelegene Erklärung und erwarten Sie, dass das Asset allein Bedeutung trägt.

Bestätigen Sie vor der Veröffentlichung:

1. Die Seite hat eine klare Antwort oben.
2. Jedes wichtige Bild hat einen beschreibenden Alt-Text.
3. Dateinamen beschreiben das sichtbare Motiv, nicht IMG_9021.
4. Die Bild-URL ist ohne Cookies crawlable.
5. Der umliegende Absatz erklärt, warum das Bild vorhanden ist.
6. Das mobile Hero ist nicht größer als der gerenderte Slot benötigt.
7. Body Images verwenden loading="lazy" nur, wenn sie unterhalb des ersten Viewports liegen.
8. Tabellen fassen Entscheidungen zusammen, die ein Leser wiederverwenden kann.
9. Externe Behauptungen verlinken auf autoritative Quellen.
10. Interne Links zeigen zum nächsten echten Workflow und nicht zu einer zufälligen Cluster-Seite.

Für den SEO-spezifischen Pass nach der Komprimierung verwenden Sie die image SEO optimization checklist. Für einmalige Dateiarbeiten decken Image Compressor, Image Converter und Image Resizer die gängigen manuellen Schritte ab.

Image credits

• Cover, responsive width chart, art-direction crop und loading-priority chart wurden für diesen Artikel mit ImageMagick generiert und als WebP exportiert. Das responsive width chart verwendet gemessene WebP q82 Ausgabe vom selben 1600 x 1000 Quellgrafik.