Jak wykonać audyt Core Web Vitals krok po kroku

Wprowadzenie – dane realne kontra dane laboratoryjne

Gdybym miał wskazać jeden błąd powtarzający się w dziewięciu na dziesięć audytów wydajności, jakie widuję, byłby to zawsze ten sam: ktoś otwiera Lighthouse, widzi zielony wynik i uznaje sprawę za zamkniętą. Problem w tym, że Lighthouse to test przeprowadzany w idealnych warunkach – kontrolowane obciążenie, stabilna sieć, wydajna maszyna testowa. Dane CrUX, czyli Chrome User Experience Report, to realne życie – pięcioletni telefon w komunikacji miejskiej na słabym łączu 4G, z kilkunastoma skryptami reklamowymi działającymi w tle. A Google do rankingu wykorzystuje wyłącznie te drugie dane.

Od 12 marca 2024 roku metryka FID (First Input Delay) została zastąpiona przez INP (Interaction to Next Paint) – to zdecydowanie trudniejsza do spełnienia metryka, bo mierzy pełny czas reakcji strony, a nie tylko jego początek. Od marca 2026 roku Google dodatkowo zaostrzył próg tolerancji: jeśli więcej niż 15% adresów URL na danej stronie jest ocenionych jako Poor, wpływa to negatywnie na ranking całej witryny, nie tylko pojedynczych podstron. Obowiązują trzy metryki i trzy progi, które trzeba spełnić na 75. percentylu danych z rzeczywistych sesji użytkowników, osobno dla urządzeń mobilnych i komputerów.

W tym artykule przeprowadzę Cię przez pełny audyt krok po kroku – od diagnozy początkowej, przez każdą z metryk osobno, aż po konfigurację serwera i stałe monitorowanie wyników.

Zacznij od danych, nie od kodu

Zanim napiszesz pierwszą linijkę stylów czy zaczniesz przekładać obrazy na nowsze formaty, otwórz Google Search Console i przejdź do raportu Core Web Vitals. Zobaczysz tam podział na grupy adresów URL z ocenami Good, Needs Improvement i Poor. Każda grupa ma przypisaną metrykę, która ją dyskwalifikuje. To jest Twoja lista priorytetów – nie to, co akurat błyska na czerwono w pojedynczym teście Lighthouse.

Następnie wklej konkretny, problematyczny adres URL do narzędzia PageSpeed Insights. Górna część raportu pokazuje dane terenowe z CrUX, dolna – dane laboratoryjne z Lighthouse. Różnica jest prosta: to górna sekcja decyduje o rankingu. Jeśli LCP w danych terenowych wynosi 3,8 sekundy, a Lighthouse pokazuje piękny wynik w okolicach 95 punktów na 100, masz do czynienia z typową rozbieżnością między warunkami laboratoryjnymi a rzeczywistością. Źródłem problemu jest najczęściej wolniejszy sprzęt użytkowników, słabsze łącze internetowe albo skrypty firm trzecich, które w warunkach laboratoryjnych po prostu nie zdążą się załadować.

Jeśli dopiero zaczynasz monitorowanie własnymi siłami, warto od razu wdrożyć bibliotekę web-vitals w wersji czwartej lub nowszej. Waży poniżej dwóch kilobajtów po kompresji, a jej moduł atrybucji wskazuje konkretny element odpowiedzialny za problem oraz fazę, w której on wystąpił. W połączeniu z nowszym mechanizmem raportowania długich klatek animacji, dostępnym w Chrome od wersji 123, otrzymujesz znacznie precyzyjniejszą atrybucję kodu blokującego główny wątek przeglądarki niż przy starszych narzędziach diagnostycznych.

LCP – cztery fazy i zła kolejność optymalizacji

Largest Contentful Paint to metryka najczęściej ciągnąca cały wynik w dół. Tylko 62% stron mobilnych osiąga dobry wynik LCP, podczas gdy INP przechodzi próg u 77% stron, a CLS u 81%. Problemem rzadko jest brak wiedzy o optymalizacji obrazów – znacznie częściej chodzi o robienie tej optymalizacji w złej kolejności.

Google dzieli LCP na cztery fazy, a każda z nich wymaga zupełnie innego rozwiązania. Zanim cokolwiek zmienisz na stronie, sprawdź w PageSpeed Insights, która z tych faz dominuje:

• Czas do pierwszego bajtu – serwer odpowiada za wolno. Na tym etapie nie pomoże żadna kompresja obrazów.
• Opóźnienie rozpoznania zasobu – przeglądarka za późno dowiaduje się, który element jest odpowiedzialny za LCP. Obraz jest ukryty za tłem CSS, ładowany przez JavaScript albo nie ma dla niego wcześniejszego wskazania w kodzie.
• Czas pobierania zasobu – sam plik jest zbyt duży jak na dostępne łącze użytkownika.
• Opóźnienie wyrenderowania elementu – plik dotarł do przeglądarki, ale nie może zostać namalowany na ekranie, bo blokują go inne style albo skrypty.

Na stronach opartych głównie na treści generowanej po stronie serwera dominuje zwykle pierwsza faza. Na stronach z dużą ilością zdjęć – trzecia. Na stronach zbudowanych w oparciu o JavaScript, takich jak aplikacje React czy Vue – czwarta. Rozwiązanie dobiera się do konkretnej fazy, a nie do samej nazwy metryki.

Serwer i czas do pierwszego bajtu (TTFB)

Czas do pierwszego bajtu wyznacza sufit, powyżej którego LCP nie ma szans się poprawić. Jeśli odpowiedź serwera trwa 1,2 sekundy, nie da się zmieścić w progu 2,5 sekundy dla LCP, niezależnie od tego, jak mały będzie plik obrazu. Google uznaje za dobry czas do pierwszego bajtu poniżej 800 milisekund, ale realistyczny cel inżynieryjny to około 200 milisekund. Przy wartościach powyżej 500 milisekund prawdopodobnie przegrywasz rankingowo z konkurencją, która ma sprawniejszą infrastrukturę.

Czas odpowiedzi serwera warto zmierzyć w narzędziach deweloperskich przeglądarki, w zakładce sieciowej, sprawdzając etap oczekiwania na odpowiedź serwera. Sprawdź też różnicę między zapytaniem obsłużonym z pamięci podręcznej a zapytaniem bez niej. Jeśli wersja z pamięci podręcznej jest szybka, a bez niej wolna, problem leży w samej aplikacji. Jeśli obie są wolne, problemem jest warstwa transportu lub sam hosting.

W praktyce największy efekt daje pełne cachowanie całej strony, tak aby system zarządzania treścią nie musiał generować jej od nowa dla każdego anonimowego odwiedzającego. Sieć dostarczania treści skraca odległość geograficzną do użytkownika. Warto też uruchomić trwałe połączenia z serwerem backendowym, włączyć nowsze protokoły transmisji z szyfrowaniem najnowszej generacji (co skraca czas nawiązywania połączenia) oraz wcześniej skompresować statyczne zasoby algorytmem Brotli.

Optymalizacja obrazu odpowiedzialnego za LCP

Jeśli elementem LCP jest obraz – a w zdecydowanej większości przypadków tak właśnie jest – warto zrobić cztery rzeczy.

Po pierwsze, nadaj temu obrazowi najwyższy priorytet ładowania. Pojedyncza zmiana w kodzie sprawia, że przeglądarka pobiera ten konkretny obraz przed wszystkimi innymi zasobami na stronie. Dzięki takiej zmianie serwis Google Flights skrócił swój wynik LCP z 2,6 do 1,9 sekundy. Warto pamiętać, że tylko jeden obraz na całej stronie powinien mieć nadany najwyższy priorytet – nadanie go kilku elementom naraz niweczy sens tej optymalizacji.

Po drugie, zastosuj wcześniejsze wskazanie tego obrazu w nagłówku strony. Dzięki temu przeglądarka zacznie go pobierać, zanim w ogóle natrafi na właściwy znacznik obrazu w kodzie strony. W przypadku obrazów responsywnych warto dodać do tego wskazania również informacje o dostępnych wariantach rozmiaru i warunkach ich zastosowania.

Po trzecie, zmień format pliku. Format WebP daje 25–35% mniejszy rozmiar pliku od klasycznego JPEG przy zachowaniu tej samej jakości wizualnej. Format AVIF idzie jeszcze dalej, redukując rozmiar o 40–60%, a od 2025 roku wsparcie dla niego przekroczyło 90% wszystkich przeglądarek. Warto korzystać ze znacznika obrazu z odpowiednimi wariantami zapasowymi dla starszych przeglądarek.

Po czwarte, serwuj obraz w odpowiednim rozmiarze. Jeśli główny obraz wyświetla się na stronie w rozmiarze 800 na 533 piksele, nie ma sensu wysyłać użytkownikowi pliku o rozdzielczości 3000 na 2000 pikseli. Odpowiednio skonfigurowane warianty rozmiaru obrazu sprawiają, że telefon z wąskim ekranem otrzymuje dopasowaną do siebie, mniejszą wersję pliku.

Jeden błąd powtarza się przy tym notorycznie: leniwe ładowanie zastosowane na obrazie odpowiedzialnym za LCP. Taki mechanizm dodaje 200–400 milisekund do czasu LCP, bo przeglądarka celowo opóźnia pobieranie pliku. Obraz znajdujący się od razu nad linią zgięcia strony nigdy nie powinien być ładowany leniwie – to jedno z najczęstszych, niemal samobójczych posunięć widocznych w audytach Core Web Vitals.

Zasoby blokujące renderowanie

Przeglądarka nie namaluje żadnego piksela na ekranie, dopóki nie pobierze i nie przetworzy wszystkich arkuszy stylów umieszczonych w nagłówku strony. Jeśli w tym miejscu znajduje się sześć zewnętrznych plików stylów i trzy zewnętrzne skrypty, wynik LCP czeka na wszystkie z nich, zanim cokolwiek się wyświetli.

Rozwiązanie jest stosunkowo proste: style potrzebne do wyrenderowania treści widocznej od razu po wejściu na stronę warto umieścić bezpośrednio w kodzie HTML, a resztę stylów ładować asynchronicznie. Skrypty niepotrzebne przy pierwszym wyrenderowaniu strony należy oznaczyć jako odroczone lub asynchroniczne. W praktyce oznacza to przesunięcie poza ścieżkę krytyczną takich elementów jak narzędzia analityczne, okna czatu, piksele marketingowe czy widgety mediów społecznościowych.

Realistyczny budżet czasowy wygląda tak: 30–80 milisekund na czas do pierwszego bajtu dzięki sieci dostarczania treści i cache po stronie serwera, style krytyczne umieszczone bezpośrednio w kodzie, skrypty odroczone poza ścieżkę krytyczną, wcześniejsze wskazanie obrazu LCP z najwyższym priorytetem oraz własne hostowanie czcionek z płynnym przejściem tekstu zamiast jego ukrywania. Po takich zmianach LCP zwykle spada poniżej dwóch sekund.

INP – zablokowany główny wątek i brak reakcji na kliknięcia

Interaction to Next Paint to najczęściej pomijana, a jednocześnie najbardziej zdradliwa metryka. INP zastąpiło FID 12 marca 2024 roku i jest drastycznie trudniejsze do spełnienia. FID mierzyło wyłącznie opóźnienie przed rozpoczęciem przetwarzania pierwszej interakcji użytkownika ze stroną. INP mierzy pełny czas – od momentu kliknięcia, przez wykonanie kodu obsługującego to zdarzenie, aż po narysowanie odpowiedzi na ekranie. Robi to dla wszystkich interakcji w trakcie całej wizyty i raportuje tę najgorszą z nich. Jeśli strona oblewa INP, właściciel często nawet nie wie o problemie, bo w rankingu nie pojawia się żadne wyraźne, czerwone ostrzeżenie.

Każda interakcja składa się z trzech faz, a diagnozowanie INP polega przede wszystkim na ustaleniu, która z nich stanowi wąskie gardło.

Pierwsza faza to opóźnienie wejściowe – czas, zanim kod obsługujący interakcję w ogóle zaczyna działać. Przyczyną jest niemal zawsze inny kod, który zajmuje główny wątek dokładnie w momencie interakcji: zbyt długo działający parser skryptów, kod narzędzia analitycznego albo ciężki mechanizm obsługi zdarzenia z poprzedniej interakcji. Dobre opóźnienie wejściowe to mniej niż 40 milisekund. Powyżej 100 milisekund oznacza to, że główny wątek jest zajęty właśnie w chwili, gdy użytkownik próbuje wejść w interakcję ze stroną.

Druga faza to czas wykonania właściwego kodu obsługującego zdarzenie. Tutaj odpowiedzialność leży zwykle po stronie samej aplikacji – zbyt duża ilość logiki w jednym mechanizmie obsługi zdarzenia, framework przerysowujący całe drzewo komponentów przy każdej drobnej zmianie albo synchroniczne odczyty z pamięci lokalnej przeglądarki.

Trzecia faza to opóźnienie prezentacji – czas, jaki zajmuje przeglądarce narysowanie efektu interakcji po zakończeniu działania kodu. Jeśli kod obsługujący zdarzenie zmodyfikował strukturę strony, a przeglądarka musi przeliczyć style i układ dla całej witryny, ta faza znacząco się wydłuża.

Diagnozowanie INP w Chrome DevTools

W narzędziach deweloperskich Chrome otwórz zakładkę Performance i nagraj sesję podczas rzeczywistego korzystania ze strony: klikaj przyciski, rozwijaj menu, wpisuj coś w polu wyszukiwania. Na osi czasu szukaj długich, wyraźnie oznaczonych bloków w głównym wątku – to zadania trwające dłużej niż 50 milisekund. Każde z nich to potencjalna przyczyna złego wyniku INP.

Odszukaj konkretną interakcję w panelu poświęconym interakcjom. Zobaczysz tam podział na trzy opisane wcześniej fazy i dowiesz się, która z nich jest najdłuższa. Jeśli dominuje opóźnienie wejściowe, problemem jest główny wątek zajęty przez inne skrypty. Jeśli dominuje czas wykonania kodu, mechanizm obsługi zdarzenia robi zbyt wiele naraz. Jeśli dominuje opóźnienie prezentacji, zbyt kosztowne są same zmiany wprowadzane w strukturze strony.

Trzy najskuteczniejsze poprawki INP

Po pierwsze, przerywaj długo działające zadania. Głównym problemem z INP jest brak kontroli nad tym, co dzieje się na głównym wątku dokładnie w momencie interakcji użytkownika. W nowoczesnych przeglądarkach istnieje mechanizm oddawania kontroli przeglądarce w trakcie działania kodu, dzięki czemu może ona na bieżąco obsłużyć oczekujące interakcje, zamiast czekać na zakończenie całego zadania. Działa to już w nowszych wersjach Chrome i Firefoksa, a dla przeglądarki Safari potrzebny jest zapasowy mechanizm oparty na krótkim opóźnieniu wykonania.

Po drugie, ogranicz skrypty firm trzecich – to zdecydowanie największe źródło problemów z INP na stronach, które audytuję. Typowa strona ładuje od ośmiu do dwunastu zewnętrznych skryptów na każdej podstronie: narzędzia analityczne, okno czatu, testy porównawcze, piksele marketingowe, widgety mediów społecznościowych. Każdy z nich zajmuje główny wątek przeglądarki. Łącznie skrypty firm trzecich zabierają średnio 150–200 milisekund z całego budżetu czasowego INP. Rozwiązaniem jest ładowanie ich dopiero po pierwszej interakcji użytkownika ze stroną albo na wyraźne żądanie – okno czatu może pokazywać na starcie samą statyczną ikonę, a pełny kod ładować dopiero po kliknięciu, narzędzia analityczne można odroczyć do momentu, gdy przeglądarka jest bezczynna. Jeśli korzystasz z menedżera tagów, warto regularnie przeglądać jego zawartość – zdarza się, że jest pełen tagów, które od lat nic już nie robią.

Po trzecie, optymalizuj mechanizmy obsługi zdarzeń. Wyszukiwanie w trakcie pisania, filtrowanie długich list czy walidacja formularzy w czasie rzeczywistym sprawiają, że każde naciśnięcie klawisza może uruchamiać kosztowny kod. Opóźnienie reakcji o 200–300 milisekund po ostatnim naciśnięciu klawisza rozwiązuje ten problem. Przy renderowaniu długich list warto zastosować wirtualizację, czyli renderowanie tylko tych elementów, które są aktualnie widoczne na ekranie. W aplikacjach opartych na komponentach warto ograniczyć niepotrzebne ponowne przeliczenia i przerysowania.

CLS – pięć źródeł przesunięć layoutu

Cumulative Layout Shift to metryka, którą najłatwiej naprawić, a mimo to najczęściej ignorowana. Można ją poprawić w jedno popołudnie, a robi to ogromną różnicę w odbiorze strony przez użytkownika. CLS mierzy, ile razy treść na stronie nieoczekiwanie przeskakuje w trakcie ładowania. Próg dobrego wyniku to 0,1. Powyżej 0,25 to już wynik uznawany za słaby.

Pięć źródeł odpowiada za ponad 90% wszystkich przypadków wysokiego CLS, a każde z nich ma prostą poprawkę.

Obrazy i filmy bez zarezerwowanych wymiarów. 62% stron mobilnych wciąż ma co najmniej jeden obraz bez wcześniej podanej szerokości i wysokości. Gdy przeglądarka nie wie, ile miejsca zarezerwować, obraz startuje z zerową wysokością, a po jego załadowaniu cała treść pod nim przeskakuje w dół. Rozwiązaniem jest podanie wymiarów dla każdego obrazu i elementu osadzonego, a dla kontenerów o zmiennej szerokości – ustalenie stałych proporcji szerokości do wysokości.

Czcionki dodatkowe. Czcionka zastępująca systemowy fallback może przesunąć tekst, bo poszczególne znaki mają inne proporcje niż w foncie zapasowym. Tylko 11% stron wcześniej wskazuje swoje pliki czcionek do pobrania. Rozwiązaniem jest wcześniejsze wskazanie najważniejszego pliku czcionki oraz takie ustawienie wyświetlania tekstu, żeby jego rozmiar był dopasowany do metryk czcionki docelowej, ewentualnie pokazanie tekstu dopiero, gdy czcionka jest już dostępna w pamięci podręcznej przeglądarki.

Dynamicznie wstrzykiwana treść. Banery informujące o plikach cookie, paski promocyjne czy widgety czatu pojawiają się dopiero po załadowaniu strony i wypychają istniejącą treść w dół. Rozwiązaniem jest pozycjonowanie takich elementów jako nakładki, zamiast wypychania nimi reszty treści, albo wcześniejsze zarezerwowanie dla nich miejsca w strukturze strony.

Miejsca na reklamy. Reklamy to najtrudniejszy przypadek, bo strona rzadko kontroluje ich ostateczny rozmiar. Rozwiązaniem jest zawsze ustawienie minimalnej wysokości kontenera reklamowego odpowiadającej największemu formatowi reklamy, jaki może się w nim pojawić. Lepiej stracić trochę pustej przestrzeni niż dopuścić do przeskoku całej reszty strony.

Animacje wpływające na układ strony. Zmiana szerokości, wysokości, marginesów czy pozycji elementu wymusza ponowne przeliczenie układu całej strony przy każdej klatce animacji. Zamiast tego warto animować przesunięcie i przezroczystość elementu – te właściwości są obsługiwane przez osobny wątek kompozytora i nie powodują przesunięć layoutu. Warto też ograniczyć zakres przeliczeń stylów do wnętrza konkretnego elementu, zamiast całej strony.

Dodatkowo, pomijanie renderowania sekcji znajdujących się poniżej widocznego obszaru ekranu, dopóki użytkownik do nich nie przewinie, oraz wcześniejsze rezerwowanie przybliżonego rozmiaru takich sekcji zapobiega skakaniu paska przewijania i zauważalnie redukuje koszt renderowania całej strony.

Przykład z życia: blog prowadzony na WordPressie z dwunastoma obrazami bez podanych wymiarów. Samo dodanie brakujących wymiarów obniżyło CLS z 0,24 do 0,06 – bez jakiejkolwiek zmiany w warstwie skryptów. Strona hotelowa z wynikiem CLS na poziomie 0,38 – poprawka pięciu obrazów w sekcji powitalnej obniżyła wynik do 0,04.

Optymalizacja serwera i konfiguracja hostingu

Znaczna część problemów z Core Web Vitals ma źródło po stronie serwera, ale w praktyce większość zespołów zaczyna prace od warstwy frontendowej. To błąd kosztujący sporo czasu. Wynik LCP nigdy nie będzie lepszy niż czas do pierwszego bajtu, a ten zależy niemal wyłącznie od infrastruktury.

Sprawdź różnicę między odpowiedzią serwera z pamięci podręcznej a bez niej. Jeśli strona obsłużona z pamięci podręcznej działa szybko, poniżej 50 milisekund, a bez niej wolno, powyżej 500 milisekund, wąskim gardłem jest sama aplikacja albo baza danych. Jeśli obie wersje są wolne, problemem jest warstwa transportu albo sam hosting.

W praktyce lista kontrolna wygląda następująco:

• Pełne cachowanie strony dla anonimowych użytkowników na poziomie serwera
• Dodatkowa pamięć podręczna dla powtarzalnych zapytań do bazy danych
• Sieć dostarczania treści ustawiona przed serwerem źródłowym
• Nowszy protokół transmisji danych z aktualnym szyfrowaniem
• Kompresja Brotli, najlepiej przygotowana wcześniej, a nie w locie
• Trwałe połączenia z serwerem backendowym – ustawienie często pomijane
• Cache kodu operacyjnego dla środowiska PHP w przypadku WordPressa
• Indeksy w bazie danych na najczęściej odpytywanych kolumnach

Różnica między tanim hostingiem współdzielonym a serwerem prywatnym z odpowiednią konfiguracją to często skok czasu do pierwszego bajtu z 800–1500 milisekund do wartości poniżej 250 milisekund. To ma bezpośrednie przełożenie na wynik LCP.

Narzędzia i stałe monitorowanie

Audyt Core Web Vitals nie jest jednorazową akcją. Jeśli poprawisz wszystko dzisiaj, za trzy miesiące nowa wtyczka, kolejny skrypt firmy trzeciej albo aktualizacja motywu może ponownie zepsuć wyniki.

Potrzebne są trzy warstwy monitorowania. Pierwsza to cotygodniowe sprawdzanie danych terenowych w Google Search Console i PageSpeed Insights – to źródło prawdy dla rankingu, choć z opóźnieniem sięgającym 28 dni. Druga to monitorowanie rzeczywistych użytkowników za pomocą biblioteki web-vitals w wersji czwartej lub nowszej – dane w czasie rzeczywistym, alerty przy przekroczeniu ustalonych progów i atrybucja elementów odpowiedzialnych za problem. Trzecia to automatyczne testy wydajnościowe w procesie wdrażania zmian, które blokują wdrożenia wprowadzające wyraźną regresję wyników.

Co kwartał warto wykonać pełny przegląd: porównać grupy adresów URL w Search Console względem poprzedniego kwartału, sprawdzić, które z nich przeskoczyły z oceny dobrej na złą, uruchomić PageSpeed Insights na reprezentatywnych podstronach oraz przejrzeć dane od rzeczywistych użytkowników pod kątem powtarzających się wzorców, na przykład najgorszego wyniku INP na telefonach ze średniej półki cenowej z systemem Android.

Nie ma sensu robić tego częściej niż raz na kwartał – dane terenowe aktualizują się z opóźnieniem 28 dni, a cykl wdrażania poprawek rzadko jest krótszy niż ten okres.

Wpływ na ranking – istnieje, ale mniejszy niż się wydaje

Core Web Vitals są potwierdzonym sygnałem rankingowym, ale stosunkowo niewielkim. Sam Google mówi to wprost – trafność treści zawsze ma pierwszeństwo. Strona z doskonałymi wynikami Core Web Vitals i słabą treścią nie wyprzedzi strony ze świetną treścią i przeciętnymi wynikami wydajnościowymi.

W praktyce Core Web Vitals działają jak bramka wejściowa. Oblewanie ich szkodzi – szczególnie od marca 2026 roku, gdy próg udziału adresów URL ocenionych jako Poor spadł do 15%. Przejście ze statusu Poor na Good daje wymierne efekty: 1–5% poprawy widoczności w średnio konkurencyjnych branżach, a w przypadkach poważnych zaniedbań technicznych nawet skok o kilkanaście pozycji w wynikach wyszukiwania. Poprawa z Good na jeszcze lepszy wynik nie przynosi już żadnych dodatkowych korzyści rankingowych – w tym miejscu pojawiają się malejące zyski i lepiej przeznaczyć czas na rozwój treści.

Core Web Vitals robią największą różnicę w konkurencyjnych zapytaniach komercyjnych, gdzie kilka stron ma podobną treść i podobny profil linków. W takich przypadkach różnica w wynikach wydajnościowych potrafi przesunąć pozycję o dwa lub trzy miejsca.

Urządzenia mobilne mają 2,3 razy większe znaczenie niż komputery stacjonarne, ponieważ Google indeksuje przede wszystkim wersję mobilną strony, a różnice sprzętowe telefonów dodatkowo wzmacniają wszelkie problemy wydajnościowe.

I najważniejsze: do rankingu liczą się wyłącznie dane terenowe z rzeczywistych użytkowników. Lighthouse, wynik PageSpeed czy inne narzędzia zewnętrzne to wyłącznie narzędzia diagnostyczne – Google nie bierze ich pod uwagę przy ocenie strony.

Podsumowanie – audyt jako proces ciągły

Audyt Core Web Vitals to proces ciągły, który wymaga systematycznego podejścia i regularnego monitorowania, a nie jednorazowej akcji przed premierą strony. Optymalizacja tych metryk poprawia pozycjonowanie w Google, ale przede wszystkim realnie zwiększa satysfakcję użytkowników i liczbę konwersji.

Kluczowa zasada brzmi: zaczynaj od danych terenowych, nie od pojedynczego testu laboratoryjnego. Diagnozuj konkretną fazę problemu, zanim wdrożysz poprawkę – kompresja obrazu nie pomoże, jeśli winny jest wolny serwer, a optymalizacja skryptów nic nie da, jeśli problemem są przesunięcia layoutu wynikające z brakujących wymiarów obrazów.

Regularny audyt, prowadzony co kwartał i uzupełniany o bieżące monitorowanie rzeczywistych użytkowników, zapewnia długoterminowy sukces w budowaniu szybkiego, stabilnego i przyjaznego dla odwiedzających serwisu internetowego.