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 eine einzelne URL kosmetisch auf „grün“ zu bringen.

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, web.dev zur CLS-Optimierung, 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 Bildgrößen-Fehler in PageSpeed Insights bedeuten

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

Seit Lighthouse 13 heißen diese Prüfungen anders. Laut Chrome for Developers sind die Audits unsized-images und layout-shifts in der Insight cls-culprits-insight aufgegangen, prioritize-lcp-image und lcp-lazy-loaded in lcp-discovery-insight. Wer in alten Tickets oder Agenturberichten nach dem früheren Audit-Namen sucht, findet ihn im aktuellen Bericht nicht mehr. Die Ursache ist dieselbe geblieben.

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.

#Wie Google CLS berechnet

Jede einzelne Verschiebung bekommt einen Score aus zwei Faktoren: Layout-Shift-Score = Impact Fraction × Distance Fraction. Die Impact Fraction ist der Anteil des Viewports, den das instabile Element in beiden Frames zusammen belegt. Die Distance Fraction ist die größte Strecke, um die es sich bewegt, relativ zur größeren Viewport-Dimension. Ein Element, das zusammen mit seiner neuen Position die Hälfte des Viewports bedeckt und sich um 15 % der Viewport-Höhe verschiebt, ergibt 0,5 × 0,15 = 0,075.

CLS addiert diese Werte nicht mehr über die gesamte Lebensdauer der Seite. web.dev definiert CLS als den größten Burst von Verschiebungen: Shifts, zwischen denen weniger als eine Sekunde liegt, bilden ein Session-Fenster, und ein Fenster dauert höchstens fünf Sekunden. Gewertet wird das Fenster mit der höchsten Summe. Eine lange Seite mit vielen kleinen, zeitlich getrennten Verschiebungen wird dadurch nicht automatisch rot.

Zwei Ausnahmen sind für Theme-Entwickler wichtig. Verschiebungen innerhalb von 500 ms nach einer diskreten Eingabe (Tippen, Klicken, Taste) tragen das Flag hadRecentInput und fließen nicht in CLS ein. Scrollen, Ziehen und Pinch-Zoom zählen nicht als solche Eingabe. Und Animationen über transform verschieben keine anderen Elemente, sie zählen laut web.dev nicht in CLS.

Google bewertet Felddaten (CrUX) strenger als einen einzelnen Lighthouse-Lauf im Labor. Maßgeblich ist das 75. Perzentil der Seitenaufrufe, getrennt nach Mobil und Desktop. 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.

#Wie der Browser aus width und height ein Seitenverhältnis ableitet

Die Attribute width und height sind laut MDN ganze Zahlen ohne Einheit und geben die intrinsische Größe in Pixeln an. Sie legen nicht fest, wie groß das Bild am Ende dargestellt wird. Ihr Nutzen: Der Browser berechnet daraus das Seitenverhältnis, bevor das Bild geladen ist. Aktuelle Browser setzen dafür intern einen Wert wie aspect-ratio: auto 640 / 360 (web.dev).

Das auto in diesem Wert hat eine präzise Bedeutung. MDN beschreibt es so: Bei einem ersetzten Element wie <img> gilt das angegebene Verhältnis, bis der Inhalt geladen ist, danach das natürliche Verhältnis der Datei. Passen Attribute und Datei nicht zusammen, springt das Bild nach dem Laden trotzdem. Genau das passiert, wenn ein Template die Maße des Originals in die Attribute schreibt, aber eine anders zugeschnittene Größe ausliefert.

Daraus folgen drei Regeln:

1. Alle Kandidaten in einem srcset brauchen dasselbe Seitenverhältnis, sonst stimmen die Attribute nur für einen davon.
2. Bei Art Direction mit <picture> und unterschiedlichen Zuschnitten bekommt jedes <source> eigene width/height. Laut web.dev unterstützen Chrome, Firefox und Safari das inzwischen.
3. Lazy geladene Bilder brauchen die Attribute besonders dringend. MDN weist darauf hin, dass ein noch nicht geladenes Bild ohne Maße 0 × 0 Pixel groß ist und dadurch unter Umständen nie in den sichtbaren Bereich gerät, der das Laden auslösen würde.

Eine verbreitete, aber wirkungslose Regel ist aspect-ratio: attr(width) / attr(height). Ohne Typangabe liefert attr() laut MDN einen CSS-String, und ein String ist kein gültiges Verhältnis. Die Zeile wird verworfen. Der Browser erledigt die Ableitung ohnehin selbst, die Regel kann weg.

#Wie behebt man Bild-CLS im HTML-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' );

wp_get_attachment_image() schreibt width, height und, sofern Unterformate existieren, srcset/sizes. Die Klasse attachment-large size-large und loading setzt WordPress selbst; ein eigenes 'loading' => 'lazy' ist nicht nötig, weil Core seit 6.3 entscheidet, welche Bilder lazy laden dürfen. 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 für Container und Zuschnitte

Für Content-Bilder mit korrekten Attributen reicht eine responsive Grundregel. Ein fixes Verhältnis auf allen Content-Bildern würde Hochformate und Panoramen auf 4:3 zwingen und verzerren:

.entry-content img {
  max-width: 100%;
  height: auto;
}

.hero-media img {
  aspect-ratio: 16 / 9;
  width: 100%;
  height: auto;
  object-fit: cover;
}

Ein festes aspect-ratio gehört auf Komponenten mit bewusstem Zuschnitt: Hero, Kartenraster, Produktkacheln, Video-Einbettungen und Container mit Hintergrundbild. Kombiniere es mit sinnvollen sizes, sonst lädt der Browser zu große Varianten und LCP leidet parallel zum CLS.

Vor aspect-ratio reservierten Themes Platz mit dem Padding-Bottom-Trick: ein Wrapper mit height: 0 und padding-bottom: 56.25% (9 geteilt durch 16), darin ein absolut positioniertes Bild. Das funktioniert weiterhin, braucht aber zusätzliches Markup. Wenn du alte Themes übernimmst, lohnt der Umbau auf aspect-ratio beim nächsten Template-Refactoring, nicht als eigenes Projekt.

#3. Lazy Loading richtig einsetzen

Lazy Loading gehört unter den Fold. Das LCP-Element (oft das Hero-Bild) darf nicht loading="lazy" tragen. Sonst verzögert der Browser den Download, bis das Layout steht.

Im Template ist der direkteste Weg, das Hero-Bild ausdrücklich als wichtig zu markieren:

echo wp_get_attachment_image(
	$hero_id,
	'full',
	false,
	array(
		'class'         => 'hero-media__img',
		'fetchpriority' => 'high',
	)
);

Mit fetchpriority="high" behandelt wp_get_loading_optimization_attributes() das Bild als sichtbar und lässt loading="lazy" weg. Der früher verbreitete Weg über den Filter wp_get_attachment_image_attributes, der nachträglich loading auf eager umstellt, hat seit WordPress 6.7 einen Haken: Core hat zu diesem Zeitpunkt bei lazy Bildern bereits auto an den Anfang von sizes gesetzt. Laut Dev Note zu 6.7 verwerfen Browser sizes="auto, ..." an einem nicht lazy geladenen Bild und fallen auf 100vw zurück. Das Hero-Bild wird dann in der größten Variante geladen. Wer den Filter behalten muss, entfernt das Präfix mit:

add_filter( 'wp_get_attachment_image_attributes', function ( $attr ) {
	if ( ! empty( $attr['class'] ) && false !== strpos( $attr['class'], 'skip-lazy' ) ) {
		$attr['loading']       = 'eager';
		$attr['fetchpriority'] = 'high';
		if ( isset( $attr['sizes'] ) ) {
			$attr['sizes'] = preg_replace( '/^\s*auto\s*,\s*/i', '', $attr['sizes'] );
		}
	}
	return $attr;
} );

fetchpriority ist laut MDN nur ein Hinweis an den Browser, mit den Werten high, low und auto. Setze high auf genau ein Bild pro Seite, sonst konkurrieren mehrere Downloads um dieselbe Priorität.

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.

#Was WordPress seit 5.5, 6.3 und 6.7 automatisch erledigt

Viele Tutorials empfehlen Code für Dinge, die Core längst übernimmt. Der Stand nach den offiziellen Dev Notes:

Die Ergänzung der Maße läuft in wp_filter_content_tags(), das in default-filters.php mit Priorität 12 an the_content hängt, also nach den Shortcodes. Lazy Loading lässt die ersten drei Content-Bilder aus; den Wert steuert der Filter wp_omit_loading_attr_threshold. Für fetchpriority="high" muss ein Bild laut 6.3-Dev-Note mindestens 50.000 Pixel Fläche haben, einstellbar über wp_min_priority_img_pixels. Ein kleines Logo bekommt die Priorität deshalb nicht.

Praktische Folge: Bilder, die über den Block-Editor mit Mediathek-Bezug eingefügt wurden, sind in aktuellen Versionen selten das Problem. Die Fehler sitzen in Theme-Templates, Builder-Ausgaben, hart codiertem HTML und Bildern ohne wp-image-{ID}-Klasse.

#Welche Bildgrößen WordPress beim Upload erzeugt

Laut WordPress-Quellcode legt eine frische Installation diese Größen an: thumbnail 150 px, medium 300 px, medium_large 768 px und large 1024 px (jeweils Breite, über Einstellungen änderbar). Seit 5.3 kommen 1536x1536 und 2048x2048 dazu. Ebenfalls seit 5.3 skaliert WordPress Originale, deren längste Seite 2560 px überschreitet, auf diese Grenze herunter und speichert sie mit dem Suffix -scaled; der Filter big_image_size_threshold ändert oder deaktiviert den Wert.

Für srcset nimmt wp_calculate_image_srcset() nur Varianten mit demselben Seitenverhältnis auf und schneidet standardmäßig bei 2048 px Breite ab (Filter max_srcset_image_width). Theme-eigene Größen per add_image_size() mit hartem Zuschnitt (crop = true) haben ein anderes Verhältnis als das Original und landen deshalb nicht im srcset des Originals. Ein Kartenraster mit 4:3-Zuschnitt braucht also mehrere eigene Größen im selben 4:3-Verhältnis, sonst gibt es nur eine einzige Datei für alle Bildschirme.

#Wie setzt man responsive Bilder und srcset in WordPress ein

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.

Wie der Browser auswählt: Bei w-Deskriptoren im srcset ignoriert er src und nutzt sizes, um die erwartete Anzeigebreite zu bestimmen. Fehlt sizes, gilt laut MDN 100vw. WordPress setzt deshalb seit 4.4 einen Standardwert, der dem Muster (max-width: {Breite}px) 100vw, {Breite}px folgt; Themes sollen ihn über den Filter wp_calculate_image_sizes an das echte Layout anpassen. Seit 6.7 stellt Core lazy geladenen Bildern auto voran, damit der Browser die tatsächlich gerenderte Breite nimmt.

Checkliste für Redaktion und Dev:

1. Medienbibliothek: Original nicht unnötig 6000 px breit hochladen
2. Theme registriert sinnvolle add_image_size-Varianten im selben Seitenverhältnis
3. Templates rufen nie nur wp_get_attachment_url() für sichtbare Content-Bilder auf
4. Nach Theme-Wechsel Unterformate neu erzeugen (z. B. wp media regenerate), sonst fehlen 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 der Desktop-Browser oft die 2048-Pixel-Variante für eine 720-Pixel-Spalte. 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.

#Bild kleiner als empfohlen: Anforderungen für Discover und Artikel-Markup

Die Search-Console-Meldung „Bild kleiner als empfohlen“ hat mit CLS nichts zu tun. Sie betrifft das Bild, das Google für Vorschauen nutzt, also Beitragsbild, og:image und das image-Feld im strukturierten Artikel-Markup. Diese Meldung stammt ursprünglich aus der AMP-Ära; die heutigen Anforderungen stehen in zwei Google-Dokumenten.

Für Google Discover sollen große Bilder mindestens 1200 px breit sein, mehr als 300.000 Pixel Fläche haben und ein Verhältnis von 16:9 haben. Große Vorschauen erscheinen nur, wenn die Seite max-image-preview:large erlaubt oder AMP nutzt. Das Website-Logo als og:image oder im Schema-Markup soll Google nicht als Vorschaubild erhalten.

Die Dokumentation zum Artikel-Markup empfiehlt mehrere hochauflösende Bilder mit mindestens 50.000 Pixeln (Breite mal Höhe) in den Verhältnissen 16:9, 4:3 und 1:1. Die Bild-URLs müssen crawlbar und indexierbar sein.

Ein Prüfskript für die Redaktion, das bei der Veröffentlichung zu schmale Beitragsbilder ins Log schreibt:

add_action( 'publish_post', function ( int $post_id ) {
	$thumbnail_id = get_post_thumbnail_id( $post_id );
	if ( ! $thumbnail_id ) {
		return;
	}
	$meta  = wp_get_attachment_metadata( $thumbnail_id );
	$width = (int) ( $meta['width'] ?? 0 );
	if ( $width < 1200 ) {
		error_log( sprintf( 'Beitrag %d: Beitragsbild nur %d px breit.', $post_id, $width ) );
	}
} );

wp_get_attachment_metadata() liefert bei skalierten Uploads die Maße der -scaled-Datei, also höchstens 2560 px. Für Discover reicht das.

#Wie vermeidet man CLS in 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. Verschiebungen innerhalb von 500 ms nach dem Klick zählen zwar nicht in CLS, ein Nachladen danach schon, und der Button wandert so oder so unter dem Finger weg.

#Wie verursachen Webfonts, Banner und Third-Party-Skripte CLS

Nicht jeder CLS ist ein Bildproblem. Cookie-Banner, die nach Consent von 0 auf 120 px springen, Fonts ohne passende font-display-Strategie 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. web.dev rät außerdem, reservierten Platz nicht kollabieren zu lassen, wenn keine Anzeige ausgeliefert wird, sondern einen Platzhalter zu zeigen.

Chrome: DevTools, dann Rendering, dann 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 nutzt die Schrift laut web.dev nur, wenn sie beim ersten Layout schon da ist)
• Eingebettete Videos und iframes ohne Aspect-Ratio-Box
• „Sticky“ Header, die nach Scrollhöhe wachsen
• Live-Chat-Bubbles, die erst nach Idle erscheinen
• Animationen über top, left oder height statt über transform

#Wie repariert man alte Beiträge programmatisch

Für Bilder mit der Klasse wp-image-{ID} ist kein eigener Code nötig: Seit 5.5 ergänzt wp_filter_content_tags() fehlende width/height selbst, und zwar mit den Maßen der tatsächlich eingebundenen Größe. Ein Filter, der stattdessen die Maße von full einsetzt, schreibt bei einem eingebundenen 300-px-Thumbnail falsche Attribute.

Eigener Code lohnt nur für Tags ohne diese Klasse, etwa aus importierten Inhalten oder altem Builder-HTML. Der folgende Filter läuft nach Core, sucht die Attachment-ID über die URL und nimmt die Maße der passenden Größe:

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

	return preg_replace_callback(
		'/<img\b[^>]*>/i',
		function ( $matches ) {
			$img = $matches[0];
			if ( preg_match( '/\swidth=/i', $img ) || ! preg_match( '/\ssrc="([^"]+)"/i', $img, $src ) ) {
				return $img;
			}
			// attachment_url_to_postid() kennt nur die Original-URL, daher Größen-Suffix entfernen.
			$original = preg_replace( '/-\d+x\d+(?=\.\w+$)/', '', strtok( $src[1], '?' ) );
			$id       = attachment_url_to_postid( $original );
			if ( ! $id ) {
				return $img;
			}
			$size = wp_image_src_get_dimensions( $src[1], wp_get_attachment_metadata( $id ), $id );
			if ( ! $size ) {
				return $img;
			}
			return str_replace( '<img', sprintf( '<img width="%d" height="%d"', $size[0], $size[1] ), $img );
		},
		$content
	);
}, 13 );

Das ist ein Sicherheitsnetz, kein Ersatz für saubere Templates. attachment_url_to_postid() stellt pro Bild eine Datenbankabfrage; bei großen Archiven lohnt ein einmaliger WP-CLI-Lauf, der die Attribute in post_content schreibt, statt bei jedem Aufruf zu filtern. Bilder von fremden Domains bleiben unangetastet: Sie zur Laufzeit per getimagesize() abzufragen, lädt bei jedem Cache-Miss die Datei vom fremden Server.

#Wie misst und prüft man CLS nach den Fixes

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

1. Core Web Vitals in der Search Console öffnen und betroffene URL-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, weil CrUX ein rollierendes 28-Tage-Fenster auswertet
5. Regression: neuer Hero-Block oder Cookie-CMP braucht denselben Check

Für eigene Felddaten eignet sich Googles Bibliothek web-vitals. Sie meldet CLS nach derselben Session-Fenster-Logik wie CrUX:

import { onCLS } from 'web-vitals';

onCLS( ( metric ) => {
	navigator.sendBeacon( '/vitals', JSON.stringify( {
		name: metric.name,
		value: metric.value,
		id: metric.id,
	} ) );
} );

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 Bildgrößen-Fehler und CLS in WordPress

• Alle sichtbaren Content-Bilder kommen über Attachment-APIs
• Hero ohne loading="lazy", mit fetchpriority="high" auf genau einem Bild
• Kein sizes="auto, ..." an Bildern, die nicht lazy laden
• Theme-add_image_size deckt Grid, Single und OG ab, jeweils im selben Verhältnis
• Beitragsbilder mindestens 1200 px breit, max-image-preview:large gesetzt
• 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

#Typische Bild-CLS-Fehler in deutschsprachigen WordPress-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

#Häufige Fragen zu Bildgrößen und CLS in WordPress

#Was verursacht CLS durch Bilder in WordPress

Meist fehlen feste Bildmaße, responsive Varianten oder reservierter Platz im Template. Dadurch springt das Layout, sobald Bilder nachgeladen werden.

#Wie behebt man Bildgrößen-Fehler sauber

Templates, Bildgrößen, srcset-Ausgaben und CSS-Regeln gemeinsam prüfen. Danach CLS erneut in echten Seitentypen messen, nicht nur auf einer einzelnen URL.

#Wie oft sollte man CLS prüfen

Nach Theme-Änderungen, neuen Komponenten, größeren Medien-Uploads und Core-Web-Vitals-Warnungen in der Search Console.

#Brechen width und height das responsive Layout

Nein. Die HTML-Attribute liefern das Seitenverhältnis. Mit CSS max-width: 100% und height: auto skaliert das Bild, der reservierte Platz bleibt erhalten.

#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.