Core Web Vitals: jak przyspieszyć stronę (LCP, INP, CLS)

Użytkownik telefonu daje stronie kilka sekund. Jeśli w tym czasie zobaczy pusty ekran albo przycisk, który ucieka spod palca, wraca do wyników wyszukiwania i wybiera konkurencję. Google mierzy te doświadczenia za pomocą trzech wskaźników nazywanych Core Web Vitals i bierze je pod uwagę przy ocenie stron.

W tym poradniku wyjaśniamy, co oznacza każdy wskaźnik, jak go zmierzyć i co konkretnie poprawić.

Trzy wskaźniki w skrócie

Wskaźnik	Co mierzy	Dobry wynik
LCP (Largest Contentful Paint)	Jak szybko pojawia się główna treść, np. zdjęcie lub nagłówek na pierwszym ekranie	do 2,5 s
INP (Interaction to Next Paint)	Jak szybko strona reaguje na kliknięcia, dotknięcia i pisanie	do 200 ms
CLS (Cumulative Layout Shift)	Czy elementy strony przeskakują podczas ładowania	do 0,1

Google ocenia stronę na podstawie 75. percentyla wizyt prawdziwych użytkowników. W praktyce oznacza to, że co najmniej trzy na cztery wizyty muszą mieścić się w dobrym zakresie.

INP od marca 2024 roku zastąpił wcześniejszy wskaźnik FID. Jest bardziej wymagający, bo mierzy wszystkie interakcje podczas wizyty, a nie tylko pierwszą.

Jak zmierzyć Core Web Vitals

• PageSpeed Insights (pagespeed.web.dev): pokazuje dane od prawdziwych użytkowników (jeśli strona ma wystarczający ruch) oraz test laboratoryjny z listą konkretnych problemów.
• Google Search Console, raport „Podstawowe wskaźniki internetowe”: pokazuje, które grupy podstron mają problemy.
• Lighthouse w przeglądarce Chrome: test laboratoryjny, przydatny podczas pracy nad poprawkami.

Zawsze sprawdzaj wynik na telefonie. Wersja komputerowa niemal zawsze wypada lepiej, a większość ruchu w małych firmach pochodzi z telefonów. Dlatego szybkość warto planować już na etapie projektu, o czym piszemy w tekście o stronie mobile first. Szybkie podsumowanie podstaw technicznych daje też nasz darmowy audyt strony.

Jak poprawić LCP

LCP to najczęściej zdjęcie w hero albo duży nagłówek. Główne przyczyny słabego wyniku i rozwiązania:

Za duże zdjęcia. Zdjęcie z aparatu ma kilka megabajtów, a na telefonie wystarczy kilkadziesiąt kilobajtów. Używaj nowoczesnych formatów (WebP, AVIF), przygotuj kilka rozmiarów obrazka i pozwól przeglądarce wybrać właściwy (atrybuty srcset i sizes).

Leniwe ładowanie głównego zdjęcia. Atrybut loading="lazy" jest świetny dla obrazków niżej na stronie, ale na zdjęciu z pierwszego ekranu opóźnia jego wyświetlenie. Główne zdjęcie ładuj od razu, najlepiej z fetchpriority="high".

Wolny serwer. Jeśli serwer odpowiada dłużej niż pół sekundy, cała reszta też się opóźnia. Pomaga lepszy hosting, cache stron, a dla stron statycznych serwowanie z sieci CDN.

Blokujące czcionki i style. Ogromny plik CSS z całym motywem albo kilka krojów pisma ładowanych z zewnętrznych serwerów potrafią wstrzymać wyświetlanie. Ładuj tylko używane grubości czcionek, z własnego serwera, z font-display: swap.

Jak poprawić INP

Słaby INP to prawie zawsze za dużo JavaScriptu wykonywanego w przeglądarce.

• Skrypty zewnętrzne: czaty, piksele reklamowe, mapy, widżety opinii, wtyczki do social mediów. Każdy z nich zajmuje procesor telefonu. Usuń te, których nikt nie używa, a resztę ładuj z opóźnieniem lub dopiero wtedy, gdy są potrzebne.
• Page buildery i rozbudowane motywy: potrafią ładować kod wszystkich swoich funkcji na każdej podstronie. Rezygnacja z nich zwykle daje największy skok.
• Długie zadania: jeśli kliknięcie uruchamia skomplikowaną operację, trzeba ją podzielić na mniejsze kawałki, żeby przeglądarka mogła w międzyczasie odświeżyć ekran.

Dobrym testem jest otwarcie strony na starszym telefonie i stuknięcie w menu: jeśli reaguje z opóźnieniem, INP też będzie słaby.

Jak poprawić CLS

Przeskakujący układ to jeden z najbardziej irytujących problemów: chcesz kliknąć link, a w ostatniej chwili wskakuje nad niego baner.

• Podawaj wymiary obrazków i filmów (width i height albo aspect-ratio w CSS). Przeglądarka zarezerwuje wtedy miejsce, zanim obrazek się wczyta.
• Rezerwuj miejsce na reklamy, banery cookies i widżety, zamiast wsuwać je nad treść.
• Uważaj na czcionki: gdy zapasowy krój ma inne proporcje niż docelowy, tekst po podmianie zmienia długość. Pomaga dobór podobnej czcionki zapasowej i wczesne ładowanie fontów.
• Animacje rób za pomocą transform i opacity, a nie zmiany wysokości czy marginesów.

Jak czytać raport w Search Console

Raport „Podstawowe wskaźniki internetowe” dzieli adresy na trzy grupy: dobre, wymagające poprawy i słabe. Progi dla oceny „słabe” to LCP powyżej 4 s, INP powyżej 500 ms i CLS powyżej 0,25. Wszystko pomiędzy dobrym wynikiem a tymi progami Google oznacza jako „wymaga poprawy”.

Kilka rzeczy, które warto wiedzieć, zanim zaczniesz poprawki:

• Adresy są grupowane. Search Console pokazuje przykładowy adres i grupę podobnych stron. Jeśli problem dotyczy szablonu wpisu blogowego, poprawka w szablonie naprawi całą grupę.
• Mobile i komputer to osobne raporty. Zacznij od wersji mobilnej, bo tam problemy są zwykle poważniejsze.
• Dane spływają z opóźnieniem. Raport opiera się na wizytach z ostatnich 28 dni, więc efekt poprawki zobaczysz dopiero po kilku tygodniach.
• Weryfikacja poprawki. Po wdrożeniu zmian kliknij „Sprawdź poprawkę”. Google przez kolejne tygodnie śledzi wizyty i potwierdza, czy problem zniknął.
• Brak danych to nie błąd. Mała strona z niewielkim ruchem może nie mieć danych od użytkowników. Wtedy opieraj się na teście laboratoryjnym w PageSpeed Insights.

Wskaźniki szybkości to tylko część technicznego zdrowia strony. Resztę, czyli indeksowanie, przekierowania i mapę witryny, sprawdzisz z naszą checklistą SEO technicznego.

Co psuje wyniki po starcie strony

Strona, która w dniu startu była szybka, po roku często wypada gorzej. Zwykle nie przez jedną dużą zmianę, tylko przez wiele drobnych:

• zdjęcia wgrywane do panelu prosto z telefonu, bez zmniejszenia,
• kolejne skrypty marketingowe: nowy piksel, narzędzie do map kliknięć, widżet opinii,
• baner cookies dodany bez zarezerwowanego miejsca,
• osadzone filmy i mapy ładowane od razu, zamiast po kliknięciu,
• nowe wtyczki instalowane „na próbę” i nigdy nieusunięte.

Pomaga prosta zasada: każdy nowy skrypt lub widżet ma właściciela i powód, a raz na kwartał przeglądasz, czy nadal jest potrzebny. Dobry panel do edycji treści może też sam zmniejszać i konwertować zdjęcia, dzięki czemu osoby dodające treści nie muszą o tym pamiętać.

Kiedy poprawki nie wystarczą

Część stron da się przyspieszyć w kilka godzin: kompresja obrazków, usunięcie zbędnych wtyczek, ustawienie cache. Bywa jednak, że problem leży w samych fundamentach: ciężkim motywie, kreatorze stron, przestarzałym hostingu. Wtedy kolejne wtyczki „przyspieszające” dają niewiele, a każda aktualizacja psuje wynik od nowa.

W takiej sytuacji często bardziej opłaca się przebudowa strony na lżejszej technologii. Porównanie dwóch popularnych podejść opisaliśmy w artykule Astro czy WordPress. Przykład z naszej praktyki: strona biura rachunkowego SH TAX zbudowana w Astro osiąga w Lighthouse na telefonie 100 punktów w SEO i dostępności oraz 94–97 w wydajności.

Lista kontrolna

• Główne zdjęcie: WebP lub AVIF, właściwy rozmiar, bez leniwego ładowania, fetchpriority="high".
• Pozostałe obrazki: leniwe ładowanie i podane wymiary.
• Czcionki: tylko potrzebne grubości, z własnego serwera, font-display: swap.
• Skrypty zewnętrzne: przegląd i usunięcie zbędnych, reszta ładowana z opóźnieniem.
• Serwer: odpowiedź poniżej 0,5 s, cache, kompresja, w miarę możliwości CDN.
• Banery i widżety: zarezerwowane miejsce, bez wsuwania nad treść.
• Kontrola co miesiąc w Search Console.

Podsumowanie

Core Web Vitals to nie wyścig o 100 punktów w teście, tylko o to, czy prawdziwi użytkownicy na zwykłych telefonach mogą wygodnie korzystać ze strony. Większość problemów ma kilka powtarzalnych przyczyn: za duże obrazki, za dużo skryptów i elementy bez zarezerwowanego miejsca.

Jeśli chcesz, żebyśmy sprawdzili Twoją stronę i ocenili, czy wystarczą poprawki, czy lepsza będzie przebudowa, napisz do nas. Więcej o tym, jak pracujemy nad widocznością w Google, przeczytasz na stronie o pozycjonowaniu stron.