Wyszukiwarka Google od dawna promuje serwisy, które dbają o komfort użytkownika, a wskaźniki Core Web Vitals – jak przyspieszyć stronę i poprawić LCP, INP i CLS to obecnie fundament technicznego SEO. Nie chodzi już tylko o to, by strona w ogóle się ładowała, ale o to, jak szybko staje się ona użyteczna i czy jej elementy nie „skaczą” podczas przeglądania treści na smartfonie. W Serwis IT codziennie analizujemy dziesiątki witryn, które mimo świetnej treści tracą zasięgi, bo ich parametry techniczne świecą się w raportach na czerwono.
Zrozumienie tych metryk wymaga odejścia od ogólnego pojęcia szybkości ładowania na rzecz precyzyjnych pomiarów interakcji. Google wybrało trzy główne filary, które najlepiej oddają odczucia człowieka siedzącego przed ekranem. To właśnie one decydują o tym, czy algorytm uzna naszą stronę za godną zaufania i wysokich pozycji w wynikach wyszukiwania. Ignorowanie tych sygnałów to prosta droga do spadków, zwłaszcza w świecie Mobile First Index.
W tym artykule przeanalizujemy każdy z parametrów, wskażemy realne progi, które musimy osiągnąć, i podpowiemy, które optymalizacje przynoszą najszybsze efekty. Skupimy się na praktyce, unikając teoretyzowania, bo w świecie IT liczy się czas renderowania liczony w milisekundach i stabilność wizualna, która przekłada się na wyższą konwersję w sklepach internetowych czy serwisach usługowych.
Czym dokładnie są wskaźniki Core Web Vitals
Podstawowe wskaźniki internetowe to zestaw trzech metryk, które oceniają szybkość ładowania, responsywność interakcji oraz stabilność wizualną. Google wprowadziło je, aby ujednolicić standardy oceny jakości technicznej stron. Pierwszy z nich, LCP (Largest Contentful Paint), mierzy czas potrzebny na wyrenderowanie największego elementu widocznego w oknie przeglądarki. Zazwyczaj jest to zdjęcie główne, baner lub duży blok tekstu. Jeśli ten element pojawia się zbyt późno, użytkownik odnosi wrażenie, że strona jest wolna.
Drugi wskaźnik to stosunkowo nowa metryka, która zastąpiła FID. Mowa o INP (Interaction to Next Paint). Mierzy ona opóźnienie w reakcji strony na działania użytkownika, takie jak kliknięcie w przycisk czy rozwinięcie menu, przez cały czas trwania sesji. To ogromna zmiana, bo wcześniej badano tylko pierwszą interakcję. Teraz liczy się płynność działania witryny od początku do końca wizyty. Trzeci filar to CLS (Cumulative Layout Shift), czyli wskaźnik przesunięć układu. Określa on, jak bardzo elementy strony zmieniają swoje położenie podczas ładowania, co często prowadzi do irytujących pomyłek, na przykład kliknięcia w reklamę zamiast w przycisk „Dalej”.
Często widzimy, że właściciele stron skupiają się na wynikach w testach syntetycznych, zapominając, że Google bierze pod uwagę dane od realnych użytkowników z ostatnich 28 dni. Jeśli Twój serwer działa wolno tylko w godzinach szczytu, to właśnie te opóźnienia wpłyną na Twoje pozycje w wyszukiwarce, nawet jeśli w nocy narzędzia pokazują idealne wyniki. Tomasz, administrator serwisu Serwis IT, od 2012 roku projektuje strony i prowadzi kampanie SEO dla firm
Progi punktowe i interpretacja wyników
Aby strona została uznana za spełniającą standardy, musi mieścić się w określonych przedziałach czasowych i punktowych dla co najmniej 75% wizyt zarejestrowanych przez przeglądarkę Chrome. Google stosuje prostą sygnalizację: kolor zielony oznacza „dobry”, żółty „wymaga poprawy”, a czerwony „słaby”. Walka o zielone wyniki to nie tylko kwestia prestiżu, ale realny czynnik rankingowy, który może dać nam przewagę nad konkurencją o podobnym profilu linków i treści.
| Wskaźnik | Dobry (Zielony) | Wymaga poprawy (Żółty) | Słaby (Czerwony) |
|---|---|---|---|
| LCP (Czas ładowania) | poniżej 2,5 s | 2,5 s – 4,0 s | powyżej 4,0 s |
| INP (Responsywność) | poniżej 200 ms | 200 ms – 500 ms | powyżej 500 ms |
| CLS (Stabilność) | poniżej 0,1 | 0,1 – 0,25 | powyżej 0,25 |
Warto zauważyć, że progi te są identyczne dla urządzeń mobilnych i komputerów stacjonarnych, ale znacznie trudniej osiągnąć je na telefonach. Bo słabsze procesory mobilne i niestabilne łącza komórkowe sprawiają, że skrypty JavaScript wykonują się wolniej. U nas w Serwis IT zawsze zaczynamy optymalizację od wersji mobilnej, bo to ona jest obecnie priorytetem dla robotów Google.
Skąd brać dane do analizy Core Web Vitals
Dane dzielimy na dwa rodzaje: laboratoryjne i terenowe. Dane laboratoryjne pochodzą z testów wykonywanych w kontrolowanym środowisku. Są świetne do debugowania, bo pozwalają natychmiast sprawdzić, czy wprowadzona zmiana w kodzie przyniosła efekt. Dane terenowe (Field Data) pochodzą z raportu Chrome User Experience Report (CrUX) i to one faktycznie decydują o rankingu. Gromadzą one informacje od prawdziwych osób odwiedzających naszą stronę w różnych warunkach.
- Narzędzia konsolowe dla webmasterów – to najważniejsze źródło informacji o tym, jak Google widzi naszą stronę. W sekcji „Podstawowe wskaźniki internetowe” znajdziemy gotowe listy adresów URL pogrupowane według problemów.
- Przeglądarkowe narzędzia deweloperskie – pozwalają na symulację wolnego łącza i słabszego procesora, co jest niezbędne do wyłapania błędów w LCP i INP.
- Publiczne testery wydajności – generują czytelne raporty z listą konkretnych plików, które blokują renderowanie strony.
- Wtyczki do przeglądarek – umożliwiają bieżący podgląd wskaźników podczas nawigacji po serwisie, co ułatwia wykrywanie nagłych skoków CLS.
I chociaż narzędzia te są darmowe, to interpretacja ich wyników wymaga wprawy. Często zdarza się, że jeden ciężki skrypt zewnętrzny, np. czat lub piksel śledzący, psuje wyniki całej domeny. Dlatego tak ważne jest, by patrzeć na dane w ujęciu długofalowym, a nie tylko po jednym odświeżeniu strony.
Jak poprawić LCP – walka o najszybszy start
Poprawa LCP to zazwyczaj największe wyzwanie techniczne. Skoro mierzymy czas renderowania największego elementu, musimy sprawdzić, co nim jest. W większości przypadków na stronach głównych to grafika w formacie JPG lub PNG. Pierwszym krokiem powinna być optymalizacja obrazów. Zmiana formatu na nowocześniejszy WebP lub AVIF potrafi zmniejszyć wagę pliku o 50–80% bez widocznej utraty jakości. Ale to nie wszystko. Musimy też zadbać o odpowiednie priorytety ładowania.
Stosujemy tutaj technikę „preload” dla najważniejszych zasobów. Jeśli przeglądarka dowie się o istnieniu głównego zdjęcia już w nagłówku dokumentu, zacznie je pobierać równolegle z analizą kodu CSS. Kolejnym aspektem jest czas odpowiedzi serwera (TTFB). Jeśli hosting potrzebuje sekundy na wysłanie pierwszego bajtu, nie ma szans na zielone LCP. Tu rozwiązaniem może być wdrożenie pamięci podręcznej (caching) na poziomie serwera lub skorzystanie z sieci dostarczania treści (CDN), która przechowuje kopie strony bliżej użytkownika.
Typowe błędy przy LCP, które widzimy w praktyce:
- Ładowanie ogromnych grafik (np. 4000 px szerokości) w miejscu, gdzie wyświetlają się w rozmiarze 400 px.
- Blokowanie renderowania przez nieoptymalne arkusze stylów CSS i skrypty JS umieszczone w sekcji head.
- Używanie animowanych sliderów na samej górze strony, które inicjują się dopiero po pełnym załadowaniu ciężkich bibliotek.
- Brak kompresji Gzip lub Brotli na serwerze, co wydłuża przesyłanie plików tekstowych.
Optymalizacja INP – jak sprawić, by strona reagowała natychmiast
Wskaźnik INP zastąpił FID, bo Google uznało, że badanie tylko pierwszego kliknięcia nie oddaje w pełni jakości interakcji. Teraz liczy się każde kliknięcie, dotknięcie ekranu i wpisanie tekstu. Głównym winowajcą słabego INP jest nadmiar JavaScriptu, który „zapycha” główny wątek przeglądarki. Gdy procesor urządzenia zajęty jest przetwarzaniem ciężkich skryptów, nie może zareagować na działanie użytkownika. Strona wydaje się wtedy „zamrożona”.
Rozwiązaniem jest dzielenie długich zadań na mniejsze fragmenty. Zamiast ładować jeden ogromny plik JS o wadze 500 KB, warto podzielić go na mniejsze moduły ładowane tylko wtedy, gdy są potrzebne. Ważne jest też odroczenie ładowania skryptów trzeciej firmy. Analizy marketingowe, widgety mediów społecznościowych czy systemy komentarzy powinny być ładowane z opóźnieniem lub dopiero po pierwszej interakcji użytkownika. U nas w Serwis IT często stosujemy zasadę minimalizmu – jeśli skrypt nie jest niezbędny do działania strony, ląduje w kolejce do późniejszego wczytania.
Koszty profesjonalnej optymalizacji kodu pod INP wahają się zazwyczaj od 1500 zł do 5000 zł netto, zależnie od stopnia skomplikowania serwisu. Ale efekty w postaci płynnego działania na starszych smartfonach są tego warte. Bo nic tak nie zniechęca klienta, jak przycisk „Dodaj do koszyka”, który reaguje po dwóch sekundach od kliknięcia.
Eliminacja CLS – koniec z uciekającą treścią
CLS to metryka najbardziej związana z kodem HTML i CSS. Przesunięcia układu zdarzają się najczęściej, gdy przeglądarka nie wie, ile miejsca zarezerwować dla elementu, który jeszcze się nie wczytał. Klasycznym przykładem jest obrazek bez określonych wymiarów width i height w kodzie. Przeglądarka najpierw wyświetla tekst, a gdy nagle pobierze obrazek, „wpycha” go między akapity, przesuwając wszystko w dół.
Aby poprawić CLS, musimy zawsze definiować proporcje dla multimediów. Dotyczy to nie tylko zdjęć, ale też ramek wideo (iframe) i banerów reklamowych. Reklamy są szczególnie problematyczne, bo często mają zmienną wysokość. Dobrą praktyką jest rezerwowanie dla nich stałego kontenera o minimalnej wysokości, aby ich pojawienie się nie powodowało skoku treści. Podobnie sprawa ma się z czcionkami webowymi. Jeśli czcionka systemowa ma inne wymiary niż ta docelowa, w momencie podmiany (tzw. FOIT/FOUT) tekst może się „rozjechać”. Stosujemy wtedy odpowiednie deskryptory w CSS, które dopasowują rozmiar czcionki zastępczej.
Przykładowe działania naprawcze dla CLS:
- Dodanie atrybutów szerokości i wysokości do każdego znacznika img.
- Używanie właściwości CSS aspect-ratio dla nowoczesnych układów.
- Unikanie wstawiania nowej treści (np. newslettera) powyżej aktualnie czytanego tekstu bez interakcji użytkownika.
- Zapewnienie, że animacje CSS korzystają z właściwości transform, a nie z parametrów takich jak top czy left, które wymuszają przeliczenie całego układu strony.
Specyfika optymalizacji na urządzeniach mobilnych
Urządzenia mobilne to obecnie ponad 60% ruchu w polskim internecie. Optymalizacja Core Web Vitals – jak przyspieszyć stronę i poprawić LCP, INP i CLS na telefonach jest trudniejsza ze względu na ograniczenia sprzętowe. Widzimy to wyraźnie w raportach: ta sama strona na desktopie ma wynik 95/100, a na mobile ledwo 40/100. Wynika to z faktu, że telefony mają znacznie słabszą wydajność jednowątkową procesora, co przy ciężkich skryptach JS staje się wąskim gardłem.
Kolejnym aspektem jest technologia sieciowa. Nawet w dobie 5G, użytkownicy w ruchu często korzystają z zasięgu 3G lub niestabilnego LTE. W takich warunkach każdy dodatkowy kilobajt danych i każde dodatkowe zapytanie do serwera (HTTP request) wydłużają czas oczekiwania. Dlatego tak ważne jest łączenie plików CSS i JS oraz minimalizacja ich objętości. Ale uwaga – zbyt duże pliki zbiorcze też mogą szkodzić, bo blokują procesor podczas ich parsowania. Złotym środkiem jest dostarczanie „krytycznego CSS” bezpośrednio w kodzie HTML, co pozwala na natychmiastowe wyświetlenie górnej części strony.
Warto też zwrócić uwagę na rozmiary elementów dotykowych. Choć nie jest to bezpośrednia część Core Web Vitals, wpływa na ogólną ocenę Page Experience. Przyciski zbyt blisko siebie mogą powodować błędne kliknięcia, co pośrednio wpływa na frustrację mierzoną przez INP. Zmiany w projekcie graficznym (UI) często muszą iść w parze z poprawkami technologicznymi.
Aspekty prawne i biznesowe szybkości stron
W Polsce i Unii Europejskiej przepisy nie nakazują wprost, by strona ładowała się w określonym czasie, ale prawo ochrony konsumentów oraz RODO mają tu swoje pośrednie znaczenie. Przeładowana skryptami śledzącymi strona nie tylko wolno działa, ale często narusza prywatność użytkowników poprzez nieprawidłowe zarządzanie plikami cookies przed wyrażeniem zgody. Optymalizacja techniczna to świetna okazja, by uporządkować kwestie prawne i usunąć zbędne kody śledzące, które nie są nam już potrzebne.
Z punktu widzenia biznesu, inwestycja w Core Web Vitals to jedna z najlepiej zwracających się prac deweloperskich. Statystyki są nieubłagane: każda sekunda opóźnienia powyżej trzech sekund to spadek konwersji o około 7–10%. Jeśli Twój sklep generuje 50 000 zł obrotu miesięcznie, poprawa szybkości może przynieść dodatkowe kilka tysięcy złotych bez wydawania złotówki więcej na reklamy. Koszt audytu SEO pod kątem technicznym zaczyna się od około 800 zł netto, a kompleksowe wdrożenie poprawek to wydatek rzędu 2000–6000 zł netto, w zależności od silnika strony (np. WordPress, PrestaShop czy dedykowany framework).
Najczęstsze pytania
Czy wynik 100/100 w testach jest konieczny do wysokich pozycji?
Nie, nie jest konieczny. Google oczekuje, że strona będzie „dobra”, czyli znajdzie się w zielonym polu. Walka o każdy ostatni punkt powyżej 90 często nie ma już realnego wpływu na ranking, a może być bardzo kosztowna w realizacji. Skupmy się na stabilnym utrzymaniu wskaźników w normie dla realnych użytkowników.
Czy hosting ma wpływ na CLS?
Bezpośrednio nie. CLS zależy od kodu strony i sposobu ładowania zasobów. Hosting ma jednak gigantyczny wpływ na LCP i TTFB. Jeśli serwer jest przeciążony, pobieranie obrazów i skryptów trwa dłużej, co pośrednio może opóźniać renderowanie elementów i wpływać na odczucia użytkownika.
Czy przejście na WebP wystarczy, by naprawić LCP?
To bardzo pomaga, ale rzadko wystarcza. LCP zależy też od struktury kodu HTML, priorytetów ładowania w przeglądarce i tego, jak szybko serwer dostarczy pierwszy dokument. Sama kompresja zdjęć to tylko jeden z elementów układanki, choć często najprostszy do wdrożenia.
Jak często Google aktualizuje dane o Core Web Vitals dla mojej strony?
Dane w Search Console są aktualizowane codziennie, ale bazują na średniej kroczącej z ostatnich 28 dni. Oznacza to, że po wprowadzeniu poprawek nie zobaczysz zmian natychmiast. Musisz uzbroić się w cierpliwość i monitorować trendy przez co najmniej 2–3 tygodnie, aby mieć pewność, że optymalizacja przyniosła skutek.
