Page Speed i Core Web Vitals a pozycje w Google

Najważniejsze informacje w pigułce

Google oficjalnie potwierdza, że Core Web Vitals (CWV) są używane przez jego systemy rankingowe. Dokumentacja Search Central mówi wprost: „Core Web Vitals are used by our ranking systems”.
To nie jest potężny czynnik, który wynosi strony na szczyt. Google podkreśla, że nie ma jednego sygnału, a dobre wyniki w raporcie CWV nie gwarantują dobrych pozycji. Ważniejsza jest trafność treści.
Trzy metryki, trzy progi: LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1, oceniane dla 75. percentyla prawdziwych użytkowników, osobno dla mobile i desktop.
Do rankingu ważne są dane z „terenu” (field data), a nie sam wynik w Lighthouse. Ocena 0–100 w PageSpeed Insights jest diagnostyką, a nie tym, co Google bezpośrednio porównuje.
Najmocniejszy argument za szybkością to nie ranking, tylko użytkownik. Badanie Google i Deloitte wykazało, że poprawa o 0,1 s w kilku metrykach mobilnych wiązała się z wyższymi konwersjami w e-commerce (szczegóły i zastrzeżenia niżej).
Dla sklepu takiego jak Shrimpfan (WordPress + WooCommerce, dużo zdjęć produktowych i blogowych): test z 25 października 2026 dał 84 pkt na mobile i 99 na desktopie, a największy szacowany zysk (ok. 1,96 s) daje usunięcie zasobów blokujących renderowanie.

Co właściwie oznacza „wskaźnik szybkości strony”

W rozmowach o SEO „page speed” znaczy trzy różne rzeczy i warto je rozróżnić:

Wynik 0–100 w PageSpeed Insights (Lighthouse). To symulacja na zadanym urządzeniu i łączu. Pokazuje, co można poprawić, ale to wynik laboratoryjny (lab data).
Core Web Vitals z danych użytkowników (field data, CrUX). To rzeczywiste doświadczenia odwiedzających, zbierane z przeglądarki Chrome w oknie 28 dni. Właśnie ten rodzaj danych odpowiada temu, co Google bierze pod uwagę w wyszukiwarce.
Subiektywna szybkość. To, czy strona „wydaje się szybka”. Mierzy to np. czas reakcji na kliknięcie.

Najczęstszy błąd to optymalizowanie pod zielony wynik 95–100 w teście laboratoryjnym, podczas gdy rzeczywiści użytkownicy na słabszych telefonach widzą co innego. Wynik 100 nie jest celem. Celem jest przejście progów CWV dla prawdziwych użytkowników.

Co mówi Google: chronologia

2010: szybkość w rankingu desktopowym. Google używał szybkości strony w wynikach desktopowych już od kwietnia 2010 roku.

2018: Speed Update dla mobile. W styczniu 2018 Google ogłosił, że od lipca szybkość będzie czynnikiem rankingowym w wyszukiwaniu mobilnym. Jednocześnie zaznaczył, że zmiana dotknie tylko stron o najwolniejszym doświadczeniu i niewielkiego odsetka zapytań. To ważne: nie chodziło o nagradzanie szybkich, tylko o osłabianie bardzo wolnych.

2020–2021: Core Web Vitals w page experience. Google zapowiedział włączenie CWV do sygnałów „doświadczenia ze strony” i wdrożył je w 2021 roku, najpierw dla mobile, później dla desktopu. Według wypowiedzi inżyniera Google (Philip Walton) Web Vitals nie działały jako sztywny, binarny czynnik rankingowy.

Kwiecień 2023: uporządkowanie przekazu. Google przeredagował dokumentację i podkreślił, że nie istnieje pojedynczy „sygnał page experience”, a główne systemy rankingowe patrzą na zestaw sygnałów związanych z doświadczeniem na stronie. Wyraźnie zaznaczył też, że dobre wyniki w raporcie CWV w Search Console nie gwarantują dobrych pozycji.

Marzec 2024: INP zastępuje FID. Metryka Interaction to Next Paint zastąpiła First Input Delay jako trzeci element Core Web Vitals. Przy okazji dokumentacja została doprecyzowana: Core Web Vitals są używane przez systemy rankingowe, a pozostałe elementy page experience nie pomagają bezpośrednio w rankingu.

Dziś. Według oficjalnej dokumentacji Google gorąco zaleca osiąganie dobrych CWV, bo wpisuje się to w to, co jego systemy rankingowe chcą nagradzać. Jednocześnie Google pisze, że wyszukiwarka stara się pokazać najbardziej trafną treść nawet wtedy, gdy doświadczenie na stronie jest słabe. Według dostępnych opracowań progi CWV w 2026 roku się nie zmieniły.

Jakie są dowody na korelację szybkości i pozycji

Tu trzeba być uczciwym, bo w tym temacie krąży dużo przesady.

Co jest potwierdzone przez Google:

CWV są używane w systemach rankingowych (dokumentacja Search Central).
Szybkość mobilna jest sygnałem od 2018 roku i dotyczy głównie stron najwolniejszych.
Do oceny wykorzystywane są dane z prawdziwych odwiedzin (CrUX), a nie wyniki laboratoryjne.

Czego Google nie publikuje:

Siły tego sygnału. Nie ma oficjalnych liczb typu „poprawa LCP o sekundę daje X pozycji”.
Wagi CWV względem treści, linków i dopasowania do intencji.

Co wynika z tego w praktyce: wiarygodne stanowisko brzmi tak, że CWV działają raczej jako czynnik wspierający lub rozstrzygający przy zbliżonej trafności treści, a nie jako dźwignia, która przeskoczy konkurencję z lepszą treścią i linkami. To moja interpretacja oficjalnych wypowiedzi, a nie cytat z Google. Zewnętrzne badania korelacyjne istnieją, ale nie dowodzą przyczynowości: szybkie strony często są po prostu lepiej zarządzane i częściej objęte pracą nad SEO.

Dlaczego warto dbać o szybkość, nawet jeśli ranking to nie wszystko

Najmocniejsze dane dotyczą nie pozycji, tylko zachowania użytkowników.

Badanie „Milliseconds Make Millions” (Google, 55 i Deloitte Digital) objęło ok. 30 milionów sesji z mobilnych stron 37 marek. Wnioski:

Poprawa o 0,1 s w czterech metrykach szybkości wiązała się ze wzrostem konwersji o 8,4% w retailu i 10,1% w turystyce.
W retailu średnia wartość zamówienia wzrosła o 9,2%.
Bounce rate na listach produktowych poprawił się o ok. 5,7% w retailu.

Zastrzeżenia, których nie wolno pominąć:

Badanie zostało zlecone przez Google i dotyczyło dużych marek, a nie małych sklepów niszowych.
Poprawa 0,1 s dotyczyła czterech metryk jednocześnie (m.in. czasu odpowiedzi serwera, pierwszego renderu, opóźnienia wejścia i czasu ładowania), na każdej stronie ścieżki zakupowej.
To korelacja zaobserwowana w danych, a nie obietnica dla każdego sklepu. Nie należy przenosić tych procentów wprost na własną stronę.

Z tego samego badania wynika też, że po przekroczeniu ok. 1 sekundy użytkownicy zaczynają tracić koncentrację na zadaniu, a po 10 sekundach są sfrustrowani i często rezygnują.

Dla sklepu internetowego wniosek jest prosty: nawet jeśli wpływ na pozycje jest umiarkowany, wolna strona kosztuje sprzedaż, bo każdy odwiedzający, który wyjdzie z karty produktu, to utracony klient. A skoro ruch z Google wymaga tyle wysiłku, szkoda go tracić na etapie ładowania.

Trzy metryki Core Web Vitals i ich progi

Metryka	Co mierzy	Dobry	Wymaga poprawy	Słaby
LCP (Largest Contentful Paint)	Kiedy pojawia się największy element treści, zwykle główne zdjęcie lub nagłówek	≤ 2,5 s	2,5–4,0 s	> 4,0 s
INP (Interaction to Next Paint)	Jak szybko strona reaguje na kliknięcia i dotknięcia	≤ 200 ms	200–500 ms	> 500 ms
CLS (Cumulative Layout Shift)	Jak bardzo układ „skacze” podczas ładowania	≤ 0,1	0,1–0,25	> 0,25

Jak liczy się zaliczenie: wynik oceniany jest dla 75. percentyla odwiedzin w ruchomym oknie 28 dni. Strona zalicza się, gdy co najmniej 75% prawdziwych odwiedzin mieści się w progu „dobry” dla danej metryki. Ocena odbywa się osobno dla mobile i desktop.

Mobile kontra desktop

Te same strony zwykle wypadają gorzej na telefonie, bo mobilne procesory są słabsze, a łącze mniej stabilne. Dlatego:

Zaczynaj od mobile. Google stosuje indeksowanie mobile-first, a u większości sklepów spora część ruchu pochodzi z telefonów.
Sprawdzaj oba urządzenia osobno. Zielony desktop nie znaczy zielonego mobile.
Największe różnice powstają w INP i LCP. Ciężkie skrypty bardziej bolą słabe telefony, a duże obrazy bardziej bolą wolne łącza.

Studium przypadku: Shrimpfan

Pracujemy na przykładzie sklepu i bloga Shrimpfan (shrimpfan.pl), poświęconego hodowli krewetek Caridina. Analiza opiera się na kodzie strony głównej oraz na teście PageSpeed Insights z 25 października 2026, wykonanym dla strony głównej. Test dotyczy jednej podstrony, więc wnioski odnoszą się do niej, a nie do całego sklepu.

Co widać na stronie głównej

Platforma: WordPress z WooCommerce (adresy produktów w formacie /produkt/, linki dodawania do koszyka) oraz wtyczką Site Kit by Google.
Meta viewport jest ustawiony, więc strona jest przygotowana pod urządzenia mobilne.
Obrazy w formacie WebP. Nazwy plików sugerują, że zdjęcia były wcześniej zmniejszane (w nazwach pojawia się „Easy Resize”). To dobry znak, bo obrazy są najczęstszą przyczyną słabego LCP.
Strona główna jest bogata w grafiki: hero, kafelki kategorii, zdjęcia produktów, miniatury sześciu wpisów blogowych, sekcje z zaletami i formularz newslettera. To oznacza wiele zapytań do serwera i duże ryzyko, że element LCP będzie obrazem.
Skrypty zewnętrzne: Site Kit i wtyczki sklepowe zwykle dokładają analitykę, formularze i paski zgody. To typowe źródło problemów z INP.

Wyniki testu PageSpeed Insights z 25 października 2026

Strona główna dostała 84 pkt na mobile i 99 pkt na desktopie, a dla obu urządzeń PageSpeed Insights pokazuje „Brak danych” w sekcji wrażeń prawdziwych użytkowników.

Kategoria	Mobile	Desktop
Wydajność	84	99
Ułatwienia dostępu	90	90
Sprawdzone metody	100	100
SEO	100	100
Dane od prawdziwych użytkowników (CWV)	brak danych	brak danych

Co to znaczy. Brak danych terenowych oznacza, że Google nie zebrał jeszcze dość odwiedzin z Chrome dla tej domeny, żeby ocenić LCP, INP i CLS. To typowe dla niszowych stron o niewielkim ruchu. To moja interpretacja: w takiej sytuacji szybkość nie jest dziś ani przewagą, ani słabością Shrimpfan w tym sygnale, a wyniki laboratoryjne służą jako wskazówka, co poprawić. Wynik 99 na desktopie nie wymaga działań, a 84 na mobile jest blisko zielonego progu (90).

Co poprawić na mobile, według raportu

Poniższa kolejność wynika z oszacowanych zysków i z mojej oceny priorytetów.

Zasoby blokujące renderowanie (szacunkowo 1960 ms). To największa oszczędność w raporcie. Chodzi o pliki CSS i JavaScript w nagłówku, które przeglądarka pobiera, zanim cokolwiek pokaże. Rozwiązania: odroczenie nieistotnych skryptów, wczytanie krytycznego CSS od razu, a reszty później, oraz ograniczenie wtyczek, które dokładają pliki na każdej podstronie.
Wykrywanie żądań LCP. Przeglądarka odkrywa główny obraz zbyt późno. Częste przyczyny to leniwe ładowanie obrazu z pierwszego ekranu albo wczytywanie go jako tła w CSS. Na podglądzie strony widać duży ciemny obraz w nagłówku, więc to prawdopodobny kandydat na element LCP, ale wymaga potwierdzenia w rozwiniętym audycie. Naprawa: wyłączyć lazy loading dla tego obrazu i nadać mu wysoki priorytet (fetchpriority) lub wstępne ładowanie (preload).
Drzewo zależności sieciowych. Pokazuje łańcuchy, w których jeden plik czeka na drugi. Skraca się je przez preconnect do domen zewnętrznych i preload kluczowych zasobów.
Wymuszone przeformatowanie. Skrypt odczytuje wymiary elementów tuż po zmianie układu, co zmusza przeglądarkę do ponownego liczenia. Raport zwykle wskazuje plik źródłowy (motyw, wtyczka lub skrypt zewnętrzny), więc to zadanie raczej dla programisty.
Obrazy (szac. 108 KiB) i nieużywany CSS (szac. 60 KiB). Dopasowanie wymiarów obrazów do miejsca wyświetlania, mocniejsza kompresja i usunięcie CSS, którego strona nie używa. Obrazy są już w WebP, więc to dopracowanie, a nie przebudowa.
Czcionki (szac. 10 ms). Zysk jest niewielki. Wystarczy ustawić wyświetlanie tekstu od razu (font-display: swap).

Raport zaznacza przy diagnostyce, że te liczby nie mają bezpośredniego wpływu na sam wynik wydajności, więc służą do znalezienia przyczyn, a nie do zdobywania punktów.

Czego jeszcze brakuje do pełnej oceny

Wartości laboratoryjne z góry raportu: LCP, FCP, TBT, CLS i Speed Index. W teście laboratoryjnym zobaczysz TBT zamiast INP, bo INP mierzy się tylko u prawdziwych użytkowników.
Nazwy plików z rozwiniętych audytów (blokowanie renderowania, wykrywanie żądań LCP, drzewo zależności), żeby wskazać konkretne wtyczki i skrypty.
Testy innych adresów: karty produktu, wpisu blogowego i koszyka. Strona główna nie pokazuje całego sklepu.
Kilka powtórzeń testu mobilnego, bo wynik potrafi się wahać o kilka punktów.

Uwaga praktyczna. W sklepie WooCommerce agresywne łączenie i odraczanie skryptów oraz usuwanie CSS może zepsuć koszyk, płatności lub formularze. Zmiany warto testować na kopii roboczej i po każdej sprawdzać dodanie produktu do koszyka oraz zamówienie.

Co najczęściej naprawia się w sklepie WordPress i WooCommerce

Obrazy. Odpowiednie wymiary (nie 3000 px dla miniatury), format WebP lub AVIF, responsywne atrybuty srcset, lazy loading poza pierwszym ekranem.
Hosting i cache. Dobra pamięć podręczna stron, aktualne PHP i szybki serwer obniżają TTFB, od którego zależy LCP.
Wtyczki. Audyt: usuń zbędne, a te, które zostają, ładuj tylko tam, gdzie są potrzebne.
Skrypty zewnętrzne. Opóźnij ładowanie analityki, czatów i widżetów do momentu interakcji lub po załadowaniu głównej treści.
Czcionki. Ogranicz liczbę wariantów i użyj ładowania, które nie blokuje renderowania.
CSS i JavaScript. Minifikacja, usunięcie nieużywanego kodu, odroczenie nieistotnych skryptów.
Stabilność układu. Wymiary obrazów, banerów i miejsc na formularze zgody, żeby nic nie „przeskakiwało”.

Jak mierzyć i monitorować

PageSpeed Insights: pokazuje dane rzeczywiste (jeśli są dostępne) i laboratoryjne dla mobile i desktop.
Google Search Console, raport Core Web Vitals: grupuje adresy URL wg statusu i pokazuje, ile stron wymaga poprawy.
Zmiany nie widać od razu. Dane terenowe obejmują okno 28 dni, więc efekt poprawek ujawnia się stopniowo.
Mierz przed i po. Zapisz wyniki, wprowadzaj zmiany pojedynczo i porównuj, żeby wiedzieć, co naprawdę zadziałało.

Mój pogląd

Gdybym miał oceniać priorytety dla takiej strony jak Shrimpfan, ułożyłbym je tak: najpierw treść i dopasowanie do intencji, potem linkowanie wewnętrzne i autorytet, a szybkość jako fundament, który nie może być słabością. Strona z unikalną wiedzą o krewetkach Caridina i własną hodowlą ma przewagę, której nie da się zastąpić zielonym wynikiem w teście. Ale wolna strona potrafi tę przewagę zmarnować, bo czytelnik wyjdzie, zanim przeczyta pierwszy akapit.

W sklepie liczy się jeszcze jedno: moment dodania do koszyka musi być natychmiastowy. Użytkownik, który klika „Dodaj do koszyka” i czeka, traci zaufanie szybciej niż ten, który tylko czeka na załadowanie bloga. Dlatego przy sklepach patrzyłbym nie tylko na LCP, ale też na INP.

Najczęściej zadawane pytania

Czy szybkość strony jest czynnikiem rankingowym Google? Tak, ale umiarkowanym. Google potwierdza, że Core Web Vitals są używane przez jego systemy rankingowe, jednocześnie zaznaczając, że trafność treści jest ważniejsza i że dobre wyniki CWV nie gwarantują wysokich pozycji.

Jakie progi Core Web Vitals trzeba spełnić? LCP do 2,5 sekundy, INP do 200 milisekund i CLS do 0,1, oceniane dla 75. percentyla rzeczywistych odwiedzin, osobno dla mobile i desktop.

Czy wynik 100 w PageSpeed Insights jest potrzebny? Nie. To wynik laboratoryjny, który służy do diagnozy. Ważniejsze jest, żeby dane z prawdziwych użytkowników mieściły się w progach „dobry”.

Czy mobile czy desktop jest ważniejszy? W większości przypadków mobile, ze względu na indeksowanie mobile-first i słabsze urządzenia użytkowników. Sprawdzaj jednak oba osobno.

Po jakim czasie widać efekt poprawek? Dane terenowe w Chrome obejmują okno 28 dni, więc pełną zmianę w raportach zobaczysz po kilku tygodniach.

Czy mała, niszowa strona też powinna dbać o Core Web Vitals? Tak, choć jej wynik zależy od tego, czy Google ma wystarczająco dużo danych z prawdziwych odwiedzin. Niezależnie od tego szybka strona poprawia komfort czytelnika i konwersję w sklepie.

Źródła

Google Search Central: Understanding page experience in Google Search results (developers.google.com/search/docs/guides/page-experience)
Google Search Central: Understanding Core Web Vitals and Google search results (developers.google.com/search/docs/appearance/core-web-vitals)
Google Search Central Blog: Using page speed in mobile search ranking, 2018 (developers.google.com/search/blog/2018/01/using-page-speed-in-mobile-search)
Google Search Central Blog: The role of page experience in creating helpful content, 2023
Search Engine Land i Search Engine Journal: omówienia aktualizacji dokumentacji Core Web Vitals w 2024 roku
web.dev: Milliseconds make millions (web.dev/case-studies/milliseconds-make-millions)