Podstawowe wskaźniki internetowe i opóźnienia: Czy szybsze strony otrzymują więcej cytowań przez sztuczną inteligencję?

Podstawowe wskaźniki internetowe i opóźnienia: Czy szybsze strony otrzymują więcej cytowań przez sztuczną inteligencję?

Wstęp

Szybka strona internetowa jest łatwiejsza w obsłudze dla ludzi. Może być również łatwiejsza do pobierania, renderowania i rozumienia przez wyszukiwarki i systemy sztucznej inteligencji.

Jednak często pomija się ważną różnicę:

Szybsza strona może poprawić indeksowanie i dostępność treści. Nie oznacza to jednak, że sama szybkość powoduje, iż system sztucznej inteligencji cytuje tę stronę.

Na dzień 2 sierpnia 2026 r. Google stwierdza, że stabilny czas odpowiedzi serwera i niższe opóźnienia mogą zwiększyć pojemność indeksowania witryny. Google oświadcza również, że jego funkcje wyszukiwania oparte na sztucznej inteligencji wykorzystują te same podstawowe systemy wyszukiwania i indeksowania co tradycyjne wyszukiwanie i nie wymagają specjalnych znaczników AI ani optymalizacji szybkości. (developers.google.com)

Ten artykuł przedstawia plan testów opartych na dowodach, zamiast twierdzić, że eksperyment został już przeprowadzony. Nie dostarczono żadnej witryny, zestawu stron, dziennika serwera ani zbioru danych cytowań. Celem jest zdefiniowanie kontrolowanego badania, które może zmierzyć:

1. Czy krótszy czas do pierwszego bajtu zwiększa częstotliwość indeksowania.
2. Czy niższy Largest Contentful Paint poprawia wykrywanie lub indeksowanie.
3. Czy niższy Cumulative Layout Shift wpływa na indeksowanie lub pobieranie przez sztuczną inteligencję.
4. Czy ulepszenia wydajności zwiększają wskaźnik, z jakim strony są widocznie cytowane przez systemy wyszukiwania oparte na sztucznej inteligencji.

Krótka odpowiedź

Krótszy czas do pierwszego bajtu może poprawić indeksowanie w odpowiednich warunkach

Obecna dokumentacja indeksowania Google mówi, że limit pojemności indeksowania może wzrosnąć, gdy witryna ma stabilne lub poprawiające się czasy odpowiedzi, w tym czas do pierwszego bajtu. Jeśli czasy odpowiedzi wzrosną, lub jeśli witryna zwraca zbyt wiele błędów serwera lub odpowiedzi z limitem częstości, Google może zmniejszyć indeksowanie. (developers.google.com)

Jednak szybszy czas odpowiedzi nie gwarantuje większej ilości indeksowania. Zapotrzebowanie na indeksowanie zależy również od takich czynników, jak:

• Jak często zmienia się witryna.
• Jak popularna jest witryna i jej strony.
• Czy treść jest użyteczna i unikalna.
• Ile istnieje zduplikowanych lub mało wartościowych adresów URL.
• Czy zaktualizowane adresy URL są uwzględnione w mapach witryny.

Oznacza to, że niższe opóźnienia powinny mieć najsilniejszy wpływ na duże, często aktualizowane lub ograniczone serwerowo witryny, a niekoniecznie na małą witrynę z ograniczoną nową treścią.

Niższy Largest Contentful Paint może pomóc pośrednio

Largest Contentful Paint mierzy moment, w którym główna widoczna treść pojawia się dla użytkownika. Google stwierdza również, że zarówno czas odpowiedzi serwera, jak i czas wymagany do renderowania stron i zasobów osadzonych mogą wpływać na efektywność indeksowania. (developers.google.com)

Prawdopodobna zależność jest pośrednia:

Niższe opóźnienia → szybsze dostarczanie zasobów → bardziej efektywne renderowanie lub pobieranie → mniej przekroczeń limitu czasu indeksowania lub niekompletnych pobrań.

Efekt powinien być najsilniejszy, gdy ważna treść zależy od:

• Wolnego JavaScriptu.
• Dużych obrazów.
• Blokujących renderowanie arkuszy stylów.
• Renderowania po stronie klienta.
• Ciężkich zasobów osadzonych.

Szybki wynik Largest Contentful Paint sam w sobie prawdopodobnie nie jest bezpośrednim sygnałem cytowania przez sztuczną inteligencję.

Niższy Cumulative Layout Shift prawdopodobnie ma niewielki bezpośredni wpływ na indeksowanie

Cumulative Layout Shift mierzy nieoczekiwane przesuwanie się widocznej treści. Jest to głównie wskaźnik doświadczenia użytkownika. Typowe przyczyny obejmują obrazy bez wymiarów, dynamicznie wstawiane reklamy, osadzoną treść i czcionki internetowe. (web.dev)

Crawler nie doświadcza przesunięcia układu w taki sam sposób jak ludzki użytkownik. Dlatego bezpośrednia zależność między niższym Cumulative Layout Shift a większą liczbą indeksowań jest mało prawdopodobna.

Może istnieć pośrednia zależność, gdy duże przesunięcie układu jest spowodowane przez:

• Treść wstawianą późno przez JavaScript.
• Ważny tekst ukryty do momentu uruchomienia skryptów.
• Obrazy lub osadzone elementy, które opóźniają budowanie strony.
• Niestabilne szablony, które generują różną treść podczas różnych pobrań.

W takich przypadkach prawdziwym problemem nie jest wynik przesunięcia układu. Prawdziwym problemem jest to, że strona może być trudna do przetworzenia lub może zbyt późno ujawniać ważną treść.

Szybsze strony nie są automatycznie cytowane częściej

Google twierdzi, że strony pojawiające się w funkcjach sztucznej inteligencji muszą najpierw zostać zaindeksowane i kwalifikować się do wyświetlenia w normalnych wynikach wyszukiwania z fragmentem. Google oświadcza również, że nie ma żadnych dodatkowych wymagań technicznych ani specjalnych optymalizacji sztucznej inteligencji dla jego przeglądów AI i trybu AI. (developers.google.com)

OpenAI podobnie stwierdza, że rankingi wyszukiwania ChatGPT zależą od wielu czynników i że zezwolenie na jego crawler wyszukiwania, OAI-SearchBot, jest ważne dla włączenia. Nie stwierdza, że niższe Core Web Vitals bezpośrednio zwiększają prawdopodobieństwo cytowania. (help.openai.com)

To sugeruje czterostopniowy model:

1. Odkrycie — Czy system dowiaduje się o istnieniu adresu URL?
2. Pobieranie i przetwarzanie — Czy system może pobrać i zrozumieć stronę?
3. Indeksowanie i pobieranie — Czy strona jest wybierana dla określonego zapytania?
4. Wybór cytowania — Czy strona jest wyświetlana jako widoczne źródło w odpowiedzi?

Szybkość strony może wpływać na pierwsze dwa etapy. Nie jest to ustalone jako bezpośrednia przyczyna czwartego etapu.

Ostatnie badania pokazują również, że systemy sztucznej inteligencji mogą czytać wiele istotnych stron, ale cytować tylko niektóre z nich. Innymi słowy, pobieranie i cytowanie to oddzielne zdarzenia. (cambridge.org)

Co należy przetestować?

Badanie powinno testować dwa różne pytania, zamiast traktować „widoczność w sztucznej inteligencji” jako jedną metrykę.

Pytanie 1: Czy wydajność wpływa na indeksowanie?

Główne wyniki:

• Czas od publikacji do pierwszego żądania crawlera.
• Liczba żądań crawlera na stronę dziennie.
• Czas między udanymi ponownymi indeksowaniami.
• Liczba stron indeksowanych na 1000 opublikowanych stron.
• Procent udanych pobrań.
• Wskaźnik błędów serwera i odpowiedzi z limitem częstości.
• Czas od publikacji do indeksowania.

Pytanie 2: Czy wydajność wpływa na wybór cytowań?

Główne wyniki:

• Procent przetestowanych zapytań, które generują widoczne cytowanie.
• Wskaźnik cytowań na kwalifikującą się stronę.
• Udział cytowania w zapytaniu.
• Procent pobranych stron, które stają się widocznymi cytowaniami.
• Trwałość cytowania w czasie.
• Wskaźnik cytowań według systemu sztucznej inteligencji.

Wyniki te muszą być rozdzielone według dostawcy. Przegląd sztucznej inteligencji Google, wynik wyszukiwania ChatGPT, odpowiedź Microsoft Copilot, odpowiedź Perplexity i odpowiedź wyszukiwania Claude mogą wykorzystywać różne indeksy, crawlery, systemy rankingowe i harmonogramy odświeżania.

Projekt eksperymentu

1. Stwórz kontrolowany zestaw stron

Użyj zestawu stron wystarczająco dużego, aby uzyskać znaczące dane o indeksowaniu i cytowaniach.

Praktyczny projekt początkowy powinien obejmować:

• 240 do 800 stron.
• Co najmniej 20 stron na szablon strony.
• Trzy do pięciu kategorii treści.
• Mieszanka stron zawsze aktualnych i regularnie aktualizowanych.
• Równa liczba stron w każdej grupie badanej.

Każda strona powinna mieć:

• Podobną strukturę HTML.
• Podobną długość treści.
• Ten sam system publikacji.
• Ten sam wzorzec linkowania wewnętrznego.
• Te same reguły kanoniczne.
• Te same zasady traktowania w mapie witryny.
• Te same uprawnienia robots.txt.
• Unikalny, użyteczny temat.

Nie twórz setek cienkich lub prawie zduplikowanych stron tylko na potrzeby eksperymentu. Wskazówki Google ostrzegają, że zduplikowane i mało wartościowe adresy URL mogą marnować zasoby indeksowania i zmniejszać efektywność witryny. (developers.google.com)

Przydatny jest projekt parowanych grup. Na przykład, paruj strony o podobnych cechach:

• Długości treści.
• Zapotrzebowaniu na temat.
• Częstotliwości aktualizacji.
• Liczbie linków wewnętrznych.
• Liczbie linków zewnętrznych.
• Historycznym ruchu.
• Pozycji w rankingu wyszukiwania.

Następnie umieść jedną stronę z każdej pary w grupie kontrolnej, a drugą w grupie badanej.

2. Użyj czynnikowego projektu badawczego

Główne rozwiązania dotyczące wydajności powinny być testowane niezależnie i łącznie.

Tworzy to kontrolowany eksperyment dla trzech wymaganych optymalizacji:

• HTTP/3.
• Buforowanie na brzegu sieci CDN.
• Kompresja obrazów.

Leczenie stabilności układu jest konieczne, ponieważ pierwsze trzy optymalizacje nie izolują niezawodnie Cumulative Layout Shift. Kompresja obrazów może obniżyć Largest Contentful Paint bez zmiany stabilności układu.

Dlaczego HTTP/3 wymaga własnego pomiaru

HTTP/3 wykorzystuje protokół transportowy QUIC i zapewnia niezależne strumienie, co pozwala uniknąć blokowania na poziomie transportu (head-of-line blocking), występującego w HTTP/2 przez TCP. Jego korzyści zależą od tego, czy klient lub crawler faktycznie negocjuje HTTP/3. (rfc-editor.org)

Dlatego rejestruj wynegocjowany protokół dla każdego żądania:

• HTTP/1.1.
• HTTP/2.
• HTTP/3.

Nie zakładaj, że włączenie HTTP/3 oznacza, że każdy crawler go używa. Jeśli Googlebot, OAI-SearchBot lub inny crawler nadal używa HTTP/2, HTTP/3 nie może wpływać na żądania tego crawlera.

Dlaczego buforowanie na brzegu sieci powinno być dokładnie testowane

Sieć dostarczania treści (CDN) może skrócić czas do pierwszego bajtu poprzez serwowanie treści bliżej requestera. Może również zmniejszyć liczbę żądań docierających do serwera źródłowego. (web.dev)

Testuj co najmniej trzy stany pamięci podręcznej:

1. Zimna pamięć podręczna — brzeg sieci musi skontaktować się z serwerem źródłowym.
2. Ciepła pamięć podręczna — brzeg sieci serwuje stronę bez kontaktu z serwerem źródłowym.
3. Revalidowana pamięć podręczna — brzeg sieci lub crawler używa wartości ETag lub Last-Modified i otrzymuje odpowiedź 304 Not Modified.

Google szczególnie zaleca efektywne buforowanie HTTP i wspiera używanie odpowiedzi 304 Not Modified, aby zmniejszyć niepotrzebne przetwarzanie i zużycie pasma. (developers.google.com)

Nie pozwól, aby buforowanie serwowało nieaktualne lub nieprawidłowe treści crawlerom. Rejestruj:

• Trafienie lub brak trafienia w pamięci podręcznej.
• Wiek pamięci podręcznej.
• Lokalizację brzegu sieci.
• Czas odpowiedzi serwera źródłowego.
• Wersję treści.
• Kod statusu.
• Nagłówki walidacyjne.

Dlaczego kompresja obrazów powinna być powiązana z Largest Contentful Paint

WebP i AVIF zazwyczaj zapewniają lepszą kompresję niż starsze formaty obrazów. Mniejsze obrazy mogą skrócić czas transferu i mogą poprawić Largest Contentful Paint, gdy obraz jest elementem Largest Contentful Paint. (web.dev)

Test powinien wykorzystywać:

• Te same wymiary obrazów.
• Ten sam cel jakości wizualnej.
• Responsywne obrazy srcset.
• Nowoczesny format z odpowiednim rozwiązaniem awaryjnym.
• Jawne wartości width i height.
• Brak leniwego ładowania dla obrazu Largest Contentful Paint.
• Adres URL obrazu widoczny w początkowym kodzie HTML.

Sama kompresja obrazów może nie poprawić Largest Contentful Paint, jeśli rzeczywiste opóźnienie wynika z JavaScriptu lub późnego odkrycia zasobów. Wskazówki dotyczące wydajności Google zauważają, że skrócenie czasu pobierania obrazów może po prostu przesunąć opóźnienie na inną część strony, jeśli element Largest Contentful Paint zostanie ujawniony późno. (web.dev)

3. Przeprowadź test wystarczająco długo

Krótki test może pominąć efekty harmonogramowania indeksowania i odświeżania indeksu.

Praktyczny projekt to:

• Dwa tygodnie pomiarów bazowych.
• Sześć do dwunastu tygodni pomiarów po wdrożeniu zmian.
• Końcowy okres odwrócenia lub skrzyżowania (crossover) jeśli to możliwe.

W przypadku testu crossover, zamień metody badane między dopasowanymi grupami stron. Jeśli efekt wydajności zniknie po usunięciu metody, wynik jest silniejszy niż proste porównanie przed i po.

Dane terenowe Core Web Vitals powinny być oceniane przez odpowiedni okres. Raport Chrome User Experience Report wykorzystuje 28-dniową agregację kroczącą, więc nie jest przeznaczony do pokazywania natychmiastowych zmian po wdrożeniu. (developer.chrome.com)

4. Zmierz całą populację crawlerów

Nie traktuj całego zautomatyzowanego ruchu jako jednej grupy.

Minimum, oddziel:

Crawlery wyszukiwarek

• Googlebot.
• Bingbot.

Crawlery wyszukiwarek sztucznej inteligencji

• OAI-SearchBot.
• PerplexityBot.
• Claude-SearchBot.

Pobieracze na żądanie użytkownika

• Perplexity-User.
• Claude-User.
• Pobieracze użytkowników ChatGPT, jeśli można ich zidentyfikować.

Crawlery treningowe

• GPTBot.
• ClaudeBot.
• Kontrolki Google-Extended.

Crawlerów treningowych nie należy używać jako proxy dla cytowań wyszukiwania sztucznej inteligencji. Anthropic, OpenAI i Google rozróżniają crawlery używane do treningu, wyszukiwania lub pobierania na żądanie użytkownika. Google również stwierdza, że Google-Extended nie wpływa na włączenie do wyszukiwarki Google ani na ranking. (help.openai.com)

Perplexity podobnie rozróżnia PerplexityBot, który wspiera indeksowanie wyszukiwania, oraz Perplexity-User, który może pobierać stronę w odpowiedzi na żądanie użytkownika. (docs.perplexity.ai)

Zweryfikuj tożsamość crawlera za pomocą opublikowanych zakresów IP lub odwrotnego DNS, tam gdzie dostawca to wspiera. Ciągi znaków user-agent mogą być kopiowane przez niezwiązane crawlery. Google wyraźnie ostrzega, że ciągi znaków user-agent Googlebot mogą być sfałszowane. (developers.google.com)

Metryki do zebrania

Metryki wydajności

Zbierz dane zarówno laboratoryjne, jak i od prawdziwych użytkowników:

• Czas do pierwszego bajtu.
• First Contentful Paint.
• Largest Contentful Paint.
• Cumulative Layout Shift.
• Interaction to Next Paint.
• Całkowita waga strony.
• Rozmiar początkowego HTML.
• Rozmiar transferu obrazów.
• Liczba żądań.
• Czas spędzony na przetwarzaniu przez serwer.
• Czas oczekiwania na zasób Largest Contentful Paint.
• Protokół HTTP.
• Status pamięci podręcznej.

Google zaleca orientacyjny cel czasu do pierwszego bajtu wynoszący 800 milisekund lub mniej, ale sam czas do pierwszego bajtu nie jest Core Web Vital. (web.dev)

Obecne progi „dobrych” Core Web Vitals dla 75. percentyla to:

• Largest Contentful Paint: 2,5 sekundy lub mniej.
• Cumulative Layout Shift: 0,1 lub mniej.
• Interaction to Next Paint: 200 milisekund lub mniej. (web.dev)

Metryki indeksowania

Dla każdego zweryfikowanego żądania crawlera, rejestruj:

text timestamp url user_agent verified_bot source_ip http_protocol status_code response_time time_to_first_byte bytes_sent cache_status edge_location etag last_modified referrer

Oblicz:

text crawl_requests_per_url_day successful_fetch_rate 5xx_rate 429_rate median_recrawl_interval p75_recrawl_interval publication_to_first_fetch publication_to_first_index

Metryki cytowań sztucznej inteligencji

Użyj stałego zestawu zapytań dla każdej platformy. Zestaw zapytań powinien obejmować:

• Bezpośrednie pytania faktyczne.
• Pytania porównawcze.
• Pytania o „najlepsze” lub rekomendacje.
• Pytania wrażliwe na świeżość.
• Pytania, na które testowana strona jest najsilniejszą odpowiedzią.
• Pytania, na które testowana strona jest istotna, ale nie dominująca.

Dla każdego zapytania, rejestruj:

text engine model or experience timestamp location device query pages shown as sources page citation order whether the tested page was cited whether the tested page was retrieved but not cited answer text hash

Powtarzaj zapytania, ponieważ odpowiedzi sztucznej inteligencji mogą się różnić. Użyj stałego harmonogramu, np. trzy razy w tygodniu, i rejestruj zmiany w silniku lub modelu.

Narzędzia dla webmasterów Microsoft Bing oferują teraz raport wydajności sztucznej inteligencji, pokazujący cytowane strony, zapytania bazowe i trendy cytowań w obsługiwanych doświadczeniach sztucznej inteligencji Microsoftu. Microsoft ostrzega, że dane są agregowane, próbkowane i obserwacyjne; nie mogą udowodnić, że konkretna zmiana strony spowodowała zmianę cytowania. (bing.com)

Google również rozpoczął wdrażanie dedykowanych raportów wydajności generatywnej sztucznej inteligencji w Search Console w czerwcu 2026 roku. Raporty były początkowo dostępne tylko dla podzbioru witryn, więc dostęp może się różnić. (developers.google.com)

Analiza statystyczna

Częstotliwość indeksowania

Użyj modelu zliczania z efektami mieszanymi, takiego jak model ujemny dwumianowy:

text crawl_count ~ treatment + time_to_first_byte + page_age + update_frequency + sitemap_status + internal_links + server_errors + (1 | page) + (1 | crawler)

Efekty strony i crawlera mają znaczenie, ponieważ niektóre strony naturalnie otrzymują więcej uwagi niż inne, a różne crawlery mają różne harmonogramy.

Odkrywanie i indeksowanie

Użyj analizy przeżycia dla:

• Czas od publikacji do pierwszego pobrania.
• Czas od publikacji do pierwszego indeksu.
• Czas od aktualizacji do ponownego indeksowania.

Kluczowym wynikiem nie jest po prostu to, czy strona została w końcu zaindeksowana. Chodzi o to, czy interwencja skróciła czas potrzebny na znalezienie i przetworzenie strony.

Wybór cytowań przez sztuczną inteligencję

Użyj hierarchicznego modelu logistycznego:

text citation_present ~ treatment + time_to_first_byte + largest_contentful_paint + cumulative_layout_shift + indexed_status + search_visibility + content_freshness + page_authority + (1 | query) + (1 | engine) + (1 | page)

Uruchom dwa oddzielne modele:

1. Model pobierania — Czy strona została pobrana lub pokazana jako kandydat?
2. Model cytowania — Jeśli pobrana, czy strona została widocznie zacytowana?

To rozróżnienie jest kluczowe. Poprawa wydajności, która zwiększa indeksowanie, ale nie pobieranie, nie jest efektem cytowania przez sztuczną inteligencję. Poprawa wydajności, która zwiększa pobieranie, ale nie cytowanie, sugeruje, że strona jest brana pod uwagę, ale przegrywa podczas wyboru źródła.

Oczekiwane wyniki

Są to hipotezy robocze, a nie deklarowane wyniki eksperymentalne.

Hipoteza 1: Czas do pierwszego bajtu będzie miał najjaśniejszy wpływ na indeksowanie

Oczekuj pozytywnej zależności między krótszym czasem do pierwszego bajtu a pojemnością indeksowania, gdy:

• Witryna ma wiele stron.
• Strony często się zmieniają.
• Serwer źródłowy jest wolny lub przeciążony.
• Witryna zwraca odpowiedzi 5xx lub 429.
• Crawler spędza znaczący czas na oczekiwaniu na odpowiedzi.

Oczekuj niewielkiego mierzalnego wpływu na małą witrynę z niskim zapotrzebowaniem na indeksowanie.

Hipoteza 2: Largest Contentful Paint będzie miał znaczenie poprzez renderowanie i dostarczanie zasobów

Oczekuj, że niższy Largest Contentful Paint pomoże, gdy:

• Strona zależy od renderowania przez przeglądarkę.
• Ważna treść jest za JavaScriptem.
• Duże obrazy lub arkusze stylów są wymagane do indeksowania.
• Crawler pobiera wiele zasobów strony.
• Wolniejsze rozwiązanie prowadzi do przekroczenia limitu czasu lub niekompletnego renderowania.

Oczekuj słabej zależności, gdy ważny tekst strony jest już obecny w początkowym HTML.

Hipoteza 3: Cumulative Layout Shift będzie miał niewielki bezpośredni wpływ

Nie oczekuj żadnej znaczącej bezpośredniej zależności między Cumulative Layout Shift a częstotliwością indeksowania lub wskaźnikiem cytowań po uwzględnieniu struktury strony i zachowania JavaScript.

Jeśli Cumulative Layout Shift wydaje się przewidywać cytowania, zbadaj, czy działa jako pośrednik dla:

• Renderowania po stronie klienta.
• Późnego wstawiania treści.
• Niestabilnych reklam.
• Ukrytego lub opóźnionego tekstu.
• Źle ustrukturyzowanego kodu HTML.

Hipoteza 4: Sama szybkość nie wygeneruje więcej cytowań sztucznej inteligencji

Najsilniejszymi predyktorami wyboru cytowania prawdopodobnie pozostaną:

• Trafność dla zapytania.
• Jakość treści.
• Jasne odpowiedzi.
• Świeżość.
• Autorytet i zaufanie.
• Kwalifikowalność do indeksu wyszukiwania.
• Pozycja w wynikach pobierania.
• Czy strona bezpośrednio wspiera przedstawiane twierdzenie.

Wytyczne Google podkreślają użyteczne, wiarygodne treści zorientowane na ludzi i stwierdzają, że funkcje wyszukiwania oparte na sztucznej inteligencji opierają się na istniejących systemach wyszukiwania i indeksowania. (developers.google.com)

Budżet wydajności dostosowany do pobierania przez sztuczną inteligencję

Poniżej przedstawiono proponowany budżet operacyjny. Nie jest to opublikowana formuła rankingowa sztucznej inteligencji.

Obecna dokumentacja Google mówi, że Googlebot pobiera pierwsze 2 megabajty obsługiwanego pliku i oddzielnie pobiera zewnętrzne skrypty i arkusze stylów. Zaleca również umieszczanie ważnych metadanych i danych strukturalnych wcześnie w HTML. (developers.google.com)

Zalecenia dotyczące wdrożenia

HTTP/3

Używaj HTTP/3, gdy jest obsługiwany przez dostawcę hostingu i sieć dostarczania treści.

Zmierz:

• Wskaźnik negocjacji HTTP/3.
• Wskaźnik powrotu do HTTP/2.
• Czas nawiązywania połączenia.
• Czas do pierwszego bajtu.
• Wydajność według regionu geograficznego.
• Wydajność według crawlera.

Nie traktuj HTTP/3 jako gwarantowanej optymalizacji dla wyszukiwarki lub sztucznej inteligencji. Jest to ulepszenie transportu, które może pomóc tylko klientom, którzy go używają.

Buforowanie na brzegu sieci dostarczania treści (CDN Edge Caching)

Dla publicznych, niespersonalizowanych stron:

• Ustaw jasne reguły Cache-Control.
• Używaj długotrwałego buforowania dla wersjonowanych zasobów statycznych.
• Używaj krótkiego, ale użytecznego buforowania dla często aktualizowanego kodu HTML.
• Unikaj fragmentacji pamięci podręcznej z powodu niepotrzebnych parametrów zapytania.
• Zachowaj kanoniczne adresy URL.
• Obsługuj ETag i Last-Modified.
• Testuj stany zimnej, ciepłej i revalidowanej pamięci podręcznej.
• Potwierdź, że żądania crawlera otrzymują te same ważne treści, co żądania ludzi.

Sieć dostarczania treści powinna zmniejszyć opóźnienia, nie tworząc nieaktualnych, niespójnych lub specyficznych dla botów wersji stron.

Kompresja obrazów

Dla obrazów:

• Używaj AVIF lub WebP, gdy jakość wizualna jest akceptowalna.
• Zapewnij responsywne rozmiary obrazów.
• Nie serwuj obrazu o rozmiarze desktopowym na małym ekranie mobilnym.
• Nie ładuj leniwie obrazu Largest Contentful Paint.
• Uwzględnij wymiary obrazu.
• Umieść obraz Largest Contentful Paint w początkowym HTML.
• Używaj fetchpriority="high" tylko wtedy, gdy jest to stosowne.
• Ważne wyjaśnienia umieszczaj w tekście, zamiast osadzać je tylko w obrazach.

Kompresja obrazów jest najbardziej wartościowa, gdy obraz jest elementem Largest Contentful Paint. Nie naprawi ona strony, której główne opóźnienie wynika z renderowania po stronie serwera lub wykonania JavaScriptu. (web.dev)

Stabilność układu

Aby zmniejszyć Cumulative Layout Shift:

• Ustaw atrybuty szerokości i wysokości dla obrazów.
• Zarezerwuj miejsce na reklamy.
• Zarezerwuj miejsce na osadzone wideo i treści społecznościowe.
• Unikaj wstawiania banerów nad istniejącym tekstem.
• Stosuj stabilne strategie ładowania czcionek.
• Unikaj zastępowania dużych bloków treści renderowanych po stronie serwera po załadowaniu strony.

Te zmiany poprawiają doświadczenie użytkownika, nawet jeśli nie mają mierzalnego wpływu na indeksowanie lub cytowania. (web.dev)

Narzędzia i monitorowanie

Narzędzia do monitorowania wydajności

Użyj:

• Chrome User Experience Report dla Core Web Vitals od prawdziwych użytkowników.
• Interfejs programistyczny Chrome User Experience Report do zautomatyzowanego zbierania danych terenowych.
• PageSpeed Insights do audytów laboratoryjnych i danych terenowych.
• Lighthouse do powtarzalnych testów laboratoryjnych.
• Lighthouse Continuous Integration do budżetów wydajności dla pull requestów.
• WebPageTest do testów wielolokacyjnych, stanów pamięci podręcznej i porównań protokołów.
• Chrome DevTools do debugowania Largest Contentful Paint i przesunięć układu.
• Biblioteka JavaScript web-vitals do monitorowania użytkowników w czasie rzeczywistym.

Interfejs programistyczny Chrome User Experience Report dostarcza zagregowane dane terenowe na poziomie strony i źródła, w tym Largest Contentful Paint, Cumulative Layout Shift, Interaction to Next Paint oraz eksperymentalny czas do pierwszego bajtu. (developer.chrome.com)

Lighthouse Continuous Integration może przeprowadzać kontrole wydajności przy każdej zmianie kodu i przerywać kompilacje, gdy budżety zostaną przekroczone. (github.com)

Monitorowanie crawlerów

Użyj logów serwera, logów brzegowych i małego zestawu syntetycznych sond.

Przykładowa sonda:

bash curl --http3 -sS -o /dev/null -D -
-w 'status=%{http_code}\nhttp_version=%{http_version}\nnamelookup=%{time_namelookup}\nconnect=%{time_connect}\nstarttransfer=%{time_starttransfer}\ntotal=%{time_total}\nsize=%{size_download}\n'
-A 'Mozilla/5.0 (compatible; OAI-SearchBot/1.0)'
https://example.com/page

Przeprowadź ten sam test z:

• Googlebot.
• Bingbot.
• OAI-SearchBot.
• PerplexityBot.
• Claude-SearchBot.
• Normalnym user-agentem przeglądarki.

Test powinien zweryfikować:

• Kod statusu.
• Pozwolenie robots.
• Nagłówki odpowiedzi.
• Zawartość HTML.
• Wersję HTTP.
• Stan pamięci podręcznej.
• Czas odpowiedzi.
• Czy ważny tekst jest obecny bez JavaScriptu.

Monitorowanie wyszukiwania i indeksowania

Użyj:

• Statystyki indeksowania z Google Search Console.
• Raporty indeksowania stron z Google Search Console.
• Inspekcję URL w Google Search Console.
• Dane mapy witryny z Google Search Console.
• Raporty generatywnej sztucznej inteligencji z Google Search Console, gdy są dostępne.
• Żądania indeksowania i zaindeksowane strony z Bing Webmaster Tools.
• Wydajność sztucznej inteligencji z Bing Webmaster Tools.
• Codzienne sprawdzanie mapy witryny i lastmod.

Interfejs programistyczny Search Console może pobierać dane wydajności według strony, zapytania, daty, urządzenia i wyglądu w wyszukiwarce, z zastrzeżeniem limitów danych. (developers.google.com)

Monitorowanie cytowań

Utwórz panel cytowań zawierający od 50 do 200 stabilnych zapytań na temat. Uruchamiaj panel według stałego harmonogramu i rejestruj:

• Czy platforma wyszukiwała.
• Które źródła się pojawiły.
• Czy testowany adres URL został zacytowany.
• Kolejność cytowania.
• Datę i godzinę odpowiedzi.
• Czy strona się zmieniła.
• Czy model lub doświadczenie wyszukiwania uległo zmianie.

Nie porównuj liczby cytowań z różnych systemów, jakby były równoważne. Microsoft stwierdza, że aktywność cytowań nie jest wynikiem rankingowym, wynikiem autorytetu, miarą ruchu ani wynikiem jakości. (bing.com)

Reguły alertów

Utwórz alerty dla:

• Wzrostu czasu do pierwszego bajtu o ponad 25 procent.
• Largest Contentful Paint przekraczającego 2,5 sekundy na 75. percentylu.
• Cumulative Layout Shift przekraczającego 0,1.
• Utrzymującego się wzrostu odpowiedzi 5xx lub 429.
• Spadku wskaźnika sukcesu crawlera.
• Zmiany w robots.txt.
• Błędu mapy witryny.
• Nagłego spadku liczby zaindeksowanych stron.
• Nagłego spadku cytowań sztucznej inteligencji na kilku platformach.
• Zmiany w wolumenie cytowań, która dotyczy tylko jednej platformy.

Spadek cytowań wpływający na jedną platformę może być spowodowany zmianą modelu, indeksu, zapytania lub produktu, a nie problemem z wydajnością strony. Microsoft wyraźnie ostrzega, że trendy cytowań są obserwacyjne i mogą zmieniać się z powodu aktualizacji treści, popytu użytkowników oraz zmian w systemie lub modelu. (bing.com)

Końcowy wniosek

Najbardziej obronny wniosek jest następujący:

Szybsze strony mogą poprawić efektywność indeksowania, zwłaszcza gdy opóźnienia serwera, rozmiar zasobów, błędy lub opóźnienia renderowania są czynnikami ograniczającymi. Jednak obecnie nie ma mocnych dowodów na to, że niższe Core Web Vitals bezpośrednio powodują, że systemy sztucznej inteligencji wybierają stronę jako cytat.

Oczekiwany łańcuch przyczynowy to:

text Lower latency → better server capacity → fewer failed or delayed fetches → faster discovery and processing → improved chance of being indexed and retrieved → possible increase in citations

Ostatni krok pozostaje niepewny, ponieważ wybór cytowania zależy od trafności, jakości, świeżości, autorytetu, intencji zapytania, pozycji w wynikach pobierania oraz zachowania każdego systemu sztucznej inteligencji.

Dla większości witryn, prawidłowa strategia wydajności nie polega zatem na „optymalizacji pod kątem cytowań sztucznej inteligencji” w izolacji. Jest to:

1. Utrzymuj ważne treści dostępne w początkowym HTML.
2. Utrzymuj stabilny czas do pierwszego bajtu.
3. Używaj buforowania na brzegu sieci dla treści publicznych.
4. Kompresuj i priorytetyzuj ważne obrazy.
5. Zapobiegaj przesunięciom układu.
6. Zwracaj niezawodne kody statusu.
7. Utrzymuj aktualne mapy witryny i linki wewnętrzne.
8. Zezwalaj na właściwe crawlery wyszukiwarek.
9. Mierz indeksowanie, indeksowanie, pobieranie i cytowanie jako oddzielne etapy.

Takie podejście skutkuje szybszą stroną internetową dla ludzi, zdrowszą witryną dla crawlerów wyszukiwarek i podstawą do testowania, aby zrozumieć widoczność w sztucznej inteligencji.