Akademia · Audyt

Jak sprawdzić swoje Core Web Vitals w AmICited

Skorzystaj z audytu Web Vitals w AmICited, aby zobaczyć Core Web Vitals swojej strony głównej — LCP, INP, CLS, FCP i TTFB — z raportu Chrome UX Report, w porównaniu z konkurencją.

7 min read · Medium priority

Jak sprawdzić swoje Core Web Vitals w AmICited — video walkthrough

Szybkie, stabilne strony mają znaczenie również dla widoczności w AI — silniki odpowiedzi preferują źródła, które ładują się szybko. Zanim zagłębisz się w audyt AmICited, warto zrozumieć, co właściwie mierzą Core Web Vitals i dlaczego problem z szybkością strony może po cichu przerodzić się w problem z cytowaniami przez AI.

Czym są Core Web Vitals?

Core Web Vitals to zestaw standaryzowanych metryk stworzonych przez Google w celu ilościowego określenia rzeczywistego doświadczenia strony : jak szybko pojawia się główna treść strony, jak szybko reaguje ona na interakcje użytkownika i jak stabilna wizualnie pozostaje podczas ładowania. Zostały zaprojektowane, by zastąpić mgliste odczucia typu „ta strona wydaje się wolna” konkretnymi liczbami, które można śledzić, porównywać i na podstawie których można rozliczać zespoły inżynierskie. Google włączył je do swoich sygnałów rankingowych wiele lat temu, a te same dane źródłowe — zbierane od rzeczywistych użytkowników Chrome za pośrednictwem Chrome UX Report (CrUX) — coraz częściej wpływają na to, które źródła silniki odpowiedzi są skłonne pobrać, wyrenderować i zacytować.

Trzy główne metryki to Largest Contentful Paint (LCP), Interaction to Next Paint (INP) oraz Cumulative Layout Shift (CLS), z których każda ma przypisany próg zaliczenia/niezaliczenia publikowany i okresowo aktualizowany przez Google. Dwie metryki pomocnicze, First Contentful Paint (FCP) i Time to First Byte (TTFB), dopełniają pełny obraz szybkości strony , izolując to, jak szybko odpowiada serwer i jak szybko cokolwiek się renderuje, jeszcze zanim gotowa będzie główna treść. Ponieważ CrUX powstaje na bazie zanonimizowanych danych terenowych — rzeczywistych wizyt rzeczywistych użytkowników Chrome — liczby te odzwierciedlają faktyczne warunki (rodzaj urządzeń, jakość sieci, geografię), a nie pojedynczy test laboratoryjny przeprowadzony na szybkim łączu biurowym.

Dlaczego ma to znaczenie konkretnie dla generative engine optimization ? Crawlery AI oraz systemy wyszukiwania stojące za AI Overviews, wyszukiwarką ChatGPT czy Perplexity muszą pobrać i przetworzyć Twoją stronę, zanim będą mogły ją zacytować. Strona, która się zawiesza, ładuje się wolno lub przesuwa treść podczas ładowania, jest droższa do przeszukiwania na dużą skalę i mniej niezawodna, jeśli chodzi o wydobycie z niej czystej treści. Wolny TTFB w szczególności może spowodować, że crawler porzuci próbę pobrania, zanim główna treść w ogóle dotrze. Nie jest to czynnik decydujący o tym, czy zostaniesz zacytowany — trafność treści, autorytet i struktura mają dużo większe znaczenie — ale chronicznie wolna lub niestabilna strona główna to tarcie, którego silniki odpowiedzi nie mają powodu tolerować, gdy szybszy konkurent oferuje te same informacje.

To także przypadek, w którym SEO techniczne i optymalizacja pod silniki odpowiedzi niemal całkowicie się pokrywają: te same poprawki inżynieryjne, które poprawiają Twoje pozycje w Google — rozmiar obrazów, czas odpowiedzi serwera, stabilność układu — są tymi samymi, które utrzymują Twoje strony dostępnymi i możliwymi do zacytowania przez systemy AI. To pokrywanie się jest właśnie powodem, dla którego AmICited pokazuje Core Web Vitals w ramach szerszego audytu widoczności w AI , a nie jako samodzielne narzędzie SEO: to jeden z elementów wpływających na to, czy silniki AI uznają Twoją stronę za wiarygodną i łatwą do obsłużenia.

Gdzie to znaleźć

Otwórz Audyt → Web Vitals z lewego menu nawigacyjnego. Strona to wyjaśnia: „Core Web Vitals dla strony głównej Twojej domeny… szybkość ładowania strony to czynnik rankingowy Google, a silniki odpowiedzi AI preferują szybko ładujące się strony”. AmICited pobiera te dane automatycznie dla Twojej śledzonej domeny oraz dla każdego monitorowanego konkurenta, więc nie musisz uruchamiać osobnego narzędzia ani wklejać adresów URL ręcznie — to ten sam zestaw konkurencyjny, którego używasz już do śledzenia udziału w głosie i pozycji w cytowaniach w innych miejscach platformy.

Audyt Web Vitals z tabelą porównawczą konkurencji

Note
Dane pochodzą z Chrome UX Report (rzeczywiste dane od odwiedzających). Nowa domena lub domena z małym ruchem może wyświetlać puste wartości () po prostu dlatego, że nie ma jeszcze wystarczającej ilości danych terenowych.

Ponieważ CrUX wymaga minimalnego wolumenu rzeczywistego ruchu Chrome, zanim opublikuje stabilne liczby dla danego adresu URL, domeny z małym ruchem — w tym wiele witryn B2B i niszowych — będą czasami przez pewien czas wyświetlać puste wartości. To zachowanie oczekiwane, nie błąd: oznacza, że Google nie zgromadził jeszcze wystarczającej ilości danych terenowych, by raportować je z pewnością, a wartości pojawią się, gdy ruch (lub czas) się skumuluje.

Co oznaczają poszczególne metryki

Tabela porównawcza konkurencji wymienia każdą domenę wraz z:

  • Wynik — ogólne podsumowanie zaliczenia/niezaliczenia Core Web Vitals, dające jednym rzutem oka odpowiedź, czy dana domena spełnia progi Google na wszystkich frontach.
  • LCP (Largest Contentful Paint) — jak szybko ładuje się główna treść, zazwyczaj największy obraz lub blok tekstu w widocznym obszarze. To metryka najbardziej bezpośrednio związana z odczuciem odwiedzającego — lub crawlera — czy „ta strona jest już gotowa”.
  • INP (Interaction to Next Paint) — jak responsywna jest strona, gdy użytkownik faktycznie z nią wchodzi w interakcję (klika, dotyka, wpisuje tekst). Zastąpiła starszą metrykę First Input Delay, ponieważ obejmuje responsywność podczas całej wizyty na stronie, a nie tylko pierwszej interakcji.
  • CLS (Cumulative Layout Shift) — jak stabilna wizualnie jest strona podczas ładowania. Wysoki CLS oznacza, że elementy przeskakują w miarę ładowania obrazów, reklam czy czcionek, co jest uciążliwe dla odwiedzających i może utrudniać systemom zautomatyzowanym spójne przetwarzanie treści.
  • FCP (First Contentful Paint) — jak szybko na ekranie pojawia się cokolwiek, jeszcze zanim gotowa będzie główna treść. To wczesny sygnał, że strona w ogóle się ładuje, a nie wisi na pustym ekranie.
  • TTFB (Time to First Byte) — szybkość odpowiedzi serwera: czas między zażądaniem strony a otrzymaniem pierwszego bajtu odpowiedzi. To niemal wyłącznie metryka backendowa/infrastrukturalna i często najłatwiejsza do poprawienia poprzez zmiany w hostingu, cache’owaniu czy CDN.

Twoja własna domena jest oznaczona jako Ty, a poniżej znajdują się strony główne śledzonych konkurentów, dzięki czemu każda metryka jest od razu benchmarkowana, zamiast być oglądana w oderwaniu od kontekstu.

Jak z tego korzystać

  1. Porównaj się z rywalami. Jeśli strony konkurencji są szybsze, to kolejna przewaga, jaką mają zarówno w wyszukiwarce, jak i w odpowiedziach AI — a jednocześnie luka, którą stosunkowo tanio zamknąć w porównaniu z pracą nad treścią czy autorytetem.
  2. Napraw czerwone wskaźniki. Niezaliczający LCP lub CLS wskazuje na konkretne prace inżynieryjne: zbyt duże obrazy hero, brakujące atrybuty width/height, skrypty blokujące renderowanie czy niezoptymalizowane czcionki webowe to zwykle winowajcy.
  3. Potraktuj priorytetowo TTFB, jeśli jest wolny. Ponieważ znajduje się na samym początku łańcucha wpływającego na pozostałe metryki, wolny TTFB ciągnie w dół także LCP, a jednocześnie jest to często metryka najszybsza do poprawienia — zwykle poprzez cache’owanie, CDN lub aktualizację hostingu, a nie przepisywanie treści.
  4. Sprawdzaj ponownie po zmianach. W miarę aktualizacji danych terenowych wróć, aby potwierdzić, że ulepszenia zostały uwzględnione. Dane CrUX obejmują ruchome okno 28 dni, więc zmiany potrzebują czasu, by się pojawić — nie oczekuj, że liczby zmienią się dzień po wdrożeniu.
  5. Traktuj TTFB jako sygnał wczesnego ostrzegania. Serwer, który regularnie potrzebuje ponad sekundy na zwrócenie pierwszego bajtu, to silny kandydat na problemy z przeszukiwaniem i renderowaniem wykraczające daleko poza ten jeden audyt — warto zapoznać się z tym, dlaczego inżynierowie crawlerów coraz częściej traktują szybki TTFB jako próg niezawodnego działania crawlerów AI , a nie jedynie miły dodatek.

Żadna z tych czterech metryk nie działa w oderwaniu od reszty Twojego technicznego fundamentu. Strona główna, która dobrze wypada w Core Web Vitals, ale blokuje crawlery AI w pliku robots.txt lub serwuje w większości pustą stronę klientom bez obsługi JavaScript, i tak nie zostanie zacytowana — szybkość pomaga dopiero wtedy, gdy crawler faktycznie ma wstęp i może przetworzyć to, co tam jest. Dlatego warto traktować ten audyt jako jeden z punktów kontrolnych w ramach szerszej rutyny, a nie jednorazową poprawkę: uruchamiaj go regularnie razem z innymi audytami AmICited, tak samo jak okresowo wracałbyś do szerszej listy kontrolnej audytu technicznego obejmującej możliwość przeszukiwania, dane strukturalne i możliwość wydobycia treści.

Web Vitals same w sobie nie zapewnią Ci cytowań, ale wolne, niestabilne strony mogą Cię hamować — ten audyt pokazuje, jak wypadasz na tle stron, spośród których wybierają silniki AI. Jeśli chcesz poznać głębsze podstawy badawcze stojące za tą rekomendacją, przeczytaj, czy szybkość strony faktycznie wpływa na widoczność w wyszukiwaniu AI , i połącz tę kontrolę z szerszym audytem dostępności dla AI swojej witryny, aby objąć również stronę związaną z możliwością przeszukiwania. Naturalnym kolejnym krokiem jest włączenie Web Vitals do regularnego cyklu monitoringu obok narzędzia do śledzenia pozycji w AI AmICited oraz śledzenia cytowań, dzięki czemu regresja wydajności zostanie wychwycona w tym samym momencie, w którym zauważysz spadek liczby wzmianek — a nie odkryta osobno, dopiero po tygodniach, gdy już kosztowała Cię widoczność.

← Wszystkie samouczki Akademii

Gotowy, aby zastosować to w praktyce?

Bezpłatne sprawdzenie · 7-dniowy okres próbny · bez karty kredytowej