Co to jest Core Web Vitals i jaki ma wpływ na stronę oraz biznes?

Strona może otworzyć się na moim komputerze niemal natychmiast, a jednocześnie działać źle dla dużej części prawdziwych użytkowników. Szybkie połączenie internetowe, wydajny procesor, zapisane wcześniej pliki w pamięci przeglądarki i blisko położony serwer potrafią całkowicie zmienić odczuwalną szybkość witryny.

Klient korzystający ze starszego telefonu i sieci komórkowej może zobaczyć tę samą stronę zupełnie inaczej. Najważniejszy baner pojawi się po kilku sekundach, menu nie zareaguje od razu na dotknięcie, a przycisk przesunie się dokładnie w momencie kliknięcia. Technicznie strona może działać, ale doświadczenie użytkownika będzie słabe.

Core Web Vitals powstały po to, aby opisywać takie sytuacje za pomocą konkretnych wskaźników. Nie mierzą całej jakości strony i nie zastępują audytu wydajności, ale pomagają ocenić trzy bardzo ważne elementy doświadczenia użytkownika:

• jak szybko pojawia się główna treść,
• jak sprawnie strona reaguje na działania użytkownika,
• czy układ pozostaje stabilny podczas korzystania.

W swojej pracy regularnie spotykam strony, których właściciele koncentrują się wyłącznie na liczbie punktów widocznej w PageSpeed Insights. Wynik rośnie z 60 do 90, więc temat zostaje uznany za zamknięty. Tymczasem prawdziwi użytkownicy nadal mogą doświadczać wolnego ładowania, opóźnionych interakcji i przesuwającego się układu.

Core Web Vitals trzeba więc nie tylko zmierzyć, ale przede wszystkim prawidłowo zinterpretować. Bez tego łatwo optymalizować wynik testu zamiast rzeczywistego działania strony.

Co to jest Core Web Vitals?

Core Web Vitals to zestaw podstawowych wskaźników internetowych opracowanych w celu mierzenia wybranych elementów doświadczenia użytkownika na stronie.

Obecny zestaw obejmuje trzy wskaźniki:

• LCP – mierzący szybkość pojawienia się głównej treści,
• INP – mierzący szybkość reakcji strony na interakcje,
• CLS – mierzący nieoczekiwane przesunięcia układu.

Każdy z nich opisuje inny rodzaj problemu. Strona może mieć dobry LCP, ale słaby INP. Może szybko pokazywać treść, lecz reagować z opóźnieniem na otwarcie menu albo wybór wariantu produktu. Może też być szybka i responsywna, ale irytować użytkownika przesuwającymi się przyciskami.

Nie powinno się więc mówić, że strona ma „dobry Core Web Vitals”, patrząc tylko na jeden parametr. Aby ocena była pozytywna, wszystkie trzy podstawowe wskaźniki muszą znajdować się w dobrym zakresie.

Jakie są trzy wskaźniki Core Web Vitals?

LCP – Largest Contentful Paint

Largest Contentful Paint mierzy czas potrzebny do wyrenderowania największego elementu treści widocznego w początkowym obszarze strony.

Najczęściej elementem LCP jest:

• duże zdjęcie w sekcji hero,
• baner główny,
• obraz produktu,
• grafika wyróżniająca wpis,
• duży blok tekstu,
• element zawierający obraz tła.

LCP nie mierzy momentu, w którym strona pobrała absolutnie wszystkie pliki. Próbuje określić, kiedy użytkownik zobaczył główną zawartość i mógł uznać, że strona rzeczywiście zaczęła być użyteczna.

Dobry wynik LCP wynosi 2,5 sekundy lub mniej. Wynik powyżej 2,5 sekundy, ale nie większy niż 4 sekundy, jest traktowany jako wymagający poprawy. LCP przekraczający 4 sekundy jest uznawany za słaby.

W praktyce nie oznacza to, że każda strona z wynikiem 2,6 sekundy jest katastrofą, a strona z wynikiem 2,4 sekundy działa idealnie. Progi pomagają klasyfikować doświadczenie, ale prawdziwa optymalizacja wymaga znalezienia przyczyny opóźnienia.

INP – Interaction to Next Paint

Interaction to Next Paint mierzy responsywność strony, czyli czas pomiędzy działaniem użytkownika a następnym widocznym odświeżeniem interfejsu.

Interakcją może być między innymi:

• kliknięcie przycisku,
• dotknięcie elementu na ekranie,
• wybranie opcji,
• otwarcie menu,
• rozwinięcie sekcji,
• wpisanie znaku za pomocą klawiatury,
• wybranie wariantu produktu,
• dodanie produktu do koszyka.

INP nie ogranicza się wyłącznie do pierwszej interakcji. Obserwuje działania użytkownika w trakcie całej wizyty i ocenia ogólną responsywność strony.

Dobry wynik INP wynosi 200 milisekund lub mniej. Wartości powyżej 200, ale nieprzekraczające 500 milisekund wymagają poprawy. INP powyżej 500 milisekund jest uznawany za słaby.

Pół sekundy może wydawać się krótkim czasem, ale w interfejsie jest wyraźnie odczuwalne. Użytkownik dotyka przycisku i nie widzi reakcji. Może więc kliknąć ponownie, uznać stronę za uszkodzoną albo zrezygnować z wykonania działania.

INP zastąpił wcześniejszy wskaźnik FID, czyli First Input Delay. FID analizował opóźnienie pierwszej interakcji, natomiast INP daje szerszy obraz responsywności podczas całego korzystania ze strony.

CLS – Cumulative Layout Shift

Cumulative Layout Shift mierzy nieoczekiwane przesunięcia widocznych elementów strony.

Typowym przykładem jest przycisk, który nagle przesuwa się w dół, ponieważ nad nim załadował się obraz lub komunikat. Użytkownik chciał kliknąć „Zobacz produkt”, ale przez zmianę układu trafia w zupełnie inny element.

CLS nie jest mierzony w sekundach. Jest wartością bez jednostki, obliczaną na podstawie wielkości przesunięcia i obszaru ekranu, którego ono dotyczy.

Dobry wynik CLS wynosi 0,1 lub mniej. Wynik powyżej 0,1, ale nie większy niż 0,25 wymaga poprawy. Wartość przekraczająca 0,25 jest uznawana za słabą.

Najczęstsze przyczyny problemów z CLS to:

• obrazy bez określonych wymiarów,
• banery ładowane po wyświetleniu strony,
• reklamy bez zarezerwowanej przestrzeni,
• późno pojawiające się komunikaty,
• zmiana fontu po pobraniu pliku,
• dynamicznie dołączane formularze,
• paski promocyjne pojawiające się nad nagłówkiem,
• elementy generowane przez zewnętrzne skrypty.

Jakie wyniki Core Web Vitals są dobre?

Aktualne podstawowe progi wyglądają następująco:

• LCP: dobry do 2,5 sekundy, wymagający poprawy powyżej 2,5 do 4 sekund, słaby powyżej 4 sekund,
• INP: dobry do 200 milisekund, wymagający poprawy powyżej 200 do 500 milisekund, słaby powyżej 500 milisekund,
• CLS: dobry do 0,1, wymagający poprawy powyżej 0,1 do 0,25, słaby powyżej 0,25.

Ocena nie jest jednak wystawiana na podstawie jednego najlepszego pomiaru. Google analizuje dane z prawdziwych wizyt i sprawdza wartość na poziomie 75. percentyla.

Można to uprościć w następujący sposób: co najmniej 75 procent zarejestrowanych wizyt powinno spełniać wymagany próg. Dzięki temu pojedynczy użytkownik z wyjątkowo szybkim urządzeniem nie przesądza o wyniku całej strony.

Urządzenia mobilne i komputery są analizowane osobno. Strona może więc przechodzić Core Web Vitals na komputerach, ale nie przechodzić ich na telefonach.

Czym różnią się dane laboratoryjne od danych rzeczywistych?

To jedno z najważniejszych rozróżnień podczas analizy Core Web Vitals.

Dane laboratoryjne

Dane laboratoryjne powstają podczas kontrolowanego testu. Narzędzie uruchamia stronę na symulowanym urządzeniu, przy określonej mocy procesora i prędkości połączenia.

Tak działa między innymi Lighthouse używany w PageSpeed Insights. Test laboratoryjny jest bardzo przydatny podczas diagnozowania problemów, ponieważ można go powtarzać po każdej zmianie i porównywać wyniki.

Nie pokazuje jednak wszystkich sytuacji, z którymi spotykają się prawdziwi użytkownicy. Jeden syntetyczny test nie odtwarza tysięcy różnych telefonów, sieci, lokalizacji, konfiguracji przeglądarki i sposobów korzystania ze strony.

Dane rzeczywistych użytkowników

Dane terenowe, nazywane również danymi rzeczywistymi lub field data, pochodzą z prawdziwych wizyt użytkowników Chrome i są gromadzone w Chrome User Experience Report.

Obejmują różne:

• urządzenia,
• prędkości połączenia,
• lokalizacje,
• wersje przeglądarek,
• czasy trwania wizyt,
• sposoby korzystania ze strony.

To właśnie dane rzeczywistych użytkowników są podstawą oceny Core Web Vitals widocznej w PageSpeed Insights i Google Search Console.

Jeżeli test laboratoryjny pokazuje świetny wynik, ale dane użytkowników są słabe, nie zakładam, że narzędzie się myli. Szukam różnicy pomiędzy warunkami testowymi a rzeczywistymi wizytami.

Dlaczego PageSpeed pokazuje dwa różne zestawy wyników?

PageSpeed Insights łączy dwa rodzaje informacji.

W górnej części raportu mogą znajdować się dane rzeczywistych użytkowników. Pokazują one historyczne doświadczenia z ostatniego okresu pomiarowego.

Niżej znajduje się test laboratoryjny Lighthouse, który jest wykonywany w momencie uruchomienia analizy.

Wyniki mogą się różnić, ponieważ:

• pochodzą z innych źródeł,
• obejmują inny okres,
• korzystają z innych urządzeń i warunków sieciowych,
• test laboratoryjny analizuje pojedyncze uruchomienie,
• dane rzeczywiste obejmują wiele wizyt,
• niektóre problemy pojawiają się dopiero po rozpoczęciu interakcji ze stroną,
• baner cookies może wyglądać inaczej dla nowego i powracającego użytkownika,
• pamięć podręczna może przyspieszać kolejne wizyty.

Możliwa jest więc sytuacja, w której Lighthouse pokazuje 95 punktów, ale strona nie przechodzi Core Web Vitals. Możliwa jest także sytuacja odwrotna: pojedynczy test laboratoryjny wypada słabo, podczas gdy dane większości prawdziwych użytkowników pozostają dobre.

Czy 100 punktów w PageSpeed oznacza idealną stronę?

Nie. Wynik od 0 do 100 widoczny w części laboratoryjnej jest syntetyczną oceną Lighthouse. Nie jest tym samym co ocena Core Web Vitals.

Sto punktów nie oznacza, że:

• strona będzie szybka dla każdego użytkownika,
• nie występują problemy po wykonaniu interakcji,
• proces zakupowy jest wygodny,
• serwer zawsze odpowiada prawidłowo,
• każda podstrona działa tak samo,
• strona jest dobrze zaprojektowana,
• treść ma wysoką jakość,
• SEO jest prawidłowo wdrożone.

Dążenie do 100 punktów za wszelką cenę może być błędem. Czasami ostatnie kilka punktów wymaga usunięcia funkcji potrzebnej biznesowo, rezygnacji z analityki albo wykonania kosztownej przebudowy dającej użytkownikowi niemal niezauważalną różnicę.

Podczas optymalizacji oceniam nie tylko możliwy wzrost wyniku, ale również koszt, ryzyko i wpływ zmiany na działanie serwisu.

Dlaczego wynik zmienia się pomiędzy kolejnymi testami?

Test PageSpeed nie musi za każdym razem zwracać identycznego wyniku. Nawet kontrolowane środowisko nie eliminuje wszystkich zmiennych.

Na rezultat mogą wpływać:

• chwilowe obciążenie serwera,
• czas odpowiedzi zewnętrznego API,
• szybkość pobierania fontów,
• działanie skryptów analitycznych,
• reklamy i osadzone materiały,
• stan pamięci podręcznej,
• różny czas wykonania JavaScriptu,
• dynamiczna zawartość strony.

Nie wyciągam więc daleko idących wniosków z jednego testu. Wykonuję kilka pomiarów, szukam powtarzalnych problemów i porównuję je z danymi rzeczywistych użytkowników.

Dlaczego po optymalizacji wynik Core Web Vitals nie zmienia się od razu?

Dane rzeczywistych użytkowników nie są generowane na żądanie po każdej zmianie. Obejmują ruch z dłuższego okresu, dlatego stare, słabsze doświadczenia przez pewien czas nadal wpływają na ocenę.

Po wdrożeniu poprawki mogę natychmiast sprawdzić stronę za pomocą testów laboratoryjnych. Raport oparty na danych rzeczywistych potrzebuje jednak nowych wizyt i czasu na zastąpienie wcześniejszych pomiarów.

Nie oznacza to, że poprawka nie działa. Trzeba odróżnić:

• natychmiastowy wynik testu po zmianie,
• historyczny raport doświadczeń użytkowników,
• moment ponownej oceny grupy adresów w Search Console.

Przy małym ruchu problemem może być również brak wystarczającej liczby danych. Wtedy PageSpeed może pokazywać wyłącznie dane dla całej domeny albo nie wyświetlać części rzeczywistej w ogóle.

Core Web Vitals a szybkość strony

Core Web Vitals są związane z wydajnością, ale nie są pełnym pomiarem szybkości strony.

Nie odpowiadają bezpośrednio na wszystkie pytania, takie jak:

• jak szybko odpowiedział serwer,
• ile waży cała strona,
• ile zapytań sieciowych wykonano,
• jak długo trwa pełne pobranie zasobów,
• ile czasu zajmuje wykonanie każdego skryptu,
• czy baza danych działa prawidłowo.

Dlatego podczas diagnostyki korzystam również z dodatkowych wskaźników.

TTFB

Time to First Byte opisuje czas oczekiwania na pierwszy bajt odpowiedzi serwera. Słaby TTFB może opóźnić wszystkie kolejne etapy ładowania, w tym LCP.

Przyczyną mogą być między innymi:

• wolny hosting,
• przeciążony serwer,
• ciężkie zapytania do bazy danych,
• brak cache strony,
• duża liczba operacji wykonywanych przed wygenerowaniem HTML,
• zewnętrzne połączenia blokujące odpowiedź,
• nieprawidłowa konfiguracja DNS lub CDN.

FCP

First Contentful Paint mierzy moment pojawienia się pierwszego elementu treści. Może to być tekst, obraz albo inny widoczny fragment strony.

FCP nie jest obecnie Core Web Vital, ale pomaga ocenić, czy użytkownik szybko otrzymuje pierwszy sygnał, że strona zaczęła się wyświetlać.

TBT

Total Blocking Time mierzy w warunkach laboratoryjnych czas, w którym główny wątek przeglądarki jest blokowany przez długie zadania.

TBT może pomóc podczas szukania problemów prowadzących do słabego INP, chociaż nie jest jego bezpośrednim odpowiednikiem. INP wymaga interakcji prawdziwych użytkowników, a laboratoryjny test nie odtworzy automatycznie wszystkich działań wykonywanych podczas wizyty.

Jak poprawić LCP?

Optymalizacja LCP zaczyna się od ustalenia, który element został uznany za największą treść i na jakim etapie pojawia się opóźnienie.

Najczęstsze przyczyny słabego LCP to:

• wolna odpowiedź serwera,
• duży obraz w sekcji hero,
• ładowanie głównego obrazu z opóźnieniem,
• umieszczenie obrazu wyłącznie jako tła CSS,
• zasoby blokujące renderowanie,
• duża liczba stylów i skryptów w nagłówku,
• font blokujący wyświetlenie tekstu,
• baner budowany dopiero przez JavaScript,
• nieprawidłowo skonfigurowane lazy loading,
• przekierowania przed otwarciem strony.

Typowym błędem jest objęcie głównego obrazu mechanizmem leniwego ładowania. Lazy loading jest przydatny dla grafik znajdujących się niżej, ale element potrzebny natychmiast na pierwszym ekranie nie powinien czekać, aż przeglądarka uzna go za wymagający pobrania.

Nie wystarczy również skompresować wszystkich zdjęć. Jeśli przyczyną jest wolny serwer albo skrypt blokujący renderowanie, zmniejszenie grafiki poprawi tylko fragment całego procesu.

Jak poprawić INP?

Słaby INP najczęściej oznacza, że przeglądarka jest zbyt zajęta, aby szybko odpowiedzieć na działanie użytkownika.

Główny wątek może być blokowany przez:

• duże pliki JavaScript,
• wiele dodatków wykonujących podobne operacje,
• ciężkie animacje,
• rozbudowane skrypty śledzące,
• dynamiczne filtrowanie dużej liczby elementów,
• nieefektywną obsługę zdarzeń,
• masowe zmiany w strukturze strony,
• skomplikowane obliczenia wykonywane po kliknięciu,
• dodatki do koszyka, wariantów lub personalizacji produktu.

Przykładem może być mobilne menu. Użytkownik dotyka ikony, ale przeglądarka w tym samym momencie wykonuje inne zadania. Menu otwiera się dopiero po wyraźnym opóźnieniu.

Innym przykładem jest wybór wariantu produktu. Po kliknięciu koloru wtyczka przelicza cenę, zmienia zdjęcie, aktualizuje dostępność, sprawdza dodatkowe reguły i uruchamia kilka zewnętrznych skryptów. Jeżeli wszystkie operacje blokują główny wątek, interfejs może przestać odpowiadać.

Poprawa INP często wymaga analizy konkretnych interakcji, a nie wyłącznie strony podczas ładowania.

Jak poprawić CLS?

W przypadku CLS najpierw szukam elementów, które zmieniają położenie po rozpoczęciu renderowania.

Podstawowe działania obejmują:

• ustawienie wymiarów obrazów i materiałów wideo,
• zarezerwowanie miejsca na reklamy i osadzone elementy,
• unikanie wstawiania nowych treści nad już widoczną zawartością,
• prawidłowe ładowanie fontów,
• rezerwowanie przestrzeni na komunikaty,
• kontrolowanie pasków promocyjnych i banerów cookies,
• ograniczenie zmian wysokości karuzel i sliderów,
• ustawienie stabilnych proporcji miniaturek produktów.

Nie każde przesunięcie jest błędem. Jeżeli użytkownik kliknie rozwijaną sekcję i treść poniżej przesunie się w dół, jest to oczekiwana konsekwencja interakcji.

Problemem są przesunięcia niespodziewane, nad którymi użytkownik nie ma kontroli.

Core Web Vitals w WordPressie

WordPress może osiągać bardzo dobre wyniki, ale sam system nie gwarantuje wydajności. Końcowy rezultat zależy od hostingu, motywu, wtyczek, sposobu budowy szablonów, treści oraz konfiguracji cache.

Podczas audytów WordPressa regularnie spotykam:

• kilka nakładających się systemów cache,
• ciężki motyw ładujący funkcje nieużywane na danej stronie,
• wtyczki do optymalizacji skonfigurowane na zasadzie włączenia wszystkich opcji,
• skrypty ładowane globalnie mimo użycia tylko na jednej podstronie,
• duplikaty bibliotek JavaScript,
• ogromne zdjęcia przesyłane bez przygotowania,
• fonty pobierane w wielu odmianach i grubościach,
• Elementorowe sekcje z dużą liczbą zagnieżdżonych kontenerów,
• animacje uruchamiane jednocześnie na wielu elementach,
• dodatki marketingowe blokujące główny wątek.

Samo zainstalowanie wtyczki optymalizacyjnej nie oznacza, że strona została zoptymalizowana. Nieprawidłowe opóźnianie JavaScriptu może uszkodzić menu, formularze, analitykę, koszyk albo zgodę cookies.

Również łączenie i minimalizowanie plików nie zawsze jest najlepszym rozwiązaniem. Nowoczesne protokoły, cache przeglądarki i sposób wykorzystania zasobów mogą sprawić, że mechaniczne łączenie wszystkiego przyniesie niewielką korzyść albo wręcz pogorszy działanie.

Core Web Vitals w Elementorze

Elementor pozwala budować rozbudowane strony bez ręcznego przygotowywania każdego szablonu, ale łatwo stworzyć projekt znacznie cięższy, niż wymaga tego efekt wizualny.

Problemy pojawiają się najczęściej, gdy:

• prosta sekcja składa się z wielu zagnieżdżonych kontenerów,
• każdy element posiada osobną animację wejścia,
• kilka dodatków rozszerza ten sam zestaw widgetów,
• duże obrazy są ustawiane jako tło sekcji,
• slider znajduje się w pierwszym ekranie,
• osobne wersje sekcji dla telefonu i komputera są ładowane jednocześnie,
• globalne style nie są wykorzystywane,
• widgety dołączają własne biblioteki na każdej podstronie.

Nie oznacza to, że każdą stronę w Elementorze trzeba przebudować w ręcznie napisanym kodzie. Najpierw sprawdzam, które elementy rzeczywiście powodują problem. Czasami wystarczy zmienić sposób budowy hero, ograniczyć dodatki albo przestać ładować nieużywane zasoby.

Core Web Vitals w WooCommerce

WooCommerce jest bardziej wymagający niż zwykła strona informacyjna. Sklep korzysta z dynamicznych danych, sesji użytkownika, koszyka, wariantów, filtrów, płatności i integracji zewnętrznych.

Na wynik mogą wpływać między innymi:

• duża liczba zapytań do bazy danych,
• rozbudowane warianty produktów,
• filtry AJAX,
• dynamiczny mini-koszyk,
• wtyczki cenowe i rabatowe,
• programy lojalnościowe,
• personalizatory produktów,
• systemy opinii,
• integracje płatności i dostawy,
• skrypty marketingowe,
• duże galerie zdjęć.

Optymalizacja samej strony głównej nie wystarcza. Trzeba oddzielnie sprawdzić:

• listę produktów,
• kategorię,
• wyszukiwarkę,
• kartę produktu prostego,
• produkt wariantowy,
• koszyk,
• checkout,
• panel klienta.

Każdy z tych widoków korzysta z innych mechanizmów i może mieć zupełnie inny problem.

Czy cache rozwiązuje problemy Core Web Vitals?

Cache może znacząco skrócić czas odpowiedzi serwera i ograniczyć liczbę operacji wykonywanych podczas generowania strony. Jest bardzo ważnym elementem optymalizacji, ale nie rozwiązuje wszystkich problemów.

Cache nie naprawi automatycznie:

• ogromnego obrazu LCP,
• przesuwającego się banera,
• ciężkiego JavaScriptu,
• zablokowanego głównego wątku,
• źle działającej interakcji,
• niepotrzebnych skryptów zewnętrznych,
• błędnej konstrukcji szablonu.

Może się też zdarzyć, że strona z cache działa dobrze dla niezalogowanych użytkowników, ale bardzo wolno w panelu klienta, koszyku albo podczas korzystania z funkcji wyłączonych z pamięci podręcznej.

Czy CDN poprawia Core Web Vitals?

CDN może skrócić drogę pomiędzy użytkownikiem a zasobami strony, odciążyć serwer i przyspieszyć pobieranie obrazów, stylów oraz skryptów.

Największą korzyść może przynieść serwisom obsługującym użytkowników z wielu regionów. Nie jest jednak automatycznym lekarstwem na wszystkie problemy.

CDN nie naprawi złego INP wynikającego z ciężkiego JavaScriptu ani CLS spowodowanego brakiem wymiarów obrazów. Nie rozwiąże również problemu wolnej bazy danych, jeśli każda strona musi być dynamicznie wygenerowana przez serwer źródłowy.

Jak Core Web Vitals wpływa na SEO?

Core Web Vitals są częścią szerszej oceny doświadczenia strony. Dobre wyniki mogą wspierać widoczność, ale nie zastępują jakości treści, dopasowania do zapytania, autorytetu serwisu, prawidłowego indeksowania i linkowania.

Strona nie zajmie automatycznie wysokiej pozycji tylko dlatego, że ma świetny LCP, INP i CLS. Może być technicznie szybka, ale nie odpowiadać na potrzeby użytkownika.

Z drugiej strony bardzo słabe działanie może utrudniać korzystanie z wartościowej treści. Jeżeli użytkownik długo czeka na główny element, interfejs nie reaguje, a układ przeskakuje podczas czytania, jakość doświadczenia spada.

Nie traktuję więc Core Web Vitals jako magicznego sposobu na wzrost pozycji. Traktuję je jako część technicznego fundamentu strony.

Jak Core Web Vitals wpływa na sprzedaż?

Wpływ na biznes nie wynika wyłącznie z algorytmu wyszukiwarki. Wynika przede wszystkim z zachowania użytkowników.

Wolna lub niestabilna strona może powodować:

• opuszczanie witryny przed wyświetleniem oferty,
• przypadkowe kliknięcia,
• wielokrotne dodanie produktu do koszyka,
• porzucenie formularza,
• rezygnację z wyboru wariantu,
• problemy z filtrowaniem produktów,
• spadek zaufania do sklepu,
• większą liczbę pytań do obsługi klienta.

Użytkownik nie musi wiedzieć, czym jest INP albo CLS. Po prostu czuje, że strona działa źle.

W przypadku reklamy płatnej problem jest jeszcze bardziej kosztowny. Firma płaci za sprowadzenie użytkownika, ale słaba wydajność utrudnia mu wykonanie działania. Budżet reklamowy jest wtedy kierowany do serwisu, który sam ogranicza własną skuteczność.

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

Optymalizacja tylko strony głównej

Strona główna może mieć świetny wynik, podczas gdy kategorie, produkty i formularze działają znacznie gorzej. Różne typy podstron trzeba analizować oddzielnie.

Koncentrowanie się wyłącznie na liczbie punktów

Wynik Lighthouse jest pomocny, ale nie zastępuje danych rzeczywistych użytkowników ani testowania funkcji.

Włączenie wszystkich opcji wtyczki optymalizacyjnej

Opóźnianie i przenoszenie każdego skryptu może zwiększyć wynik testu, a jednocześnie uszkodzić ważne elementy strony.

Usuwanie funkcji bez oceny biznesowej

Skrypt analityczny, czat albo system opinii może obciążać stronę, ale jego usunięcie nie zawsze jest właściwą decyzją. Najpierw analizuję jego znaczenie, konfigurację i możliwość lżejszego wdrożenia.

Testowanie tylko na szybkim komputerze

Wydajny sprzęt może ukryć problemy z JavaScriptem i czasem reakcji. Stronę trzeba sprawdzać również w warunkach zbliżonych do słabszych urządzeń.

Brak kontroli po aktualizacjach

Aktualizacja motywu, wtyczki, systemu cookies albo kodu analitycznego może ponownie pogorszyć wyniki. Optymalizacja nie jest jednorazowym stanem zapisanym na zawsze.

Poprawianie objawu zamiast przyczyny

Jeżeli LCP jest słaby z powodu serwera, kompresowanie kolejnych ikon nie rozwiąże głównego problemu. Jeżeli INP psuje skrypt wariantów, optymalizacja zdjęć nie przyspieszy interakcji.

Jak samodzielnie sprawdzić Core Web Vitals?

Podstawową kontrolę można rozpocząć od kilku narzędzi.

PageSpeed Insights

Pozwala sprawdzić dane rzeczywistych użytkowników, jeśli są dostępne, oraz wykonać test laboratoryjny. Warto zwrócić uwagę, czy raport dotyczy konkretnego adresu, czy całej domeny.

Google Search Console

Raport Core Web Vitals grupuje podobne adresy i pokazuje, które rodzaje podstron mają problemy. Dzięki temu można zauważyć, że błąd dotyczy na przykład całego szablonu produktu, a nie jednego adresu.

Chrome DevTools

Panel wydajności umożliwia dokładniejszą analizę ładowania, przesunięć układu, zadań JavaScript i interakcji. Jest szczególnie przydatny przy diagnozowaniu problemów z INP.

Podczas podstawowej kontroli warto zadać sobie pytania:

1. Czy raport zawiera dane prawdziwych użytkowników?
2. Czy analizuję telefon, czy komputer?
3. Który z trzech wskaźników nie przechodzi oceny?
4. Jaki element jest raportowany jako LCP?
5. Czy problem dotyczy pojedynczego adresu, czy całej grupy?
6. Czy wynik powtarza się w kilku testach?
7. Czy strona zachowuje się źle także podczas rzeczywistej wizyty?
8. Czy problem pojawia się podczas ładowania, czy dopiero po interakcji?
9. Czy użytkownicy zalogowani i niezalogowani otrzymują ten sam widok?
10. Czy po ostatniej zmianie nie została uszkodzona żadna funkcja?

Jak wygląda prawidłowy proces optymalizacji?

Skuteczna optymalizacja nie zaczyna się od przypadkowego instalowania kolejnych dodatków.

Najpierw:

1. Określam problem – sprawdzam, który wskaźnik jest słaby i na jakich urządzeniach.
2. Rozdzielam dane rzeczywiste od laboratoryjnych – ustalam, czy problem dotyczy prawdziwych użytkowników, pojedynczego testu, czy obu źródeł.
3. Identyfikuję szablony – sprawdzam, czy problem występuje na stronie głównej, produktach, wpisach, kategoriach czy całym serwisie.
4. Szukam przyczyny – analizuję serwer, zasoby, obrazy, fonty, skrypty, układ i interakcje.
5. Wdrażam jedną grupę zmian – dzięki temu wiem, co rzeczywiście przyniosło efekt.
6. Testuję funkcje – sprawdzam menu, formularze, koszyk, płatności, analitykę i zgodę cookies.
7. Porównuję wyniki – wykonuję kilka testów laboratoryjnych i obserwuję nowe dane użytkowników.
8. Monitoruję regresje – kontroluję stronę po aktualizacjach i większych zmianach.

Taki proces zajmuje więcej czasu niż kliknięcie kilku przełączników, ale pozwala poprawić rzeczywiste działanie bez przypadkowego uszkadzania serwisu.

Czy każda strona musi osiągać idealne wyniki?

Każda strona powinna dążyć do dobrego doświadczenia użytkowników, ale nie każda będzie miała identyczne możliwości i ograniczenia.

Prosta strona informacyjna może osiągnąć bardzo wysokie wyniki stosunkowo niewielkim kosztem. Rozbudowany sklep z personalizatorem, filtrowaniem, analityką, płatnościami i integracjami wykonuje znacznie więcej pracy.

Nie oznacza to, że słabe wyniki trzeba zaakceptować. Oznacza jedynie, że optymalizacja powinna uwzględniać funkcję strony i znaczenie poszczególnych mechanizmów.

Najważniejsze jest usunięcie rzeczywistych wąskich gardeł, a nie poświęcanie potrzebnych funkcji dla kilku dodatkowych punktów w syntetycznym teście.

Najważniejsze wnioski

• Core Web Vitals mierzą szybkość pojawienia się głównej treści, responsywność interfejsu i stabilność układu.
• Obecne podstawowe wskaźniki to LCP, INP i CLS.
• Dobry LCP wynosi maksymalnie 2,5 sekundy.
• Dobry INP wynosi maksymalnie 200 milisekund.
• Dobry CLS wynosi maksymalnie 0,1.
• Ocena opiera się na 75. percentylu doświadczeń użytkowników.
• Dane laboratoryjne pomagają diagnozować problemy, ale nie zastępują danych z prawdziwych wizyt.
• Wynik Lighthouse od 0 do 100 nie jest tym samym co ocena Core Web Vitals.
• Cache, CDN i kompresja obrazów mogą pomóc, ale nie rozwiązują każdego rodzaju problemu.
• W WordPressie i WooCommerce trzeba analizować motyw, wtyczki, serwer, treści oraz konkretne interakcje.
• Dobre Core Web Vitals wspierają doświadczenie użytkownika, ale nie zastępują wartościowej treści i prawidłowego SEO.
• Optymalizacja powinna poprawiać realne działanie strony, a nie wyłącznie wynik pojedynczego testu.

Nie wiesz, dlaczego Twoja strona nie przechodzi Core Web Vitals?

Podczas audytu sprawdzam dane rzeczywistych użytkowników, wyniki laboratoryjne, konfigurację serwera, sposób ładowania zasobów oraz działanie najważniejszych szablonów i funkcji.

Mogę wskazać, który element odpowiada za słaby LCP, jakie interakcje pogarszają INP i skąd biorą się nieoczekiwane przesunięcia wpływające na CLS.

Nie zakładam automatycznie, że potrzebna jest wymiana motywu, usunięcie wszystkich wtyczek albo przebudowa całej strony. Najpierw ustalam prawdziwą przyczynę problemu i oddzielam zmiany, które rzeczywiście poprawią doświadczenie użytkownika, od działań wykonywanych wyłącznie dla liczby w raporcie.

DIGIKROM

Zobacz pełny biogram