Jak przyspieszyć witrynę i poprawić Core Web Vitals?

Wolna strona kosztuje podwójnie: odwiedzający wychodzą, zanim cokolwiek zobaczą, a Google spycha ją niżej w wynikach. Jeśli Search Console pokazuje ostrzeżenia o wydajności albo PageSpeed Insights świeci na czerwono, ten wpis jest dla Ciebie. Pokażemy, co dokładnie mierzą Core Web Vitals w 2026 roku, jakie wyniki uznaje się za dobre i jak realnie przyspieszyć witrynę, także wtedy, gdy prowadzisz małą firmę i nie masz działu IT.

Czym są Core Web Vitals w 2026 roku

Core Web Vitals to trzy wskaźniki, którymi Google opisuje realne doświadczenie użytkownika na stronie: jak szybko widzi treść, jak sprawnie strona reaguje na jego działania i czy układ nie skacze mu pod palcem. To nie są syntetyczne liczby z laboratorium, tylko dane zbierane od prawdziwych użytkowników przeglądarki Chrome. Trzy metryki to:

• LCP (Largest Contentful Paint) mierzy, po jakim czasie pojawia się największy element widoczny na pierwszym ekranie, najczęściej zdjęcie baneru lub duży nagłówek. To wskaźnik odczuwanej szybkości ładowania.
• INP (Interaction to Next Paint) mierzy responsywność, czyli ile czasu mija od kliknięcia lub dotknięcia do momentu, w którym ekran faktycznie na nie reaguje. INP zastąpił dawny wskaźnik FID w marcu 2024 roku, więc to o nim mówimy dzisiaj, a nie o FID.
• CLS (Cumulative Layout Shift) mierzy stabilność układu, czyli jak bardzo elementy przeskakują podczas ładowania. Wysoki CLS to sytuacja, w której chcesz kliknąć przycisk, a w ostatniej chwili wskakuje reklama i klikasz coś innego.

LCP, INP i CLS: progi, które trzeba znać

Google dzieli wyniki na trzy koszyki: dobry, wymaga poprawy i słaby. Co ważne, wynik uznaje się za dobry dopiero wtedy, gdy próg osiąga 75 procent wizyt, a nie średnia. Poniżej progi, do których warto celować:

Nie musisz mieć trójki idealnej od razu. Najpierw wyjdź ze strefy „słabo”, potem walcz o „dobrze”. Zwykle jedna metryka ciągnie stronę w dół i to od niej warto zacząć.

Jak zmierzyć szybkość i Core Web Vitals

Zanim cokolwiek poprawisz, zmierz stan wyjściowy, inaczej nie będziesz wiedzieć, czy zmiany pomagają. Warto rozróżnić dwa rodzaje danych: laboratoryjne (test w kontrolowanych warunkach, ten sam za każdym razem) oraz z realnego ruchu (zebrane od prawdziwych użytkowników). Google w rankingu bierze pod uwagę te drugie.

• PageSpeed Insights to punkt startowy. Łączy wynik laboratoryjny z realnymi danymi z raportu Chrome UX, osobno dla wersji mobilnej i desktopowej, i podpowiada konkretne rzeczy do poprawy. Zawsze patrz najpierw na wynik mobilny, bo Google indeksuje strony przede wszystkim w wersji na telefon.
• Raport Core Web Vitals w Google Search Console pokazuje trend w czasie i grupuje adresy o podobnych problemach, dzięki czemu widzisz skalę: czy kuleje jedna podstrona, czy cały szablon.
• Narzędzia deweloperskie w przeglądarce (zakładka Performance oraz panel Lighthouse) przydają się, gdy chcesz znaleźć konkretny skrypt albo obraz odpowiedzialny za problem.

Zasada jest prosta: mierz na telefonie, patrz na dane z realnego ruchu i nie panikuj po jednym teście, bo pojedynczy pomiar laboratoryjny potrafi się wahać.

Obrazy: zwykle największy balast

W większości witryn to właśnie grafiki ważą najwięcej i najczęściej psują LCP. Cztery ruchy, które dają największy efekt:

• Nowoczesne formaty. Zamień JPG i PNG na WebP lub AVIF. Przy tej samej jakości plik potrafi być mniejszy o połowę, a AVIF bywa jeszcze lżejszy niż WebP.
• Realne wymiary. Nie wgrywaj zdjęcia 4000 pikseli szerokości, jeśli wyświetla się na 800. Skaluj pliki do rozmiaru, w jakim faktycznie się pokazują.
• Podane wymiary w kodzie. Ustaw atrybuty width i height (albo rezerwuj miejsce w CSS), żeby przeglądarka wiedziała, ile miejsca zostawić. To najprostszy sposób na niski CLS.
• Lazy loading. Grafiki poniżej pierwszego ekranu ładuj dopiero, gdy użytkownik do nich dojedzie (atrybut loading="lazy"). Uwaga: głównego obrazu LCP nie ładuj leniwie, bo opóźnisz to, co najważniejsze.

Na WordPressie kompresję i konwersję do WebP zrobią za Ciebie wtyczki, takie jak ShortPixel czy Imagify, a lazy loading działa domyślnie od wersji 5.5. Warto jednak sprawdzić, czy nie obejmuje przypadkiem obrazu z pierwszego ekranu.

JavaScript i skrypty zewnętrzne

Jeśli obrazy najczęściej psują LCP, to JavaScript najczęściej psuje INP. Ciężkie skrypty blokują główny wątek przeglądarki, więc kliknięcia czekają w kolejce. Co z tym zrobić:

• Ogranicz ilość kodu. Usuń nieużywane wtyczki, biblioteki i widżety. Każdy dodatek to kolejne kilobajty do pobrania i wykonania.
• Odrocz i wczytuj asynchronicznie. Skrypty, które nie są potrzebne od razu, oznacz jako defer lub async, żeby nie blokowały renderowania treści.
• Minifikuj i łącz pliki. Usunięcie spacji i komentarzy oraz połączenie plików zmniejsza rozmiar i liczbę zapytań. Na WordPressie pomogą Autoptimize lub wbudowane opcje wtyczek cache.
• Przytnij skrypty zewnętrzne. Czaty, mapy, piksele reklamowe, testy A/B i widżety społecznościowe to kod z cudzych serwerów, nad którym nie masz kontroli. Zostaw tylko te, które naprawdę zarabiają, a resztę wczytuj z opóźnieniem albo po interakcji użytkownika.

Cache, CDN i hosting

Ta trójka decyduje o tym, jak szybko serwer w ogóle zaczyna odpowiadać, czyli o fundamencie, na którym stoi reszta.

• Cache strony sprawia, że serwer nie buduje strony od nowa przy każdej wizycie, tylko podaje gotową wersję. Efekt bywa spektakularny, ładowanie potrafi przyspieszyć kilkukrotnie. Na WordPressie sprawdzą się WP Super Cache, LiteSpeed Cache lub WP Rocket.
• CDN (sieć serwerów rozsianych po świecie) serwuje pliki z lokalizacji najbliższej użytkownikowi. Skraca to czas dostarczenia grafik, skryptów i stylów, zwłaszcza gdy masz odbiorców z różnych regionów.
• Hosting jest granicą tego, co da się osiągnąć. Nawet najlepiej zoptymalizowana strona nie pomoże na przeciążonym, tanim serwerze współdzielonym. Szukaj hostingu z dyskami SSD lub NVMe, obsługą HTTP/2 lub HTTP/3, aktualnym PHP 8+ oraz cache po stronie serwera, takim jak Redis czy OPcache.

Czcionki, czyli cichy hamulec

Czcionki webowe rzadko trafiają na listę podejrzanych, a potrafią pogorszyć zarówno LCP, jak i CLS. Kilka nawyków, które pomagają:

• Ładuj tylko potrzebne kroje i grubości. Trzy grubości jednego fontu w zupełności wystarczą większości stron. Każda dodatkowa to kolejny plik do pobrania.
• Hostuj czcionki lokalnie. Trzymanie plików na własnym serwerze eliminuje dodatkowe łączenie z serwerami zewnętrznymi i skraca czas oczekiwania.
• Ustaw font-display: swap. Dzięki temu tekst pojawia się natychmiast w czcionce zastępczej i podmienia się po wczytaniu docelowej, zamiast zostawiać pusty ekran.
• Dobierz zbliżony font zapasowy. Gdy czcionka zastępcza ma podobne proporcje do docelowej, podmiana nie przesuwa układu i CLS pozostaje niski.

Dlaczego to wpływa na SEO i konwersję

Core Web Vitals są jednym z sygnałów, które Google bierze pod uwagę przy ustalaniu pozycji. To nie jest najważniejszy czynnik, treść i dopasowanie do zapytania wciąż ważą więcej, ale przy dwóch podobnych stronach szybsza zwykle wygrywa. Co istotne, mierzone są dane z realnego ruchu i przede wszystkim z wersji mobilnej.

Jeszcze mocniejszy jest wpływ na konwersję. Każda sekunda oczekiwania to część odwiedzających, która wychodzi, zanim zobaczy ofertę. Szybsza strona to niższy współczynnik odrzuceń, więcej wypełnionych formularzy i, w sklepie, więcej zakupów. W praktyce optymalizacja wydajności zwraca się podwójnie: rośnie widoczność w Google i rośnie odsetek osób, które faktycznie coś robią po wejściu na stronę.

Nie musisz wdrażać wszystkiego naraz. Zacznij od pomiaru w PageSpeed Insights, popraw najsłabszą metrykę, a różnicę zobaczysz szybciej, niż myślisz. Jeśli budujesz witrynę od zera, warto od początku postawić na lekki, dobrze zaprojektowany serwis, w którym wydajność jest wpisana w fundament, a nie doklejana później.