Page experience i Core Web Vitals: jak Google mierzy satysfakcję użytkownika – NavBoost, dwell time i patenty

W skrócie: Page experience to zbiór sygnałów, które Google używa do oceny doświadczenia użytkownika na stronie. Core Web Vitals (LCP, INP, CLS) są rdzeniem tego systemu, ale to tylko część większego obrazu. Wyciek Google API z 2024 ujawnił wewnętrzne sygnały NavBoost – goodClicks, badClicks, lastLongestClicks – które potwierdzają, że Google mierzy satysfakcję użytkownika na poziomie każdego kliknięcia. Patenty opisują system SAT-click (dwell time powyżej 30 sekund = satysfakcja) i DSAT (powrót do SERP poniżej 30 sekund = niezadowolenie). W połączeniu z politykami spamowymi Google, page experience tworzy zamknięty system: spam sites z natury mają słabe CWV, krótki dwell time i wysoki bounce rate – co oznacza, że systemy jakości i systemy antyspamowe wzajemnie się wzmacniają.

Ten artykuł jest częścią serii o Google Spam Policies. Page experience nie jest polityką spamową w ścisłym sensie, ale tworzy pomost między systemami antyspamowymi (SpamBrain) a systemami rankingowymi (Core Ranking Systems). Serwis z scaled content abuse z natury ma słabe CWV. Serwis z sekcją kuponową ma krótki dwell time. Te korelacje nie są przypadkowe.

Czym jest page experience w rozumieniu Google?

Google definiuje page experience jako zbiór aspektów, które „core ranking systems” biorą pod uwagę przy ocenie strony. Kluczowe: Google wprost stwierdza, że „nie ma jednego sygnału rankingowego page experience – nasze systemy uwzględniają różnorodne sygnały związane z doświadczeniem użytkownika.”

Page experience obejmuje:

  • Core Web Vitals – LCP (Largest Contentful Paint, ładowanie), INP (Interaction to Next Paint, responsywność), CLS (Cumulative Layout Shift, stabilność wizualna)
  • HTTPS – bezpieczne połączenie jako sygnał zaufania
  • Mobile-friendliness – dostosowanie do urządzeń mobilnych (mobile-first indexing od 2019)
  • Intrusive interstitials – wyskakujące okienka i reklamy blokujące dostęp do treści
  • Oznaczenie treści reklamowej – wyraźne oddzielenie reklam od treści głównej

John Mueller z Google wielokrotnie podkreślał hierarchię: „Relevance is still by far much more important. Just because your website is faster doesn’t necessarily mean you’ll jump to position number one.” Core Web Vitals działają jako tiebreaker – gdy dwie strony mają porównywalną jakość treści, ta z lepszym doświadczeniem użytkownika wygrywa.

Jak Core Web Vitals wpływają na rankingi – co mówią dane?

Poniższa infografika podsumowuje stan Core Web Vitals w maju 2026 na podstawie danych CrUX (18,4 miliona originów), porównanie CMS, sygnały NavBoost i powiązanie z AI Search.

Core Web Vitals benchmarki 2026: 55,9% pass rate globalnie, WordPress 44% vs <a href=Shopify 65%, NavBoost sygnały, speed-to-revenue” class=”wp-image-23719″/>

Addy Osmani, inżynier Google Chrome i współtwórca Core Web Vitals, opisał historię systemu w szczegółowej retrospektywie. Kluczowy fakt: w 2024 roku optymalizacja Core Web Vitals zaoszczędziła użytkownikom Chrome szacunkowo 30 000 lat czasu oczekiwania. To potrójny wzrost względem 12 000 lat w 2023. CWV to nie abstrakcja – to mierzalny wpływ na miliony użytkowników.

Dane o wpływie na biznes:

FirmaCo zoptymalizowanoEfektŹródło
VodafoneLCP poprawa o 31%+8% wzrost sprzedażyweb.dev case study
Deloitte + GooglePoprawa page speed o 0,1 sekundy+8,4% conversion rate w retail, +9,2% wartość koszykaBadanie Deloitte
CoinStatsLCP fix (Base64 images → src)+300% URL z „Good” CWV = +300% impressions w SearchDebugBear case study
Nuvemshop (180K sklepów)LCP: 57% → 96% pass rate (+68%)+8,9% conversion rate, +8,4% cart engagement (mobile organic)web.dev case study (czerwiec 2026)

Najświeższy case study pochodzi z czerwca 2026: Nuvemshop, największa platforma e-commerce w Ameryce Łacińskiej (180 000 sklepów), poprawiła LCP pass rate z 57% do 96% – co przełożyło się na +8,9% conversion rate i +8,4% cart engagement na mobile z ruchu organicznego. Co istotne: problem nie leżał w rozmiarze obrazów ani szybkości serwera. Przyczyną było to, że przeglądarka wybierała niewłaściwy element jako LCP z powodu opóźnień CSS transitions na karuzeli. Fix był prosty: usunięcie transitions z pierwszej sekcji, usunięcie lazy loading z obrazów above-the-fold i dodanie fetchpriority=”high”. Trzy zmiany, żadna nie wymagała przebudowy architektury.

Stan rynku w lipcu 2025: tylko 44% stron WordPress na mobile zdaje wszystkie trzy testy CWV. To oznacza, że ponad połowa serwisów na najpopularniejszym CMS-ie daje użytkownikom słabe doświadczenie – i każdy serwis, który poprawi CWV, zyskuje przewagę nad większością konkurencji.

Porównanie CMS pokazuje skalę problemu: WordPress (44% pass rate na mobile) przegrywa z Shopify (65%), Wix (60%) i Squarespace (57%). Ale to nie jest problem platformy – WordPress INP wynosi 85,89% (porównywalny z Wix). Problem leży w LCP i TTFB: tylko 32% stron WordPress ma dobry TTFB (czas odpowiedzi serwera). Przyczyna: tanie shared hosting bez edge caching. Przeniesienie strony z shared hostingu na managed hosting z CDN typowo obniża TTFB z 800-1400ms do 120-250ms – ta jedna zmiana często przenosi LCP z „poor” do „good” bez żadnej innej optymalizacji.

Ciekawy insight z Web Almanac 2025: strony główne (home pages) zdają CWV gorzej niż podstrony – 45% vs 56% na mobile. Różnica 11 punktów procentowych. Strony główne niosą cięższe hero images, więcej dynamicznych elementów i więcej skryptów third-party. Jeśli Twój ogólny pass rate wygląda słabo, audytuj stronę główną osobno – prawdopodobnie ciągnie średnią w dół.

Najnowsze dane (maj 2026): globalny pass rate wynosi 55,9% dla wszystkich trzech metryk (źródło: CrUX, 18,4 miliona originów). LCP jest najtrudniejszą metryką (68,6% pass), CLS najłatwiejszą (81,3%), INP pomiędzy (86,6%). Trend jest pozytywny ale spowalnia: mobile pass rate rósł z 32% w 2021, przez 44% w 2024, do 48% w 2025. Łatwe wygrane się kończą.

Co ujawnił wyciek Google API o sygnałach satysfakcji użytkownika?

W 2024 roku wyciek wewnętrznej dokumentacji Google API (Content API Warehouse) potwierdził istnienie systemu NavBoost – mechanizmu, który Google przez lata oficjalnie minimalizował. Analiza SEO Stack wyjawia kluczowe sygnały:

  • goodClicks – kliknięcia, które Google uznaje za „successful user outcome.” Użytkownik kliknął wynik, spędził na stronie znaczący czas i nie wrócił do SERP, żeby kliknąć inny wynik. Innymi słowy: kliknięcie rozwiązało zapytanie
  • badClicks – odwrotność. Użytkownik wrócił do wyników wyszukiwania szybko. To jest sygnał pogo-stickingu, który Google przez lata zaprzeczał jako czynnik rankingowy. Wyciek potwierdza, że jest to nazwany, przechowywany atrybut z wartością zmiennoprzecinkową wewnątrz modelu rankingowego
  • lastLongestClicks – ostatnie kliknięcie w sesji z najdłuższym dwell time. To prawdopodobnie najcenniejszy sygnał w całym modelu: strona, która konsekwentnie jest ostatnim klikniętym wynikiem z najdłuższym czasem wizyty, to strona, która rozwiązuje zapytanie
  • squashed – mechanizm ograniczający wpływ pojedynczych outlierów (np. bot traffic lub nietypowe zachowania). Zapobiega manipulacji click signals

Dlaczego NavBoost jest istotny w kontekście spam policies? Dlatego, że strony spamowe z natury generują słabe sygnały NavBoost. Scaled content (auto-generowane artykuły) ma krótki dwell time – użytkownik widzi niską jakość i wraca do SERP. Doorway pages generują pogo-sticking – użytkownik nie znajduje tego, czego szukał. Sekcje kuponowe mają ekstremalnie krótki dwell time (klik → redirect → wyjście). Systemy jakości i systemy antyspamowe wzajemnie się wzmacniają.

Jak patenty Google opisują system oceny satysfakcji użytkownika?

Patent US10387390 – Satisfaction metrics (SAT-click i DSAT)

Patent US10387390 opisuje system oceny satysfakcji z wyników wyszukiwania. Kluczowe mechanizmy:

  • SAT-click – kliknięcie wyniku, po którym dwell time przekracza próg (np. 30 sekund). System interpretuje to jako satysfakcję użytkownika z wyniku
  • Time to Success (TTS) – czas potrzebny na znalezienie satysfakcjonującego wyniku. Score 1.0 jeśli SAT-click w ciągu 10 sekund, 0.6 jeśli 10-20 sekund, 0.3 powyżej 20 sekund. Im szybciej użytkownik znajdzie satysfakcjonujący wynik, tym wyższy score
  • DSAT signal – sygnał niezadowolenia: kliknięcie wyniku z dwell time poniżej progu (np. 30 sekund) LUB przeformułowanie zapytania po zobaczeniu wyników. Oba wzorce sugerują, że wyniki nie spełniły oczekiwań użytkownika

Patent US9449078 – Evaluating ranking quality via dwell time

Patent US9449078 opisuje modelowanie dystrybucji dwell time jako mieszaniny dwóch gaussowskich rozkładów w skali logarytmicznej: jeden dla „good clicks” (długi dwell time) i jeden dla „bad clicks” (krótki dwell time). System używa algorytmu EM (Expectation-Maximization) do rozdzielenia tych komponentów. Wyniki, które nie są klikane w ogóle, otrzymują prawdopodobieństwo 1.0 bycia „bad click” – brak kliknięcia = strona nie zainteresowała użytkownika.

Bill Slawski w analizie rerankingu stron na podstawie wiarygodności opisał, że Google używa kombinacji sygnałów: dwell time (ile czasu użytkownik spędza na stronie), revisitation patterns (jak często ludzie wracają na stronę) i expert popularity (zachowania użytkowników z potwierdzoną ekspertyzą w danej dziedzinie). Te trzy sygnały razem tworzą obraz „wiarygodności” strony w oczach Google.

Patent US9355095 – Click noise characterization

Patent US9355095 definiuje „dwell time” jako średni czas między dwoma konsekutywnymi akcjami użytkownika (kliknięcie wyniku, powrót do SERP, zamknięcie przeglądarki). System rozróżnia cztery kategorie interakcji: accidental clicks (natychmiastowy powrót), short measurement (użytkownik chciał kliknąć, ale treść nie spełniła oczekiwań), long measurement (użytkownik zaangażowany) i extra-long measurement (użytkownik idle – np. zostawił kartę otwartą). Każda kategoria ma inną wagę w modelu jakości.

Jak LCP, INP i CLS wpływają na sygnały satysfakcji?

Core Web Vitals i sygnały satysfakcji (NavBoost, SAT-click) nie są niezależnymi systemami – tworzą sprzężenie zwrotne:

CWV metrykaPróg „Good”Wpływ na satysfakcjęPołączenie ze spamem
LCP (ładowanie)pod 2,5sWolne ładowanie → użytkownik odchodzi zanim zobaczy treść → brak SAT-click, wysoki DSATSpam sites z setkami reklam i trackerów mają LCP 6-10s
INP (responsywność)pod 200msLagujący interfejs → frustracja → szybkie wyjście → badClickScaled content z overloaded JavaScript, intrusive popups
CLS (stabilność)pod 0,1Przesuwające się elementy → misclick → powrót do SERP → pogo-stickingAgresywne reklamy displayowe wstrzykiwane dynamicznie

Marzec 2024: Google zastąpił FID (First Input Delay) nową metryką INP (Interaction to Next Paint). FID mierzył tylko pierwszą interakcję na stronie. INP mierzy każdą interakcję w całej sesji i raportuje najgorszą 2-5% interakcji. To oznacza, że strona może mieć doskonały FID (szybka pierwsza reakcja), ale fatalny INP (laguje po załadowaniu JavaScript). Zmiana dotyczy szczególnie skomplikowanych SPA (Single Page Applications) i serwisów z ciężkim JavaScript.

Jak page experience łączy się z politykami spamowymi Google?

Page experience nie jest polityką spamową, ale tworzy sprzężenie zwrotne z systemami antyspamowymi:

  • Intrusive interstitials – Google wprost wymienia unikanie interstitials i dialogów jako element page experience. Spamowe serwisy (gambling, payday loans, fake downloads) intensywnie używają wyskakujących okienek. Patent US9031929B1 (site quality score) może obniżyć score całego serwisu, który masowo stosuje intrusive interstitials
  • Ads density – Google w Quality Rater Guidelines wymaga, żeby reklamy nie dominowały nad treścią główną (above the fold). Spamowe serwisy z thin affiliate content mają często 70-80% powierzchni strony zajętej przez reklamy
  • Pogo-sticking jako sygnał spamu – patent US9449078 modeluje pogo-sticking (szybki powrót do SERP) jako „bad click.” Doorway pages z natury generują pogo-sticking, bo użytkownik nie znajduje treści odpowiadającej zapytaniu. Systemy jakości i antyspamowe mierzą ten sam sygnał
  • Dwell time na sekcjach kuponowych – patent US9195944B1 (z artykułu o SRA) mierzy czas wizyty na subdirectory. Sekcje kuponowe mają dwell time 3-5 sekund = ekstremalnie niski score. Page experience i SRA policy mierzą ten sam wskaźnik

Jak CWV wpływa na widoczność w AI Search?

Nowy wymiar page experience w 2026: wpływ na widoczność w AI Overviews i AI Search. Analiza CD Studio z grudnia 2025 wykazała, że strony ze słabym CWV rzadko pojawiają się w odpowiedziach generowanych przez AI. To logiczne: jeśli AI system cytuje stronę, a użytkownik na nią przechodzi i doświadcza wolnego ładowania lub lagującego interfejsu – to negatywne doświadczenie podważa zaufanie do AI odpowiedzi. Google ma motywację, żeby cytować strony, które dostarczają dobre UX.

Dodatkowy insight: strony budowane przez AI website builders (Durable, 10Web, Wix ADI) mają pass rate CWV na poziomie 29% – wobec 42% średniej ogólnej i 61% dla stron kodowanych ręcznie. AI potrafi wygenerować stronę w minuty, ale nie potrafi jeszcze zoptymalizować jej pod CWV. To jest ważne w kontekście scaled content abuse: masowo generowane strony (AI lub template) mają z natury gorsze CWV niż strony budowane z troską o użytkownika.

Jak poprawić page experience – praktyczne kroki?

  • Sprawdź CWV w Google Search Console – raport Core Web Vitals pokazuje, które strony nie zdają testów i dlaczego. Zacznij od stron z największym ruchem organicznym
  • Zoptymalizuj LCP – najczęstsze przyczyny wolnego LCP: niezoptymalizowane obrazy (użyj WebP/AVIF, lazy loading, CDN), render-blocking CSS/JS (defer, async, critical CSS inline), wolny serwer (TTFB powyżej 800ms)
  • Popraw INP – zidentyfikuj długie zadania JavaScript (Chrome DevTools Performance tab), podziel je na mniejsze fragmenty, użyj Web Workers dla ciężkich obliczeń. Szczególnie ważne na stronach z dużą ilością interaktywnych elementów
  • Zmniejsz CLS – nadaj wymiary obrazom i reklamom (width/height), nie wstrzykuj dynamicznie elementów above the fold, unikaj fontów powodujących layout shift (font-display: swap + preload)
  • Usuń intrusive interstitials – wyskakujące okienka blokujące treść to podwójny problem: pogorszenie CWV (CLS) i bezpośredni sygnał negatywny w page experience. Cookie banners są wyjątkiem, ale powinny być jak najmniej inwazyjne

Źródła i dalsze czytanie

Page experience to jedna z 10 rodzin ryzyka w spam audit checkliście z tabelą progów CWV i mapą patentów.

Google, Understanding page experience – oficjalna dokumentacja page experience signals.

Google, Core Web Vitals and Google Search – oficjalne progi LCP, INP, CLS.

Addy Osmani (Google Chrome), The History of Core Web Vitals – szczegółowa retrospektywa od 2014 do 2025, 30 000 lat zaoszczędzonego czasu.

SEO Stack, NavBoost Unpacked – analiza wycieku Google API: goodClicks, badClicks, lastLongestClicks.

Bill Slawski, How a Search Engine May Rerank Pages Based on Credibility – analiza rerankingu na podstawie dwell time, revisitation patterns i expert popularity.

DebugBear, Are Core Web Vitals a Ranking Factor? – CoinStats case study: +300% Good CWV = +300% impressions.

web.dev, Nuvemshop Case Study (June 2026) – LCP improvement +68%, +8,9% conversion rate na 180K sklepów e-commerce.

Patenty cytowane: US10387390 (satisfaction metrics, SAT-click/DSAT), US9449078 (dwell time ranking quality), US9355095 (click noise characterization).

Czy poprawa Core Web Vitals automatycznie poprawi moje pozycje?

Nie automatycznie. CWV to tiebreaker – gdy dwie strony mają porównywalną jakość treści i autorytetu, ta z lepszym doświadczeniem użytkownika wygrywa. Poprawa CWV z 'poor’ do 'good’ daje zauważalny efekt. Ale dalsze optymalizacje z 'good’ do 'perfect’ prawdopodobnie nie przesuną pozycji. Treść i relevance są nadal najważniejsze.

Czy Lighthouse score wpływa na rankingi?

Nie bezpośrednio. Google nie bierze pod uwagę wyniku Lighthouse przy rankingu. Liczy się CrUX (Chrome User Experience Report) – dane od prawdziwych użytkowników, nie syntetyczne testy. Lighthouse to narzędzie diagnostyczne do identyfikowania problemów, ale wynik w PageSpeed Insights nie przekłada się bezpośrednio na pozycje.

Co to jest NavBoost i skąd wiemy, że istnieje?

NavBoost to wewnętrzny system Google do oceny jakości wyników na podstawie zachowań użytkowników (kliknięcia, dwell time, pogo-sticking). Google przez lata oficjalnie minimalizował znaczenie click signals. Wyciek Content API Warehouse w 2024 roku potwierdził istnienie NavBoost jako nazwanego modelu z konkretnymi atrybutami: goodClicks, badClicks, lastLongestClicks. Wcześniej istnienie NavBoost potwierdzono w dokumentach z procesu antytrustowego DOJ vs Google.

Dlaczego Google zastąpił FID przez INP w 2024?

FID (First Input Delay) mierzył tylko opóźnienie pierwszej interakcji użytkownika ze stroną. Problem: strona mogła mieć doskonały FID (szybka reakcja na pierwsze kliknięcie), ale lagować przy każdej kolejnej interakcji. INP (Interaction to Next Paint) mierzy każdą interakcję w całej sesji i raportuje najgorszą 2-5%. To daje pełniejszy obraz responsywności, szczególnie na stronach z ciężkim JavaScript.

Jak page experience łączy się z politykami spamowymi?

Page experience nie jest polityką spamową, ale tworzy sprzężenie zwrotne z systemami antyspamowymi. Spamowe serwisy z natury mają słabe CWV (wolne ładowanie przez nadmiar reklam i trackerów), krótki dwell time (użytkownicy szybko odchodzą od niskiej jakości treści) i wysoki pogo-sticking rate (doorway pages, thin content). Systemy jakości (CWV, NavBoost) i systemy antyspamowe (SpamBrain) mierzą te same sygnały z różnych perspektyw – co oznacza, że wzajemnie się wzmacniają.

Podobne wpisy

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Wymagane pola są oznaczone *