- Czym naprawdę są Core Web Vitals i gdzie najczęściej zaczyna się błąd interpretacji
- Dlaczego wynik z Lighthouse nie zawsze oznacza realny problem biznesowy
- Jak czytać PageSpeed Insights, Search Console i CrUX bez wyciągania złych wniosków
- Najczęstsze błędy wpływające na LCP, czyli dlaczego największy element ładuje się za wolno
- Za ciężki obraz hero, brak preloadu i zła strategia optymalizacji obrazów
- Wolny serwer, wysoki TTFB i źle ustawiony cache
- CSS i fonty blokujące renderowanie pierwszego ekranu
- Najczęstsze błędy wpływające na INP, czyli dlaczego strona reaguje z opóźnieniem
- Przeciążony JavaScript main thread i zbyt duża hydracja
- Skrypty zewnętrzne, tagi marketingowe i funkcje dodawane bez kontroli
- Ciężkie komponenty UI, filtry, wyszukiwarki i niska wydajność mobile
- Najczęstsze błędy wpływające na CLS oraz jak prowadzić skuteczny audyt i monitoring
- Brak zarezerwowanego miejsca na obrazy, iframe’y, reklamy i bannery
- Fonty, komunikaty cookies i elementy dynamiczne dodawane po czasie
- Jak prowadzić audyt Core Web Vitals, ustalać priorytety i nie popsuć strony po wdrożeniach
Najczęstsze błędy Core Web Vitals i jak je naprawić to temat, który dziś dotyczy nie tylko developerów, ale również właścicieli firm, specjalistów SEO i osób odpowiedzialnych za sprzedaż online. W tym artykule wyjaśnię, czym są Core Web Vitals, jak poprawnie czytać wyniki narzędzi takich jak PageSpeed Insights i Lighthouse, które problemy naprawdę wpływają na użytkownika oraz jak podejść do optymalizacji bez obsesji na punkcie wyniku 100/100.
Czym naprawdę są Core Web Vitals i gdzie najczęściej zaczyna się błąd interpretacji
Core Web Vitals, czyli podstawowe wskaźniki internetowe, to zestaw metryk Google opisujących trzy różne obszary doświadczenia użytkownika. Largest Contentful Paint mierzy odczuwalną szybkość ładowania najważniejszego elementu widocznego na pierwszym ekranie, Interaction to Next Paint pokazuje responsywność strony po interakcji, a Cumulative Layout Shift ocenia stabilność wizualną interfejsu. Pierwszy częsty błąd polega na tym, że wszystkie problemy wydajnościowe wrzuca się do jednego worka. Tymczasem słaby LCP oznacza zwykle inny problem niż słaby INP czy wysoki CLS, dlatego naprawa musi wynikać z diagnozy, a nie z ogólnego hasła „strona jest wolna”.
Drugim błędem jest traktowanie wyniku z testu jako prawdy absolutnej. PageSpeed Insights pokazuje zarówno dane laboratoryjne, czyli lab data, jak i dane rzeczywistych użytkowników, czyli field data. Te pierwsze pochodzą z kontrolowanego testu i są świetne do diagnozowania, ale nie opisują pełnego obrazu zachowania strony w różnych krajach, na różnych telefonach i połączeniach internetowych. Dane rzeczywistych użytkowników pochodzą z Chrome UX Report, czyli CrUX, i to one lepiej pokazują, co faktycznie widzą odwiedzający. Jeżeli ktoś poprawia tylko to, co świeci się na czerwono w pojedynczym teście Lighthouse, może łatwo zoptymalizować raport, a nie doświadczenie użytkownika.
Masz pytania? Porozmawiajmy o Twoim marketingu
Skontaktuj się ze mną!
Katarzyna Toboła
Dlaczego wynik z Lighthouse nie zawsze oznacza realny problem biznesowy
Lighthouse jest bardzo dobrym narzędziem diagnostycznym, ale nie jest pełnym obrazem realnej wydajności strony. Test syntetyczny odbywa się w określonych warunkach i na konkretnym typie emulowanego urządzenia. To oznacza, że wynik może się zmieniać między uruchomieniami, a strona z oceną 70 może działać odczuwalnie dobrze dla użytkowników, jeśli najważniejsze zasoby krytyczne ładują się sprawnie i interfejs pozostaje responsywny. Z drugiej strony strona z pozornie wysoką oceną może mieć problemy na prawdziwych urządzeniach mobilnych, jeśli użytkownik trafia na ciężki checkout, dynamiczne bannery lub skrypty marketingowe uruchamiane dopiero po wejściu w interakcję.
W praktyce sensowna analiza zaczyna się od porównania lab data z field data. Jeżeli CrUX pokazuje problem z LCP na stronie głównej, a laboratoryjnie nie wygląda to źle, warto sprawdzić wpływ lokalizacji użytkowników, jakości hostingu, odpowiedzi serwera, wariantów urządzeń mobilnych i czasu ładowania obrazów hero. Jeżeli natomiast field data jest dobre, a test laboratoryjny wskazuje ostrzeżenia drugorzędne, nie zawsze trzeba ruszać architekturę strony. Wydajność powinna wspierać UX, konwersję i SEO techniczne, a nie być sztuką dla sztuki.
Jak czytać PageSpeed Insights, Search Console i CrUX bez wyciągania złych wniosków
W Google Search Console raport Core Web Vitals grupuje adresy według podobnych problemów i typów szablonów. To cenne, bo pozwala zobaczyć, że kłopot zwykle nie dotyczy jednej podstrony, tylko całej klasy stron, na przykład kart produktów, wpisów blogowych albo stron kategorii. Wielu właścicieli serwisów popełnia błąd, analizując wyłącznie stronę główną, podczas gdy największy ruch i przychód generują zupełnie inne szablony. Z kolei CrUX raportuje dane z 28 dni, więc efekt wdrożenia nie jest widoczny od razu. Jeśli ktoś po dwóch dniach uznaje, że optymalizacja nie zadziałała, zwykle po prostu zbyt wcześnie patrzy na field data.
Warto również rozumieć różnicę między wskaźnikami dodatkowymi a samymi Core Web Vitals. FCP, TTFB i TBT są bardzo użyteczne diagnostycznie. TTFB bywa sygnałem problemów po stronie hostingu, backendu, bazy danych lub cache serwera. TBT często podpowiada, że główny wątek JavaScript jest przeciążony, co może później przełożyć się na słaby INP. Te metryki nie zastępują jednak analizy LCP, INP i CLS, tylko pomagają dojść do źródła problemu.
Najczęstsze błędy wpływające na LCP, czyli dlaczego największy element ładuje się za wolno
LCP najczęściej psuje się przez połączenie kilku czynników: wolną odpowiedź serwera, ciężki obraz hero, blokowanie renderowania przez CSS i JavaScript, brak priorytetyzacji zasobów oraz nieoptymalne ładowanie fontów. To właśnie tutaj pojawia się wiele najbardziej kosztownych błędów wydajnościowych, bo użytkownik widzi pusty lub niekompletny pierwszy ekran i ma wrażenie, że strona działa wolno, nawet jeśli reszta treści dociąga się już sprawnie. W kontekście mobile performance każdy dodatkowy transfer, każdy ciężki framework i każdy niepotrzebny zasób nad linią załamania ekranu może wydłużać odczucie oczekiwania.
Za ciężki obraz hero, brak preloadu i zła strategia optymalizacji obrazów
Bardzo częsty błąd to używanie ogromnych grafik w sekcji hero, które wyglądają dobrze na monitorze projektanta, ale są zbyt ciężkie dla smartfona użytkownika. Skuteczna optymalizacja obrazów nie polega wyłącznie na kompresji. Trzeba zadbać o właściwe wymiary, srcset i sizes, aby urządzenie mobilne nie pobierało obrazu przeznaczonego dla desktopu. W wielu przypadkach warto stosować format WebP lub format AVIF, choć zawsze należy sprawdzić kompromis między wagą pliku, jakością i kompatybilnością. Jeżeli obraz jest elementem LCP, nie powinien być leniwie ładowany. Lazy loading ma sens dla treści poniżej pierwszego ekranu, ale dla obrazu kluczowego może tylko pogorszyć szybkość ładowania strony.
W praktyce poprawę daje także preload obrazu LCP oraz właściwe ustawienie priorytetów pobierania. Jeśli przeglądarka zbyt późno odkrywa najważniejszy zasób, nawet dobrze skompresowany plik będzie ładował się za późno. Dotyczy to szczególnie stron budowanych na nowoczesnych frameworkach, gdzie struktura DOM i renderowanie strony są zależne od JavaScript. Gdy obraz hero pojawia się dopiero po wykonaniu skryptów, LCP rośnie nie dlatego, że obraz jest wielki, ale dlatego, że przeglądarka za późno dowiaduje się o jego istnieniu.
Wolny serwer, wysoki TTFB i źle ustawiony cache
Jeżeli pierwsze bajty odpowiedzi przychodzą z opóźnieniem, przeglądarka nie może rozpocząć kolejnych etapów renderowania. Wysoki TTFB bywa skutkiem słabego hostingu, przeciążonej aplikacji, nieoptymalnych zapytań do bazy danych, braku cache serwera albo źle skonfigurowanego reverse proxy. Tu często pojawia się błąd strategiczny: firmy inwestują w frontend, a ignorują backend i infrastrukturę. Tymczasem nawet najlepsza minifikacja plików nie naprawi strony, która zaczyna odpowiadać po kilkuset milisekundach lub dłużej w warunkach obciążenia.
Rozwiązaniem nie zawsze jest natychmiastowa migracja. Czasem wystarczy poprawić cache przeglądarki, cache serwera, włączyć CDN, skrócić ścieżkę generowania HTML, zoptymalizować bazę danych albo usunąć kosztowne fragmenty logiki z pierwszego requestu. W e-commerce szczególnie ważne jest rozróżnienie treści, które można cachować agresywnie, od tych, które muszą być personalizowane. Dobrze ustawiony cache może znacząco obniżyć obciążenie aplikacji bez utraty funkcjonalności koszyka czy konta użytkownika.
CSS i fonty blokujące renderowanie pierwszego ekranu
Kolejny klasyczny problem to blokowanie renderowania przez zbyt duże arkusze stylów. Jeśli strona ładuje cały framework CSS, wiele nieużywanego kodu i kilka dodatków wizualnych przed pokazaniem podstawowej treści, critical rendering path staje się niepotrzebnie długi. Warto rozważyć critical CSS dla elementów pierwszego ekranu, odroczenie mniej istotnych stylów oraz usuwanie nieużywanego kodu. Nie chodzi o ryzykowne ręczne kasowanie fragmentów, ale o kontrolowaną optymalizację CSS z testami regresji.
Podobny wpływ mają fonty. Zbyt wiele krojów i wariantów pogarsza wydajność, a nieprzemyślana konfiguracja może wpływać także na CLS. Przydatne są preload najważniejszych plików fontów, font-display oraz ograniczenie liczby wariantów grubości. Trzeba jednak zachować równowagę między brandingiem a techniką. Dla części marek typografia jest elementem tożsamości, ale nawet wtedy da się poprawić szybkość poprzez właściwe formaty, subsety znaków i lepszą kolejność ładowania.
Najczęstsze błędy wpływające na INP, czyli dlaczego strona reaguje z opóźnieniem
INP jest dziś jednym z najtrudniejszych obszarów optymalizacji, bo opisuje nie samo ładowanie, lecz to, jak szybko interfejs reaguje na kliknięcie, tapnięcie czy wpisywanie danych. Użytkownik może zobaczyć stronę szybko, ale jeśli po naciśnięciu przycisku nic się nie dzieje, doświadczenie nadal jest słabe. To częsty problem nowoczesnych aplikacji frontendowych, serwisów z rozbudowaną analityką, e-commerce z wieloma integracjami oraz stron opartych o ciężki JavaScript. Wysoki INP oznacza zwykle, że główny wątek przeglądarki jest zablokowany lub przeładowany zadaniami.
Przeciążony JavaScript main thread i zbyt duża hydracja
Najczęstszy błąd to nadmiar pracy wykonywanej przez JavaScript po załadowaniu widoku. W aplikacjach typu Single Page Application użytkownik często dostaje interfejs, który wygląda na gotowy, ale w praktyce jeszcze się „uaktywnia”. Ten proces, nazywany hydration, może być kosztowny, jeśli komponentów jest dużo, stan aplikacji jest rozbudowany, a urządzenie użytkownika jest słabsze. Właśnie wtedy pojawiają się opóźnienia po kliknięciu, zacinające się formularze i wolne menu mobilne.
Zamiast bezrefleksyjnie usuwać skrypty, lepiej ocenić architekturę. Czasem rozwiązaniem będzie częściowa hydratacja, code splitting, opóźnienie inicjalizacji mniej ważnych komponentów lub przeniesienie części logiki bliżej serwera. W niektórych projektach sensowny jest server-side rendering albo static site generation, bo skracają czas do pokazania i użycia treści. Nie oznacza to jednak, że każda strona musi zmieniać stack technologiczny. Często największy efekt daje po prostu ograniczenie pracy wykonywanej na starcie oraz rozbijanie długich zadań na mniejsze.
Skrypty zewnętrzne, tagi marketingowe i funkcje dodawane bez kontroli
Drugi typowy problem to zewnętrzne skrypty analityczne, reklamowe, czaty, popupy, testy A/B, mapy, widgety opinii i integracje marketing automation. Każdy z tych elementów może być uzasadniony biznesowo, ale razem potrafią bardzo obciążyć JavaScript main thread. Błąd polega zwykle na braku priorytetyzacji. Zespół dodaje nowe funkcje i tagi, ale nikt nie sprawdza ich kosztu wydajnościowego na urządzeniach mobilnych. W efekcie przycisk „dodaj do koszyka” reaguje wolniej, wyszukiwarka wewnętrzna się zacina, a checkout robi się frustrujący.
Dobra optymalizacja JavaScript polega na tym, by rozróżnić skrypty krytyczne, funkcjonalne i opcjonalne. Niektóre można ładować po interakcji, inne po zgodzie użytkownika, a jeszcze inne wcale nie muszą występować na każdej podstronie. Audyt tagów bywa jednym z najszybszych sposobów na poprawę INP bez przebudowy frontendu. Ważne jednak, by nie wyłączyć przez przypadek elementów niezbędnych dla pomiaru kampanii, zgodności prawnej czy obsługi procesu zakupu.
Ciężkie komponenty UI, filtry, wyszukiwarki i niska wydajność mobile
Na słabe INP szczególnie narażone są sklepy internetowe i serwisy z rozbudowanym interfejsem. Filtry kategorii, autocomplete w wyszukiwarce, konfiguratory produktów, rozwijane panele, koszyk boczny czy wieloetapowy checkout często wykonują dużo pracy po każdej interakcji. Na desktopie problem może być mało widoczny, ale na przeciętnym smartfonie opóźnienie staje się wyraźne. Dlatego analiza mobile performance powinna być domyślna, a nie dodatkowa.
W takich przypadkach warto profilować zachowanie interfejsu i sprawdzać, które akcje uruchamiają długie zadania, kosztowne reflow albo nadmierne przeliczanie stanu. Pomaga uproszczenie komponentów, debouncing wybranych akcji, wirtualizacja list, ograniczenie liczby jednoczesnych obserwatorów oraz przesunięcie mniej ważnych efektów wizualnych poza krytyczny moment interakcji. Poprawa INP bardzo często nie wynika z jednej magicznej zmiany, tylko z serii małych decyzji projektowych i frontendowych.
Najczęstsze błędy wpływające na CLS oraz jak prowadzić skuteczny audyt i monitoring
CLS odpowiada za stabilność wizualną, czyli za to, czy układ strony nie „skacze” podczas ładowania. To wskaźnik szczególnie ważny z perspektywy użyteczności, bo nawet szybka strona irytuje, jeśli użytkownik chce kliknąć przycisk, a w ostatniej chwili layout się przesuwa. W praktyce błędy CLS często są bagatelizowane, ponieważ nie zawsze są dobrze widoczne w statycznym zrzucie ekranu. Dopiero analiza zachowania strony w czasie pokazuje, jak dynamiczne komponenty, reklamy, fonty i obrazy wpływają na realny odbiór interfejsu.
Brak zarezerwowanego miejsca na obrazy, iframe’y, reklamy i bannery
Najbardziej klasyczny błąd to brak jawnie określonych wymiarów dla obrazów, embedów, playerów wideo i iframe’ów. Gdy przeglądarka nie wie, ile miejsca zarezerwować, układ musi zostać przeliczony po pobraniu zasobu. To samo dotyczy reklam i bannerów ładowanych po czasie. Jeśli kontener nie ma przewidywalnej wysokości albo aplikacja wstawia komunikaty nad istniejącą treść, użytkownik obserwuje przesunięcia, które psują doświadczenie i zwiększają ryzyko błędnych kliknięć.
Naprawa zwykle jest prosta koncepcyjnie, choć wymaga dyscypliny wdrożeniowej. Trzeba rezerwować miejsce na dynamiczne elementy, definiować width i height lub odpowiednie proporcje, projektować placeholdery i unikać wstrzykiwania treści nad już wyświetlonym contentem. W przypadku reklam i komponentów personalizowanych trzeba współpracować nie tylko z developerem, ale też z zespołem biznesowym, bo ich sposób osadzania ma bezpośredni wpływ na stabilność wizualną.
Fonty, komunikaty cookies i elementy dynamiczne dodawane po czasie
CLS potrafią generować również fonty. Jeśli po załadowaniu właściwego kroju długości wierszy i metryki znaków zmieniają się znacząco, tekst może przeskakiwać. Pomagają dobrze dobrane fallbacki, font-display i ograniczenie zmian między fontem zastępczym a docelowym. Podobny problem tworzą paski cookies, sticky bannery, popupy i komunikaty promocyjne pojawiające się natychmiast po wejściu. Jeśli system dodaje je na górze strony bez wcześniejszej rezerwacji miejsca, wynik CLS pogarsza się bardzo szybko.
Warto też pamiętać o dynamicznych komponentach frameworków frontendowych. Karuzele, akordeony, sekcje rekomendacji, moduły „ostatnio oglądane” czy asynchronicznie dociągane recenzje produktów powinny być projektowane tak, aby ich późniejsze pojawienie się nie zmieniało gwałtownie układu. To obszar, w którym optymalizacja wydajności spotyka się bezpośrednio z projektowaniem interfejsu.
Jak prowadzić audyt Core Web Vitals, ustalać priorytety i nie popsuć strony po wdrożeniach
Dobry audyt Core Web Vitals zaczyna się od podziału serwisu na typy stron i analizę tego, gdzie znajduje się ruch, konwersja oraz największe ryzyko techniczne. Inaczej podchodzi się do bloga, inaczej do katalogu ofert, a inaczej do sklepu internetowego z zaawansowanymi filtrami i wieloma skryptami sprzedażowymi. Następnie warto porównać dane z Google Search Console, Chrome UX Report, PageSpeed Insights oraz testów lokalnych. Dzięki temu można odróżnić jednorazowe anomalie od powtarzalnych problemów szablonu.
Priorytetyzacja powinna opierać się na wpływie na użytkownika i biznes. Jeśli największy problem dotyczy strony produktu na mobile, a nie strony głównej, to właśnie tam powinny trafić pierwsze zasoby. Po wdrożeniu zmian konieczne są testy regresji, aby poprawa wskaźników nie zepsuła funkcjonalności, ścieżki zakupowej lub pomiaru analitycznego. W 2026 roku coraz częściej wykorzystuje się AI do analizy raportów, wykrywania anomalii i automatyzacji monitoringu, ale rekomendacje generowane automatycznie nadal trzeba sprawdzać w kontekście biznesowym i technicznym. AI może pomóc uporządkować diagnozę, lecz nie zastąpi zrozumienia, jak działa konkretny serwis.
Najbardziej dojrzałe podejście zakłada stały monitoring po publikacji. Wydajność strony nie jest jednorazowym projektem, tylko procesem. Nowa wtyczka, dodatkowy skrypt marketingowy, zmiana hostingu, wariant landing page’a albo nowy komponent frontendu potrafią w kilka dni cofnąć wcześniejsze postępy. Dlatego warto wdrożyć kontrolę po deploymencie, regularnie śledzić field data oraz ustalić zasady, które łączą wydajność strony, SEO techniczne, użyteczność i cele sprzedażowe. To właśnie w takim modelu poprawa Core Web Vitals realnie wspiera widoczność strony w Google, ale bez złudzenia, że sama technika zastąpi jakość treści, intencję wyszukiwania i ogólną wartość serwisu.
Masz pytania? Porozmawiajmy o Twoim marketingu
Skontaktuj się ze mną!
Jacek Kałuża