Bilder für die Website optimieren: die richtige Bildgröße für Fotografen – ohne dass die Seite langsam wird
Fotografen haben mit ihrer Website ein besonderes Problem: Die Bilder sind das Produkt, sie müssen scharf aussehen – und sie sind gleichzeitig das Schwerste auf der Seite. Wer sucht, wie man Bilder für die Website optimieren soll, findet selbstbewusste Zahlen: 1200 Pixel, 2000 Pixel, „unter 200 KB“. Keine davon ist überall falsch, keine überall richtig.
Dieser Beitrag zeigt, wie du die optimale Bildgröße für deine Webseite ausrechnest, welches Format du exportierst, was WordPress, Squarespace, Wix und Shopify mit deinen Uploads machen und warum das größte Bild auf deiner Startseite entscheidet, wie schnell Google deine Seite findet.
Vom Layout ausgehen, nicht von einer magischen Zahl
Die richtige Frage ist nicht „2000 oder 2500 Pixel?“, sondern: Wie breit wird das Bild angezeigt, und auf welchen Bildschirmen?
Websites messen das Layout in CSS-Pixeln. Moderne Handys und Laptops haben zwei oder drei physische Pixel pro CSS-Pixel (die Pixeldichte). Die Rechnung lautet also:
benötigte Bildbreite = angezeigte Breite in CSS-Pixeln × Pixeldichte
| Wo das Bild sitzt | Angezeigte Breite | Nötig bei 2× | Nötig bei 3× (Handys) |
|---|---|---|---|
| Hero über die volle Breite am Laptop | 1440 px | 2880 px | — |
| Inhaltsspalte / Blogbild | 800 px | 1600 px | — |
| Zweispaltige Galerie-Kachel | 600 px | 1200 px | — |
| Volle Breite am Handy | 390 px | 780 px | 1170 px |
Das heißt nicht, dass jedes Bild mit 2880 Pixeln ausgeliefert werden sollte. Websites können mehrere Größen anbieten und den Browser wählen lassen – und die meisten Baukästen erledigen genau das für dich.
Den Browser wählen lassen: Responsive Images
Der Mechanismus heißt Responsive Images. Die Seite listet mit srcset mehrere Versionen eines Bildes, beschreibt mit sizes die angezeigte Breite, und der Browser lädt die kleinste Datei, die auf dem aktuellen Bildschirm noch scharf aussieht. Der Leitfaden von MDN erklärt das ausführlich; in der Praxis sieht es so aus:
<img
src="portrait-1200.jpg"
srcset="portrait-640.jpg 640w, portrait-1200.jpg 1200w, portrait-2400.jpg 2400w"
sizes="(max-width: 800px) 100vw, 1200px"
width="1200" height="800"
alt="Porträt eines Paares im Sonnenuntergang">Ein Handy lädt dann die 640-Pixel-Datei, ein Retina-Laptop die mit 2400 Pixeln. Breite und Höhe reservieren den Platz, damit das Layout beim Laden nicht springt.
Was dein Homepage-Baukasten mit dem Upload macht
Auf den meisten Plattformen ist die hochgeladene Datei nicht die Datei, die Besucher bekommen. Das System erzeugt daraus mehrere Größen und oft moderne Formate.
| Plattform | Was passiert | Was das für deinen Export heißt |
|---|---|---|
| WordPress | erzeugt mehrere Bildgrößen und gibt srcset automatisch aus; seit 5.3 werden sehr große Uploads verkleinert (historisch auf 2560 px, Themes und Plugins können das ändern) | eine hochwertige Datei hochladen, groß genug fürs größte Layout – nicht jede Größe selbst exportieren |
| Squarespace | liefert über eine eigene Bildpipeline responsive Versionen aus | eine saubere, hochaufgelöste Datei hochladen, keine bereits von einem Web-Optimierer zusammengepresste |
| Wix | skaliert und optimiert Bilder auf den eigenen Servern | keine eigene Kompressionskaskade vor dem Upload einbauen |
| Shopify | das Bild-CDN liefert skalierte Varianten, das Theme entscheidet wie | ein großes Original hochladen und die responsive Ausgabe des Themes prüfen |
WordPress dokumentiert das in der Referenz zu Responsive Images und unterstützt seit Version 6.5 AVIF, sofern die Bildbibliothek des Servers das kann. Bei den gehosteten Plattformen lohnt ein Blick in die aktuelle Hilfe – deren interne Kompressionseinstellungen ändern sich und werden nicht verlässlich veröffentlicht.
Die praktische Konsequenz: Auf einem CMS exportierst du eine hochwertige Datei pro Bild – für volle Breite rund 2500–3000 Pixel an der langen Kante, JPEG-Qualität 80–90, sRGB – und überlässt den Rest der Plattform. „1580 Pixel bei Qualität 73“ vor dem Upload ist Scheingenauigkeit, wenn das System die Datei ohnehin neu kodiert.

Welches Format: JPEG, WebP oder AVIF?
Steuerst du das HTML selbst, liefere AVIF oder WebP mit JPEG-Fallback aus. 2026 unterstützen rund 95 % der Browser AVIF und rund 97 % WebP, und beide erzeugen bei ähnlicher Bildqualität meist kleinere Dateien. Nutzt du ein CMS, konvertiert es oft selbst. Unser Vergleich JPEG, TIFF, PNG oder WebP geht die Formate im Detail durch.
Warum das größte Bild über deine Geschwindigkeit entscheidet
Googles Core Web Vitals messen unter anderem den Largest Contentful Paint (LCP): wie lange es dauert, bis das größte sichtbare Element geladen ist. Auf der Startseite eines Fotografen ist das fast immer das Hero-Bild. Laut web.dev gilt ein LCP von 2,5 Sekunden oder weniger als gut, gemessen am 75. Perzentil der Besuche.
Drei Regeln zählen mehr als jede Kompressionseinstellung:
- Das Hero-Bild nie per Lazy Loading laden. Lazy Loading ist ideal für Bilder weiter unten; beim ersten sichtbaren Bild verzögert es den LCP.
- Das Hero-Bild früh ins HTML setzen – nicht als Hintergrundbild, das später per JavaScript oder Slider-Skript nachgeladen wird.
- Es als wichtig markieren mit
fetchpriority="high", wenn dein Theme oder Baukasten das zulässt. Das ist ein Hinweis an den Browser, keine Garantie.
Alles unterhalb des sichtbaren Bereichs darf loading="lazy" nutzen. Und gib Bildern immer Breite und Höhe mit, damit die Seite beim Laden nicht springt.
Farbprofil und Metadaten
- Farbe: in sRGB konvertieren und das sRGB-Profil eingebettet lassen. Moderne Browser können größere Farbräume darstellen, sRGB ist aber der sichere gemeinsame Nenner – siehe sRGB oder Adobe RGB.
- Metadaten: Copyright und Urheberangaben behalten, GPS entfernen. Standortdaten in einem veröffentlichten Foto können die Wohnung eines Kunden verraten. Der Lightroom-Export kann sie entfernen, und unser kostenloses Tool EXIF-Daten entfernen erledigt das für Dateien, die du woanders exportierst.
Das Export-Preset fürs Web
| Einstellung | Wert |
|---|---|
| Format | JPEG (dein CMS erzeugt WebP/AVIF) |
| Qualität | 80–90 |
| Farbraum | sRGB, Profil eingebettet |
| Größe | lange Kante ~2500–3000 px für volle Breite, ~1600–2000 px für Inhaltsbilder |
| Ausgabeschärfe | Bildschirm, Standard |
| Metadaten | Copyright und Kontakt; Standort entfernt |
Es ist eines der vier Presets aus unserem Guide die besten Lightroom-Export-Einstellungen. Wie weit sich ein bestimmtes Foto komprimieren lässt, testest du mit unserem kostenlosen Bild-Komprimierer. Das große Ganze – Google-Unternehmensprofil, Seitenstruktur, Alt-Texte – steht in SEO für Fotografen.

FAQ: Bilder für die Website optimieren
Was ist die optimale Bildgröße für eine Webseite?
Das hängt von der angezeigten Breite ab: Multipliziere sie für hochauflösende Bildschirme mit 2. Für Bilder über die volle Breite heißt das etwa 2500–3000 Pixel an der langen Kante, für Inhaltsbilder 1600–2000 Pixel. Auf einem CMS lädst du eine große Version hoch und lässt die Plattform kleinere erzeugen.
Wie viele KB sollten Bilder auf der Website haben?
Eine feste Grenze gibt es nicht. Entscheidend ist, dass das größte sichtbare Bild schnell genug für einen LCP unter 2,5 Sekunden lädt. Responsive Images, moderne Formate und kein Lazy Loading beim Hero-Bild bringen meist mehr, als jede Datei unter eine feste KB-Zahl zu pressen.
Soll ich JPEG oder WebP in WordPress hochladen?
Lade ein hochwertiges JPEG hoch, wenn dein Workflow nicht ohnehin WebP oder AVIF erzeugt. WordPress erstellt die kleineren Größen selbst und kann je nach Server moderne Formate erzeugen.
Fazit
Wer Bilder für die Website optimieren will, rechnet angezeigte Breite mal Pixeldichte – und muss auf den meisten Plattformen nur eine großzügige, hochwertige Version hochladen. Exportiere in sRGB, entferne GPS-Daten, lass dein CMS die kleineren Größen und modernen Formate erzeugen und gib dem Hero-Bild Priorität statt es verzögert zu laden. So bleibt dein Portfolio scharf und schnell.
Die Website ist dein Schaufenster; die vollaufgelösten Dateien deiner Kunden gehören in eine Galerie. Exportlab liefert sie in Originalqualität.


