Core Web Vitals: jak poprawić LCP, INP i CLS

Core Web Vitals to trzy metryki opisujące doświadczenie użytkownika na stronie: Largest Contentful Paint (LCP) mierzy szybkość wyświetlenia głównej treści, Interaction to Next Paint (INP) — czas reakcji na kliknięcie, dotknięcie lub naciśnięcie klawisza, a Cumulative Layout Shift (CLS) — stabilność układu. Dobry wynik oznacza LCP do 2,5 sekundy, INP do 200 milisekund i CLS do 0,1 w 75. percentylu wizyt, osobno dla urządzeń mobilnych i komputerów. Poprawa tych wskaźników wymaga pracy nad konkretnymi przyczynami: serwerem, obrazami, JavaScriptem, fontami i elementami, które zmieniają położenie podczas ładowania.

Ten artykuł dotyczy właśnie tej pracy. Dla każdej metryki: co mierzy, gdzie realnie idzie czas, jakie przyczyny wracają w prawdziwych szablonach i które poprawki ruszają liczbę. Dodatkowo: dlaczego jeden przebieg PageSpeed Insights niczego nie dowodzi i dlaczego ta sama praca jest warunkiem wykorzystania strony w odpowiedziach AI.

W skrócie

• Progi dobrego wyniku: LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1, w 75. percentylu wczytań strony, osobno dla urządzeń mobilnych i desktopu.
• Dane polowe decydują, laboratoryjne diagnozują. Google podaje, że pomiar laboratoryjny nie zastępuje pomiaru polowego, więc jeden przebieg PageSpeed jest dowodem wyłącznie na temat tego przebiegu.
• LCP to cztery kolejne części (TTFB, opóźnienie rozpoczęcia pobierania, czas pobierania, opóźnienie renderowania elementu), a INP to trzy fazy (opóźnienie wejścia, przetwarzanie, prezentacja). Poprawa złej części nie zmienia nic.
• CLS najczęściej powoduje niezarezerwowane miejsce: obrazy bez wymiarów, boksy reklamowe i osadzenia, późno wczytywane fonty oraz banery zgody przesuwające treść.
• Google potwierdza, że Core Web Vitals są używane przez systemy rankingowe i w tym samym dokumencie, że dobre wyniki nie gwarantują wysokich pozycji.
• Wyszukiwanie AI nie ma osobnego progu Core Web Vitals. Google stosuje w AI Overviews i AI Mode te same wymagania techniczne oraz podstawowe zasady SEO co w zwykłych wynikach.
• Kolejność poprawek wyznacza szablon i udział w ruchu, najpierw mobile. Zawodzą szablony, nie pojedyncze strony.
• Skrypty zewnętrzne i sposób wyświetlania banera zgody trzeba sprawdzić wcześnie, ponieważ mogą pogarszać jednocześnie INP i CLS.

Co dokładnie mierzą LCP, INP i CLS

Każda metryka ma trzy przedziały. Znaczenie mają dwie granice: linia „dobrze", do której się celuje, i linia „słabo", która oznacza stronę zepsutą, a nie tylko wolną.

Dwa szczegóły zmieniają sposób czytania tych liczb. Punktem oceny jest 75. percentyl wizyt, a nie średnia. Oznacza to, że co najmniej trzy czwarte doświadczeń powinno mieścić się w dobrym progu. Wyniki są też rozdzielone na urządzenia mobilne i komputery. Ten sam kod może działać dobrze na laptopie, a wyraźnie gorzej na telefonie z wolniejszym procesorem i połączeniem.

Obok trzech metryk kluczowych stoją diagnostyki, które nie są oceniane, ale pokazują, gdzie szukać: Time to First Byte (TTFB) dla opóźnienia serwera i sieci, First Contentful Paint (FCP) dla zasobów blokujących renderowanie i Total Blocking Time (TBT) jako laboratoryjny zamiennik metryki interaktywności.

Dlaczego jeden pomiar w PageSpeed Insights nic nie dowodzi

Ponieważ to dane laboratoryjne, a dane laboratoryjne odpowiadają na inne pytanie. Raport PageSpeed pokazuje dwie rzeczy obok siebie i cytowana jest zwykle ta niewłaściwa.

Wynik laboratoryjny potrafi się wahać między dwoma kolejnymi przebiegami na tym samym adresie: symulowany procesor i sieć się zmieniają, zimna pamięć podręczna różni się od ciepłej, a skrypty zewnętrzne odpowiadają inaczej minuta po minucie. Dwie dalsze pułapki: dane polowe są agregowane po grupach podobnych adresów, więc liczba pokazana dla strony o małym ruchu zwykle opisuje cały jej szablon, a dane polowe mają opóźnienie, bo odzwierciedlają wizyty, które już się zdarzyły. Kolejność jest więc taka: wydać poprawkę, potwierdzić w laboratorium, że przyczyna zniknęła, a potem poczekać, aż dane polowe to potwierdzą.

Słowniczek

• 75. percentyl — wartość, w której mieści się trzy czwarte wczytań strony; punkt, w którym oceniane są Core Web Vitals.
• CrUX (Chrome User Experience Report) — publiczny zbiór pomiarów wydajności od realnych użytkowników Chrome, będący źródłem danych polowych w PageSpeed Insights i Search Console.
• Długie zadanie — zadanie zajmujące główny wątek dłużej niż 50 ms; jednostka, z której zbudowane są problemy z INP.
• Zasób blokujący renderowanie — arkusz stylów albo synchroniczny skrypt, który przeglądarka musi pobrać i przetworzyć, zanim cokolwiek wyrenderuje.
• Element LCP — element uznany przez przeglądarkę za największy w widocznym obszarze, zwykle obraz hero, nagłówek albo obraz tła z CSS.
• bfcache — pamięć nawigacji wstecz i wprzód, czyli zrzut strony w pamięci, dzięki któremu powrót jest natychmiastowy i nie powtarza przesunięć układu.
• Dane polowe — pomiary z realnych wizyt, na których rozstrzyga się zdanie oceny Core Web Vitals.

LCP: która część osi czasu zjada czas

LCP nie jest jedną liczbą, tylko czterema następującymi po sobie: TTFB, opóźnienie rozpoczęcia pobierania zasobu LCP (przerwa między nadejściem odpowiedzi a startem pobierania), czas pobierania oraz opóźnienie renderowania elementu (od zakończenia pobierania do wyrenderowania). Wytyczne Google dla dobrze zrównoważonej strony lokują około 40% w TTFB, około 40% w czasie pobierania i poniżej 10% w każdym z dwóch opóźnień. Rozkład warto przeczytać przed dotknięciem czegokolwiek — kompresja obrazu nie naprawi TTFB na poziomie 1,2 sekundy.

Przyczyny, które wracają najczęściej:

• Zasób LCP jest odkrywany późno, bo jest wskazany z CSS albo wstrzykiwany JavaScriptem, a nie obecny w pierwszym HTML.
• Obraz hero ma atrybut loading="lazy", więc przeglądarka obniża priorytet jedynego obrazu, który definiuje metrykę.
• Arkusze stylów blokujące renderowanie albo synchroniczne znaczniki <script> w sekcji <head> wstrzymują pierwsze wyrenderowanie.
• Obraz jest za duży, nieskompresowany albo podany w przestarzałym formacie.
• TTFB jest zawyżony łańcuchami przekierowań, odpowiedziami niepodlegającymi cache'owaniu albo serwerem odległym od użytkownika, przed którym nie stoi CDN.

Poprawki, z grubsza w kolejności zwrotu:

1. Umieścić kandydata na element LCP w pierwszym HTML z atrybutem fetchpriority="high" i usunąć loading="lazy" ze wszystkiego, co może być elementem LCP. Obrazom poniżej pierwszego ekranu i w karuzelach warto nadać fetchpriority="low", żeby przestały konkurować.
2. Wstępnie pobrać to, czego parser nie widzi. Jeśli obraz hero pochodzi z właściwości background-image, albo font jest odkrywany dopiero po przetworzeniu arkusza stylów, <link rel="preload"> zamyka lukę opóźnienia pobierania.
3. Odblokować renderowanie. Wbudować w stronę CSS potrzebny na pierwszym ekranie, resztę odłożyć, a skryptom w sekcji <head> nadać async albo defer.
4. Zmniejszyć plik. Nowoczesne formaty (AVIF, WebP), właściwe wymiary dla podawanego punktu przełamania, CDN obrazów, długie czasy życia w Cache-Control.
5. Zająć się TTFB bezpośrednio. Usunąć skoki przekierowań, podawać cache'owany HTML z brzegu sieci i przestać doklejać unikalne parametry zapytania, które czynią każdy adres niecache'owalnym.
6. Podawać treść jako HTML. Renderowanie po stronie serwera albo prerender usuwa całą klasę problemów, w której treść główna istnieje dopiero po wykonaniu bundla.

Tu należą też fonty: font blokujący renderowanie tekstu opóźnia tekstowy LCP, więc font-display warto ustawić na wartość inną niż auto i block, a kroje potrzebne na pierwszym ekranie pobrać wstępnie.

INP: co trzyma główny wątek w momencie dotknięcia

INP mierzy najgorszą interakcję, jaką realnie miał odwiedzający, w trzech fazach: opóźnienie wejścia (czekanie, zanim procedura obsługi wystartuje, bo główny wątek jest zajęty), czas przetwarzania (własna praca tej procedury) i opóźnienie prezentacji (czekanie na kolejną wyrenderowaną klatkę). Budżet 200 ms obejmuje wszystkie trzy.

Większość awarii to opóźnienie wejścia i opóźnienie prezentacji, a nie wolny kod obsługi. Główny wątek jest zajęty czymś innym — obliczaniem skryptu, inicjalizacją zewnętrznego taga, hydracją frameworka, wymuszonym przeliczeniem układu — a dotknięcie czeka w kolejce.

Przyczyny, które wracają najczęściej:

• Długie zadania podczas wczytywania i chwilę po nim: parsowanie, kompilowanie i wykonywanie dużych bundli.
• Skrypty zewnętrzne — menedżery tagów, widżety czatu, narzędzia testowe, analityka, oprogramowanie zgody — wykonujące się w momencie, w którym ktoś pierwszy raz próbuje wejść w interakcję.
• Szarpanie układem: odczyt właściwości układu i zapis stylu w tej samej pętli, wymuszający synchroniczne przeliczenie układu wielokrotnie.
• Bardzo duże drzewo DOM, które podnosi koszt każdego przeliczenia stylów i układu.
• Renderowanie HTML strony po stronie klienta bez oddawania wątku, więc przeglądarka nigdy nie dostaje przerwy na odpowiedź.

Poprawki:

1. Dzielić długą pracę na krótsze zadania. Przeglądarka musi regularnie odzyskiwać główny wątek, aby obsłużyć interakcję i narysować kolejną klatkę. Można wykorzystać scheduler.yield() tam, gdzie jest obsługiwane, oraz przygotować rozwiązanie zastępcze dla pozostałych przeglądarek. Nie należy opierać krytycznej funkcji wyłącznie na API, które nie ma jeszcze pełnej obsługi.
2. Robić mniej na głównym wątku. Wysyłać mniej JavaScriptu, odłożyć to, co nie jest potrzebne do pierwszej interakcji, i ocenić każdy zewnętrzny tag pytaniem, co się zepsuje, jeśli wczyta się dwie sekundy później.
3. Trzymać procedurę obsługi minimalną. Wykonać widoczną aktualizację, a resztę odłożyć na po wyrenderowaniu klatki. Wywołania analityczne i synchronizacja stanu nie muszą dziać się w środku kliknięcia.
4. Grupować odczyty i zapisy, żeby jedna klatka nie wymuszała wielokrotnego synchronicznego przeliczenia układu.
5. Obniżyć koszt renderowania. Spłaszczyć głęboko zagnieżdżony DOM i zastosować content-visibility, żeby sekcje poza ekranem renderowały się dopiero przy zbliżaniu do widocznego obszaru.

CLS: co nie rezerwuje sobie miejsca

CLS zlicza nieoczekiwane przesunięcia treści, która była już widoczna. Przesunięcia w ciągu 500 ms od interakcji użytkownika są wyłączone z liczenia — dlatego rozwijana harmonijka jest w porządku, a slot reklamowy rozszerzający się sam z siebie nie jest. Jedna dźwignia stoi poza poniższą tabelą: kwalifikacja strony do bfcache, dzięki której nawigacja wstecz i wprzód przywraca stan natychmiast, zamiast odtwarzać całe przesuwające się wczytanie.

Slot reklamowy i baner zgody warto nazwać osobno: to dwa najczęstsze źródła CLS na stronach komercyjnych i oba należą zwykle do kogoś innego niż programista. Slot bez zarezerwowanej wysokości przesuwa stronę za każdym razem, gdy się wypełni, a na mobile przesuwa mocniej, bo widok jest niski. Baner zgody wstrzyknięty po pierwszym wyrenderowaniu robi dwie rzeczy naraz: przesuwa treść, która była już widoczna, i zajmuje główny wątek dokładnie w momencie, w którym odwiedzający decyduje, czy dotknąć ekranu. Oba da się naprawić bez rezygnowania z czegokolwiek: wysokość slotu zarezerwować w CSS podawanym z serwera, a warstwę zgody wyrenderować jako nakładkę, która nie przesuwa treści. Sama mechanika zgód i tryb zgody Google to osobny temat, opisany we wpisie o Consent Mode v2.

Core Web Vitals a widoczność w Google i odpowiedziach AI

Core Web Vitals są częścią jakości strony ocenianej przez systemy rankingowe Google, ale nie zastępują trafnej i przydatnej treści. Google wyraźnie zaznacza, że dobry wynik w Search Console lub PageSpeed Insights nie gwarantuje wysokiej pozycji. W praktyce poprawa wydajności ma wartość przede wszystkim dla użytkownika, a w wyszukiwarce może pomóc wtedy, gdy kilka stron równie dobrze odpowiada na zapytanie.

AI Overviews i AI Mode nie wprowadzają dodatkowego progu wydajności ani specjalnych znaczników. Obowiązują te same podstawy co w klasycznym SEO: strona musi spełniać wymagania techniczne Google, być dostępna do indeksowania i zawierać pomocną, wiarygodną treść. Szybka, stabilna strona ułatwia korzystanie z materiału po przejściu z odpowiedzi AI, ale nie istnieje osobny „wynik szybkości dla AI”.

W ramach AI SEO wydajność traktujemy więc jako element technicznego fundamentu, obok indeksowania, renderowania i kontroli dostępu robotów. Dopiero na tej podstawie można rozwijać encję marki, dane strukturalne i treści, które mają szansę zostać zacytowane. Dostęp robotów wyjaśnia wpis o robotach AI i tym, kogo wpuszczać, a dobór źródeł — przewodnik po AI Overviews i GEO.

Polski kontekst: szablon platformy, widżety i baner zgody

Na polskim rynku trzy rzeczy powtarzają się w audycie na tyle regularnie, że warto je nazwać osobno.

Szablon platformy, nie strona. Duża część polskich sklepów stoi na platformach, w których jeden szablon obsługuje tysiące adresów — Shoper, PrestaShop, WooCommerce, Magento, Shopify. To dobra wiadomość dla kolejności prac: poprawka w szablonie karty produktu rusza wszystkie karty produktu naraz. To zła wiadomość dla diagnostyki, bo raport polowy dla pojedynczego adresu o małym ruchu opisuje zwykle cały ten szablon, nie tę stronę. Wniosek praktyczny: notować grupy adresów, nie adresy.

Warstwa widżetów. W sklepach działa często wiele skryptów zewnętrznych: mapa punktów odbioru, opinie, czat, oddzwanianie, porównywarki, piksele reklamowe i nagrywanie sesji. Każdy z nich może mieć niewielki koszt, lecz razem potrafią zająć główny wątek w chwili pierwszej interakcji i pogorszyć INP. Warto sprawdzić, które narzędzia są rzeczywiście używane, które muszą ładować się od razu, a które można uruchomić dopiero po zgodzie lub działaniu użytkownika.

Baner zgody. Wdrożenia zgody na polskich stronach powstawały często pod presją terminu i wstrzykują banner po pierwszym wyrenderowaniu, na środek widoku, dopychając treść w dół. To pojedyncza zmiana, która rusza CLS i INP jednocześnie: warstwę zgody wyrenderować jako nakładkę nad treścią, a nie element przesuwający układ, i nie wykonywać w niej pracy, której nie wymaga sama decyzja użytkownika.

Do tego jedna uwaga o strukturze ruchu. W polskim e-commerce duża część sesji przychodzi z urządzeń mobilnych, a ocena Core Web Vitals jest rozdzielona po klasie urządzenia. To znaczy, że wynik desktopowy, którym łatwo się pochwalić, nie mówi nic o wyniku, który rozstrzyga. Kolejność prac zawsze zaczyna się od mobile.

Które poprawki idą pierwsze

Core Web Vitals są raportowane po grupach adresów i to jest podpowiedź. Zawodzą szablony, nie strony: jeden szablon karty produktu obsługuje tysiące adresów, więc jedna poprawka rusza tysiące adresów naraz.

Dwie zasady bezpieczeństwa. Naprawiać przyczyny, nie wyniki — ten sam wynik może brać się z wolnego serwera albo z przeciążonego obrazu, a tylko jedno z tych dwóch naprawia się dotykaniem obrazu. I stawiać liczbę biznesową obok metryki: jeśli LCP szablonu się poprawia, a wskaźnik dodania do koszyka albo rozpoczęcia formularza nie rusza, wąskie gardło było gdzie indziej — i to jest informacja, nie porażka. Same wzorce, które psują konwersję niezależnie od wydajności, zbiera wpis o błędach na landing page.

Jak podchodzimy do tego w Space Ads

Analizę wydajności zaczynamy od danych polowych, a nie od pojedynczego wyniku Lighthouse. Raport Core Web Vitals w Search Console pokazuje problematyczne grupy adresów i klasę urządzeń. PageSpeed Insights pomaga odróżnić problem z ładowaniem, reakcją na interakcję i stabilnością. Następnie odtwarzamy ważne ścieżki w Chrome DevTools: rozkładamy LCP na części, rejestrujemy powolne interakcje i wskazujemy elementy odpowiedzialne za przesunięcia układu. Każda rekomendacja opisuje konkretny szablon, przyczynę, oczekiwany efekt i koszt wdrożenia. Skrypty zewnętrzne oraz warstwę zgody oceniamy osobno, ponieważ ich wpływ często obejmuje wiele podstron i więcej niż jedną metrykę.

Plan działania

1. Przeczytać najpierw dane polowe. Raport Core Web Vitals w Search Console: które grupy adresów zawodzą, na której metryce, mobile czy desktop. Notować grupy, nie strony.
2. Ustalić szablon stojący za każdą zawodzącą grupą oraz jego udział w sesjach i przychodzie. Ta kolejność jest planem.
3. Znaleźć przyczynę w laboratorium. Dla LCP — rozkład na podczęści. Dla INP — nagrana interakcja w panelu Performance, żeby znaleźć długie zadanie. Dla CLS — nakładka pokazująca obszary przesunięć układu.
4. Naprawić najpierw przyczyny globalne — blokujący arkusz stylów, blokujący tag zewnętrzny, wczytywanie fontów, warstwa zgody. Te lądują na wszystkich szablonach naraz.
5. Potem naprawić najważniejszy szablon: element LCP, następnie ścieżka interakcji, następnie rezerwowanie miejsca.
6. Zweryfikować w laboratorium przed wydaniem. Podczęść, która zjadała czas, powinna być widocznie mniejsza, a nowe długie zadanie nie powinno się pojawić.
7. Postawić zabezpieczenie przed regresją — budżet wydajnościowy w CI albo monitorowaną metrykę realnych użytkowników — żeby kolejna funkcja po cichu nie cofnęła pracy.
8. Przeczytać dane polowe ponownie po przewinięciu się okna i porównać metrykę biznesową szablonu obok metryki kluczowej.

Ten cykl warto trzymać jako część szerszego audytu strony internetowej, a nie jako jednorazowe zadanie techniczne — bo źródła awarii wracają razem z każdym nowym wdrożeniem. Jak wygląda pełny zakres audytu w warstwie widoczności, opisuje wpis o tym, czym jest audyt SEO.

Częsty błąd i co zrobić zamiast tego

Najczęstsze pytania

Czym są Core Web Vitals?

Core Web Vitals to trzy metryki, którymi Google opisuje doświadczenie strony: Largest Contentful Paint (LCP) dla wydajności wczytywania, Interaction to Next Paint (INP) dla reagowania na interakcje i Cumulative Layout Shift (CLS) dla stabilności wizualnej. Ocenia się je na danych polowych od realnych użytkowników, w 75. percentylu wczytań strony, osobno dla urządzeń mobilnych i desktopu.

Jakie są progi dobrego wyniku LCP, INP i CLS?

Wynik dobry to LCP najwyżej 2,5 sekundy, INP najwyżej 200 milisekund i CLS najwyżej 0,1. Wynik słaby zaczyna się powyżej 4 sekund dla LCP, powyżej 500 milisekund dla INP i powyżej 0,25 dla CLS. Przedział pośredni oznacza, że metryka wymaga poprawy.

Dlaczego PageSpeed Insights daje inny wynik za każdym razem?

Sekcja laboratoryjna wykonuje jedno symulowane wczytanie z dławionym procesorem i siecią, więc stan pamięci podręcznej, czasy odpowiedzi skryptów zewnętrznych i wahania symulacji zmieniają wynik między przebiegami. Sekcja polowa, pochodząca od realnych użytkowników z Chrome User Experience Report, jest tą częścią, która odzwierciedla faktyczne działanie strony.

Czy Core Web Vitals to czynnik rankingowy?

Google podaje, że Core Web Vitals są używane przez jego systemy rankingowe, i w tej samej dokumentacji, że dobre wyniki nie gwarantują wysokich pozycji, bo wyszukiwarka nadal dąży do pokazania najtrafniejszej treści, nawet gdy doświadczenie strony jest słabsze. W praktyce doświadczenie strony rozstrzyga między stronami o porównywalnie użytecznej treści.

Ile czasu mija, zanim Core Web Vitals poprawią się po wdrożeniu?

Przyczyna znika z pomiaru laboratoryjnego w momencie wydania poprawki, ale dane polowe są agregowane z ostatnich wizyt, więc raportowane metryki ruszają dopiero, gdy zbierze się dość wizyt po zmianie. Przyczynę warto potwierdzić w laboratorium od razu, a liczbę polową traktować jako opóźnione potwierdzenie.

Czy Core Web Vitals wpływają na widoczność w wyszukiwaniu AI?

Google nie podaje osobnego progu Core Web Vitals dla AI Overviews ani AI Mode. Do tych funkcji stosuje te same wymagania techniczne i zasady SEO co do zwykłych wyników. Dobra wydajność wspiera jakość strony i doświadczenie użytkownika po kliknięciu, ale sama nie powoduje cytowania w odpowiedzi AI.

Czym różni się INP od starszej metryki FID?

INP zastąpił First Input Delay jako metrykę kluczową dla reagowania na interakcje. FID mierzył wyłącznie opóźnienie, zanim procedura obsługi pierwszej interakcji wystartowała, a INP mierzy pełne opóźnienie najgorszej interakcji na stronie, łącznie z czasem przetwarzania procedury i czekaniem na kolejną wyrenderowaną klatkę.

Czy audyt strony internetowej obejmuje Core Web Vitals?

Solidny audyt strony internetowej traktuje Core Web Vitals jako jeden z rodzajów dowodów, obok danych o zachowaniu, analizy ścieżki i przeglądu heurystycznego. Sam wynik metryk nie mówi, co naprawić — dopiero rozkład LCP na podczęści, sprofilowana interakcja i obszary przesunięć układu wskazują przyczynę i koszt jej usunięcia.

Najważniejsze

• Core Web Vitals to LCP (≤ 2,5 s), INP (≤ 200 ms) i CLS (≤ 0,1), oceniane na danych polowych od realnych użytkowników w 75. percentylu i rozdzielone po klasie urządzenia.
• Dane polowe rozstrzygają, czy grupa adresów zdaje ocenę; dane laboratoryjne znajdują przyczyny i testują poprawki. Jeden przebieg laboratoryjny jest dowodem wyłącznie na temat tego przebiegu.
• LCP ma cztery podczęści, a INP trzy fazy — rozkład warto przeczytać pierwszy, inaczej praca ląduje na złym odcinku osi czasu.
• CLS to prawie zawsze niezarezerwowane miejsce: wymiary obrazów, sloty reklamowe, wstrzykiwane banery, późne fonty i animacje wymuszające układ.
• Warstwa skryptów zewnętrznych razem z banerem zgody jest zwykle największą pojedynczą wygraną, bo rusza INP i CLS jednocześnie.
• Kolejność prac wyznacza szablon i udział w ruchu, najpierw mobile. Zawodzą szablony, nie pojedyncze strony.
• Dla AI Overviews i AI Mode nie ma osobnego progu Core Web Vitals; obowiązują te same podstawowe wymagania techniczne i zasady SEO co w zwykłych wynikach Google.

Źródła

• web.dev — Web Vitals: progi, 75. percentyl, dane polowe kontra laboratoryjne
• web.dev — Optimize Largest Contentful Paint: podczęści LCP i poprawki
• web.dev — Optimize Interaction to Next Paint oraz Optimize long tasks: oddawanie wątku, scheduler.yield(), próg 50 ms
• web.dev — Optimize Cumulative Layout Shift: rezerwowanie miejsca, fonty, animacje, bfcache
• Google Search Central — Doświadczenie na stronie w wynikach wyszukiwania Google
• Google Search Central — Funkcje AI a witryna internetowa
• Google Search Central — Zarządzanie budżetem crawlowania dużych witryn
• Chrome for Developers — Chrome UX Report

Progi metryk, nazwy raportów i obsługa API przez przeglądarki odpowiadają dokumentacji na stan lipiec 2026 — Google i dostawcy przeglądarek zmieniają zestaw metryk oraz powierzchnie raportowania, więc przed decyzją opartą na konkretnym progu warto sprawdzić aktualną dokumentację.

Czytaj dalej

• Czym jest audyt SEO i jak go poprawnie wykonać
• Roboty AI: GPTBot, ClaudeBot i PerplexityBot — wpuszczać czy blokować
• AI Overviews i GEO: cytowania marki w wyszukiwaniu AI
• Jak wykorzystać Google Search Console w SEO
• Błędy na landing page, które zabijają konwersje
• AI SEO · Audyt UX