Jak poprawić Core Web Vitals na stronie: kompletny przewodnik techniczny

Pytanie o to, jak poprawić Core Web Vitals na stronie, wraca zawsze wtedy, gdy raport w Google Search Console oznacza połowę adresów jako wymagające poprawy. Wbrew pozorom nie jest to problem jednej wtyczki — jak poprawić Core Web Vitals na stronie rozstrzyga się równolegle na czterech poziomach: infrastruktury serwerowej, konfiguracji domeny i DNS, kodu szablonu oraz zachowania przeglądarki po stronie użytkownika. Google mierzy trzy wskaźniki: LCP, czyli czas wyświetlenia największego elementu, INP, opisujący reakcję interfejsu na kliknięcia, oraz CLS, który punktuje przesunięcia układu. Każdy z nich ma inne przyczyny i inne narzędzia naprawcze. Poniższy przewodnik prowadzi od warstwy sprzętowej, przez domenę i certyfikat, aż po optymalizację obrazów i skryptów, wskazując konkretne progi, koszty w złotówkach i kolejność działań, która daje najszybszy zwrot. Kolejność ma znaczenie, bo optymalizacja front-endu na wolnym serwerze przypomina malowanie ścian w domu pozbawionym fundamentów.

Trzy wskaźniki i progi, które trzeba znać przed optymalizacją

Core Web Vitals opierają się na danych z prawdziwego ruchu zbieranych w raporcie CrUX z ostatnich 28 dni. Aby adres uzyskał ocenę pozytywną, 75 procent sesji musi zmieścić się poniżej progu — osobno dla urządzeń mobilnych i osobno dla komputerów. Jeden słaby segment potrafi zepsuć ocenę całej grupy adresów.

LCP opisuje moment, w którym największy blok treści pierwszego ekranu staje się widoczny. Zwykle jest to zdjęcie nagłówkowe, baner slidera albo duży blok tekstu. INP zastąpił dawny wskaźnik FID i mierzy najgorsze opóźnienie reakcji na kliknięcie lub dotknięcie w całej sesji, więc karze ciężkie skrypty działające długo po załadowaniu strony.

CLS zlicza nieoczekiwane przesunięcia układu ważone powierzchnią i dystansem. Najczęstsi winowajcy to obrazy bez zadeklarowanych wymiarów, reklamy wstrzykiwane po renderze, banery zgody na pliki cookie oraz fonty webowe podmieniane w trakcie ładowania. Poniższa tabela zbiera progi, do których warto porównywać wyniki po każdej zmianie.

Hosting i wydajność serwera jako fundament dobrego LCP

Kiedy zastanawiasz się, jak poprawić Core Web Vitals na stronie z wynikiem LCP powyżej czterech sekund, zacznij od czasu odpowiedzi serwera. Jeśli sam TTFB wynosi 1,2 sekundy, żadna kompresja obrazów nie uratuje wyniku, bo przeglądarka przez ten czas nie ma czego renderować. Budżet na pierwszy bajt to realnie 200–500 milisekund.

Jak wybrać hosting pod WordPress

Pytanie o to, jak wybrać hosting pod WordPress, sprowadza się do kilku parametrów technicznych, a nie do pojemności dysku. Szukaj dysków NVMe, aktualnej wersji PHP z włączonym OPcache, obsługi HTTP/2 lub HTTP/3, wbudowanego cache po stronie serwera oraz limitu pamięci co najmniej 512 MB na proces PHP.

Ceny w polskich firmach zaczynają się od około 150–300 zł rocznie za pakiet współdzielony i sięgają 600–900 zł rocznie za pakiety zarządzane z dedykowanym cache. Różnica w TTFB między tanim planem a pakietem z NVMe i lokalnym Redisem potrafi wynieść 400–700 milisekund, co bezpośrednio przekłada się na LCP.

Czym różni się VPS od hostingu współdzielonego

To, czym różni się VPS od hostingu współdzielonego, ma bezpośredni wpływ na stabilność wskaźników. Na hostingu współdzielonym dziesiątki kont walczą o ten sam procesor, więc czas odpowiedzi skacze w godzinach szczytu. VPS przydziela gwarantowane rdzenie i pamięć, dzięki czemu rozrzut wyników w CrUX wyraźnie maleje.

Za VPS z dwoma rdzeniami i 4 GB RAM zapłacisz zwykle 40–80 zł miesięcznie, ale dochodzi obowiązek samodzielnej administracji. Jeżeli decydujesz się na zmianę środowiska, kwestia tego, jak przenieść stronę na inny hosting, sprowadza się do skopiowania plików i bazy, uruchomienia kopii na adresie testowym i dopiero potem przełączenia ruchu produkcyjnego.

Domena, DNS i certyfikat SSL: milisekundy przed pierwszym bajtem

Zanim przeglądarka wyśle jakiekolwiek żądanie, musi rozwiązać nazwę domeny. Zapytanie DNS bez cache kosztuje 20–120 milisekund i wlicza się do LCP każdego nowego użytkownika. Dlatego to, jak skonfigurować rekordy dns domeny, jest realnym zagadnieniem wydajnościowym, a nie wyłącznie administracyjnym szczegółem konfiguracji.

Warto wiedzieć, co to jest rekord CNAME, bo jego nadużycie kosztuje czas. CNAME wskazuje jedną nazwę na drugą, więc każdy dodatkowy poziom to kolejne odpytanie serwerów nazw. W domenie głównej stosuj rekord A lub ALIAS, a łańcuchy aliasów skracaj do jednego kroku. TTL na poziomie 3600 sekund to rozsądny kompromis.

Administracja domeną bywa niedoceniana, dopóki strona nie zniknie z sieci. Jeśli musisz ustalić, jak sprawdzić kto jest właścicielem domeny, użyj zapytania WHOIS lub nowszego protokołu RDAP w panelu rejestratora. Z kolei pytanie o to, jak przedłużyć domenę po wygaśnięciu, ma termin: po okresie karencji domena wchodzi w kwarantannę, a przywrócenie kosztuje zwykle 300–600 zł.

Warstwa szyfrowania również konsumuje milisekundy. Rozważając, jak zainstalować certyfikat SSL na serwerze, sprawdź, czy panel oferuje automatyczne odnawianie — darmowy certyfikat SSL Let’s Encrypt wystawiany jest na 90 dni i wymaga cyklicznej odnowy. Włącz OCSP stapling oraz TLS 1.3, bo skracają uzgadnianie połączenia o jedną rundę komunikacji.

Osobny temat to przekierowania. Kwestia tego, jak ustawić przekierowanie 301 w htaccess, wygląda prosto, ale łańcuch typu http, potem wersja bez www, a dopiero potem docelowy adres, dokłada dwa pełne obiegi żądań. Każdy z nich to 100–300 milisekund straty. Zawsze kieruj bezpośrednio na finalny adres HTTPS.

Obrazy, fonty i skrypty, czyli codzienna praca nad LCP oraz CLS

Element odpowiadający za LCP na stronach firmowych to najczęściej zdjęcie nagłówkowe. Zapisz je w formacie WebP lub AVIF, ogranicz szerokość do faktycznego rozmiaru kontenera i nadaj atrybut fetchpriority=high. Jednocześnie usuń z niego lazy loading, bo odroczone ładowanie obrazu z pierwszego ekranu opóźnia LCP nawet o sekundę.

Przesunięcia układu eliminuje się deklaracjami wymiarów. Każdy obraz i element iframe powinien mieć atrybuty width oraz height albo zdefiniowany aspect-ratio w arkuszu stylów. Fonty webowe podłączaj z ustawieniem font-display: swap i dopasowanym size-adjust, a miejsce na baner zgody rezerwuj statycznie, zamiast wstrzykiwać go po załadowaniu dokumentu.

INP psują długie zadania JavaScript przekraczające 50 milisekund. Poniższa lista porządkuje działania, które w praktyce dają największą poprawę przy najmniejszym nakładzie pracy.

• Odrocz skrypty zewnętrzne atrybutami defer lub async i ładuj czaty oraz mapy dopiero po interakcji użytkownika.
• Ogranicz liczbę wtyczek dodających własne pliki CSS i JS na każdej podstronie, nie tylko tam, gdzie są potrzebne.
• Podziel długie zadania na mniejsze fragmenty, oddając kontrolę wątkowi głównemu między operacjami.
• Usuń nieużywany CSS i wczytaj krytyczne style bezpośrednio w dokumencie, a resztę asynchronicznie.
• Włącz kompresję Brotli oraz nagłówki cache-control z długim czasem życia dla zasobów statycznych.

Pomiar i diagnostyka: dane laboratoryjne kontra dane z ruchu

Planując, jak poprawić Core Web Vitals na stronie, rozdziel dwa źródła danych. Lighthouse i PageSpeed Insights uruchamiają symulację na wirtualnym urządzeniu z dławionym łączem, natomiast raport CrUX pokazuje, co faktycznie zmierzyli użytkownicy. Decyzje o priorytetach podejmuj na podstawie danych polowych, a laboratoryjnych używaj do diagnozy przyczyn.

Jeśli testujesz stronę z domowego łącza, wyniki potrafią mylić. Zagadnienie, jak sprawdzić prędkość internetu rzetelnie, sprowadza się do kilku zasad: pomiar wykonuj po kablu, zamknij aplikacje pobierające dane w tle, powtórz test na dwóch niezależnych serwerach i porównaj medianę z trzech prób zamiast pojedynczego wyniku.

Podobnie działa lokalna sieć bezprzewodowa. Zanim uznasz stronę za wolną, sprawdź, jak wzmocnić sygnał wifi w domu: przenieś router na wysokość około 1,5 metra, przełącz klienta na pasmo 5 GHz, wybierz mniej obciążony kanał, a w większych mieszkaniach rozważ system mesh za 400–800 zł zamiast wzmacniacza sygnału.

Docelowo wdroż własny monitoring RUM. Biblioteka web-vitals zbiera wartości LCP, INP i CLS wraz z atrybucją, czyli wskazaniem konkretnego elementu odpowiedzialnego za wynik. Dane wysyłane do analityki pozwalają porównać szablony, urządzenia i źródła ruchu, zamiast zgadywać na podstawie jednego pomiaru strony głównej.

Jak długo trzeba czekać na poprawę wyników w Search Console?

Raport Core Web Vitals w Search Console bazuje na kroczącym oknie 28 dni, więc efekt wdrożenia nigdy nie pojawia się natychmiast. Pierwsze sygnały poprawy widać zwykle po siedmiu do dziesięciu dni, gdy nowe sesje zaczynają przeważać nad starymi, a pełna zmiana statusu adresu z wymagającego poprawy na dobry zajmuje około czterech tygodni od zakończenia prac. Jeżeli po miesiącu wynik nie drgnął, przyczyną jest zwykle to, że optymalizacja objęła tylko część szablonów albo że problem występuje wyłącznie na urządzeniach mobilnych z wolniejszymi procesorami. Dlatego równolegle z raportem Google prowadź własny monitoring RUM, który pokazuje zmianę już następnego dnia po wdrożeniu i pozwala szybko cofnąć nieudaną modyfikację.

Czy przejście na HTTP/3 realnie poprawia Core Web Vitals?

Tak, choć skala zależy od profilu ruchu. HTTP/3 opiera się na protokole QUIC, który skraca nawiązanie połączenia i lepiej radzi sobie ze stratą pakietów, co jest typowe dla sieci komórkowych. Na stronach odwiedzanych głównie z telefonów w ruchu miejskim poprawa TTFB sięga 50–150 milisekund, a przy wielu zasobach z jednej domeny zysk kumuluje się w LCP. Na szybkim łączu światłowodowym różnica bywa niemierzalna. Włączenie protokołu to zwykle jedno ustawienie w panelu hostingu lub w konfiguracji CDN, więc koszt wdrożenia jest bliski zera. Traktuj to jako uzupełnienie, a nie zamiennik pracy nad obrazami, skryptami i czasem generowania strony po stronie serwera.

Co zrobić, gdy PageSpeed pokazuje 95 punktów, a dane z ruchu są słabe?

Rozbieżność między wynikiem laboratoryjnym a danymi polowymi jest normalna i zwykle ma trzy przyczyny. Po pierwsze, test laboratoryjny mierzy jeden adres, najczęściej stronę główną, podczas gdy CrUX agreguje cały ruch, w tym ciężkie podstrony kategorii i wyników wyszukiwania. Po drugie, symulacja nie odtwarza rzeczywistych urządzeń użytkowników — telefon z niższej półki potrzebuje trzykrotnie więcej czasu na przetworzenie tego samego skryptu. Po trzecie, INP mierzy realne interakcje, których automatyczny test w ogóle nie wykonuje. Rozwiązaniem jest segmentacja: sprawdź wyniki osobno dla najważniejszych szablonów, porównaj urządzenia mobilne z desktopowymi i dopiero wtedy wybierz element do naprawy.