Bilder sind meist das Schwerste auf einer Seite, was sie zum größten Geschwindigkeits-Hebel macht, den Sie steuern. Bringen Sie ihre Abmessungen und ihr Dateigewicht in Ordnung, und Seiten fühlen sich sofort da an. Machen Sie es falsch, scheitern Sie an den Core Web Vitals, egal wie sauber Ihr Code ist. Hier sind die Ziele und der Workflow, um sie zu erreichen.
Ziele für die Abmessungen
Passen Sie die Pixelgröße des Bildes an den Ort an, an dem es tatsächlich erscheint. Grobe Richtschnur:
- Vollbreiter Hero: 1600–2000 px breit deckt die meisten Desktop-Layouts ab. Breiter zu gehen hilft selten und kostet viele Bytes.
- Foto im Inhalt: die Breite Ihrer Inhaltsspalte, üblich 800–1200 px.
- Thumbnail / Kartenbild: 300–500 px.
- Avatar / Icon: 48–200 px in der Größe, in der es angezeigt wird.
Ein 4000-px-Bild in einen 800-px-Platz zu liefern bedeutet, dass der Browser das 25-fache der Pixel herunterlädt und dekodiert, die er je zeigen wird. Das ist reine Verschwendung – und das Dekodieren großer Bilder ruckelt zudem den Haupt-Thread.
Ziele für das Gewicht
Die Abmessungen setzen die Obergrenze; die Kompression setzt das tatsächliche Gewicht. Zielen Sie auf:
- Hero-Bild: unter 200 KB (idealerweise 100–150 KB).
- Foto im Inhalt: 80–150 KB.
- Thumbnail: 10–30 KB.
- Gesamtbilder pro Seite: versuchen Sie, für die ganze Seite unter ~1 MB zu bleiben.
Überschreitet ein einzelnes Bild ~300 KB, behandeln Sie es als Bug zum Untersuchen.
Warum das die Core Web Vitals treibt
Googles Largest Contentful Paint (LCP) misst, wie lange es dauert, bis das größte Element auf dem Bildschirm rendert – und auf den meisten Seiten ist dieses größte Element ein Bild (meist der Hero). Ein schwerer, überdimensionierter Hero bläht LCP direkt auf. Ein guter LCP liegt unter 2,5 Sekunden; ein aufgeblähter Hero kann das auf mobilen Verbindungen ganz allein sprengen.
Zwei weitere bildbezogene Gewinne:
- Setzen Sie width- und height-Attribute, damit der Browser Platz reserviert – das schützt Ihren Cumulative-Layout-Shift(CLS)-Wert.
- Priorisieren Sie den Hero (kein Lazy-Load für das LCP-Bild) und laden Sie alles unterhalb der Falz per Lazy-Load.
Der Zwei-Schritt-Workflow
Schritt 1 – auf die echte Anzeigebreite skalieren. Nutzen Sie den Bildskalierer, um jedes Bild auf die Größe zu bringen, in der es erscheint. Seitenverhältnis gesperrt, hochwertige Verkleinerung. Das allein senkt das Gewicht oft um 80–90 %.
Schritt 2 – komprimieren. Geben Sie die skalierten Dateien in den Bildkompressor: Qualität 75–85 für Fotos (visuell verlustfrei), 256-Farben-Quantisierung für PNGs. Er gibt nie eine Datei größer als das Original aus, verarbeitet Stapel und hat ein optionales Breitenlimit, sodass Sie beide Schritte praktisch auf einmal erledigen können. Für moderne Browser quetscht das Umwandeln von Fotos in WebP weitere 25–35 % heraus.
Messen, nicht raten
Sind Ihre Bilder optimiert, bestätigen Sie, dass die Seite tatsächlich schneller wurde. Die Page QA von IMG.DIY prüft eine Live-URL über Google PageSpeed Insights und meldet das Bildgewicht der Seite, damit Sie jede Datei aufspüren, die noch zu schwer ist. Ein Vorbehalt: Page QA braucht eine Internetverbindung – anders als die Bildwerkzeuge ruft sie Googles PageSpeed-API auf, sie kann also nicht offline laufen. Nutzen Sie sie nach dem Deployment, um Ihren echten LCP und Ihr Bildbudget zu prüfen.
Standardmäßig privat
Die Werkzeuge zum Skalieren, Komprimieren und Umwandeln laufen komplett in Ihrem Browser mit Canvas und WebAssembly – nichts wird hochgeladen, und nach Ihrem ersten Besuch sind sie zwischengespeichert und funktionieren offline. Sie können die Bilder einer ganzen Website ohne Verbindung vorbereiten und dann Page QA online ausführen, sobald die Seite live ist.
Kurze Zusammenfassung: Abmessungen richtig dimensionieren, auf die Gewichtsziele komprimieren, den Hero für LCP priorisieren und mit Page QA verifizieren.