Treści są zoptymalizowane. Strona ma ekspertyzę, autorytet i sygnały zaufania. Ale gdy robot AI dociera do Twojej strony i trafia na przekroczenie limitu czasu, bo serwer odpowiada 6 sekund albo LCP nie kończy renderowania przez 5 sekund, robot idzie dalej. Treści nigdy nie trafiają do indeksu. Cytowania nigdy się nie pojawiają.
Wolna strona zabija widoczność. Nie powoli. Natychmiast i bez wyjątków.
Roboty AI działają w ograniczeniach, których nie mają tradycyjne wyszukiwarki. Mają ścisłe okna czasowe, ograniczone budżety obliczeniowe i mało cierpliwości. Strona, która idealnie wypada w Google, może być całkowicie niewidoczna dla ChatGPT, Perplexity czy Claude, bo nie ładuje się w czasie, jaki wyznacza robot. Ten rozdział opisuje, jak działają Core Web Vitals dla AI, które metryki liczą się najbardziej i jakie zmiany musisz wprowadzić.
Co mierzą Core Web Vitals i po co powstały
Core Web Vitals to trzy metryki stworzone przez Google do mierzenia rzeczywistego doświadczenia osób odwiedzających. Obejmują moment, w którym przeglądarka zaczyna pokazywać treść, moment, w którym można wejść w interakcję ze stroną, i to, jak stabilny pozostaje układ podczas ładowania. Google traktuje je jako czynniki rankingowe. Ale dla robotów AI to czynniki przetrwania.
Te trzy metryki to:
Largest Contentful Paint (LCP): czas, po którym ładuje się największy element wizualny. Cel to poniżej 2,5 sekundy. To pierwsze, co widać. Jeśli główny obraz, nagłówek lub główna sekcja treści pojawiają się po 4 sekundach, czekają zarówno ludzie, jak i roboty.
Interaction to Next Paint (INP): czas, po którym przeglądarka reaguje po kliknięciu. Cel to poniżej 200 milisekund. Ta metryka sprawdza, czy JavaScript jest rozdęty i czy strona zawiesza się, gdy roboty symulują interakcję.
Cumulative Layout Shift (CLS): jak bardzo strona „skacze” podczas ładowania. Cel to poniżej 0,1. Gdy elementy nieoczekiwanie się przesuwają, roboty pobierają treść pomieszaną lub niepełną. Starannie napisane akapity stają się w odczycie robota bełkotem.
W tradycyjnym wyszukiwaniu to wskazówki. Dla robotów AI to twarde limity.
Dlaczego roboty AI mają inne wymagania co do szybkości niż Google
Robot Google rozkłada pracę. Przeszukuje miliony adresów URL na tysiącach serwerów. Może pozwolić sobie na czekanie 10 sekund na załadowanie strony, bo oczekiwanie rozkłada się na ogromną infrastrukturę.
Roboty AI działają w trybie wnioskowania na zapytanie. Gdy ktoś zadaje pytanie ChatGPT, Perplexity ma od 3 do 5 sekund, by znaleźć, pobrać i przetworzyć Twoje treści, zanim odpowiedź zacznie się generować. Liczy się każda sekunda. Każda milisekunda jest odliczana od budżetu przeszukiwania.
Badania zachowania robotów AI pokazują, że witryny z First Contentful Paint poniżej 0,4 sekundy mają średnio 6,7 cytowania, a witryny ładujące się powyżej 1,13 sekundy mają średnio 2,1 cytowania. To nie korelacja. To przyczynowość. Wolne strony są pomijane.
Robot pobierający treści ChatGPT ma udokumentowany próg limitu czasu. Strony, które nie odpowiedzą w tym oknie, są oznaczane jako niedostępne i dostają niższy priorytet w kolejnych próbach. Robot Perplexity robi to samo. Witryna, która odpowiada 6 sekund, nie dostaje drugiej szansy.
Time to First Byte (TTFB): metryka, na której robotom AI zależy najbardziej
TTFB mierzy czas między wysłaniem żądania a otrzymaniem pierwszego bajtu z serwera. To najczystsza miara responsywności serwera.
Dla robotów AI TTFB decyduje, czy w ogóle podejmą próbę renderowania. Jeśli serwer odpowiada 700 milisekund, robot zmarnował 700 milisekund ze swojego okna 3 do 5 sekund. Robot rezygnuje z renderowania i przechodzi do czytania samego HTML, co oznacza, że treści renderowane przez JavaScript stają się niewidoczne.
Wartości odniesienia są jasne. TTFB poniżej 200 milisekund uchodzi za wyjątkowy. 200 do 500 milisekund jest akceptowalne, ale nie idealne. Powyżej 600 milisekund masz problem z infrastrukturą serwerową.
Większość artykułów o wydajności traktuje TTFB jako drugorzędny wobec metryk wizualnych. Dla robotów AI to strażnik bramy. Jeśli TTFB zawodzi, nic innego się nie liczy.
Typowe przyczyny wolnego TTFB to wolne zapytania do bazy danych przy każdym wczytaniu strony, przeciążony hosting z zbyt wieloma witrynami na serwerze, słabe geograficzne trasowanie żądań i brak buforowania w sieci dostarczania treści (CDN). To nie są problemy projektowe. To problemy infrastruktury.
Largest Contentful Paint (LCP): czekanie na duży element
LCP mierzy czas, aż największy element wizualny załaduje się w całości. Zwykle to główny obraz, obraz w tle lub duży blok tekstu. Na stronach z dużą ilością treści to główny obszar treści.
LCP poniżej 2,5 sekundy to próg „dobry”. Roboty AI cytują strony w tym zakresie 2,8 raza częściej niż strony z wolniejszym LCP. Różnica jest wyraźna.
Robot nie czeka, aż załadują się wszystkie elementy. Ale czeka na pojawienie się głównej treści. Jeśli główny obraz ma 4 megabajty i nie został zoptymalizowany pod web, robot bezczynnie czeka na pobranie obrazu. Zanim obraz się załaduje, limit czasu robota już minął.
Typowe przyczyny wolnego LCP to zbyt duże obrazy bez kompresji, niezoptymalizowane osadzone wideo blokujące renderowanie, czcionki internetowe bez podzbiorów, które wolno się ładują, oraz skrypty firm trzecich renderowane nad linią załamania. Każdy z nich dodaje sekundy do LCP.
Rozwiązaniem nie jest czekanie dłużej. Rozwiązaniem jest przyspieszenie LCP. To znaczy optymalizacja obrazów, leniwe ładowanie treści poniżej linii załamania, asynchroniczne ładowanie skryptów i ewentualna wymiana ciężkich osadzeń firm trzecich na statyczne alternatywy w HTML.
Interaction to Next Paint (INP): wydajność wykonywania JavaScript
INP mierzy responsywność. Gdy ktoś (lub robot symulujący osobę) wchodzi w interakcję ze stroną, ile czasu mija, zanim coś zmieni się na ekranie? Cel to poniżej 200 milisekund.
Dla robotów AI INP pokazuje, czy JavaScript jest zoptymalizowany, czy rozdęty. Słaby wynik INP sygnalizuje, że strona uruchamia za dużo kodu w głównym wątku albo że kod nie jest odpowiednio dzielony i odraczany.
Roboty symulujące interakcję robią to, by pobrać treści dynamiczne. Jeśli strona ładuje statyczny HTML, ale polega na JavaScript przy renderowaniu formularzy, treści warunkowych lub elementów interaktywnych, robot musi wykonać ten JavaScript. Jeśli JavaScript jest wolny, robot dostaje słaby wynik INP i oznacza stronę jako nieefektywną.
Ukryty problem renderowania po stronie klienta polega na tym, że większość robotów AI w ogóle nie renderuje JavaScript. Badania pokazują, że statyczny HTML ze znacznikami schema osiąga 94% skuteczności odczytu, a treści renderowane przez JavaScript tylko 23%. To znaczy, że jeśli treści są ukryte za JavaScript, roboty AI mogą ich nigdy nie zobaczyć.
Jeśli witryna używa renderowania po stronie klienta, problem z INP staje się problemem widoczności. Robot nie może czekać na wykonanie JavaScript, więc pomija treści zależne od JavaScript.
Cumulative Layout Shift (CLS): stabilność podczas pobierania treści
CLS mierzy niestabilność wizualną. Gdy elementy strony przesuwają się podczas ładowania, Cumulative Layout Shift rośnie. Cel to poniżej 0,1.
Dla robotów CLS nie dotyczy doświadczenia osoby odwiedzającej. Dotyczy dokładności odczytu. Gdy DOM przesuwa się w trakcie pobierania treści przez robota, robot może chwycić złe elementy. Nagłówek może przesunąć się na miejsce innego nagłówka. Pasek boczny może wypchnąć główną treść z pozycji. Robot pobiera tekst, który jest w danym miejscu, a nie ten, który logicznie tam należy.
Typowe przyczyny wysokiego CLS to miejsca na reklamy ładowane późno, które spychają treść w dół, obrazy bez podanych wymiarów, które ładują się i przesuwają układ, czcionki internetowe, które się podmieniają i zmieniają odstępy, oraz karuzele z automatycznym odtwarzaniem, które przesuwają treść. Każde z nich powoduje ruch układu.
Rozwiązaniem jest zarezerwowanie miejsca na wszystko, co się załaduje. Podaj wymiary obrazów w HTML. Ustaw font-display na swap, by czcionki nie blokowały renderowania. Ładuj reklamy i treści dynamiczne w zarezerwowanych kontenerach, które nie powodują przesunięć układu.
Jak optymalizować pod szybkość dla robotów AI
Optymalizacja szybkości dla robotów AI różni się od optymalizacji dla ludzi. Osoby odwiedzające dbają o to, kiedy zobaczą stronę i kiedy mogą z nią wejść w interakcję. Roboty dbają o to, kiedy serwer odpowie i czy cała treść się wyrenderuje.
Zacznij od TTFB. Jeśli serwer odpowiada dłużej niż 500 milisekund, nic innego się nie liczy. Przejrzyj zapytania do bazy danych, przenieś się do szybszego dostawcy hostingu, wdróż buforowanie na poziomie aplikacji lub użyj CDN. Inwestycja w TTFB zwraca się natychmiast w pokryciu przez roboty.
Zoptymalizuj obrazy. Każdy obraz na stronie powinien być skompresowany, zmieniony do wymiarów wyświetlania i serwowany w nowoczesnych formatach, takich jak WebP, z zapasowym PNG. Użyj narzędzia do kompresji obrazów. Dla głównych obrazów użyj CDN z automatyczną optymalizacją.
Odrocz niekrytyczny JavaScript. Ładuj tylko ten JavaScript, który jest absolutnie potrzebny, by robot zobaczył treść. Skrypty śledzące analitykę, ładujące reklamy lub obsługujące funkcje interaktywne należy odroczyć lub ładować asynchronicznie. To zwalnia główny wątek i przyspiesza wykonanie.
Renderuj krytyczne treści po stronie serwera. Jeśli witryna używa frameworka działającego po stronie klienta, wyrenderuj ścieżkę krytyczną na serwerze i „uwodnij” ją po stronie klienta. To sprawia, że roboty widzą treść od razu. Statyczne generowanie witryn (SSG) jest jeszcze lepsze: strony buduje się do HTML w momencie wdrożenia.
Unikaj dużych osadzeń firm trzecich. Jeśli osadzasz odtwarzacze YouTube, odtwarzacze audio lub duże zewnętrzne widżety, blokują renderowanie. Zastąp je miniaturą, która ładuje się po kliknięciu, albo przenieś najważniejsze informacje do statycznego HTML.
Zarezerwuj miejsce na treści dynamiczne. Zdefiniuj jawne wymiary dla obrazów, reklam i sekcji dynamicznych. To zapobiega przesunięciom układu i sprawia, że robot pobiera właściwą treść.
Użyj CDN. Sieć dostarczania treści kieruje żądania do geograficznie najbliższego serwera, co zmniejsza opóźnienie i TTFB. Większość CDN oferuje też automatyczną optymalizację i kompresję obrazów.
Co WEMASY zapewnia dla szybkości i optymalizacji pod roboty
Kreator stron WEMASY zawiera hosting z automatycznym buforowaniem w CDN, optymalizację obrazów przy wgrywaniu i renderowanie całej treści witryny po stronie serwera. Strony zbudowane w WEMASY domyślnie spełniają standardy Core Web Vitals.
Gdy publikujesz witrynę w WEMASY, TTFB jest zoptymalizowany przez nasz CDN, obrazy są automatycznie zmniejszane i kompresowane, a HTML jest serwowany jako strony statyczne, a nie generowany na żądanie. To znaczy, że roboty AI widzą treści od razu, bez czekania na renderowanie czy przetwarzanie.
Sprawdź, co zawierają plany cenowe WEMASY.
Najczęstsze pytania
Czy szybkość strony wpływa na cytowania AI bardziej niż na tradycyjne SEO?
Roboty AI są bardziej wrażliwe na szybkość, bo działają w ciaśniejszych ograniczeniach czasowych. Tradycyjne roboty Google mogą czekać 10 sekund na załadowanie strony. Roboty AI zwykle przerywają po 3 do 5 sekundach. W tradycyjnym SEO szybkość to sygnał rankingowy. W GEO szybkość to próg. Jeśli go nie spełnisz, cytowań w ogóle nie będzie. Dzięki kreatorowi stron WEMASY ustawisz to bezpośrednio na swojej stronie.
Jak sprawdzić, czy mój TTFB jest wystarczająco szybki dla robotów AI?
Użyj Google PageSpeed Insights (uruchom test tak, jakby robił to robot, sprawdzając wersję na komputer). Szukaj TTFB poniżej 500 ms. Jeśli jest wyższy, trzeba sprawdzić hosting, bazę danych lub kod aplikacji. Inne darmowe narzędzia do testowania szybkości też pokazują TTFB. Jeśli TTFB stale przekracza 600 ms, skontaktuj się z dostawcą hostingu lub rozważ przejście na szybszy.
Czy optymalizować Core Web Vitals, jeśli nie śledzę tradycyjnych pozycji w Google?
Tak. Core Web Vitals bezpośrednio wpływają na widoczność w AI. Badania pokazują, że 85% witryn cytowanych przez platformy AI spełnia wszystkie trzy progi Core Web Vitals. Nawet jeśli pozycje w Google nie mają dla Twojego biznesu znaczenia, widoczność w AI ma. Optymalizacja jest ta sama.
Czy warto przejść na szybszy hosting tylko dla Core Web Vitals?
Jeśli obecny TTFB przekracza 600 ms, tak. Różnica w koszcie między podstawowym a szybkim hostingiem to zwykle 5 do 15 $ miesięcznie. Zwrot z lepszych cytowań AI i pokrycia przez roboty jest znacznie wyższy. Szybki hosting poprawia też doświadczenie osób odwiedzających i konwersję, a nie tylko dostępność dla robotów.
Czy buforowanie poprawia Core Web Vitals?
Buforowanie jest niezbędne. Buforowanie w przeglądarce każe przeglądarkom osób odwiedzających zapisywać obrazy i pliki statyczne lokalnie, żeby nie pobierać ich ponownie. Buforowanie na serwerze zapisuje w pamięci w pełni wyrenderowane strony, żeby nie budować ich od zera. Oba znacząco zmniejszają TTFB i LCP. Wdrażaj nagłówki pamięci podręcznej konsekwentnie i używaj CDN z automatycznym buforowaniem.
Czy optymalizacja szybkości pod roboty AI pogorszy doświadczenie osób odwiedzających?
Nie. Optymalizacje pod szybkość dla robotów, czyli szybsze serwery, kompresja obrazów i odraczanie JavaScript, poprawiają doświadczenie we wszystkich obszarach. Strony, które ładują się szybciej dla robotów, ładują się szybciej dla ludzi. Jedyny wyjątek to próba optymalizacji wyłącznie pod roboty przez usuwanie obrazów lub okrajanie treści, co zaszkodziłoby osobom odwiedzającym. Tak nie rób. Optymalizuj pod szybkość bez odbierania wartości.