Rozmiar obrazu mniejszy niż zalecany: błąd AMP w GSC

CLS mierzy stabilność wizualną: jeśli coś w obszarze widoku przeskakuje podczas ładowania strony, wynik rośnie. Brak width/height w <img>, późno ładowane obrazy hero, banery cookies i sloty reklamowe bez zarezerwowanej wysokości to zwykli podejrzani. Oficjalne źródła: web.dev o CLS, web.dev o optymalizacji CLS, MDN aspect-ratio oraz wp_get_attachment_image().

W sklepach i motywach magazynowych ten sam schemat błędu wraca bez przerwy: motyw pisany na zamówienie wstawia obrazy sztywnym kodem, redakcja wgrywa oryginały o szerokości 5000 pikseli, a wtyczka optymalizacyjna kompresuje pliki, nigdy nie dopisując wymiarów do HTML. PageSpeed robi się wtedy “zielony” na adresie demonstracyjnym, a w CrUX zostaje czerwony, bo szablony kategorii i produktów używają innych ścieżek obrazów.

#Co oznaczają błędy rozmiaru obrazów w PageSpeed Insights

Lighthouse przez lata zgłaszał, że elementy obrazu nie mają jawnie określonej szerokości i wysokości, gdy HTML nie podawał wymiarów. Przeglądarka poznaje wtedy proporcje dopiero po pobraniu pliku i spycha tekst oraz przyciski w dół. Na stronach produktów z wieloma miniaturami sumuje się to w czerwony CLS.

Od Lighthouse 13 te testy nazywają się inaczej. Według Chrome for Developers audyty unsized-images i layout-shifts weszły w skład cls-culprits-insight, a prioritize-lcp-image i lcp-lazy-loaded w skład lcp-discovery-insight. Kto szuka w aktualnym raporcie dawnej nazwy audytu ze starego zgłoszenia albo raportu agencji, już jej nie znajdzie. Przyczyna pozostała ta sama.

W WordPressie błędy biorą się najczęściej stąd:

• Szablony pisane na zamówienie używają sztywnego <img src="..."> bez atrybutów
• Page buildery zapisują HTML obrazów bez wymiarów w meta wpisu
• Ikony SVG nie mają ani viewBox, ani rozmiaru w CSS
• Obrazy tła w CSS nie mogą mieć width/height w kodzie (miejsce trzeba zarezerwować na kontenerze)
• Shortcody galerii ze starszych wtyczek renderują <img> z pominięciem API załączników
• Adresy CDN tylko kopiują plik i gubią metadane z biblioteki mediów

Osobny przypadek to obrazy zewnętrzne (hotlinkowane materiały producentów albo CDN serwisów społecznościowych). WordPress nie zna ich wymiarów. Albo hostujesz je lokalnie i traktujesz jak załączniki, albo zabezpieczasz otaczający kontener stałymi proporcjami i min-height.

#Jak Google oblicza CLS

Każde pojedyncze przesunięcie dostaje wynik z dwóch czynników: wynik przesunięcia = impact fraction × distance fraction. Impact fraction to część obszaru widoku, jaką niestabilny element zajmuje łącznie w obu klatkach. Distance fraction to największa odległość, o jaką się przesunął, w stosunku do większego wymiaru obszaru widoku. Element, który razem z nową pozycją zajmuje połowę obszaru widoku i przesuwa się o 15% jego wysokości, daje 0,5 × 0,15 = 0,075.

CLS nie sumuje już tych wartości przez cały czas życia strony. web.dev definiuje CLS jako największą serię przesunięć: przesunięcia oddzielone od siebie mniej niż sekundą tworzą okno sesji, a jedno okno trwa najwyżej pięć sekund. Liczy się okno z najwyższą sumą. Długa strona z wieloma drobnymi, rozłożonymi w czasie przesunięciami nie robi się więc automatycznie czerwona.

Dla twórców motywów ważne są dwa wyjątki. Przesunięcia w ciągu 500 ms od dyskretnej interakcji (dotknięcie, kliknięcie, klawisz) mają flagę hadRecentInput i nie wchodzą do CLS. Przewijanie, przeciąganie i powiększanie dwoma palcami nie liczą się jako taka interakcja. Do tego animacje przez transform nie przesuwają innych elementów, więc według web.dev nie wliczają się do CLS.

Google ocenia dane terenowe (CrUX) surowiej niż pojedynczy laboratoryjny przebieg Lighthouse. Decyduje 75. percentyl odsłon, osobno dla urządzeń mobilnych i komputerów. Dlatego po poprawkach mierz prawdziwe typy stron (strona główna, wpis, kategoria, produkt, koszyk), a nie tylko adres, który przypadkiem zrobił się zielony.

CLS laboratoryjny i terenowy potrafią się rozjechać. W laboratorium często brakuje banerów zgody, testów A/B i wolnych skryptów zewnętrznych. Jeśli Search Console pokazuje wynik “słaby”, a Lighthouse “dobry”, wierz danym terenowym i włącz Layout Shift Regions na prawdziwym telefonie albo w realistycznej emulacji.

#Jak przeglądarka wylicza proporcje obrazu z width i height

Według MDN atrybuty width i height to liczby całkowite bez jednostki, które podają rozmiar własny obrazu w pikselach. Nie przesądzają, w jakim rozmiarze obraz zostanie ostatecznie wyświetlony. Ich zadanie: przeglądarka wylicza z nich proporcje, zanim obraz się załaduje. Aktualne przeglądarki ustawiają w tym celu wewnętrznie wartość w rodzaju aspect-ratio: auto 640 / 360 (web.dev).

auto w tej wartości ma precyzyjne znaczenie. MDN opisuje je tak: dla elementu zastępowanego, takiego jak <img>, obowiązują podane proporcje do chwili załadowania treści, a potem naturalne proporcje pliku. Jeśli atrybuty i plik do siebie nie pasują, obraz i tak przeskoczy po załadowaniu. Dokładnie tak się dzieje, gdy szablon wpisuje do atrybutów wymiary oryginału, a serwuje inaczej przycięty rozmiar.

Wynikają z tego trzy zasady:

1. Wszyscy kandydaci w jednym srcset muszą mieć te same proporcje, inaczej atrybuty pasują tylko do jednego z nich.
2. Przy art direction w <picture> z różnymi kadrami każdy <source> dostaje własne width/height. Według web.dev Chrome, Firefox i Safari już to obsługują.
3. Obrazy ładowane leniwie potrzebują atrybutów najbardziej. MDN zwraca uwagę, że niezaładowany obraz bez wymiarów ma 0 × 0 pikseli i przez to może nigdy nie wejść w widoczny obszar, który uruchomiłby jego ładowanie.

Popularna, ale bezużyteczna reguła to aspect-ratio: attr(width) / attr(height). Bez podania typu attr() zwraca według MDN ciąg znaków CSS, a ciąg znaków nie jest poprawną proporcją. Deklaracja zostaje odrzucona. Przeglądarka i tak sama wylicza proporcje, więc tę regułę można usunąć.

#Jak naprawić CLS obrazów w kodzie HTML

#1. Ustaw width i height

<img src="photo.jpg" width="800" height="600" alt="Opis">

W WordPressie lepiej użyć funkcji z rdzenia, która pobiera wymiary z metadanych załącznika:

echo wp_get_attachment_image( $attachment_id, 'large' );

wp_get_attachment_image() zapisuje width, height oraz, jeśli istnieją rozmiary pośrednie, srcset/sizes. Klasę attachment-large size-large i loading WordPress ustawia sam; ręczne 'loading' => 'lazy' nie jest potrzebne, bo od wersji 6.3 rdzeń decyduje, które obrazy mogą ładować się leniwie. Sztywne tagi <img> w starych motywach to najczęstszy powód, dla którego tylko nowe wpisy są “czyste”, a archiwum dalej generuje CLS.

Jeśli używasz pól obrazu ACF, zapisuj ID załącznika, a nie sam adres URL. Z ID zbudujesz wp_get_attachment_image(). Z gołego adresu zostaje ci zgadywanie albo dodatkowe zapytanie do tabeli załączników.

#2. CSS aspect-ratio dla kontenerów i kadrów

Dla obrazów w treści z poprawnymi atrybutami wystarczy podstawowa responsywna reguła. Stałe proporcje na wszystkich obrazach w treści wcisnęłyby portrety i panoramy w 4:3 i je zniekształciły:

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

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

Stałe aspect-ratio pasuje do komponentów ze świadomym kadrem: hero, siatki kart, kafelki produktów, osadzone wideo i kontenery z obrazem tła. Łącz je z sensownym sizes, inaczej przeglądarka pobierze za duże warianty i obok CLS ucierpi też LCP.

Przed aspect-ratio motywy rezerwowały miejsce sztuczką z padding-bottom: kontener z height: 0 i padding-bottom: 56.25% (9 podzielone przez 16), a w nim obraz pozycjonowany absolutnie. To nadal działa, ale wymaga dodatkowego kodu. Jeśli przejmujesz stary motyw, przenieś go na aspect-ratio przy najbliższej przebudowie szablonów, a nie jako osobny projekt.

#3. Jak poprawnie używać lazy loading

Leniwe ładowanie należy poniżej linii zgięcia. Element LCP (często obraz hero) nie może mieć loading="lazy". Inaczej przeglądarka wstrzymuje pobieranie, aż układ będzie gotowy, co opóźnia LCP. Pozostałe fazy LCP opisujemy w przewodniku po Core Web Vitals.

W szablonie najprostsza droga to jawne oznaczenie obrazu hero jako ważnego:

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

Przy fetchpriority="high" funkcja wp_get_loading_optimization_attributes() traktuje obraz jako widoczny i pomija loading="lazy". Dawniej popularna droga przez filtr wp_get_attachment_image_attributes, który po fakcie przestawia loading na eager, ma od WordPressa 6.7 haczyk: rdzeń zdążył już dopisać auto na początku sizes przy obrazach leniwych. Według notatki deweloperskiej do 6.7 przeglądarki odrzucają sizes="auto, ..." na obrazie, który nie ładuje się leniwie, i wracają do 100vw. Obraz hero pobiera się wtedy w największym wariancie. Jeśli musisz zostawić filtr, usuń ten przedrostek:

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;
} );

Według MDN fetchpriority to tylko wskazówka dla przeglądarki, z wartościami high, low i auto. Ustaw high na dokładnie jednym obrazie na stronie, inaczej kilka pobrań konkuruje o ten sam priorytet.

W motywach sklepowych często widać, że pierwsze zdjęcie produktu ładuje się leniwie, bo ogólny filtr oznacza wszystkie img. Wyjątek dla obrazów nad linią zgięcia oszczędza CLS i LCP. Sprawdź też slidery: jeśli slajdy 2 i 3 ładują się leniwie, a slajd 1 nie ma wymiarów, cała ramka karuzeli i tak przeskakuje.

#Co WordPress robi automatycznie od wersji 5.5, 6.3 i 6.7

Wiele poradników zaleca kod na rzeczy, które rdzeń dawno przejął. Stan według oficjalnych notatek deweloperskich:

Uzupełnianie wymiarów odbywa się w wp_filter_content_tags(), którą default-filters.php podpina pod the_content z priorytetem 12, czyli po shortcodach. Leniwe ładowanie pomija pierwsze trzy obrazy w treści; liczbę steruje filtr wp_omit_loading_attr_threshold. Aby dostać fetchpriority="high", obraz musi według notatki do 6.3 mieć co najmniej 50 000 pikseli powierzchni, co zmienia filtr wp_min_priority_img_pixels. Małe logo nie dostaje więc tego priorytetu.

Wniosek praktyczny: obrazy wstawione przez edytor blokowy z powiązaniem z biblioteką mediów rzadko są problemem w aktualnych wersjach. Błędy siedzą w szablonach motywu, wyjściu page builderów, sztywnym HTML i obrazach bez klasy wp-image-{ID}.

#Jakie rozmiary obrazów WordPress tworzy przy wgrywaniu

Według kodu źródłowego WordPressa świeża instalacja tworzy takie rozmiary: thumbnail 150 px, medium 300 px, medium_large 768 px i large 1024 px (za każdym razem szerokość, do zmiany w ustawieniach). Od wersji 5.3 dochodzą 1536x1536 i 2048x2048. Również od 5.3 WordPress zmniejsza oryginały, których dłuższy bok przekracza 2560 px, do tej granicy i zapisuje je z przyrostkiem -scaled; filtr big_image_size_threshold zmienia tę wartość albo ją wyłącza.

Do srcset funkcja wp_calculate_image_srcset() bierze tylko warianty o tych samych proporcjach i domyślnie odcina je na szerokości 2048 px (filtr max_srcset_image_width). Własne rozmiary motywu dodane przez add_image_size() z twardym kadrowaniem (crop = true) mają inne proporcje niż oryginał, więc nie trafiają do jego srcset. Siatka kart z kadrem 4:3 potrzebuje zatem kilku własnych rozmiarów w tych samych proporcjach 4:3, inaczej dla wszystkich ekranów jest tylko jeden plik.

#Jak używać responsywnych obrazów i srcset w WordPressie

Rdzeń generuje srcset, gdy korzystasz z API załączników. Page buildery i pola obrazu ACF z ręcznie wpisanym adresem URL je omijają. Wtedy brakuje wymiarów i pasujących wariantów.

Jak przeglądarka wybiera: przy deskryptorach w w srcset ignoruje src i na podstawie sizes ustala oczekiwaną szerokość wyświetlania. Jeśli sizes nie ma, według MDN obowiązuje 100vw. Dlatego WordPress od wersji 4.4 ustawia wartość domyślną według wzoru (max-width: {szerokość}px) 100vw, {szerokość}px; motywy powinny dopasować ją do prawdziwego układu filtrem wp_calculate_image_sizes. Od 6.7 rdzeń dodaje auto na początku przy obrazach ładowanych leniwie, żeby przeglądarka użyła faktycznie wyrenderowanej szerokości.

Checklista dla redakcji i programistów:

1. Biblioteka mediów: nie wgrywaj bez powodu oryginałów o szerokości 6000 px
2. Motyw rejestruje sensowne warianty add_image_size w tych samych proporcjach
3. Szablony nigdy nie wywołują samego wp_get_attachment_url() dla widocznych obrazów w treści
4. Po zmianie motywu wygeneruj rozmiary pośrednie od nowa (np. wp media regenerate), inaczej brakuje kandydatów do srcset
5. Dopasuj atrybut sizes do prawdziwej szerokości układu (z paskiem bocznym albo na pełną szerokość)

Typowy przypadek magazynu: treść na komputerze ma 720 px szerokości, na telefonie 100 vw. Jeśli sizes ma wartość 100vw, przeglądarka na komputerze często pobiera wariant 2048 px dla kolumny 720 px. To nie jest błąd CLS, ale wydłuża LCP i strona sprawia wrażenie ciężkiej. Myśl o CLS i LCP razem, a nie po kolei.

#Rozmiar obrazu mniejszy niż zalecany: wymagania Discover i danych strukturalnych artykułu

Komunikat Search Console “rozmiar obrazu mniejszy niż zalecany” nie ma nic wspólnego z CLS. Dotyczy obrazu, którego Google używa w podglądach, czyli obrazka wyróżniającego, og:image i pola image w danych strukturalnych artykułu. Ten komunikat pochodzi z czasów AMP, kiedy dotyczył głównie stron AMP; dzisiejsze wymagania opisują dwa dokumenty Google.

Według dokumentacji Google Discover duże obrazy powinny mieć co najmniej 1200 px szerokości, ponad 300 000 pikseli powierzchni i proporcje 16:9. Duże podglądy pojawiają się tylko wtedy, gdy strona zezwala na max-image-preview:large albo używa AMP. Bez tej dyrektywy Google pokazuje małe miniatury. Nie podawaj Google logo witryny jako og:image ani jako obrazu podglądu w danych strukturalnych.

Dokumentacja danych strukturalnych artykułu zaleca kilka obrazów w wysokiej rozdzielczości, mających co najmniej 50 000 pikseli (szerokość razy wysokość), w proporcjach 16:9, 4:3 i 1:1. Adresy obrazów muszą być dostępne dla robota i możliwe do zaindeksowania.

Skrypt kontrolny dla redakcji, który przy publikacji zapisuje w logu zbyt wąskie obrazki wyróżniające:

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( 'Wpis %d: obrazek wyróżniający ma tylko %d px szerokości.', $post_id, $width ) );
	}
} );

Przy zmniejszonych plikach wp_get_attachment_metadata() zwraca wymiary pliku -scaled, czyli najwyżej 2560 px. Dla Discover to wystarczy.

#Jak uniknąć CLS w WooCommerce i układach siatki

Siatki produktów to miejsca, gdzie CLS pojawia się najczęściej. Każdy kafelek potrzebuje tej samej ramki obrazu. Jeśli produkt nie ma obrazka wyróżniającego, a zastępczy PNG jest węższy, karta przeskakuje. Ustaw w motywie jeden kontener z proporcjami i object-fit: cover dla zdjęć produktów.

Warianty i galerie: WooCommerce podmienia miniatury przez JavaScript. Zarezerwuj wysokość galerii, zanim uruchomią się skrypty wariantów. Inaczej ktoś klika “rozmiar M”, duże zdjęcie doładowuje się później i przycisk dodawania do koszyka ucieka. Przesunięcia w ciągu 500 ms od kliknięcia nie liczą się do CLS, ale doładowanie po tym czasie już tak, a przycisk i tak ucieka spod palca.

#Jak fonty, banery i skrypty zewnętrzne powodują CLS

Nie każdy CLS to problem obrazów. Banery cookies, które po zgodzie skaczą z 0 do 120 px, fonty bez dobranej strategii font-display i późne widżety afiliacyjne tworzą te same obszary przesunięć w DevTools. Zarezerwuj minimalną wysokość dla pasków zgody i slotów reklamowych, zanim załadują się skrypty. web.dev radzi też, żeby nie zwijać zarezerwowanego miejsca, gdy reklama się nie wyświetli, tylko pokazać w nim element zastępczy.

W Chrome: DevTools, potem Rendering, potem Layout Shift Regions. Przeładuj stronę, a niebieskie obszary wskażą winowajców. Pilnuj emulacji mobilnej; CLS na komputerze może być “zielony”, podczas gdy mobilny CrUX zostaje czerwony.

Inne źródła poza obrazami:

• Fonty, które przeskakują z zastępczego na własny (font-display: optional według web.dev używa fontu tylko wtedy, gdy jest dostępny przy pierwszym układzie)
• Osadzone wideo i iframe bez kontenera z proporcjami
• Przyklejone nagłówki, które rosną wraz z przewijaniem
• Dymki czatu na żywo, które pojawiają się dopiero po bezczynności
• Animacje przez top, left albo height zamiast przez transform

#Jak naprawić stare wpisy programowo

Obrazy z klasą wp-image-{ID} nie potrzebują własnego kodu: od wersji 5.5 wp_filter_content_tags() sama uzupełnia brakujące width/height, i to wymiarami faktycznie osadzonego rozmiaru. Filtr, który zamiast tego wstawia wymiary full, przy osadzonej miniaturze 300 px zapisze błędne atrybuty.

Własny kod opłaca się tylko dla tagów bez tej klasy, na przykład z importowanych treści albo starego HTML z page buildera. Poniższy filtr działa po rdzeniu, znajduje ID załącznika po adresie URL i bierze wymiary pasującego rozmiaru:

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() zna tylko adres oryginału, więc usuwamy przyrostek rozmiaru.
			$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 );

To siatka bezpieczeństwa, a nie zamiennik porządnych szablonów. attachment_url_to_postid() wykonuje jedno zapytanie do bazy na każdy obraz; przy dużych archiwach lepiej raz uruchomić WP-CLI, które zapisze atrybuty w post_content, niż filtrować przy każdym wywołaniu. Obrazy z obcych domen zostają nietknięte: odpytywanie ich w trakcie działania przez getimagesize() pobiera plik z obcego serwera przy każdym chybieniu cache.

#Jak mierzyć i sprawdzać CLS po poprawkach

Po każdej poprawce nie ograniczaj się do ponownego uruchomienia Lighthouse. Sposób, który sprawdza się w projektach agencyjnych:

1. Otwórz raport Core Web Vitals w Search Console i zanotuj grupy adresów, których dotyczy problem
2. Sprawdź po jednym adresie z każdego typu szablonu z włączonym Layout Shift Regions
3. Emuluj telefon z Androidem ze średniej półki, nie tylko komputer
4. Po wdrożeniu odczekaj 28 dni danych terenowych, zanim zgłosisz “gotowe”, bo CrUX ocenia kroczące okno 28 dni
5. Regresja: nowy blok hero albo nowa platforma zgód (CMP) wymaga tej samej kontroli

Do własnych danych terenowych nadaje się biblioteka Google web-vitals. Raportuje CLS według tej samej logiki okien sesji co CrUX:

import { onCLS } from 'web-vitals';

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

Zapisuj, które typy stron zmierzyłeś. Jeśli zielona jest tylko strona główna, a pojedynczy wpis zostaje czerwony, zlecenie nie jest skończone. Redakcja i programiści potrzebują wspólnej definicji “gotowe”.

#Checklista błędów rozmiaru obrazów i CLS w WordPressie

• Wszystkie widoczne obrazy w treści przechodzą przez API załączników
• Hero bez loading="lazy", z fetchpriority="high" na dokładnie jednym obrazie
• Brak sizes="auto, ..." na obrazach, które nie ładują się leniwie
• add_image_size w motywie pokrywa siatkę, pojedynczy wpis i OG, za każdym razem w tych samych proporcjach
• Obrazki wyróżniające mają co najmniej 1200 px szerokości, max-image-preview:large ustawione
• Banery zgody i sloty reklamowe mają zarezerwowaną wysokość
• CrUX i Search Console sprawdzone ponownie po wdrożeniu
• Żadnych hero z obrazem tła bez kontenera z proporcjami
• Obrazy zastępcze w siatce produktów mają tę samą wysokość kafelka

#Typowe błędy CLS obrazów w projektach WordPress

• Wtyczka optymalizacyjna włączona, ale motyw dalej renderuje sztywne tagi <img>
• Osobna wersja AMP albo “motyw mobilny” z innym kodem niż wersja na komputery
• Konwersja do WebP podmienia pliki, ale nie usuwa starych kandydatów do srcset
• Redakcja wkleja zrzuty całego okna przeglądarki (3000×2000) bez kadrowania
• Page builder zapisuje bezwzględne szerokości w pikselach, które psują się na telefonach i są potem poprawiane przez JavaScript

#Najczęstsze pytania o rozmiary obrazów i CLS w WordPressie

#Co powoduje CLS przez obrazy w WordPressie

Najczęściej brakuje stałych wymiarów obrazów, responsywnych wariantów albo zarezerwowanego miejsca w szablonie. Układ przeskakuje wtedy, gdy obrazy się doładowują.

#Jak poprawnie naprawić błędy rozmiaru obrazów

Sprawdź razem szablony, rozmiary obrazów, wyjście srcset i reguły CSS. Potem zmierz CLS ponownie na prawdziwych typach stron, a nie tylko na jednym adresie URL.

#Jak często sprawdzać CLS

Po zmianach w motywie, nowych komponentach, większych wgraniach mediów i ostrzeżeniach Core Web Vitals w Search Console.

#Czy width i height psują responsywny układ

Nie. Atrybuty HTML podają proporcje obrazu. Z CSS max-width: 100% i height: auto obraz się skaluje, a zarezerwowane miejsce zostaje.

#Podsumowanie

Błędy rozmiaru obrazów rzadko są problemem jednej wtyczki. Pojawiają się tam, gdzie szablony omijają API załączników, gdzie hero zderza się z leniwym ładowaniem i gdzie ignoruje się dane terenowe. Kto uporządkuje wymiary, proporcje i powtarzalny pomiar, dostaje stabilniejsze układy i mniej ostrzeżeń w Search Console, bez kosmetyki PageSpeed na adresie demonstracyjnym.

Więcej o pracy nad wydajnością: kompleksowa optymalizacja WordPressa.