Core Web Vitals w 2025 roku: jak poprawić LCP, INP i CLS bez przebudowy strony

Core Web Vitals w 2025 roku: co mierzyć i jak nie wyciągać błędnych wniosków

LCP, INP i CLS jako trzy różne klasy problemów

Core Web Vitals nie są jednym wskaźnikiem „szybkości strony”. Każda z trzech metryk mierzy inny etap korzystania z witryny. LCP dotyczy tego, kiedy użytkownik zobaczy główną treść widoczną po wejściu na stronę. INP mierzy opóźnienie reakcji interfejsu na interakcje, takie jak kliknięcie, dotknięcie ekranu lub wpisanie tekstu. CLS opisuje stabilność układu, czyli nieoczekiwane przesuwanie się widocznych elementów. ^[5]

Te problemy często mają inne przyczyny i wymagają innych napraw. Wolny serwer, brak cache lub zbyt ciężki obraz otwierający stronę mogą obniżać LCP, ale nie muszą mieć dużego wpływu na INP. Z kolei chat, mapa, filtr produktów albo rozbudowany formularz mogą pogarszać INP, mimo że strona ładuje się szybko. CLS zwykle wynika z błędów w strukturze widoku: braku zarezerwowanego miejsca dla obrazu, reklamy, bannera lub fontu.

Najczęstszy błąd polega na wdrażaniu jednej globalnej „optymalizacji PageSpeed” dla wszystkich metryk naraz. Na przykład agresywne opóźnianie JavaScriptu może poprawić wynik laboratoryjny, ale jednocześnie uszkodzić menu, koszyk albo obsługę formularza. Lepszy rezultat daje ustalenie, który wskaźnik pogarsza doświadczenie użytkownika oraz jaki element jest jego realnym źródłem.

Dane laboratoryjne a dane od rzeczywistych użytkowników

PageSpeed Insights pokazuje dwa rodzaje danych. Dane laboratoryjne pochodzą z kontrolowanego testu i pomagają odtworzyć problem: wskazują blokujące zasoby, wielkość JavaScriptu, opóźnienia odpowiedzi serwera czy element LCP. Są bardzo przydatne podczas pracy technicznej, ale nie opisują pełnej sytuacji wszystkich odwiedzających. ^[4]

Dane terenowe, dostępne między innymi przez raport CrUX oraz Google Search Console, pochodzą od rzeczywistych użytkowników. Uwzględniają różne telefony, przeglądarki, przepustowość sieci, lokalizacje i stan pamięci podręcznej. To one lepiej pokazują, czy wydajność strony internetowej faktycznie poprawiła się dla odbiorców, a nie tylko w pojedynczym teście.

Ten sam adres URL może osiągać odmienne wyniki na komputerze i telefonie. Użytkownik desktopowy może mieć szybkie łącze oraz mocny procesor, podczas gdy użytkownik mobilny korzysta ze słabszego urządzenia i sieci komórkowej. Dlatego poprawa Core Web Vitals w 2025 roku powinna zaczynać się od segmentacji danych: urządzenia, rodzaj strony, źródło ruchu i najczęściej odwiedzane adresy.

Od czego zacząć diagnostykę

Najpierw trzeba ustalić, czy problem dotyczy całej witryny, czy tylko wybranych szablonów. Strona główna, wpis blogowy, karta produktu, listing kategorii i formularz kontaktowy zwykle wykorzystują inne zasoby. Poprawka wprowadzona dla jednego widoku nie musi rozwiązać problemu na drugim.

Praktyczna kolejność analizy wygląda następująco:

1. Sprawdź raport Core Web Vitals w Google Search Console i ustal, które adresy lub grupy adresów mają problem.
2. Porównaj wyniki mobilne i desktopowe, zamiast zakładać, że problem występuje identycznie wszędzie.
3. Przetestuj reprezentatywne strony w PageSpeed Insights oraz narzędziach deweloperskich przeglądarki.
4. Wskaż konkretny zasób, komponent lub interakcję odpowiedzialną za pogorszenie wyniku.
5. Wybierz najmniej inwazyjny wariant naprawy i po wdrożeniu wykonaj test funkcjonalny.

Nie należy traktować pojedynczego wyniku z testu jako wyroku. Różnica kilku punktów w syntetycznym narzędziu nie zawsze oznacza zmianę odczuwalną dla użytkownika. Znacznie ważniejsze jest skrócenie oczekiwania na główną treść, poprawa reakcji formularzy i filtrów oraz usunięcie przesunięć, które prowadzą do przypadkowych kliknięć.

Trzy warianty poprawy bez przebudowy strony — co różni ich koszt, ryzyko i efekt

Wariant 1: konfiguracja hostingu, cache i dostarczania zasobów

Najmniej inwazyjny wariant obejmuje ustawienia serwera, pamięci podręcznej, kompresji i CDN. Ma największy sens, gdy dokument HTML odpowiada zbyt wolno, zasoby statyczne są pobierane bez odpowiednich nagłówków cache albo użytkownicy znajdują się daleko od serwera źródłowego.

Do tej grupy należą między innymi: cache pełnych stron dla anonimowych użytkowników, cache obiektowy, kompresja odpowiedzi, optymalizacja przekierowań, CDN dla obrazów i plików statycznych oraz prawidłowe nagłówki Cache-Control. Takie działania często wspierają poprawę LCP, ponieważ skracają czas dostarczenia HTML, CSS, obrazów i fontów.

Ten wariant nie rozwiąże jednak każdego problemu. CDN nie naprawi skryptu blokującego główny wątek przeglądarki. Cache nie usunie CLS wywołanego przez baner cookie dodawany nad treścią. Infrastruktura jest dobrym początkiem, ale nie powinna zastępować diagnostyki frontendu.

Wariant 2: selektywna optymalizacja frontendu i skryptów

Drugi wariant polega na zmianie sposobu ładowania zasobów bez zmiany architektury całej strony. Najczęściej obejmuje obrazy, fonty, style CSS, zewnętrzne skrypty oraz kolejność ich pobierania. Jest to zwykle najbardziej opłacalna droga dla stron opartych na popularnych CMS-ach, motywach i gotowych wtyczkach.

Można ograniczyć nieużywany JavaScript na określonych podstronach, opóźnić widget czatu, załadować mapę dopiero po kliknięciu, podzielić duży pakiet kodu lub wyłączyć skrypt testów A/B na stronach, gdzie nie jest potrzebny. Podobnie działa poprawna optymalizacja obrazów: główna grafika nie powinna być traktowana tak samo jak zdjęcia daleko pod treścią.

Ryzyko wdrożeniowe jest umiarkowane. Zmiana atrybutów defer, async albo mechanizmów opóźniających JavaScript może zmienić kolejność uruchamiania funkcji. Po każdej zmianie trzeba ręcznie sprawdzić menu, wyszukiwarkę, logowanie, formularze, koszyk, płatność i zdarzenia analityczne.

Wariant 3: poprawki krytycznych szablonów oraz komponentów

Najbardziej zaawansowany, lecz nadal nieoznaczający pełnej przebudowy, wariant dotyczy konkretnych komponentów. Źródłem problemu może być jeden powtarzalny moduł: banner promocyjny, rekomendacje produktów, filtr katalogu, formularz wieloetapowy, osadzony kalendarz, sekcja opinii lub reklama.

W takim przypadku opłaca się poprawić komponent u źródła. Można zarezerwować dla niego miejsce, uprościć liczbę renderowanych elementów, przełożyć ładowanie danych na później lub ograniczyć liczbę operacji wykonywanych po kliknięciu. Efekt bywa większy niż przy globalnej minifikacji, ponieważ usuwa konkretną przyczynę problemu. ^[1]

Wariant	Typowe źródła problemu	Mocne strony	Ryzyka wdrożeniowe	Kiedy wybrać
Hosting, cache i CDN	Wolny HTML, brak cache, ciężkie zasoby statyczne	Mała ingerencja w stronę, szybki efekt dla LCP	Możliwe problemy z cache treści dynamicznych	Gdy serwer i dostarczanie plików są wąskim gardłem
Optymalizacja frontendu	Obrazy, fonty, nadmiarowy CSS i JavaScript	Dobra relacja efektu do zakresu prac	Ryzyko błędnej kolejności uruchamiania skryptów	Gdy strona ma dużo dodatków, tagów i zasobów
Poprawki komponentów	Filtry, bannery, widgety, formularze, reklamy	Usuwa źródło problemu na wielu podstronach	Wymaga testów konkretnej funkcji	Gdy jeden moduł powtarzalnie pogarsza INP lub CLS

Jak poprawić LCP: wybór właściwego elementu i skrócenie jego ścieżki renderowania

Najpierw ustal, co faktycznie jest elementem LCP

Element Largest Contentful Paint nie zawsze jest tym, czym wydaje się na pierwszy rzut oka. Na stronie głównej może to być obraz hero, ale na wpisie blogowym często będzie nim nagłówek lub wyróżnione zdjęcie. W sklepie może to być główne zdjęcie produktu, a na stronie kategorii duży banner nad listą produktów.

Nie należy optymalizować obrazu tylko dlatego, że jest duży wizualnie. Trzeba potwierdzić jego rolę w raporcie PageSpeed Insights lub narzędziach deweloperskich. Czasem obraz jest dobrze zoptymalizowany, ale przeglądarka odkrywa jego adres dopiero po uruchomieniu JavaScriptu. Wtedy kompresja pliku niewiele zmieni, ponieważ problem leży w zbyt późnym rozpoczęciu pobierania.

Ścieżka LCP zwykle obejmuje odpowiedź serwera, pobranie HTML, wykrycie zasobu przez przeglądarkę, pobranie CSS i obrazu oraz wyrenderowanie elementu. Opóźnienie na każdym etapie sumuje się. Dlatego skuteczna poprawa LCP wymaga prześledzenia całej sekwencji, a nie jednego działania wykonanego „na ślepo”.

Wariant szybki: priorytety zasobów, cache i optymalizacja obrazu

Jeżeli elementem LCP jest grafika, należy sprawdzić jej rzeczywiste wymiary, wagę, format i sposób dostarczania. Duży obraz przeznaczony na ekran desktopowy nie powinien być wysyłany bez zmian na telefon. Responsywne obrazy z użyciem srcset i sizes pozwalają przeglądarce pobrać wariant odpowiedni dla aktualnego ekranu.

Główna grafika nie powinna otrzymywać atrybutu loading="lazy", jeśli jest widoczna od razu po wejściu na stronę. Lazy loading ma sens dla zasobów poza pierwszym ekranem. W przypadku obrazu hero opóźnienie ładowania może bezpośrednio pogorszyć LCP, nawet gdy sam plik jest lekki.

Przydatne bywają także priorytety pobierania oraz preload najważniejszego zasobu. Należy używać ich oszczędnie. Dodanie preloadu do wielu obrazów, fontów i skryptów tworzy konkurencję o przepustowość, przez co przeglądarka może pobierać kluczowy plik wolniej zamiast szybciej. ^[2]

• Serwuj obrazy w nowoczesnym formacie, jeżeli środowisko i kompatybilność projektu na to pozwalają.
• Nie przesyłaj obrazu o znacznie większych wymiarach niż te używane w widoku.
• Utrzymuj trwałe adresy plików, aby CDN i przeglądarka mogły skutecznie korzystać z cache.
• Wybierz jeden zasób krytyczny do preloadu, zamiast oznaczać w ten sposób całą sekcję otwierającą.
• Sprawdź, czy obraz LCP jest obecny w HTML, a nie dodawany dopiero przez skrypt.

Wariant rozszerzony: ograniczenie blokowania renderowania

LCP może pozostać słaby mimo lekkiego obrazu, gdy przeglądarka długo czeka na CSS, fonty albo odpowiedź serwera. Pierwszym krokiem jest skrócenie czasu generowania dokumentu HTML. Typowe źródła opóźnienia to łańcuchy przekierowań, brak cache dla użytkowników niezalogowanych, ciężkie zapytania do bazy danych i zewnętrzne API wywoływane przed wysłaniem strony.

Drugim obszarem jest CSS. Duży arkusz stylów nie zawsze jest problemem sam w sobie, ale krytyczne style potrzebne do wyrenderowania pierwszego ekranu powinny być dostępne bez zbędnego oczekiwania. Style używane wyłącznie przez galerie, formularze wieloetapowe czy komponenty umieszczone na końcu strony nie muszą blokować początkowego renderowania.

Fonty również mogą wpływać na moment pojawienia się tekstu. Jeśli duży nagłówek jest elementem LCP, ładowanie wielu odmian kroju pisma przed jego narysowaniem może pogorszyć wynik. Pomaga ograniczenie liczby wariantów fontu, użycie odpowiedniej strategii wyświetlania oraz sprawdzenie, czy font nie jest pobierany z opóźnieniem przez zewnętrzny skrypt.

Typowa sytuacja: obraz otwierający stronę jest dobrze skompresowany i dostępny przez CDN, ale jego adres pojawia się dopiero po wykonaniu skryptu slidera. Przeglądarka rozpoczyna pobieranie zbyt późno. Prostsze rozwiązanie to umieszczenie pierwszego obrazu bezpośrednio w HTML, a interaktywną część slidera uruchomić dopiero po wyrenderowaniu początkowego widoku.

Jak poprawić INP: porównanie strategii ograniczania opóźnień interakcji

INP pogarsza się wtedy, gdy użytkownik wykona interakcję, a przeglądarka zbyt długo nie może rozpocząć lub zakończyć reakcji wizualnej. Problemem nie musi być sam kliknięty element. Przycisk może działać poprawnie, lecz jego obsługę blokuje długie zadanie JavaScriptu, przebudowa dużej części DOM albo kosztowne obliczenia uruchomione przez inny komponent.

Przy planowaniu kolejnych kroków pomocny może być tekst: Jakie ustawienia routera mają wpływ na wydajność systemu?.

Bez przebudowy całej aplikacji najczęściej warto rozważyć cztery kierunki: ograniczenie JavaScriptu, podzielenie pracy głównego wątku, opóźnienie zewnętrznych widgetów oraz usprawnienie konkretnej interakcji. Różnią się zakresem, ryzykiem i tym, czy poprawiają wiele miejsc naraz, czy tylko jeden istotny scenariusz.

Strategia	Co usuwa lub ogranicza	Największa korzyść	Ograniczenie	Najlepsze zastosowanie
Redukcja JavaScriptu	Nieużywane biblioteki, skrypty marketingowe, kod uruchamiany globalnie	Mniej pracy przeglądarki na wielu podstronach	Wymaga kontroli zależności i analityki	Strony z rozbudowanym motywem, tagami i wtyczkami
Dzielenie długich zadań	Blokujące operacje wykonywane jednorazowo	Szybsza reakcja na kliknięcie i wpisywanie danych	Nie zmniejsza całkowitej ilości pracy	Filtry, wyszukiwarki, formularze i rozbudowane listy
Opóźnienie widgetów	Chaty, mapy, odtwarzacze, systemy opinii i testów A/B	Odciąża stronę przed pierwszą interakcją	Może zmienić dostępność funkcji od razu po wejściu	Widgety pomocnicze, niewymagane w pierwszych sekundach
Optymalizacja konkretnej interakcji	Nadmiarowe renderowanie, zapytania i manipulacje DOM po kliknięciu	Wyraźna poprawa kluczowego działania użytkownika	Efekt może być lokalny	Koszyk, filtr, formularz, menu, kalendarz lub wyszukiwarka

Wariant 1: ogranicz JavaScript uruchamiany bez potrzeby

Najszerszy efekt daje usunięcie kodu, który pobiera się i wykonuje na każdej stronie, mimo że jest potrzebny tylko w wybranych miejscach. Dotyczy to zwłaszcza bibliotek sliderów, modułów formularzy, skryptów galerii, integracji społecznościowych oraz kodu wstrzykiwanego przez menedżery tagów.

Przykładowo skrypt obsługujący kalendarz rezerwacji nie musi być ładowany na stronie kontaktowej, a kod filtrowania produktów nie jest potrzebny na wpisach blogowych. Podobnie widget opinii może zostać aktywowany tylko na kartach produktów, zamiast inicjalizować się globalnie po każdym wejściu na serwis.

Warto odróżnić minifikację od realnej redukcji pracy. Zmniejszenie pliku JavaScript może skrócić pobieranie, ale niekoniecznie rozwiąże problem INP, jeżeli przeglądarka nadal musi wykonać dużo kodu, utworzyć tysiące elementów DOM albo przeliczyć style dla dużego fragmentu strony. Najlepszy efekt daje nie tylko mniejszy pakiet, lecz także mniejsza liczba funkcji uruchamianych automatycznie.

Ten wariant ma sens dla stron, które przez lata gromadziły dodatki i integracje. Wymaga jednak ostrożności: przed usunięciem skryptu trzeba potwierdzić, czy nie obsługuje on zgód cookie, śledzenia konwersji, walidacji formularza albo funkcji wymaganej na urządzeniach mobilnych.

Wariant 2: podziel długą pracę na krótsze etapy

Główny wątek przeglądarki nie może jednocześnie wykonywać długiego JavaScriptu i szybko obsługiwać kolejnego kliknięcia, przewijania lub wpisywania tekstu. Jeżeli po wybraniu filtra kod od razu przetwarza pełną listę produktów, sortuje dane, aktualizuje adres URL i przebudowuje wiele elementów, użytkownik może odnieść wrażenie, że interfejs nie reaguje.

Nie zawsze trzeba przepisywać całą funkcję. Często wystarczy rozdzielić jej pracę na etapy: najpierw pokazać stan ładowania lub zaznaczenie wybranego filtra, następnie przetworzyć dane, a na końcu wyrenderować listę. Krótsze zadania dają przeglądarce okazję do narysowania aktualnego stanu interfejsu i obsługi kolejnych zdarzeń.

Pomocne mogą być mechanizmy takie jak requestAnimationFrame, requestIdleCallback stosowany z rozwagą albo planowanie mniej pilnych prac po zakończeniu bieżącej interakcji. Nie są one uniwersalnym lekarstwem: przeniesienie kosztownej operacji na później nie usuwa jej kosztu. Pozwala jednak nie blokować najważniejszej odpowiedzi wizualnej, na przykład otwarcia panelu filtrowania lub potwierdzenia kliknięcia przycisku.

Ten wariant jest szczególnie użyteczny, gdy użytkownik widzi opóźnienie mimo szybkiej odpowiedzi serwera. Typowe przypadki to rozwijane menu z wieloma kategoriami, wyszukiwarka z podpowiedziami, konfigurator produktu, formularz z warunkowymi polami oraz tabela z dużą liczbą wierszy.

Wariant 3: uruchamiaj widgety po intencji użytkownika

Zewnętrzne widgety często obciążają stronę niezależnie od tego, czy użytkownik z nich skorzysta. Chat może pobrać kod, połączyć się z usługą zewnętrzną i utworzyć widżet tuż po wejściu. Mapa może inicjalizować bibliotekę oraz pobierać dodatkowe zasoby, choć odwiedzający chce jedynie przeczytać adres firmy. Odtwarzacz wideo, system rekomendacji czy narzędzie do testów A/B mogą działać podobnie.

Najmniej inwazyjnym rozwiązaniem jest pokazanie lekkiego zastępnika i załadowanie pełnego widgetu dopiero po wyraźnym działaniu użytkownika. Mapa może zostać aktywowana po kliknięciu przycisku „Pokaż mapę”, a film po wybraniu miniatury. W przypadku czatu można rozważyć późniejszą inicjalizację, o ile nie jest on podstawowym kanałem obsługi dla danej strony.

Plus tego podejścia jest prosty: użytkownicy, którzy nie korzystają z funkcji, nie ponoszą jej pełnego kosztu. Minusem jest dodatkowy krok dla osób, które jej potrzebują. Dlatego nie należy stosować go automatycznie do każdego elementu. Jeśli formularz kontaktowy lub wyszukiwarka produktów są kluczowe dla konwersji, lepszym rozwiązaniem może być ich bezpośrednia optymalizacja niż opóźnianie.

Wariant 4: napraw jedną interakcję, która ma znaczenie biznesowe

Niektóre problemy INP wynikają z pojedynczego scenariusza, który powtarza się na wielu stronach. Przykładem jest filtr katalogu produktów odświeżający całą listę po każdym zaznaczeniu opcji, przycisk „Dodaj do koszyka” uruchamiający kilka równoległych zapytań albo formularz walidujący wszystkie pola przy każdym wpisanym znaku.

W takich sytuacjach należy ograniczyć pracę wykonywaną po interakcji. Dla filtra może to oznaczać aktualizowanie tylko zmienionych elementów zamiast tworzenia całej listy od nowa. Dla formularza — walidację pola po opuszczeniu pola lub po krótkiej przerwie w pisaniu, a nie po każdej literze. Dla koszyka — natychmiastowe pokazanie potwierdzenia wizualnego, podczas gdy mniej istotne aktualizacje wykonają się później.

Ważne jest także ograniczenie wielokrotnych nasłuchiwaczy zdarzeń. Jeśli ten sam klik uruchamia kod motywu, wtyczki, analityki, testu A/B i niestandardowego skryptu, opóźnienie może narastać bez widocznego pojedynczego błędu. Warto sprawdzić, czy wszystkie zdarzenia są rzeczywiście konieczne w chwili interakcji.

• Pokazuj zmianę stanu interfejsu możliwie szybko, na przykład aktywny przycisk, spinner lub komunikat o dodaniu produktu.
• Nie renderuj ponownie całego komponentu, gdy zmienia się tylko jeden jego fragment.
• Ogranicz liczbę elementów DOM tworzonych po kliknięciu lub wpisaniu tekstu.
• Przenieś mniej pilne aktualizacje analityczne i pomocnicze poza krytyczny moment reakcji.
• Sprawdź działanie na słabszym telefonie, ponieważ tam koszt JavaScriptu jest zwykle bardziej odczuwalny.

Jak ograniczyć CLS: warianty stabilizowania obrazów, modułów dynamicznych i fontów

CLS pojawia się, gdy elementy zmieniają swoje położenie po tym, jak użytkownik zaczął już oglądać lub obsługiwać stronę. Najbardziej uciążliwe przesunięcia nie zawsze są duże wizualnie. Wystarczy, że przycisk przesunie się w chwili kliknięcia, a użytkownik wybierze inną opcję niż zamierzał.

Najczęściej da się ograniczyć ten problem bez zmiany wyglądu serwisu. W zależności od przyczyny należy zarezerwować miejsce dla mediów, ustabilizować moduły ładowane asynchronicznie albo ograniczyć zmianę wymiarów tekstu po pobraniu fontów.

Wariant 1: stałe proporcje dla obrazów i osadzonych mediów

Obraz, którego wymiary nie są znane podczas początkowego renderowania, może pojawić się dopiero po załadowaniu pliku i wypchnąć treść znajdującą się niżej. Dotyczy to zdjęć produktów, miniaturek artykułów, banerów, osadzonych filmów i ramek z treścią zewnętrzną.

Najprostszym rozwiązaniem jest przekazanie przeglądarce informacji o przewidywanych wymiarach. Dla obrazów HTML zwykle oznacza to poprawne atrybuty width i height, a dla kontenerów responsywnych — ustalenie proporcji za pomocą CSS, na przykład właściwości aspect-ratio. Dzięki temu układ może zarezerwować miejsce, zanim faktyczna grafika zostanie pobrana.

Ten wariant jest dobry dla stron, na których obrazy pochodzą z CMS-a lub CDN i mają powtarzalne formaty. Trzeba jednak uważać na przypadki, w których jeden komponent wyświetla obrazy o różnych proporcjach. Wtedy sztywna wysokość może prowadzić do kadrowania albo pustych przestrzeni. Lepsze będzie określenie przewidywalnych proporcji dla poszczególnych typów kart i bannerów.

Wariant 2: rezerwuj miejsce dla treści dynamicznej

Moduły dynamiczne są częstą przyczyną przesunięć, ponieważ ich finalny rozmiar może zależeć od odpowiedzi API, systemu reklamowego lub zewnętrznego skryptu. Dotyczy to bloków rekomendacji, wyników personalizacji, bannerów promocyjnych, komunikatów o dostępności, sekcji opinii i reklam.

Nie każdy taki moduł powinien mieć zawsze dużą, pustą przestrzeń. Warto dobrać rozwiązanie do jego roli. Jeżeli komponent pojawia się regularnie i ma zbliżoną wysokość, można zarezerwować dla niego miejsce od początku. Jeżeli może się nie pojawić, lepiej umieścić go w obszarze, który nie przesunie kluczowej treści, albo użyć kompaktowego placeholdera o kontrolowanych wymiarach.

Reklamy wymagają szczególnej ostrożności. Slot reklamowy może otrzymać kreację o różnej wysokości, dlatego kod strony powinien przewidywać dopuszczalne formaty. Ukrywanie pustego slotu dopiero po załadowaniu strony może samo wywołać przesunięcie. Bezpieczniej określić zasady jego zachowania przed renderowaniem lub umieścić reklamę poza obszarem intensywnej interakcji.

Typ elementu	Najbezpieczniejszy wariant stabilizacji	Ryzyko przy złym wdrożeniu
Zdjęcie produktu lub artykułu	Wymiary obrazu i kontrolowane proporcje kontenera	Przesuwanie kart oraz przycisków pod zdjęciem
Film, mapa lub osadzony materiał	Placeholder o docelowych proporcjach	Nagłe zwiększenie wysokości po inicjalizacji iframe
Banner promocyjny	Stały obszar lub miejsce przewidziane w szablonie	Wypchnięcie nagłówka, menu albo treści
Rekomendacje i opinie	Szkielet ładowania o przewidywalnej wysokości	Skok układu po pobraniu danych z API
Reklama	Slot z wcześniej określonymi zasadami wymiarów	Przesunięcie treści i przypadkowe kliknięcia

Wariant 3: ogranicz zmiany układu wywołane przez fonty

Font internetowy może zmienić szerokość tekstu, liczbę wierszy nagłówka i wysokość całego bloku po pobraniu pliku. Jeśli nad tekstem lub pod nim znajdują się przyciski, zdjęcia albo formularz, taka zmiana może być widoczna jako CLS.

Najważniejsze punkty

• LCP, INP i CLS opisują różne problemy, dlatego każda metryka wymaga osobnej diagnozy i działań naprawczych.
• Wnioski warto opierać zarówno na danych laboratoryjnych, jak i terenowych, z uwzględnieniem urządzeń, szablonów oraz najczęściej odwiedzanych adresów.
• Najmniej inwazyjne usprawnienia obejmują konfigurację hostingu, cache, kompresję, CDN oraz prawidłowe dostarczanie zasobów.
• Selektywna optymalizacja obrazów, fontów, CSS i JavaScriptu może poprawić wydajność bez przebudowy całej strony, ale wymaga testów funkcjonalnych.
• Największy efekt często przynosi usunięcie przyczyny problemu w konkretnym komponencie, takim jak filtr, banner, widget, formularz lub reklama.
• Przy poprawie LCP należy najpierw potwierdzić, który element jest elementem LCP, a następnie skrócić całą ścieżkę jego renderowania.

Źródła

• [1] web.dev / Google – The most effective ways to improve Core Web Vitals ↑
• [2] web.dev / Google – Optimize Largest Contentful Paint ↑
• [3] web.dev / Google – Optimize Cumulative Layout Shift
• [4] Google for Developers – About PageSpeed Insights ↑
• [5] Google Search Central – Understanding Core Web Vitals and Google search results ↑