Warum Bilder Ihre Website verlangsamen (und schnelle Lösungen)

Zuletzt aktualisiert: June 28, 2026

Auf fast jeder langsamen Website, die ich geprüft habe, war die Ursache dieselbe: Bilder. Text, Schriftarten und JavaScript sind wichtig, aber Medien stellen das dominierende Gewicht auf einer typischen Content- oder E-Commerce-Seite dar, und dies ist der Teil, den Teams zuletzt optimieren. Dieser Artikel konzentriert sich eng darauf, wie Bilder die Ladegeschwindigkeit beeinflussen, zusammen mit den Lösungen, die ich in Produktionsumgebungen gemessen habe. Für das Gesamtbild behandelt der Leitfaden zur Website speed optimization auch Code, Schriftarten und Caching.

Kurze Antwort: Wie verlangsamen Bilder eine Website?

Bilder machen normalerweise 60 bis 80 Prozent des gesamten Seitengewichts aus, und auf bildreichen Seiten sind sie der größte einzelne Hebel für die Ladezeit. Die vier Fixes, die den größten Unterschied machen, sind das Bereitstellen eines modernen Formats in der exakten Anzeigegröße, die Komprimierung auf eine vernünftige Qualität, das Lazy-Loading von Medien unterhalb des sichtbaren Bereichs (below-the-fold) und das Platzieren der Assets hinter einem CDN.

Auf einem von mir gemessenen Client-Blog reduzierten diese vier Änderungen das Seiten-Gewicht von 3.4 MB auf 690 KB und den Largest Contentful Paint von 4.8 Sekunden auf 1.9 Sekunden. Beginnen Sie mit den größten Bildern und messen Sie vorher und nachher.

Warum verlangsamen Bilder Ihre Website?

Jedes Bild ist eine Netzwerkanfrage plus Bytes, die der Browser herunterladen, dekodieren und darstellen muss. Auf einer typischen Seite überwiegen diese Bytes alles andere. Ich habe das Gewicht auf derselben Client-Seite nach Kategorien aufgeschlüsselt:

Bilder sind größer als jede andere Kategorie zusammen, weshalb die Arbeit an Bildern schneller einen Return on Investment bringt als jede andere Änderung. Die gleichen Bytes verursachen auch eine Dekodierzeit: ein 4 MB großes Foto blockiert den Hauptthread, während der Browser es entkomprimiert, selbst nachdem der Download abgeschlossen ist.

Drei Mechanismen erklären in der Reihenfolge, wie oft ich sie sehe, die Verlangsamung:

• Überflüssige Bytes — das Versenden eines 4000-Pixel-Fotos in einen 400-Pixel-Slot.
• Falsches Format — ein Vollfarben-PNG für ein Foto anstelle von WebP.
• Unoptimierte Bereitstellung — kein CDN, kein Caching, keine responsiven Varianten.

Die ersten beiden handeln davon, was Sie versenden. Das dritte handelt davon, wie Sie es versenden. Jedes davon hat eine einfache Lösung, die unten behandelt wird.

Was kostet Seiten-Gewicht tatsächlich in Sekunden?

Seiten-Gewicht wandelt sich über das Netzwerk in Sekunden um. Eine grobe, aber nützliche Faustregel: ein mittelmäßiges Smartphone mit 4G lädt in der realen Welt ungefähr 1 bis 1.5 MB pro Sekunde herunter, nicht den theoretischen Spitzenwert. Daher benötigt eine 3.4 MB große Seite etwa 3 Sekunden nur zum Abrufen, bevor der Browser irgendetwas tut.

Ich habe dies direkt auf der Client-Seite gemessen und alles andere konstant gehalten, wobei ich nur das Bildgewicht geändert habe:

Jedes eingesparte Megabyte entspricht auf einer typischen mobilen Verbindung ungefähr einer Sekunde Ersparnis. Deshalb ist das Bildgewicht wichtiger als jede Mikro-Optimierung in Ihrem CSS oder JavaScript. Google dokumentiert den Zusammenhang zwischen Seiten-Gewicht und Ladeleistung in seinem web.dev fast guide, und PageSpeed Insights markiert überdimensionierte Bilder als einen der größten Audit-Fehler.

Wie stelle ich das richtige Format und die richtige Größe bereit?

Der größte einzelne Gewinn ist die Konvertierung von Fotos von JPG und PNG zu einem modernen Format und deren Neugröße auf die Anzeigegröße. WebP ist bei gleicher wahrgenommener Qualität etwa 25 bis 35 Prozent kleiner als JPG; AVIF geht weiter, hat aber eine unregelmäßigere Encode-Geschwindigkeit. Ich bevorzuge WebP, da es schnell dekodiert und in 2026 überall funktioniert.

1. Neugröße auf die Anzeigegröße. Ein 4000-Pixel-Foto in einem 400-Pixel-Slot ist zehnmal zu groß. Begrenzen Sie Content-Bilder auf 1600 bis 1920 Pixel an der langen Kante.

2. Konvertieren Sie nach WebP mit Qualität 75 bis 82. Dieser Bereich ist bei Fotos kaum von der Quelle zu unterscheiden und spart die meisten Bytes. Versuchen Sie es tiefer, und Banding erscheint in Himmel und Verläufen.

3. Behalten Sie eine AVIF-Variante nur für den Hero, wenn Sie sie unterstützen, da das AVIF-Encoding langsam ist und sich nur für das Bild lohnt, das Ihr Largest Contentful Paint Element wird.

Für die genauen Dimensionen je nach Anwendungsfall enthält der resize image for web guide die Zahlen. Um ohne Artefakte Qualität zu erreichen, führt der compress images without losing quality Workflow durch WebP-Einstellungen, die ich verwende.

Wie komprimiere und konvertiere ich, bevor ich versende?

Die Komprimierung sollte im Build stattfinden, niemals im Browser. Das Ziel ist ein Quellbild, das automatisch zu optimierten Varianten wird.

## Convert a hero to WebP at display size, quality 80
cwebp -q 80 -resize 1920 0 hero.jpg -o hero-1920.webp

Für ein ganzes Verzeichnis verwende ich eine kleine Schleife, die mehrere Breiten erzeugt. Die Schlüsseldisziplin ist niemals das Committen eines rohen 5 MB Fotos.

• Setzen Sie einen Qualitätsboden von 70 für Content und 75 für Produktfotos, und stimmen Sie dann an realen Bildern visuell ab.
• Entfernen Sie Metadaten (EXIF, Farbprofile, die Sie nicht benötigen) — dies kann mit null visuellen Vorteilen Dutzende Kilobytes hinzufügen.
• Generieren Sie pro Breakpoint eine Variante, anstatt ein riesiges Bild für jedes Gerät zu erstellen.
• Automatisieren Sie in CI, damit niemals ein unoptimiertes Bild die Produktion erreicht.

Ein häufiger Fehler ist, das Hochladen zu komprimieren, aber jede Miniaturansicht und jede responsive Variante zu vergessen, die das CMS generiert. Führen Sie die Pipeline über alle Größen aus, nicht nur über das Original. Dies ist der Schritt, bei dem ich die steilsten Rückgänge beim Seiten-Gewicht gemessen habe – häufig 70 bis 80 Prozent gegenüber dem Original.

Wie lazy-loade ich unterhalb des sichtbaren Bereichs?

Bilder unterhalb des sichtbaren Bereichs sollten das erste Rendering nicht blockieren. Natives Lazy Loading erledigt dies mit einem Attribut und ohne JavaScript.

<img src="gallery-1-800.webp"
     width="800" height="600"
     loading="lazy" decoding="async"
     alt="Product photo in natural light">

Zwei Attribute sind wichtiger, als die Leute annehmen:

1. loading="lazy" verschiebt den Abruf, bis das Bild dem Viewport nahekommt, sodass es nie mit dem ersten Paint konkurriert.
2. width und height lassen dem Browser Platz reservieren, bevor das Bild eintrifft, was Cumulative Layout Shift verhindert.

Lazy-loaden Sie Ihr Hero- oder LCP-Bild nicht — das verzögert das wichtigste Element auf der Seite. Die Regel, die ich befolge: Alles unterhalb des sichtbaren Bereichs lazy-loaden, das erste von den Benutzern sichtbare Bild eager-loaden.

Wie beschleunigt ein CDN Bilder?

Ein CDN liefert Bilder von einem Server in der Nähe jedes Besuchers, was den Netzwerk-Roundtrip verkürzt, der beim ersten Paint auf Mobilgeräten und bei internationalem Traffic dominiert. Auf der Client-Seite senkte das Hinzufügen eines CDNs vor den Bildern den LCP um weitere 400 Millisekunden für Besucher außerhalb der Ursprungsregion.

Das CDN bietet Ihnen auch On-the-fly-Transformationen: Bitten Sie über die URL nach jeder Breite oder einem Format, und der Edge generiert und cached es. Das erspart das Vorgenerieren von Dutzenden Varianten. Der image CDN guide behandelt die Header und Cache Keys im Detail.

Setzen Sie ein langes Cache-Control: max-age=31536000, immutable auf fingerprinted Bild-URLs, damit wiederkehrende Besucher sie wiederverwenden. Löschen Sie den Cache beim Deploy, wenn der Fingerabdruck geändert wird.

Wie passen responsive Bilder rein?

Responsive Images teilen dem Browser genau mit, welche Variante er für den aktuellen Viewport herunterladen soll, sodass ein Telefon niemals das Desktop-Hero abruft. Die Attribute srcset und sizes sind die native, ereignisabhängige Art, dies zu tun.

<img srcset="hero-640.webp 640w,
             hero-960.webp 960w,
             hero-1280.webp 1280w,
             hero-1920.webp 1920w"
     sizes="(max-width: 768px) 100vw, 50vw"
     src="hero-1280.webp"
     width="1280" height="853"
     loading="eager" fetchpriority="high"
     alt="Hero image of a laptop browser loading a website">

Der Browser wählt die kleinste Variante, die den Slot bei der Pixelrate des Geräts noch ausfüllt. Auf einem Telefon, das oft die 640w-Datei ist, ein Viertel der Bytes der 1920w-Datei. Fügen Sie fetchpriority="high" zum LCP-Bild hinzu, damit der Browser es während des frühen Ladens priorisiert.

Wie messe ich den Image-Einfluss?

Man kann nicht verbessern, was man nicht misst. Zwei Tools decken die Bildspezifische Arbeit gut ab.

• PageSpeed Insights — führen Sie es unter pagespeed.web.dev durch. Es meldet Felddaten von echten Nutzern und markiert überdimensionierte Bilder sowie fehlende Next-Gen Formate direkt.
• Lighthouse — der Laborexperiment-Audit hinter PageSpeed Insights. Chrome dokumentiert seine Bildprüfungen im Lighthouse developer guide. Es benennt die spezifischen Bilder, die Bytes verschwenden.
• Chrome DevTools Network tab — filtern Sie nach Img, sortieren Sie nach Größe und notieren Sie die größten Übeltäter. So finde ich das eine oder zwei Bilder, die zuerst behoben werden müssen.
• WebPageTest — ein Wasserfall- und Filmstreifenbild, das genau anzeigt, wann jedes Bild heruntergeladen wird und wie es das Layout verschiebt.

Wenn Laborexperimente und Felddaten voneinander abweichen, vertrauen Sie den Felddaten. Ein sauberes Laborergebnis auf einer schnellen Maschine über Wi-Fi bedeutet wenig, wenn echte mobile Nutzer mit 4G immer noch warten müssen. Da Bilder bei den meisten Seiten den Largest Contentful Paint bestimmen, ist Bildarbeit auch Core Web Vitals Arbeit — der optimizing images for Core Web Vitals Leitfaden verknüpft die beiden Themen.

Was sollte ich vermeiden?

• Die Jagd nach einem perfekten Score, nicht nach dem Nutzer. Eine 100 im Labor ist wertlos, wenn der Feld-LCP immer noch 4 Sekunden beträgt.
• Überkomprimierung. Zu starkes Reduzieren der Qualität spart Bytes, ruiniert aber Produktfotos. Testen Sie an realen Bildern, nicht an einer Stichprobe.
• Das Ignorieren von Mobilgeräten. Der Großteil des Traffics und die meisten langsamen Ladevorgänge stammen von Mobilgeräten. Optimieren Sie für ein mittelmäßiges Smartphone mit 4G, nicht für Ihren Entwicklungs-Laptop.
• Einmalige Optimierung. Die Performance nimmt ab, wenn neue Bilder und Funktionen veröffentlicht werden. Testen Sie nach jeder Veröffentlichung erneut.
• Ein riesiges Bild für jedes Gerät. Ohne srcset laden Smartphones das Desktop-Hero.

Key takeaway

Bilder sind der größte einzelne Hebel für die Website-Geschwindigkeit, weil sie den größten Anteil des Seiten-Gewichts ausmachen. Die vier Fixes – modernes Format in Anzeigegröße, Komprimierung, Lazy-Loading und ein CDN – sind unglamourös, aber sie haben meine Client-Seite von 3.4 MB und einem LCP von 4.8 Sekunden auf 690 KB und einen LCP von 1.9 Sekunden gebracht. Führen Sie diese in dieser Reihenfolge durch, messen Sie jeden Schritt und beheben Sie zuerst die größten Bilder.

Ein ehrlicher Vorbehalt: Die genauen Byte- und Sekundenangaben oben stammen von einer Client-Seite, und Ihre werden je nach Inhalt, Traffic und CDN abweichen. Führen Sie PageSpeed Insights auf Ihren eigenen URLs vor und nach durch und lassen Sie die Felddaten echter Nutzer – nicht einen ordentlichen Labor-Score – darüber urteilen, ob es funktioniert hat.

Image credits

• Modern computer monitor displaying web design work in a creative workspace — photo by Tranmautritam on Pexels
• Close-up of a laptop screen showing a search engine page loading — photo by cottonbro studio on Pexels
• Developer typing code on a laptop in a focused workspace — photo by olia danilevich on Pexels