Wenn sich Ihre Website langsam anfühlt, sind Bilder der erste Ort, an dem Sie nachsehen sollten. Auf den meisten Websites machen sie mehr Gesamtgewicht der Seite aus als alle anderen Ressourcen zusammen — HTML, CSS und JavaScript eingeschlossen. Das macht sie auch zum Punkt mit dem größten Hebel, da eine Handvoll gut komprimierter Bilder Sekunden von einer Ladezeit abschneiden kann, an die ein Dutzend kleiner Code-Anpassungen nicht herankäme.

Wo Bilder tatsächlich wehtun

Googles Core Web Vitals sind die Geschwindigkeitsmetriken, die in das Suchranking einfließen. Es sind drei, und Bilder betreffen zwei davon unmittelbar:

Metrik	Schwelle „gut“	Wirken Bilder darauf?
Largest Contentful Paint (LCP)	unter 2,5 s	Unmittelbar, und meist entscheidend
Cumulative Layout Shift (CLS)	unter 0,1	Ja, aber über das Markup, nicht über das Gewicht
Interaction to Next Paint (INP)	unter 200 ms	Nur indirekt

LCP misst, wie lange das größte sichtbare Element zum Rendern braucht. Auf den meisten Seiten ist dieses Element ein Bild: ein Hero-Banner, ein Produktfoto, das Titelbild eines Beitrags. Ein schweres Bild ist die häufigste Einzelursache für ein LCP, das durchfällt.

CLS misst, wie stark das Layout während des Ladens springt. Damit hat die Dateigröße nichts zu tun: Es passiert, wenn ein Bild ohne deklarierte Abmessungen ankommt, sodass der Browser erst erfährt, wie viel Platz es braucht, nachdem alles andere schon positioniert wurde.

INP misst die Reaktion auf Eingaben, und Bilder berühren das nur am Rand: Ein sehr großes Bild kostet beim Dekodieren Zeit im Haupt-Thread, was währenddessen die Antwort auf eine Berührung verzögern kann.

Ein Detail, das viel Verwirrung erspart: Google bewertet dies am 75. Perzentil echter Nutzer über ein rollierendes 28-Tage-Fenster, über den Chrome User Experience Report. Sie bestehen erst, wenn mindestens 75 % der tatsächlichen Seitenaufrufe die Schwelle erreichen. Deshalb können ein perfekter Lighthouse-Wert und ein roter Search-Console-Bericht bestens gleichzeitig existieren — dazu weiter unten mehr.

Was ein Megabyte in Sekunden kostet

Das ist der Teil, der die Abwägung greifbar macht. Das Standard-Mobilprofil von Lighthouse drosselt auf 1,6 Mbit/s bei 150 ms Latenz — eine absichtlich unglamouröse Verbindung, etwa das langsamste Viertel von 4G. Bei diesem Tempo kommen rund 195 KB pro Sekunde an.

Nehmen Sie die JPG-Qualitätskurve, die wir in Bilder komprimieren, ohne an Qualität zu verlieren gemessen haben, und rechnen Sie die Dateigrößen in Übertragungszeit um:

Qualität	Dateigröße	Übertragungszeit bei 1,6 Mbit/s
100	1220 KB	6,25 s
95	402 KB	2,06 s
90	234 KB	1,20 s
85	151 KB	0,77 s
80	118 KB	0,60 s
70	75 KB	0,38 s

Halten Sie das nun gegen ein LCP-Budget von 2,5 Sekunden — und denken Sie daran, dass das Budget alles abdecken muss, nicht nur das Bild: DNS, Verbindungsaufbau, Serverantwort, HTML-Parsing, CSS, und erst dann den Bild-Download.

Bei Qualität 100 überschreitet allein das Bild das gesamte Budget um fast vier Sekunden. Bei 95 verbraucht es über 80 % davon. Bei 85 nimmt es weniger als ein Drittel und lässt echten Raum für alles andere. Es ist dieselbe Ein-Schritt-Ersparnis von 100 auf 95 aus dem Kompressionsartikel, nur neu formuliert als Unterschied zwischen Bestehen und Durchfallen.

Zwei Vorbehalte, damit die Zahlen ehrlich bleiben. Unser Testbild trägt viel Korn, seine absoluten Größen liegen also höher als bei einem typischen Handyfoto: Übertragbar sind die Verhältnisse, die KB sind illustrativ. Und eine echte Verbindung ist keine gleichmäßige Leitung: Das Bild kann meist erst zu laden beginnen, wenn das HTML geparst ist, was die praktische Lage etwas schlechter macht als die Tabelle, nicht besser.

Daraus ergibt sich ein Gewichtsbudget für die Seite

Drehen Sie diese Rechnung um, und es entsteht eine Zahl, mit der Sie tatsächlich planen können. Bei 195 KB pro Sekunde kauft ein LCP-Budget von 2,5 Sekunden etwa 490 KB insgesamt — und dieses Gesamtbudget deckt HTML, CSS, blockierendes JavaScript und Schriften ab, bevor ein einziges Bild-Byte ausgegeben wird.

Nehmen wir an, das Seitengerüst kostet 150 KB. Bleiben rund 340 KB für alles, was oberhalb der Falz gerendert wird. Ein Hero-Bild bei Qualität 85 (151 KB in unserer Tabelle) passt bequem. Drei nicht.

Das ist auch die Antwort auf „wie viele Bilder sind zu viele“. Eine Galerieseite mit zehn Fotos zu je 118 KB ergibt 1,18 MB — sechs Sekunden Übertragung auf dieser Verbindung, bevor irgendetwas anderes lädt. Die Lösung ist nicht, jedes einzelne härter zu komprimieren, sondern zwei zu laden und die anderen acht verzögert nachzuladen, damit nur das um das Budget konkurriert, was sichtbar ist.

Zwei Dinge verschaffen Ihnen Luft außerhalb des Budgets. Caching bedeutet, dass Wiederkehrende für Bilder, die sie schon haben, nichts zahlen — setzen Sie also lange Cache-Control-Zeiten für Dateien, deren URL sich mit dem Inhalt ändert. Und ein CDN verkürzt den Hin- und Rückweg, nicht die Nutzlast: Diese 150 ms Latenz gelten pro Anfrage und werden bei jeder einzelnen bezahlt.

Die Reihenfolge, auf die es ankommt

Drei Hebel, und sie sind nicht gleich stark. Ziehen Sie in dieser Reihenfolge:

Auf die echte Anzeigegröße skalieren. Ein 4000 Pixel breites Foto in einer 600 Pixel breiten Spalte lädt die Daten aller 4000 Pixel herunter, damit der Browser die meisten wegwerfen kann. Keine Qualitätseinstellung holt das zurück. Das ist der größte Einzelgewinn und der, der am häufigsten übersprungen wird.
Format wechseln. WebP landet bei gleicher visueller Qualität typischerweise 25 bis 35 Prozent unter einem vergleichbaren JPG, AVIF noch darunter. Beide lassen sich in jedem Browser, der noch Updates erhält, ohne Risiko anzeigen. (WebP vs JPG vs PNG vs AVIF behandelt die Abwägungen.)
Und dann die Qualität einstellen. Zu diesem Zeitpunkt optimieren Sie eine schon vernünftige Datei — genau der richtige Moment dafür.

Vier Auslieferungsfehler, die gute Kompression zunichtemachen

Sie können einwandfrei komprimieren und beim LCP trotzdem durchfallen. So geht das.

Das Hero-Bild verzögert laden. Das häufigste Eigentor dieser ganzen Liste. loading="lazy" sagt dem Browser, dieses Bild sei nicht dringend — es auf Ihr LCP-Bild anzuwenden verzögert also aktiv genau das, was gemessen wird. Verzögern Sie, was unterhalb der Falz liegt; niemals, was darüber liegt.

Abmessungen nicht angeben. Setzen Sie immer width und height (oder ein CSS-aspect-ratio). Der Browser reserviert dann den richtigen Platz, bevor die Datei ankommt, und CLS tritt gar nicht mehr auf. Kostet nichts, behebt eine ganze Metrik.

Allen Geräten dieselbe Größe ausliefern. Ein Handy bekommt dieselbe 2000-Pixel-Datei wie ein Desktop. srcset mit sizes lässt den Browser wählen:

<img
  src="hero-800.jpg"
  srcset="hero-400.jpg 400w, hero-800.jpg 800w, hero-1600.jpg 1600w"
  sizes="(max-width: 600px) 100vw, 800px"
  width="800" height="500"
  alt="…"
  fetchpriority="high"
/>

Dieses fetchpriority="high" ist das Gegenstück zum Lazy-Loading-Fehler: Es sagt dem Browser, dieses Bild zuerst zu holen, vor den anderen Bildern, die er zur gleichen Zeit entdeckt hat.

Keine modernen Formate mit Rückfallebene anbieten. <picture> erlaubt es, AVIF an alles auszuliefern, was es versteht, und sauber zurückzufallen:

<picture>
  <source srcset="foto.avif" type="image/avif" />
  <source srcset="foto.webp" type="image/webp" />
  <img src="foto.jpg" width="800" height="500" alt="…" />
</picture>

Der Browser nimmt den ersten Typ, den er kennt. Nirgends geht etwas kaputt.

Laborwerte gegen echte Nutzer

Sollte man verstehen, bevor man einem Score nachjagt. Lighthouse und PageSpeed Insights führen einen Labortest durch: ein Ladevorgang, ein simuliertes Gerät, eine gedrosselte Verbindung. Deterministisch und nützlich, um Probleme zu finden.

Der Core-Web-Vitals-Bericht der Search Console zeigt Felddaten: echte Besucher, echte Geräte, echte Netze, aggregiert am 75. Perzentil über 28 Tage. Andere Frage, andere Antwort.

Zwei praktische Folgen. Ein Laborwert verbessert sich, sobald Sie die Korrektur ausrollen; der Feldbericht braucht Wochen zum Nachziehen, weil er die alte Erfahrung weiter mit einrechnet. Und ein Labortest über die Glasfaser Ihres Laptops sagt sehr wenig über einen Besucher mit schlechter Mobilverbindung — und genau den misst das 75. Perzentil.

Nutzen Sie den Labortest, um zu finden, was falsch ist. Nutzen Sie die Felddaten, um zu entscheiden, ob es wirklich behoben ist.

Wie Sie prüfen, wo Sie stehen

Schicken Sie die Seite durch PageSpeed Insights. Es berichtet Labor- und Felddaten nebeneinander für jede öffentliche URL und benennt das konkrete Element, das es als Ihr LCP gewählt hat — meist der schnellste Weg zu der Erkenntnis, dass das Bild, das Sie für das Problem hielten, gar nicht das gemessene ist.

Den Kompressionsteil richtig machen

Der häufigste Fehler hier ist nicht, die Kompression zu überspringen, sondern zu einem Werkzeug zu greifen, das Ihre Bilder auf den Server eines anderen lädt, um die Arbeit zu erledigen. Das ist langsamer, und es hinterlässt während der Verarbeitung eine Kopie Ihrer möglicherweise noch unveröffentlichten Inhalte irgendwo außerhalb Ihrer Kontrolle.

img-compress übernimmt die Schritte 2 und 3 aus der obigen Liste: komprimieren und umwandeln zwischen JPG, PNG, WebP und AVIF, vollständig auf Ihrem eigenen Gerät, HEIC-Fotos vom iPhone eingeschlossen, wobei ein einzelnes Hero-Bild genauso mühelos fertig wird wie ein ganzer Stapel Produktfotos vor einem Launch.

Schritt 1, das Skalieren, macht es bewusst nicht: Es kodiert neu, ohne die Abmessungen zu ändern, denn die richtigen Abmessungen hängen davon ab, wohin das Bild geht. Das gehört in Ihren Bildeditor oder Ihr CMS. Und die oben genannten Auslieferungsattribute gehören in Ihre Templates — die kann kein Kompressor für Sie einfügen.

Wie Bildgröße die Geschwindigkeit Ihrer Website beeinflusst