Core Web Vitals – jak poprawić LCP, INP i CLS?

Szybkość strony internetowej nie sprowadza się do czasu potrzebnego na pobranie wszystkich plików. Witryna może zakończyć ładowanie po dwóch sekundach, ale przez kolejny moment nie reagować na kliknięcia. Może też szybko wyświetlić pierwsze elementy, podczas gdy główna zawartość pojawi się znacznie później. Zdarza się również, że przycisk lub formularz przesuwa się podczas ładowania, utrudniając użytkownikowi wykonanie zaplanowanej czynności. Właśnie takie problemy pozwalają identyfikować Core Web Vitals.

Core Web Vitals to zestaw wskaźników opracowanych przez Google, które mierzą rzeczywiste doświadczenia użytkowników związane z ładowaniem strony, jej responsywnością i stabilnością wizualną. Obecnie obejmują trzy metryki: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) oraz Cumulative Layout Shift (CLS).

Ich optymalizacja wymaga czegoś więcej niż instalacji wtyczki cache lub kompresji obrazów. Aby skutecznie poprawić wyniki, trzeba ustalić, które zasoby opóźniają wyświetlenie głównej zawartości, jakie operacje blokują reakcję strony i które elementy powodują nieoczekiwane przesunięcia układu. Jak przeprowadzić taką analizę i które działania techniczne mają największy sens?

Czym są Core Web Vitals i jakie mają znaczenie dla SEO?

Core Web Vitals stanowią część szerszego podejścia do oceny doświadczeń użytkowników na stronach internetowych. Każda z trzech metryk odpowiada za inny aspekt funkcjonowania witryny.

• LCP (Largest Contentful Paint) – mierzy czas wyświetlenia największego kwalifikującego się elementu treści w widocznym obszarze strony.
• INP (Interaction to Next Paint) – ocenia responsywność strony na interakcje użytkownika, takie jak kliknięcia, dotknięcia ekranu czy użycie klawiatury.
• CLS (Cumulative Layout Shift) – mierzy nieoczekiwane przesunięcia elementów interfejsu podczas korzystania ze strony.

Google wykorzystuje Core Web Vitals w swoich systemach rankingowych. Nie oznacza to jednak, że osiągnięcie idealnych wyników automatycznie zapewni wysokie pozycje. Trafność treści, dopasowanie do intencji użytkownika i inne sygnały SEO nadal pozostają bardzo ważne.

Znaczenie wskaźników wykracza jednak poza widoczność organiczną. Problemy z wydajnością mogą utrudniać przeglądanie produktów, korzystanie z formularzy, przechodzenie między podstronami i realizowanie zakupów. Dlatego poprawa Core Web Vitals powinna być rozpatrywana również w kontekście UX i optymalizacji konwersji.

Jakie są aktualne progi Core Web Vitals?

Google określa trzy przedziały oceny dla każdej metryki: wynik dobry, wymagający poprawy oraz słaby.

Ocena opiera się na 75. percentylu wyników z rzeczywistych wizyt użytkowników, oddzielnie dla urządzeń mobilnych i komputerów. Oznacza to, że co najmniej 75% obserwacji powinno osiągać dobry próg danej metryki.

Istotne jest również to, że dobry średni wynik nie oznacza automatycznie zaliczenia Core Web Vitals. Jeśli większość użytkowników korzysta z szybkich komputerów, ale istotna grupa odwiedzających na smartfonach doświadcza poważnych opóźnień, analiza oparta wyłącznie na średnich może ukrywać problem.

INP zastąpił wcześniejszą metrykę FID (First Input Delay) w marcu 2024 roku. Starsze poradniki skupiające się na optymalizacji FID nie odzwierciedlają więc w pełni aktualnego sposobu oceny responsywności.

LCP (Largest Contentful Paint) – jak poprawić czas wyświetlania głównej zawartości?

LCP mierzy moment wyświetlenia największego kwalifikującego się elementu zawartości widocznego w początkowym obszarze strony. Najczęściej jest nim duży obraz, baner, zdjęcie produktu albo blok tekstowy.

Przykładowo sklep internetowy może wyświetlić menu i logo już po 0,8 sekundy, ale główny baner produktowy dopiero po 4,5 sekundy. W takiej sytuacji użytkownik widzi podstawowe elementy interfejsu, jednak najważniejsza część strony pojawia się zdecydowanie później.

Dobry LCP powinien wynosić maksymalnie 2,5 sekundy.

Od czego zależy wynik LCP?

Na ostateczny czas wpływa kilka etapów procesu ładowania:

1. Time to First Byte (TTFB) – czas od rozpoczęcia nawigacji do otrzymania pierwszego bajtu odpowiedzi serwera.
2. Resource load delay – opóźnienie między otrzymaniem dokumentu a rozpoczęciem pobierania zasobu LCP.
3. Resource load duration – czas pobierania zasobu, jeśli element LCP wymaga zewnętrznego pliku.
4. Element render delay – czas oczekiwania na faktyczne wyświetlenie elementu po udostępnieniu potrzebnych zasobów.

Rozdzielenie tych etapów jest bardzo ważne. Jeśli obraz zajmuje tylko niewielką część całkowitego czasu LCP, jego dodatkowa kompresja może przynieść minimalny efekt. Rzeczywistym problemem może być JavaScript opóźniający renderowanie albo późne odkrycie adresu obrazu przez przeglądarkę.

1. Zoptymalizuj główny obraz strony

W wielu sklepach internetowych oraz witrynach firmowych elementem LCP jest zdjęcie znajdujące się w pierwszym ekranie.

Warto zadbać o jego odpowiedni rozmiar, format i sposób dostarczania.

• Wykorzystuj nowoczesne formaty, takie jak WebP lub AVIF, jeśli są odpowiednie dla danego obrazu i środowiska.
• Dobieraj rozdzielczość do rzeczywistych wymiarów wyświetlania, uwzględniając ekrany o większej gęstości pikseli.
• Stosuj responsywne obrazy z atrybutami srcset i sizes.
• Ograniczaj zbędne metadane i dobieraj rozsądny poziom kompresji.
• Zapewnij możliwość wczesnego wykrycia zasobu przez przeglądarkę.

Nie należy jednak skupiać się wyłącznie na wielkości pliku. Obraz ważący 150 KB może nadal opóźniać LCP, jeśli przeglądarka rozpoczyna jego pobieranie dopiero po zakończeniu wykonywania kilku skryptów.

2. Nie stosuj lazy loading dla obrazu LCP

Lazy loading jest przydatnym rozwiązaniem dla zdjęć znajdujących się poza początkowym obszarem ekranu. Pozwala ograniczać pobieranie zasobów, których użytkownik jeszcze nie potrzebuje.

Inaczej wygląda sytuacja z obrazem stanowiącym LCP. Jeśli znajduje się on od razu w widocznym obszarze strony, jego opóźnione ładowanie może pogorszyć wynik.

Przykład konfiguracji odpowiedniej dla priorytetowego obrazu:

<img
  src="/images/baner-glowny.webp"
  width="1200"
  height="600"
  alt="Wyposażenie biurowe"
  loading="eager"
  fetchpriority="high"
>

Atrybut fetchpriority=”high” wskazuje przeglądarce, że dany zasób powinien otrzymać wysoki priorytet pobierania. Nie należy jednak dodawać go do wszystkich zdjęć. Jeśli wiele obrazów otrzyma ten sam priorytet, mechanizm straci część praktycznej wartości.

Ważne jest również to, aby rzeczywiście ustalić element LCP dla różnych wersji strony. Na komputerze może być nim duży baner, a na smartfonie zupełnie inny obraz lub nagłówek tekstowy.

3. Skróć czas odpowiedzi serwera

Jeśli wysoki TTFB odpowiada za znaczną część LCP, warto rozpocząć optymalizację od warstwy serwerowej.

Możliwe działania obejmują:

• konfigurację cache odpowiedzi HTML tam, gdzie jest to bezpieczne,
• optymalizację zapytań do bazy danych,
• ograniczenie zbędnych operacji wykonywanych przez backend,
• zastosowanie CDN i edge caching w odpowiednich scenariuszach,
• analizę wydajności hostingu i aplikacji,
• usunięcie niepotrzebnych przekierowań przed załadowaniem właściwej strony.

Nie należy zakładać, że zmiana hostingu automatycznie poprawi wszystkie Core Web Vitals. Jeśli głównym problemem jest wykonywanie dużej ilości JavaScript po stronie użytkownika, sam szybszy serwer może mieć ograniczony wpływ na INP.

4. Ogranicz zasoby blokujące renderowanie

Przeglądarka może pobrać główny obraz, ale nadal nie wyświetlić go z powodu konieczności przetworzenia krytycznych arkuszy CSS lub skryptów.

Warto przeanalizować:

• nieużywany CSS,
• duże pliki JavaScript ładowane synchronicznie,
• skrypty marketingowe uruchamiane przed wyświetleniem treści,
• czcionki blokujące pojawienie się głównego tekstu,
• elementy wymagające renderowania całego interfejsu przez JavaScript.

W przypadku aplikacji typu SPA pomocne może być renderowanie po stronie serwera (SSR) lub generowanie statycznego HTML, jeśli pozwala to przeglądarce wcześniej odkryć i wyświetlić kluczową zawartość. Takie wdrożenie wymaga jednak uwzględnienia obciążenia backendu i całej architektury aplikacji.

INP (Interaction to Next Paint) – jak poprawić responsywność strony?

INP ocenia, jak szybko strona reaguje wizualnie na interakcje użytkownika. Nie chodzi wyłącznie o pierwsze kliknięcie, ale o responsywność podczas korzystania z dokumentu.

Przykładowo użytkownik wybiera filtr produktów, otwiera menu, zmienia wariant produktu lub klika przycisk „Dodaj do koszyka”. Jeśli przeglądarka przez dłuższy czas nie jest w stanie przedstawić aktualizacji interfejsu, użytkownik odczuwa opóźnienie.

Dobry wynik INP wynosi maksymalnie 200 ms.

Jak obliczany jest INP?

INP obejmuje opóźnienie wejściowe, czas przetwarzania zdarzenia oraz opóźnienie wyświetlenia kolejnej klatki interfejsu.

W uproszczeniu:

INP = input delay + processing duration + presentation delay

Oznacza to, że poprawa samego kodu funkcji obsługującej kliknięcie nie zawsze wystarczy. Interakcja może być opóźniona również przez wcześniejsze operacje blokujące główny wątek albo przez kosztowną aktualizację układu strony.

INP bazuje na interakcjach obserwowanych podczas wizyty i uwzględnia niemal najwolniejszą z nich, z mechanizmem ograniczającym wpływ wartości odstających przy większej liczbie interakcji.

1. Ogranicz długie zadania JavaScript

Jedną z najczęstszych przyczyn wysokiego INP jest wykonywanie długich zadań na głównym wątku przeglądarki. Mogą one blokować reakcję na kliknięcia, dotknięcia ekranu i użycie klawiatury.

Zadania przekraczające 50 ms są klasyfikowane jako long tasks. Nie oznacza to, że każde takie zadanie automatycznie powoduje zły INP, ale ich duża liczba zwiększa ryzyko opóźnień.

Warto wówczas:

• usunąć niepotrzebne skrypty,
• ograniczyć ilość JavaScript uruchamianego podczas ładowania strony,
• dzielić kosztowne operacje na mniejsze zadania,
• odkładać niepilne obliczenia poza krytyczną ścieżkę interakcji,
• przenosić odpowiednie obliczenia do Web Workers, jeśli architektura na to pozwala.

W nowoczesnych przeglądarkach można wykorzystywać również mechanizmy oddawania czasu głównemu wątkowi, np. scheduler.yield(), z odpowiednią obsługą środowisk, które go nie wspierają.

2. Ogranicz skrypty zewnętrzne

W serwisach firmowych i sklepach internetowych duża część JavaScript pochodzi z usług zewnętrznych: systemów analitycznych, narzędzi marketing automation, czatów, personalizacji czy rozbudowanych widgetów.

Nie każdy zewnętrzny skrypt jest problemem. Istotne jest jednak ustalenie, które narzędzia wykonują kosztowne operacje i czy ich działanie musi rozpoczynać się natychmiast.

Przykładowo widget kontaktowy wykorzystywany przez niewielką część użytkowników nie zawsze musi inicjalizować wszystkie moduły podczas pierwszego renderowania strony.

Opóźnienie jego ładowania do momentu, gdy będzie potrzebny, może zmniejszyć obciążenie głównego wątku. Takie rozwiązanie trzeba jednak przetestować, aby nie pogorszyć działania funkcji, z której użytkownik rzeczywiście chce skorzystać.

3. Unikaj kosztownych zmian DOM

Duże aktualizacje drzewa DOM mogą wymagać ponownego obliczenia stylów, układu i renderowania znacznej części strony.

Problem często pojawia się w sklepach posiadających rozbudowane listy produktów i dynamiczne filtry.

Przykładowo wybór producenta może powodować natychmiastowe przetworzenie kilku tysięcy elementów. Jeśli cała operacja wykonywana jest synchronicznie, interfejs może przestać reagować na kolejne działania użytkownika.

Rozwiązaniem może być ograniczenie zakresu aktualizowanego DOM, wirtualizacja długich list lub rozdzielenie kosztownych operacji od szybkiej informacji zwrotnej dla użytkownika.

4. Zapewnij szybką informację zwrotną

Jeżeli wykonanie operacji wymaga pobrania danych z serwera, użytkownik powinien szybko otrzymać informację, że jego działanie zostało zarejestrowane.

Przykładowo po kliknięciu „Dodaj do koszyka” interfejs może natychmiast pokazać stan oczekiwania, a następnie potwierdzić rzeczywisty wynik operacji.

Nie należy jednak mylić wizualnej reakcji z zakończeniem procesu biznesowego. Samo wyświetlenie animacji nie oznacza, że zamówienie zostało poprawnie zapisane. Interfejs powinien prezentować stan zgodny z rzeczywistą operacją.

CLS (Cumulative Layout Shift) – jak zapobiegać przesuwaniu się elementów strony?

CLS mierzy nieoczekiwane przesunięcia widocznych elementów podczas korzystania ze strony. W przeciwieństwie do LCP i INP nie jest wyrażany w sekundach czy milisekundach. To bezwymiarowy wynik zależny od wielkości i odległości przesunięć.

Przykładowo użytkownik chce kliknąć przycisk rezerwacji, ale tuż przed wykonaniem działania nad formularzem pojawia się baner, który przesuwa cały układ. W rezultacie może kliknąć niewłaściwy element.

Dobry wynik CLS powinien wynosić maksymalnie 0,1.

1. Określ wymiary obrazów

Jedną z najprostszych metod ograniczania CLS jest określenie wymiarów obrazów jeszcze przed ich załadowaniem.

Przykład:

<img
  src="/images/produkt.webp"
  width="800"
  height="800"
  alt="Przykładowy produkt"
>

Dzięki atrybutom width i height przeglądarka może wcześniej określić proporcje obrazu i zarezerwować odpowiednie miejsce w układzie.

W responsywnych projektach można połączyć to z CSS:

.product-image {
  display: block;
  width: 100%;
  height: auto;
}

Pozwala to zachować właściwe proporcje obrazu przy dopasowaniu do szerokości kontenera.

2. Rezerwuj miejsce dla elementów dynamicznych

Problemy z CLS często wynikają z elementów wczytywanych po początkowym renderowaniu strony. Mogą to być reklamy, filmy, moduły rekomendacji, widgety lub sekcje personalizowane.

Jeśli dany element ma przewidywalny rozmiar, warto zarezerwować przestrzeń przed pobraniem jego zawartości.

Przykładowo:

.video-container {
  width: 100%;
  aspect-ratio: 16 / 9;
}

Takie rozwiązanie sprawia, że późniejsze pojawienie się filmu nie musi przesuwać pozostałych elementów strony.

Jeśli wysokość modułu jest zmienna, można rozważyć odpowiedni min-height, szkielet ładowania lub inne rozwiązanie dopasowane do realnych wymiarów zawartości. Nie należy jednak rezerwować nadmiernej przestrzeni, która pogorszy wygląd strony.

3. Zadbaj o prawidłowe ładowanie czcionek

Zmiana czcionki podczas ładowania może wpływać na szerokość tekstu, liczbę wierszy i położenie sąsiadujących elementów.

Warto wykorzystywać odpowiednio dobrane fonty zastępcze i analizować działanie font-display. W niektórych projektach pomocne mogą być również właściwości pozwalające dostosować metryki czcionek zastępczych.

Nie należy jednak zakładać, że sama zmiana font-display na swap zawsze poprawi CLS. Jeśli czcionka zastępcza istotnie różni się wymiarami od docelowej, jej podmiana również może powodować przesunięcia układu.

4. Unikaj wstawiania nowych elementów nad widoczną treścią

Banery promocyjne, komunikaty marketingowe i niektóre moduły zgód mogą powodować przesuwanie całej strony, jeśli są dynamicznie wstawiane ponad istniejącą zawartością.

Warto przeanalizować, czy takie elementy muszą wpływać na układ dokumentu. W określonych przypadkach można zarezerwować dla nich miejsce wcześniej lub zastosować inny sposób prezentacji.

Nie należy przy tym ukrywać wymaganych informacji ani pogarszać dostępności interfejsu wyłącznie w celu poprawy wskaźnika CLS.

5. Stosuj animacje, które nie zmieniają układu strony

Animowanie właściwości takich jak width, height, top czy left może prowadzić do ponownych obliczeń układu.

Jeżeli efekt wizualny na to pozwala, warto wykorzystywać właściwości transform i opacity. Pozwala to ograniczyć kosztowne operacje layoutu.

Nie każda animacja z użyciem transform jest automatycznie optymalna dla wydajności, ale często stanowi lepszą alternatywę niż animowanie wymiarów i położenia elementów w normalnym układzie dokumentu.

Jak analizować Core Web Vitals w PageSpeed Insights?

PageSpeed Insights to jedno z podstawowych narzędzi wykorzystywanych podczas audytu wydajności. Łączy dane pochodzące z rzeczywistych doświadczeń użytkowników, jeśli są dostępne, z wynikami diagnostycznymi generowanymi przez Lighthouse.

Te dwa źródła informacji nie są tożsame.

Dane rzeczywistych użytkowników – CrUX

Chrome User Experience Report (CrUX) zawiera zagregowane informacje o doświadczeniach kwalifikujących się użytkowników przeglądarki Chrome.

W PageSpeed Insights dane terenowe obejmują ruchome okno około 28 dni. Można w nich znaleźć wyniki Core Web Vitals dla konkretnego adresu lub całego origin, jeśli dostępna jest wystarczająca ilość danych.

To właśnie wyniki rzeczywistych użytkowników są szczególnie ważne przy ocenie spełniania progów Core Web Vitals.

Dane laboratoryjne – Lighthouse

Lighthouse uruchamia test w kontrolowanych warunkach. Pozwala wskazać potencjalne problemy z zasobami, renderowaniem i wykonywaniem skryptów.

Nie należy jednak traktować wyniku Lighthouse jako pełnego odzwierciedlenia doświadczeń wszystkich użytkowników.

Przykładowo pojedynczy test może wykazać LCP na poziomie 1,8 sekundy, podczas gdy dane CrUX wskazują 3,5 sekundy. Różnica może wynikać z warunków sieciowych, urządzeń, sposobu korzystania ze strony i wielu innych czynników.

Warto też pamiętać, że INP nie jest bezpośrednio mierzone w standardowym teście laboratoryjnym Lighthouse tak samo jak w danych terenowych. Do diagnozowania potencjalnych problemów z responsywnością wykorzystuje się między innymi Total Blocking Time (TBT), analizę zadań głównego wątku i rzeczywiste testy interakcji.

Google Search Console – jak interpretować raport Core Web Vitals?

Google Search Console udostępnia raport dotyczący podstawowych wskaźników internetowych, pozwalający ocenić problemy występujące w grupach adresów URL.

Warto zwrócić uwagę, że raport nie jest pełnym pomiarem każdej podstrony z osobna. Google może grupować adresy o podobnym charakterze, wykorzystując dostępne dane CrUX.

Dlatego problemy warto analizować według typów stron:

• strona główna,
• kategorie produktowe,
• karty produktów,
• artykuły blogowe,
• podstrony usługowe,
• strony z formularzami lub innymi rozbudowanymi interakcjami.

Jeśli problem występuje w całej grupie kart produktów, jego przyczyną może być wspólny szablon lub skrypt, a nie zawartość pojedynczego produktu.

Po wdrożeniu zmian można skorzystać z funkcji weryfikacji poprawki. Nie oznacza to jednak natychmiastowej poprawy wyników, ponieważ dane terenowe odzwierciedlają doświadczenia gromadzone w określonym okresie.

Jak diagnozować LCP, INP i CLS w Chrome DevTools?

Chrome DevTools pozwala przeprowadzić szczegółową analizę wydajności pojedynczej strony i powiązać słabe wyniki z konkretnymi elementami interfejsu oraz operacjami przeglądarki.

Najważniejszym obszarem jest panel Performance, w którym można nagrać proces ładowania i interakcji.

Diagnostyka LCP

Podczas analizy należy ustalić, który element został rozpoznany jako LCP i co opóźnia jego wyświetlenie.

Warto przeanalizować przebieg żądań sieciowych, czas pobierania dokumentu HTML, kolejność ładowania zasobów i operacje blokujące renderowanie.

Jeśli obraz LCP rozpoczyna pobieranie późno, należy sprawdzić jego dostępność w kodzie HTML, priorytet pobierania oraz zależności od CSS i JavaScript.

Diagnostyka INP

W przypadku responsywności należy nagrać konkretne interakcje, np. otwieranie menu, zmianę filtrów albo dodawanie produktu do koszyka.

Następnie warto zidentyfikować długie zadania, funkcje JavaScript oraz kosztowne operacje renderowania występujące pomiędzy rozpoczęciem interakcji a aktualizacją interfejsu.

Sam fakt, że skrypt ma duży rozmiar, nie jest wystarczającym dowodem, że odpowiada za zły INP. Konieczne jest sprawdzenie jego rzeczywistego zachowania.

Diagnostyka CLS

Podczas nagrywania wydajności należy przeanalizować przesunięcia układu i elementy, które zmieniają położenie.

Ważne jest przy tym rozróżnienie elementu przesuniętego od rzeczywistej przyczyny przesunięcia. Jeśli przycisk spada niżej po pojawieniu się banera, problemem może być baner, mimo że to przycisk jest widoczny jako element zmieniający położenie.

CLS warto testować również po początkowym załadowaniu strony, np. podczas przewijania, rozwijania elementów i wyświetlania dynamicznych treści.

Jak ustalić, które optymalizacje Core Web Vitals wykonać najpierw?

Jednym z największych błędów jest próba poprawiania wszystkich wskazówek PageSpeed Insights jednocześnie. Nie każda rekomendacja ma taką samą wartość, a niektóre zmiany mogą poprawiać jeden wskaźnik kosztem innego.

Przykładowo agresywne opóźnianie JavaScript może skrócić czas ładowania początkowego, ale jednocześnie pogorszyć działanie elementów interaktywnych. Z kolei nieprawidłowo skonfigurowany lazy loading może ograniczyć transfer danych, lecz opóźnić wyświetlenie głównego obrazu.

Priorytety najlepiej ustalać na podstawie rzeczywistych wyników, liczby dotkniętych podstron i znaczenia biznesowego.

Po każdej istotnej zmianie warto wykonać ponowne pomiary laboratoryjne i monitorować dane rzeczywistych użytkowników. Pozwala to odróżnić faktyczną poprawę od jednorazowej zmienności testu.

Praktyczny przykład – optymalizacja Core Web Vitals sklepu internetowego

Załóżmy, że sklep internetowy posiada 15 tysięcy produktów, a raport Google Search Console wskazuje problemy z Core Web Vitals na urządzeniach mobilnych.

Dane terenowe dla grupy kategorii pokazują następujące wyniki:

• LCP: 4,3 s,
• INP: 310 ms,
• CLS: 0,19.

Wszystkie trzy metryki wymagają interwencji, ale przyczyny mogą być całkowicie odmienne.

Etap 1. Analiza LCP

W Chrome DevTools okazuje się, że największym elementem w początkowym widoku jest baner kategorii. Obraz pobierany jest w zbyt dużej rozdzielczości i posiada aktywny lazy loading.

Dodatkowo system rozpoczyna pobieranie jego pliku dopiero po wykonaniu skryptu odpowiedzialnego za prezentację karuzeli.

Rozwiązaniem może być przygotowanie odpowiednio dobranych wersji obrazu, wyłączenie lazy loading dla elementu LCP i umożliwienie wcześniejszego pobierania zasobu.

Etap 2. Analiza INP

Test interakcji pokazuje, że największe opóźnienie występuje po zmianie filtrów produktów. Skrypt synchronicznie przetwarza duży zbiór danych i przebudowuje znaczną część listingu.

Zamiast koncentrować się na kolejnej kompresji obrazów, warto zoptymalizować sposób filtrowania, ograniczyć koszt aktualizacji DOM i poprawić harmonogram wykonywania zadań JavaScript.

Etap 3. Analiza CLS

W trakcie ładowania strony nad produktami pojawia się baner promocyjny, dla którego nie zarezerwowano wcześniej miejsca. Powoduje to przesunięcie nagłówka kategorii i pierwszego rzędu produktów.

Po poprawieniu sposobu rezerwowania przestrzeni można ograniczyć nieoczekiwane przesunięcia bez usuwania samego modułu marketingowego.

Etap 4. Test i ocena rezultatów

Po wdrożeniu przeprowadzamy ponowne testy w PageSpeed Insights i Chrome DevTools. Następnie obserwujemy dane CrUX oraz raport Core Web Vitals w Search Console.

Warto również monitorować wskaźniki biznesowe, np. rozpoczęcia sesji, przejścia do produktów, dodania do koszyka i zakupy.

Nie można jednak zakładać, że samo poprawienie LCP z 4,3 do 2,3 sekundy automatycznie zwiększy sprzedaż o określony procent. Taki wpływ wymaga osobnej analizy, uwzględniającej sezonowość, źródła ruchu, zmiany w ofercie i inne czynniki.

Core Web Vitals a SEO – czy lepsze wyniki gwarantują wyższe pozycje?

Google uwzględnia Core Web Vitals w swoich systemach rankingowych, jednak nie stanowią one samodzielnego wyznacznika jakości strony.

Witryna osiągająca bardzo dobre wyniki wydajnościowe może nadal mieć słabą widoczność, jeśli jej zawartość nie odpowiada na zapytania użytkowników, architektura jest nieprawidłowa albo treści nie zapewniają wystarczającej wartości.

Z drugiej strony strona posiadająca bardzo wartościową zawartość może uzyskiwać dobre pozycje pomimo nieidealnych wyników technicznych.

Nie należy więc traktować osiągnięcia 100 punktów w Lighthouse jako głównego celu strategii SEO. Znacznie ważniejsze jest usunięcie problemów, które rzeczywiście utrudniają korzystanie z witryny i wpływają na doświadczenia odwiedzających.

Warto również odróżnić wyniki laboratoryjne od terenowych. Wysoka ocena Lighthouse nie oznacza automatycznie, że 75% rzeczywistych wizyt spełnia progi LCP, INP i CLS.

Najczęstsze błędy podczas optymalizacji Core Web Vitals

Podczas pracy nad wydajnością szczególnie warto unikać następujących praktyk:

• Optymalizacja wyłącznie wyniku Lighthouse bez analizy danych rzeczywistych użytkowników.
• Włączanie lazy loading dla wszystkich obrazów, również tych odpowiadających za LCP.
• Dodawanie fetchpriority=”high” do wielu zasobów, bez ustalenia ich rzeczywistego znaczenia.
• Automatyczne łączenie i opóźnianie wszystkich skryptów, bez weryfikacji wpływu na interakcje.
• Skupianie się wyłącznie na kompresji obrazów, gdy główne opóźnienie wynika z backendu lub JavaScript.
• Ignorowanie mobilnych wyników wydajności i analizowanie wyłącznie szybkich komputerów.
• Usuwanie potrzebnych funkcji strony wyłącznie w celu poprawy wskaźników.
• Brak pomiarów po wdrożeniu zmian i zakładanie, że każda techniczna optymalizacja automatycznie poprawia doświadczenia użytkowników.
• Traktowanie TBT jako odpowiednika INP, mimo że metryki mierzą różne zjawiska.

Najlepsze rezultaty przynosi analiza rzeczywistego wąskiego gardła, a nie mechaniczne wykonywanie wszystkich sugestii narzędzia diagnostycznego.

Jak monitorować Core Web Vitals po optymalizacji?

Wydajność serwisu nie jest wartością stałą. Może zmieniać się wraz z dodawaniem nowych funkcji, skryptów marketingowych, modułów sprzedażowych i aktualizacji systemu CMS.

Dlatego warto prowadzić regularny monitoring obejmujący zarówno dane laboratoryjne, jak i terenowe.

Przy większych serwisach można dodatkowo wdrożyć Real User Monitoring (RUM), czyli zbieranie informacji o rzeczywistych doświadczeniach użytkowników. Biblioteka web-vitals umożliwia mierzenie LCP, INP i CLS w przeglądarkach oraz przesyłanie tych danych do systemu analitycznego.

Takie pomiary można segmentować według typu strony, urządzenia, wersji aplikacji lub innych parametrów pomocnych podczas diagnostyki. Należy przy tym zachować zgodność z wymaganiami dotyczącymi prywatności i zbierania danych.

Warto również przeprowadzać testy regresji wydajności po większych zmianach technicznych, np. wdrożeniu nowego szablonu produktu, przebudowie menu czy uruchomieniu kolejnych narzędzi marketingowych.

Jak skutecznie poprawić Core Web Vitals?

Optymalizacja LCP, INP i CLS powinna być procesem opartym na danych, a nie zbiorem uniwersalnych ustawień stosowanych na każdej stronie internetowej.

W przypadku LCP najważniejsze jest ustalenie, co opóźnia wyświetlenie głównej zawartości. Dla INP kluczowa będzie analiza interakcji, pracy JavaScript i kosztu renderowania. Przy CLS należy znaleźć elementy powodujące nieoczekiwane przesunięcia oraz zadbać o stabilność układu.

Duże znaczenie ma również właściwa kolejność działań. W serwisie posiadającym setki kategorii i tysiące produktów poprawienie wspólnego szablonu może przynieść większe korzyści niż optymalizowanie pojedynczych stron bez analizy skali problemu.

Celem nie jest uzyskanie idealnego wyniku w narzędziu testowym, ale stworzenie witryny, która szybko prezentuje najważniejsze treści, sprawnie reaguje na działania użytkowników i zachowuje stabilny układ.

W 4PEOPLE analizujemy Core Web Vitals jako element technicznego SEO, łącząc dane z Google Search Console, PageSpeed Insights i narzędzi deweloperskich z oceną rzeczywistego funkcjonowania serwisu. Dzięki temu możliwe jest określenie priorytetów optymalizacji i wdrażanie zmian mających znaczenie zarówno dla widoczności organicznej, jak i komfortu użytkowników.

FAQ – Core Web Vitals, LCP, INP i CLS

Co to są Core Web Vitals?

Core Web Vitals to trzy wskaźniki Google służące do oceny doświadczeń użytkowników związanych z wydajnością strony. Obejmują Largest Contentful Paint (LCP), Interaction to Next Paint (INP) oraz Cumulative Layout Shift (CLS). Mierzą odpowiednio ładowanie głównej zawartości, responsywność na interakcje i stabilność wizualną.

Jakie wyniki Core Web Vitals są uznawane za dobre?

Dobry LCP wynosi maksymalnie 2,5 sekundy, INP maksymalnie 200 milisekund, a CLS maksymalnie 0,1. Progi ocenia się na podstawie 75. percentyla rzeczywistych obserwacji, oddzielnie dla urządzeń mobilnych i komputerów.

Jak poprawić LCP w PageSpeed Insights?

Należy ustalić, który element odpowiada za LCP i co opóźnia jego wyświetlenie. W zależności od przyczyny pomocne może być skrócenie TTFB, poprawa priorytetu ładowania głównego obrazu, rezygnacja z lazy loading dla tego elementu, optymalizacja zasobów lub ograniczenie blokującego renderowanie CSS i JavaScript.

Jak obniżyć INP na stronie internetowej?

Poprawa INP wymaga przede wszystkim ograniczenia pracy blokującej główny wątek przeglądarki. Pomocne może być dzielenie długich zadań JavaScript, redukcja zbędnych skryptów, optymalizacja aktualizacji DOM i przyspieszenie informacji zwrotnej po interakcjach użytkownika.

Co powoduje wysoki CLS?

Najczęstsze przyczyny to obrazy bez określonych wymiarów, dynamicznie wstawiane banery, reklamy i widgety, zmiany czcionek oraz animacje wpływające na układ strony. Naprawa polega przede wszystkim na wcześniejszym rezerwowaniu przestrzeni i kontrolowaniu zmian interfejsu.

Czy Core Web Vitals wpływają na pozycje w Google?

Tak, Google wykorzystuje Core Web Vitals w systemach rankingowych, ale nie są one jedynym czynnikiem decydującym o widoczności. Dobre wyniki nie gwarantują wysokich pozycji. Istotne pozostają również trafność, jakość treści oraz inne elementy SEO.

Czy wynik 100/100 w PageSpeed Insights jest konieczny?

Nie. Wynik Lighthouse jest oceną laboratoryjną i nie stanowi oficjalnego progu rankingowego Google. Ważniejsze są rzeczywiste doświadczenia użytkowników i spełnianie rekomendowanych progów LCP, INP oraz CLS.

Czy wtyczka cache wystarczy do poprawy Core Web Vitals?

Nie zawsze. Cache może pomóc ograniczyć czas odpowiedzi serwera, ale nie rozwiąże wszystkich problemów z JavaScript, renderowaniem czy przesunięciami układu. Skuteczna optymalizacja wymaga zidentyfikowania przyczyn słabych wyników dla poszczególnych metryk.

Dlaczego PageSpeed Insights pokazuje inne wyniki niż Google Search Console?

Narzędzia mogą wykorzystywać różne zakresy danych i sposoby prezentacji wyników. PageSpeed Insights łączy dane terenowe z testem laboratoryjnym Lighthouse, natomiast raport Core Web Vitals w Search Console grupuje strony na podstawie danych CrUX. Różnice nie muszą oznaczać błędu pomiaru.

Jak długo trzeba czekać na poprawę raportu Core Web Vitals?

Zmiany techniczne mogą być widoczne w testach laboratoryjnych od razu po wdrożeniu, ale dane terenowe potrzebują czasu. CrUX wykorzystuje ruchome okno około 28 dni, dlatego poprawa w Google Search Console może pojawiać się stopniowo, wraz z napływem nowych obserwacji.