Bildgrößen-Fehler & CLS in WordPress beheben

Bildgrößen-Fehler und Cumulative Layout Shift (CLS) gehören zu den häufigsten Warnungen, die Webmaster in der Google Search Console und in PageSpeed Insights sehen. Dieser Leitfaden zeigt, wie du die Ursachen in WordPress findest, Templates und Medienpipeline korrigierst und CLS reproduzierbar misst statt einmalig „grün“ zu schummeln.

CLS misst visuelle Stabilität: Springt etwas im Viewport, während die Seite lädt, steigt der Score. Fehlende width/height an <img>, spät ladende Hero-Bilder, Cookie-Banner und Werbe-Slots ohne reservierte Höhe sind die üblichen Verdächtigen. Offizielle Vertiefung: web.dev zu CLS, MDN aspect-ratio und wp_get_attachment_image().

In deutschen Shops und Magazin-Themes trifft man denselben Musterfehler immer wieder: Das Custom-Theme schreibt Bilder per hartem Markup, die Redaktion lädt 5000-Pixel-Originals, und ein Optimierungs-Plugin komprimiert Dateien, ohne jemals Maße in den HTML-Baum zu schreiben. PageSpeed wird dann „grün“ auf einer Demo-URL und bleibt in CrUX rot, weil Kategorie- und Produkttemplates andere Bildpfade nutzen.

#Was sind Bildgrößen-Fehler?

PageSpeed meldet „Image elements do not have explicit width and height“, wenn das HTML keine Maße mitgibt. Der Browser kennt das Seitenverhältnis erst nach dem Download und schiebt Text und Buttons nach unten. Auf Produktseiten mit vielen Thumbnails summiert sich das zu einem roten CLS.

In WordPress entstehen die Fehler oft so:

• Custom-Templates nutzen hart codiertes <img src="..."> ohne Attribute
• Page-Builder speichern Bild-HTML ohne Maße in Post Meta
• SVG-Icons ohne ViewBox und ohne CSS-Größe
• Background-Images in CSS können kein width/height im Markup setzen (Platz muss per Container reserviert werden)
• Galerie-Shortcodes aus älteren Plugins rendern <img> ohne Attachment-API
• CDN-URLs, die nur die Datei spiegeln und Meta aus der Mediathek verlieren

Ein weiterer Sonderfall: externe Bilder (Hotlinking auf Hersteller-PDFs oder Social-CDN). WordPress kennt deren Maße nicht. Entweder lokal hosten und als Attachment behandeln, oder den umgebenden Container mit fester Aspect-Ratio und min-height absichern.

#Was ist CLS?

CLS summiert Layout-Verschiebungen über die Lebensdauer der Seite (mit Session-Fenstern in neueren Definitionen). Google bewertet Felddaten (CrUX) strenger als einen einzelnen Lighthouse-Lauf im Labor. Deshalb: nach Fixes echte Seitentypen messen (Startseite, Beitrag, Kategorie, Produkt, Warenkorb), nicht nur die URL, die zufällig grün wurde.

Wichtig: Labor-CLS und Feld-CLS können auseinanderlaufen. Im Labor fehlen oft Consent-Banner, A/B-Tests und langsame Third-Party-Skripte. Wenn Search Console „schlecht“ meldet und Lighthouse „gut“, glaube den Felddaten und öffne Layout Shift Regions auf einem echten Mobilgerät oder einer realistischen Emulation.

#Lösungen im Markup

#1. width und height setzen

<img src="bild.jpg" width="800" height="600" alt="Beschreibung">

In WordPress bevorzugt die Core-Funktion nutzen, die Maße aus der Attachment-Meta zieht:

echo wp_get_attachment_image(
	$attachment_id,
	'large',
	false,
	array(
		'class'   => 'wp-image-' . (int) $attachment_id,
		'loading' => 'lazy',
	)
);

wp_get_attachment_image() schreibt width, height und meist auch srcset/sizes. Harte <img>-Tags in Legacy-Themes sind der häufigste Grund, warum nur neue Beiträge „sauber“ sind und der Altbestand CLS produziert.

Wenn du ACF Image Fields nutzt: speichere die Attachment-ID, nicht nur die URL. Aus der ID baust du wp_get_attachment_image(). Aus einer nackten URL bleibt dir nur Raten oder ein Extra-Request gegen die Attachment-Tabelle.

#2. CSS aspect-ratio

.entry-content img {
  aspect-ratio: 4 / 3;
  width: 100%;
  height: auto;
}

Aspect-Ratio reserviert Platz, auch wenn das Bild noch lädt. Kombiniere es mit sinnvollen sizes, sonst lädt der Browser zu große Varianten und LCP leidet parallel zum CLS. Für Hero-Blöcke oft besser eine spezifische Klasse (hero-media { aspect-ratio: 16 / 9; }) statt einer globalen Regel, die Logos und Icons verzerrt.

#3. Lazy Loading richtig einsetzen

Lazy Loading gehört unter dem Fold. Das LCP-Element (oft das Hero-Bild) darf nicht loading="lazy" tragen. Sonst verzögert WordPress die Entdeckung des kritischen Bildes.

add_filter( 'wp_get_attachment_image_attributes', function ( $attr, $attachment, $size ) {
	if ( ! empty( $attr['class'] ) && false !== strpos( $attr['class'], 'skip-lazy' ) ) {
		$attr['loading'] = 'eager';
		$attr['fetchpriority'] = 'high';
	}
	return $attr;
}, 10, 3 );

In deutschen Shop-Themes siehst du oft, dass das erste Produktbild lazy ist, weil ein generisches Filter alle img markiert. Ausnahme für Above-the-fold spart CLS und LCP. Prüfe auch Slider: Wenn Slide 2 und 3 sofort lazy sind, aber Slide 1 ohne Maße, springt trotzdem der ganze Karussell-Rahmen.

#Responsive Bilder und srcset

Core liefert srcset, wenn du Attachment-APIs nutzt. Page-Builder und ACF-Image-Felder mit manueller URL umgehen das. Dann fehlen Maße und passende Varianten.

Checkliste für Redaktion und Dev:

1. Medienbibliothek: Original nicht unnötig 6000 px breit hochladen
2. Theme registriert sinnvolle add_image_size-Varianten
3. Templates rufen nie nur wp_get_attachment_url() für sichtbare Content-Bilder auf
4. Nach Theme-Wechsel regenerieren (z. B. regenerierte Thumbnails), sonst 404 auf srcset-Kandidaten
5. sizes-Attribut an die echte Layoutbreite anpassen (Sidebar vs. Full-Bleed)

Ein typischer deutscher Magazin-Fall: Desktop-Content ist 720 px breit, Mobile 100 vw. Wenn sizes auf 100vw steht, lädt das Handy oft die 2048-Pixel-Variante. Das ist kein CLS-Bug, aber es verlängert LCP und fühlt sich wie „schwere Seite“ an. CLS und LCP gemeinsam denken, nicht nacheinander.

#WooCommerce- und Grid-Layouts

Produktgitter sind CLS-Hotspots. Jede Kachel braucht denselben Bildrahmen. Wenn ein Produkt kein Featured Image hat und der Fallback ein schmaleres Placeholder-PNG ist, springt die Karte. Setze im Theme einen einheitlichen Wrapper mit Aspect-Ratio und object-fit: cover für Produktbilder.

Variationen und Galerien: WooCommerce wechselt Thumbnails per JS. Reserviere die Galerie-Höhe, bevor Variation-Skripte feuern. Sonst klickt jemand „Größe M“, das große Bild lädt nach, und der Add-to-Cart-Button wandert. Das ist CLS mit Umsatzwirkung, nicht nur ein Laborscore.

#Webfonts, Banner und Third-Party

Nicht jeder CLS ist ein Bildproblem. Cookie-Banner, die nach Consent von 0 auf 120 px springen, Fonts ohne font-display und späte Affiliate-Widgets erzeugen dieselben Shift-Regionen in DevTools. Reserviere Min-Höhen für Consent-Leisten und Ad-Slots, bevor Skripte laden.

Chrome: DevTools → Rendering → Layout Shift Regions. Neu laden, blaue Flächen markieren die Schuldigen. Auf Mobil emulation achten; Desktop-CLS kann „grün“ sein, während Mobile-CrUX rot bleibt.

Weitere Quellen jenseits von Bildern:

• Webfonts, die von Fallback auf Custom springen (font-display: optional oder passende Metrics)
• Eingebettete Videos ohne Aspect-Ratio-Box
• „Sticky“ Header, die nach Scrollhöhe wachsen
• Live-Chat-Bubbles, die erst nach Idle erscheinen

#Alte Beiträge programmatisch reparieren

Wenn tausende Posts HTML ohne Maße in post_content haben, hilft ein Filter, der Attachment-IDs matched und Attribute nachzieht:

add_filter( 'the_content', function ( $content ) {
	if ( false === strpos( $content, '<img' ) ) {
		return $content;
	}

	return preg_replace_callback(
		'/<img[^>]+>/i',
		function ( $matches ) {
			$img = $matches[0];
			if ( preg_match( '/\swidth=/i', $img ) && preg_match( '/\sheight=/i', $img ) ) {
				return $img;
			}
			if ( ! preg_match( '/wp-image-(\d+)/', $img, $m ) ) {
				return $img;
			}
			$meta = wp_get_attachment_image_src( (int) $m[1], 'full' );
			if ( ! $meta ) {
				return $img;
			}
			return str_replace(
				'<img',
				'<img width="' . (int) $meta[1] . '" height="' . (int) $meta[2] . '"',
				$img
			);
		},
		$content
	);
}, 12 );

Das ist ein Sicherheitsnetz, kein Ersatz für saubere Templates. Builder-HTML ohne wp-image-ID bleibt unangetastet. Für große Archive lohnt ein einmaliger WP-CLI-Lauf, der Content schreibt statt nur zur Laufzeit zu filtern - weniger CPU, klarere Diffs im Git der Export-Backups.

#Messung und Abnahme

Nach jedem Fix nicht nur Lighthouse erneut starten. Ablauf, der in Agenturprojekten hält:

1. Search Console → Core Web Vitals → betroffene URLs-Gruppen notieren
2. Pro Template-Typ eine URL mit Layout Shift Regions prüfen
3. Auf Mid-Range-Android emulieren (nicht nur Pixel-Desktop)
4. Nach Deploy 28 Tage Felddaten abwarten, bevor du „erledigt“ meldest
5. Regression: neuer Hero-Block oder Cookie-CMP braucht denselben Check

Dokumentiere die gemessenen Seitentypen. Wenn nur die Startseite grün ist und die Blog-Single rot bleibt, ist der Auftrag nicht fertig. Redaktion und Dev brauchen eine gemeinsame Definition von „done“.

#Checkliste für Teams

• Alle sichtbaren Content-Bilder kommen über Attachment-APIs
• Hero ohne loading="lazy", mit fetchpriority="high" wo sinnvoll
• Theme-add_image_size deckt Grid, Single und OG ab
• Consent-Banner und Ad-Slots haben reservierte Höhe
• CrUX/Search Console nach Deploy erneut geprüft
• Keine Background-Heroes ohne Aspect-Ratio-Container
• Product-Grid-Fallbacks haben dieselbe Kachelhöhe

#Häufige Fehler in deutschsprachigen Projekten

• Optimierungs-Plugin an, aber Theme rendert weiter harte <img>-Tags
• AMP oder „Mobile Theme“-Fork mit anderem Markup als Desktop
• WebP-Konvertierung ersetzt Dateien, löscht aber keine alten srcset-Kandidaten
• Redaktion fügt Screenshots als volle Browserfenster ein (3000×2000) ohne Zuschnitt
• Page-Builder speichert absolute Pixelbreiten, die auf Mobile brechen und dann per JS nachkorrigiert werden

#Fazit

Bildgrößen-Fehler sind selten ein einzelnes Plugin-Problem. Sie entstehen dort, wo Templates die Attachment-API umgehen, wo Hero und Lazy Loading kollidieren und wo Felddaten ignoriert werden. Wer Maße, Aspect-Ratio und reproduzierbare Messungen festzieht, bekommt stabilere Layouts und weniger Search-Console-Lärm - ohne PageSpeed-Kosmetik auf einer Demo-URL.

Mehr Kontext zur Performance-Arbeit: WordPress-Geschwindigkeitsoptimierung.