Optymalizacja szybkości strony: Core Web Vitals

Piszemy ten tekst w trakcie naprawiania własnych wyników, i tak jest uczciwiej. We wrześniu 2026 strona główna lineup.agency miała na urządzeniach mobilnych CLS na poziomie 0,141, przy progu 0,1, a nasz najdłuższy przewodnik osiągał LCP 4,8 sekundy przy progu 2,5 sekundy. Oba wyniki są niedobre i oba są w trakcie poprawy.

Wspominamy o tym, bo teksty o wydajności zwykle pisze się z pozycji kogoś, kto już wszystko ma zielone. Praktyczna wiedza bierze się raczej z sytuacji odwrotnej.

1. Core Web Vitals w 2026: co się liczy

Trzy wskaźniki, z których każdy mierzy inne odczucie użytkownika. Progi poniżej dotyczą siedemdziesiątego piątego centyla wizyt, czyli wyniku, który osiąga trzy czwarte Twoich użytkowników.

Wskaźnik	Co mierzy	Próg dobry	Najczęstsza przyczyna
LCP	Czas do wyrenderowania największego elementu	do 2,5 s	Nieoptymalizowany obraz w pierwszym widoku
CLS	Przesunięcia układu po załadowaniu	do 0,1	Baner zgody i reklamy bez zarezerwowanego miejsca
INP	Opóźnienie reakcji na interakcje	do 200 ms	Ciężkie skrypty analityczne i wtyczki

Jaki to ma realny wpływ na pozycje

Mniejszy, niż sugeruje większość tekstów na ten temat. Google potwierdza, że doświadczenie strony jest sygnałem, ale szybka strona ze słabszą treścią nie wyprzedzi wolniejszej, która lepiej odpowiada na zapytanie. Wydajność rozstrzyga tam, gdzie konkurencja ma zbliżoną jakość treści.

Znacznie mocniej widać wpływ na konwersję. Użytkownik mobilny, który czeka pięć sekund na treść, często nie czeka do końca, i to jest strata niezależna od rankingu.

Traktuj Core Web Vitals jako inwestycję w konwersję, która przy okazji pomaga w rankingu. Odwrotne uzasadnienie prowadzi do rozczarowania, bo sam skok wskaźników rzadko przesuwa pozycje w widoczny sposób.

2. LCP: znajdź przyczynę w dziesięć minut

W ponad połowie serwisów, które optymalizowaliśmy, największym elementem jest obraz w pierwszym widoku, a przyczyna słabego wyniku sprowadza się do jednej z trzech rzeczy.

1. Obraz jest za ciężki. Zdjęcie 3000 pikseli szerokości wyświetlane w kontenerze o szerokości 800 pikseli. Rozwiązanie: format WebP lub AVIF plus atrybut srcset z realnymi rozmiarami.
2. Obraz ma leniwe ładowanie. WordPress dodaje atrybut loading z wartością lazy do wszystkich obrazów automatycznie, także do tego w pierwszym widoku, co celowo opóźnia najważniejszy element. Rozwiązanie: wyłącz leniwe ładowanie dla obrazu wyróżniającego i dodaj mu wysoki priorytet pobierania.
3. Serwer odpowiada wolno. Jeśli czas do pierwszego bajtu przekracza 600 ms, żadna optymalizacja obrazu nie pomoże, bo przeglądarka jeszcze nie wie, co ma pobrać. Rozwiązanie: cache po stronie serwera i lepszy hosting.

Jak sprawdzić, który to przypadek

Otwórz PageSpeed Insights i znajdź sekcję z rozbiciem LCP na fazy. Jeśli dominuje czas odpowiedzi serwera, problem jest po stronie hostingu. Jeśli dominuje opóźnienie wczytywania zasobu, problem jest w priorytecie lub leniwym ładowaniu. Jeśli dominuje czas pobierania, obraz jest po prostu za duży.

To rozbicie oszczędza godziny zgadywania i jest najczęściej pomijanym elementem raportu.

3. CLS: skąd biorą się przesunięcia

CLS mierzy, ile treści przesunęło się po tym, jak użytkownik zaczął czytać. Winowajca prawie zawsze należy do jednej z czterech kategorii.

Źródło	Dlaczego przesuwa	Poprawka
Obrazy bez wymiarów	Przeglądarka nie wie, ile miejsca zarezerwować	Atrybuty width i height albo aspect-ratio
Baner zgody na cookies	Wstrzykiwany po wyrenderowaniu strony	Stała wysokość kontenera albo nakładka bez przesuwania treści
Czcionki zewnętrzne	Podmiana kroju zmienia wysokość bloków tekstu	font-display swap plus dopasowany krój zapasowy
Osadzone treści i reklamy	Ramka wczytuje się z opóźnieniem	Kontener o zadeklarowanych proporcjach

CLS jest zwykle najtańszym z trzech wskaźników do poprawienia. Dodanie wymiarów do obrazów i zarezerwowanie miejsca na baner zgody to często praca na kilka godzin, która przenosi wynik z czerwonego do zielonego.

4. INP: dlaczego jest trudniejszy niż dawny FID

Poprzedni wskaźnik mierzył opóźnienie tylko pierwszej interakcji, więc wystarczyło, żeby strona szybko reagowała na pierwsze kliknięcie. INP mierzy wszystkie interakcje w trakcie wizyty i raportuje wartość bliską najgorszej z nich.

To zmienia zakres pracy. Nie wystarczy przyspieszyć start strony, trzeba zająć się skryptami działającymi przez cały czas jej życia.

Trzy najczęstsze przyczyny w WordPressie

• Nadmiar skryptów śledzących. Analytics, piksel reklamowy, mapa ciepła, czat i menedżer tagów, wszystkie ładowane w tym samym momencie. Każdy dokłada pracy do głównego wątku.
• Wtyczki dodające obsługę zdarzeń do wielu elementów. Suwaki, galerie i budowniczowie stron potrafią rejestrować setki nasłuchiwaczy zdarzeń.
• Długie zadania JavaScript bez podziału. Jeden skrypt blokujący główny wątek na 400 ms sprawia, że każde kliknięcie w tym czasie wygląda na zignorowane.

Praktyczna kolejność działań: najpierw usuń skrypty, których nikt nie używa, bo w większości serwisów co najmniej jeden taki jest. Potem opóźnij ładowanie tych, które nie są potrzebne od razu, na przykład czatu. Dopiero na końcu zajmuj się dzieleniem długich zadań, bo to wymaga pracy programistycznej.

5. WordPress w praktyce

Większość polskich stron firmowych działa na WordPressie, więc warto zejść na poziom konkretów.

Działanie	Wpływ	Pracochłonność	Ryzyko
Konwersja obrazów do WebP	Duży na LCP	Niska, wtyczka	Niskie
Wyłączenie leniwego ładowania w pierwszym widoku	Duży na LCP	Niska	Niskie
Wymiary obrazów i miejsce na baner zgody	Duży na CLS	Niska	Niskie
Cache po stronie serwera	Średni, głównie czas odpowiedzi	Niska	Średnie
Łączenie i minifikacja zasobów	Zmienny	Niska	Wysokie
Usunięcie nieużywanych wtyczek	Średni na INP	Średnia	Średnie
Zmiana motywu na lżejszy	Bardzo duży	Bardzo wysoka	Wysokie

Zwróć uwagę na wiersz o łączeniu i minifikacji. To ustawienie w wtyczkach cache bywa włączane odruchowo i potrafi zepsuć stronę w sposób niewidoczny na pierwszy rzut oka: formularz przestaje wysyłać, suwak się nie uruchamia, menu mobilne nie otwiera się na niektórych przeglądarkach. Po każdej zmianie ustawień cache sprawdź ręcznie stronę główną, jedną podstronę usługi i formularz kontaktowy.

6. Jak mierzyć: laboratorium kontra dane polowe

Dwa rodzaje danych, które odpowiadają na różne pytania i bywają mylone.

	Dane laboratoryjne	Dane polowe
Skąd pochodzą	Symulacja w kontrolowanych warunkach	Realne wizyty użytkowników Chrome
Do czego służą	Diagnoza i sprawdzanie poprawek	Ocena, czy problem dotyczy użytkowników
Dostępność	Zawsze	Tylko przy odpowiednim ruchu
Czas reakcji na zmianę	Natychmiast	Do 28 dni

Dane polowe pochodzą ze zbioru CrUX i wymagają wystarczającej liczby wizyt, żeby w ogóle się pojawić. Witryny o małym ruchu, w tym nasza własna, po prostu nie osiągają tego progu. Zostają wtedy dane laboratoryjne, które są dobre do diagnozy, ale nie mówią, co widzą prawdziwi użytkownicy.

Druga pułapka dotyczy cierpliwości. Raport w Search Console operuje na oknie 28 dni, więc poprawka wdrożona dziś nie zmieni statusu w ciągu tygodnia. Sprawdzaj efekt w danych laboratoryjnych od razu, a w polowych po miesiącu.

7. Przypadek: droga do wyniku 100 na 100

Klient z branży motoryzacyjnej, strona na WordPressie z rozbudowanym motywem i kilkunastoma wtyczkami. Punkt wyjścia: wynik mobilny w okolicach czterdziestu punktów, LCP powyżej pięciu sekund, wyraźne przesunięcia układu przy wczytywaniu.

Kolejność prac była nudna i celowo zachowawcza. Najpierw obrazy: konwersja do WebP, właściwe rozmiary i wyłączenie leniwego ładowania dla pierwszego widoku. To załatwiło większość problemu z LCP. Potem wymiary obrazów i stała wysokość kontenera banera zgody, co usunęło przesunięcia. Na końcu przegląd wtyczek i usunięcie trzech, których nikt nie używał od lat, oraz opóźnienie ładowania czatu do pierwszej interakcji użytkownika.

Efekt końcowy to 100 na 100 w PageSpeed Insights dla wersji mobilnej. Warto jednak zaznaczyć dwie rzeczy. Po pierwsze, to wynik laboratoryjny. Po drugie, sto punktów nie było celem samym w sobie i nie przełożyło się na skokowy wzrost pozycji. Przełożyło się na krótszy czas wczytywania dla użytkownika mobilnego, a to była rzecz, po którą przyszedł klient.

8. Najczęściej zadawane pytania

Jak powstał ten przewodnik

Progi i definicje wskaźników pochodzą z dokumentacji web.dev i są aktualne na wrzesień 2026. Przykłady i szacunki czasu pracy pochodzą z optymalizacji wykonanych przez LineUp na witrynach WordPress klientów w latach 2025 do 2026, w tym z wdrożenia, które zakończyło się wynikiem 100 na 100 w PageSpeed Insights. Podane oszczędności czasu ładowania dotyczą tych konkretnych wdrożeń, a nie są średnią.

9. Źródła i materiały

Materiały źródłowe wykorzystane przy pisaniu tego przewodnika. Liczby opisane jako własne pochodzą z kampanii prowadzonych przez LineUp, zgodnie z notą metodologiczną powyżej.

1. web.dev, Core Web Vitals. Definicje wskaźników i aktualne progi zaliczenia. web.dev ↗
2. web.dev, optymalizacja LCP. Przyczyny wolnego renderowania największego elementu i sposoby naprawy. web.dev ↗
3. web.dev, optymalizacja INP. Jak diagnozować i skracać czas reakcji na interakcje. web.dev ↗
4. Google Search Central, doświadczenie strony. Stanowisko Google w sprawie roli wskaźników w rankingu. developers.google.com ↗