Bildlieferung 2025 — fetchpriority, preload, HTTP/2 Push (entfallen)

Warum jetzt Bildlieferung entscheidend ist

Bilder dominieren Transfer und Paint. Schon 200–300 ms Verzögerung bei der LCP‑Bildbeschaffung verschlechtert Absprungrate und CVs. 2025 zählt: explizite Priorisierung, sparsames Preload, präzise srcset/sizes und saubere Cache‑Strategien.

TL;DR

LCP stabilisieren mit: (1) fetchpriority am LCP‑Bild, (2) genau einem preload mit korrekten URLs, (3) präzisem srcset/sizes entsprechend dem Layout, (4) festen Dimensionen gegen CLS und (5) sauberem Cache/CDN‑Setup.

Regel 1 — LCP explizit priorisieren

• fetchpriority="high" am LCP‑Bild; bei festem Layout zusätzlich loading="eager" und decoding="async".
• Immer width/height setzen, CLS vermeiden.

Regel 2 — Ein einziges, korrektes Preload

• <link rel="preload" as="image" imagesrcset="…" imagesizes="…">.
• Kein Preload‑Spam; HTTP/2/3 multiplexed.
• Preload‑URLs identisch mit dem finalen <img>.

Beispiel

<link rel="preload" as="image" imagesrcset="/img/hero@1x.jpg 1x, /img/hero@2x.jpg 2x" imagesizes="100vw" />
<img src="/img/hero@1x.jpg" srcSet="/img/hero@1x.jpg 1x, /img/hero@2x.jpg 2x" sizes="100vw" fetchpriority="high" alt="…" />

Grundbegriffe (30 Sekunden)

• LCP: größtes sichtbares Element (oft das Hero‑Bild)
• CLS: Layoutsprünge; fehlende Dimensionen verschlechtern CLS
• Priority Hints: fetchpriority zum Steuern relativer Priorität
• Preload: <link rel="preload"> startet einen Abruf früher

Preload‑Fehlmuster (vermeiden)

• as="image" vergessen → keine Prioritätswirkung
• imagesizes inkonsistent → falsche Auflösung wird vorgeladen
• andere URL als im <img> → Doppelabruf

Korrektes Preload (responsive)

<link
	rel="preload"
	as="image"
	href="/hero-1200.avif"
	imagesrcset="/hero-800.avif 800w, /hero-1200.avif 1200w, /hero-1600.avif 1600w"
	imagesizes="(min-width: 1024px) 1200px, 92vw"
	fetchpriority="high"
/>

Regel 3 — Konsistente responsive Größen

• sizes exakt wie CSS verhalten; Übergrößen vermeiden.
• Art‑Direction bei Bedarf via <picture>.

Regel 4 — Lazy offscreen, n+1 vorladen

• loading="lazy" für nicht‑kritische Bilder.
• Mit IntersectionObserver n+1 beim Annähern vorladen.

Regel 5 — Cache/CDN

• Fingerprinted Assets: Cache-Control: public, max-age=31536000, immutable.
• Vary/Accept beachten, wenn CDN Formate aushandelt.

Seitentypen

• Start: einzigartiges LCP, Priorität hoch, Fonts in swap.
• Artikel: Titelbild priorisieren; Galerien lazy.
• Liste: Thumbnails lazy; n+1 vorladen beim Scrollen.

Regel 6 — HTTP/2/3 und Cache‑Design

• Erste Ansicht leicht, Wiederbesuche sehr schnell: Cache-Control/ETag sauber setzen
• Langzeitcache für fingerprinted Assets; CDN‑Formatverhandlung erfordert korrektes Vary

Messen & Debuggen

• Web‑Vitals LCP + Netzwerktraces.
• CDN‑Kosten und Cache‑Treffer beobachten.

Checkliste (Dauerbetrieb)

• [ ] LCP‑Bild mit fetchpriority="high"
• [ ] Max. ein Preload
• [ ] width/height gesetzt (kein CLS)
• [ ] srcset/sizes reflektiert Layout
• [ ] Cache‑Strategie (erste Ansicht leicht, Wiederbesuch schnell)
• [ ] CDN‑Derivate ≤ 3 Stufen (z. B. 800/1200/1600)
• [ ] DevTools: Priority/Größe/Cache regelmäßig prüfen

FAQ

• F: Preload oder Priority Hints – was zuerst?
  • A: Unterschiedliche Aufgaben: Preload startet früher, Priority Hints steuert relative Reihenfolge. Für das Hero hilft die Kombination.
• F: Soll ich loading="eager" nutzen?
  • A: Nur wenn das Layout fix ist; sonst droht CLS‑Risiko.
• F: Bringt HTTP/3 automatisch Vorteile?
  • A: Nur mit guter Gestaltung. Priorität, Auflösung und Cache zuerst korrekt setzen.

Weiterführend

• Responsiv: Responsive Bildgestaltung 2025 — Praxisleitfaden zu srcset/sizes
• Kompression: Ultimative Bildkompressions-Strategie 2025 – Praxisleitfaden zur Qualitätswahrung bei maximaler Performance