Core Web Vitals a latence: Získají rychlejší stránky více citací od umělé inteligence?

Core Web Vitals a latence: Získají rychlejší stránky více citací od umělé inteligence?

Úvod

Rychlý web je pro lidi snazší k použití. Může být také snazší pro vyhledávače a systémy umělé inteligence k načítání, vykreslování a pochopení.

Často se však opomíjí důležité rozlišení:

Rychlejší stránka může zlepšit procházení a dostupnost obsahu. To ale neznamená, že samotná rychlost způsobí, že systém umělé inteligence stránku cituje.

K 2. srpnu 2026 Google uvádí, že stabilní doby odezvy serveru a nižší latence mohou zvýšit kapacitu procházení webu. Google také uvádí, že jeho funkce vyhledávání s umělou inteligencí používají stejné základní vyhledávací a indexovací systémy jako tradiční vyhledávání a nevyžadují speciální značení pro umělou inteligenci ani optimalizace rychlosti. (developers.google.com)

Tento článek představuje plán testování založený na důkazech, spíše než aby tvrdil, že již proběhl dokončený experiment. Nebyl poskytnut žádný web, sada stránek, serverový protokol ani datová sada citací. Cílem je definovat kontrolovanou studii, která může měřit:

1. Zda nižší čas do prvního bytu zvyšuje frekvenci procházení.
2. Zda nižší Největší vykreslení obsahu (Largest Contentful Paint) zlepšuje objevování nebo indexování.
3. Zda nižší Kumulativní posun rozvržení (Cumulative Layout Shift) ovlivňuje procházení nebo získávání informací umělou inteligencí.
4. Zda vylepšení výkonu zvyšují míru, s jakou jsou stránky viditelně citovány vyhledávacími systémy umělé inteligence.

Stručná odpověď

Nižší čas do prvního bytu může za správných podmínek zlepšit procházení

Současná dokumentace společnosti Google k procházení uvádí, že limit kapacity procházení se může zvýšit, pokud má web stabilní nebo zlepšující se doby odezvy, včetně času do prvního bytu. Pokud se doby odezvy zvýší, nebo pokud web vrací příliš mnoho serverových chyb nebo odpovědí s omezením rychlosti, Google může procházení snížit. (developers.google.com)

Rychlejší doba odezvy však nezaručuje více procházení. Poptávka po procházení závisí také na faktorech, jako jsou:

• Jak často se web mění.
• Jak populární je web a jeho stránky.
• Zda je obsah užitečný a jedinečný.
• Kolik duplicitních nebo nízko hodnotných URL existuje.
• Zda jsou aktualizované URL zahrnuty v souborech sitemap.

To znamená, že nižší latence by měla mít nejsilnější účinek na velké, často aktualizované nebo serverem omezené webové stránky, nikoli nutně na malý web s omezeným novým obsahem.

Nižší Největší vykreslení obsahu (Largest Contentful Paint) může pomoci nepřímo

Největší vykreslení obsahu (Largest Contentful Paint) měří, kdy se uživateli zobrazí hlavní viditelný obsah. Google také uvádí, že doba odezvy serveru i čas potřebný k vykreslení stránek a vložených zdrojů mohou ovlivnit efektivitu procházení. (developers.google.com)

Pravděpodobný vztah je nepřímý:

Nižší latence → rychlejší doručení zdrojů → efektivnější vykreslování nebo načítání → méně vypršení časových limitů procházení nebo neúplných načítání.

Efekt by měl být nejsilnější, když důležitý obsah závisí na:

• Pomalém JavaScriptu.
• Velkých obrázcích.
• Stylových předpisech blokujících vykreslování.
• Vykreslování na straně klienta.
• Náročných vložených zdrojích.

Samotné vysoké skóre Největšího vykreslení obsahu (Largest Contentful Paint) pravděpodobně nebude přímým signálem pro citace umělé inteligence.

Nižší Kumulativní posun rozvržení (Cumulative Layout Shift) má pravděpodobně malý přímý vliv na procházení

Kumulativní posun rozvržení (Cumulative Layout Shift) měří neočekávaný pohyb viditelného obsahu. Jde především o metriku uživatelské zkušenosti. Mezi běžné příčiny patří obrázky bez rozměrů, dynamicky vkládané reklamy, vložený obsah a webové fonty. (web.dev)

Procházeč nezaznamená posun rozvržení stejným způsobem jako lidský návštěvník. Proto je přímý vztah mezi nižším Kumulativním posunem rozvržení (Cumulative Layout Shift) a větším procházením nepravděpodobný.

Nepřímý vztah může existovat, pokud je velký posun rozvržení způsoben:

• Obsahem vloženým pozdě pomocí JavaScriptu.
• Důležitým textem skrytým, dokud se nespustí skripty.
• Obrázky nebo vloženým obsahem, které zpožďují sestavení stránky.
• Nestabilními šablonami, které produkují odlišný obsah během různých načítání.

V těchto případech není skutečným problémem skóre posunu rozvržení. Skutečným problémem je, že stránka může být obtížně zpracovatelná nebo může důležitý obsah zobrazovat příliš pozdě.

Rychlejší stránky nejsou automaticky citovány častěji

Google uvádí, že stránky objevující se ve funkcích umělé inteligence musí být nejprve indexovány a způsobilé k zobrazení v běžných výsledcích vyhledávání s úryvkem. Google také uvádí, že pro jeho přehledy a režim umělé inteligence neexistují žádné další technické požadavky ani speciální optimalizace pro umělou inteligenci. (developers.google.com)

OpenAI podobně uvádí, že vyhledávací žebříčky ChatGPT závisí na více faktorech a že povolení jejich vyhledávacího procházeče, OAI-SearchBot, je důležité pro zařazení. Neuvádí, že nižší Core Web Vitals přímo zvyšují pravděpodobnost citace. (help.openai.com)

To naznačuje čtyřfázový model:

1. Objevování — Zjistí systém, že URL existuje?
2. Načítání a zpracování — Dokáže systém načíst a porozumět stránce?
3. Indexování a vyhledávání — Je stránka vybrána pro konkrétní dotaz?
4. Výběr citace — Je stránka zobrazena jako viditelný zdroj v odpovědi?

Rychlost stránky může ovlivnit první dvě fáze. Není stanovena jako přímá příčina čtvrté fáze.

Nedávný výzkum také ukazuje, že systémy umělé inteligence mohou číst mnoho relevantních stránek, ale citují pouze některé z nich. Jinými slovy, vyhledávání a citování jsou samostatné události. (cambridge.org)

Co by se mělo testovat?

Studie by měla testovat dvě různé otázky, spíše než považovat „viditelnost pro umělou inteligenci“ za jednu metriku.

Otázka 1: Ovlivňuje výkon procházení?

Primární výsledky:

• Čas od publikace do prvního požadavku procházeče.
• Počet požadavků procházeče na stránku za den.
• Čas mezi úspěšnými opětovnými procházeními.
• Počet stránek procházených na 1 000 publikovaných stránek.
• Procento úspěšných načítání.
• Míra serverových chyb a odpovědí s omezením rychlosti.
• Čas od publikace do indexování.

Otázka 2: Ovlivňuje výkon výběr citací?

Primární výsledky:

• Procento testovaných dotazů, které vedou k viditelné citaci.
• Míra citací na způsobilou stránku.
• Podíl citací v rámci dotazu.
• Procento načtených stránek, které se stávají viditelnými citacemi.
• Trvalost citace v čase.
• Míra citací podle systému umělé inteligence.

Tyto výsledky musí být odděleny podle poskytovatele. Přehled umělé inteligence Google, výsledek vyhledávání ChatGPT, odpověď Microsoft Copilot, odpověď Perplexity a vyhledávací odpověď Claude mohou používat různé indexy, procházeče, systémy řazení a plány aktualizací.

Experimentální návrh

1. Sestavte kontrolovanou sadu stránek

Použijte dostatečně velkou sadu stránek k vytvoření smysluplných dat o procházení a citacích.

Praktický výchozí návrh by zahrnoval:

• 240 až 800 stránek.
• Nejméně 20 stránek na šablonu stránky.
• Tři až pět kategorií obsahu.
• Směs trvale aktuálních a pravidelně aktualizovaných stránek.
• Stejný počet stránek v každé léčebné skupině.

Každá stránka by měla mít:

• Podobnou HTML strukturu.
• Podobnou délku obsahu.
• Stejný publikační systém.
• Stejný vzor interního propojení.
• Stejná kanonická pravidla.
• Stejné zacházení se sitemapou.
• Stejná oprávnění v robots.txt.
• Jedinečné, užitečné téma.

Nevytvářejte stovky tenkých nebo téměř duplicitních stránek pouze pro experiment. Pokyny společnosti Google varují, že duplicitní a nízko hodnotné URL mohou plýtvat zdroji procházení a snižovat efektivitu webu. (developers.google.com)

Užitečný je design s párováním. Například spárujte stránky s podobným:

• Délkou obsahu.
• Poptávkou po tématu.
• Frekvencí aktualizací.
• Počtem interních odkazů.
• Počtem externích odkazů.
• Historickým provozem.
• Pozicí ve vyhledávání.

Poté umístěte jednu stránku z každého páru do kontrolní skupiny a druhou do léčebné skupiny.

2. Použijte faktoriální návrh ošetření

Hlavní výkonnostní ošetření by měla být testována nezávisle i společně.

Tím se vytvoří kontrolovaný experiment pro tři požadované optimalizace:

• HTTP/3.
• Edge caching sítě pro doručování obsahu (CDN).
• Komprese obrázků.

Ošetření stability rozvržení je nezbytné, protože první tři optimalizace spolehlivě neizolují Kumulativní posun rozvržení (Cumulative Layout Shift). Komprese obrázků může snížit Největší vykreslení obsahu (Largest Contentful Paint), aniž by vůbec změnila stabilitu rozvržení.

Proč HTTP/3 potřebuje vlastní měření

HTTP/3 používá transportní protokol QUIC a poskytuje nezávislé streamy, které mohou zabránit blokování typu head-of-line na transportní vrstvě, které se vyskytuje u HTTP/2 přes TCP. Jeho výhody závisí na tom, zda klient nebo procházeč skutečně vyjednává HTTP/3. (rfc-editor.org)

Proto zaznamenejte vyjednaný protokol pro každý požadavek:

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

Nepředpokládejte, že zapnutí HTTP/3 znamená, že jej používají všichni procházeči. Pokud Googlebot, OAI-SearchBot nebo jiný procházeč nadále používá HTTP/2, HTTP/3 nemůže ovlivnit požadavky tohoto procházeče.

Proč by se mělo pečlivě testovat edge caching

Síť pro doručování obsahu (CDN) může snížit čas do prvního bytu tím, že doručuje obsah blíže k žadateli. Může také snížit počet požadavků, které se dostanou na původní server. (web.dev)

Testujte alespoň tři stavy cache:

1. Studená cache — Edge musí kontaktovat origin.
2. Teplá cache — Edge doručuje stránku bez kontaktování originu.
3. Revalidovaná cache — Edge nebo procházeč používá hodnotu ETag nebo Last-Modified a obdrží odpověď 304 Not Modified.

Google konkrétně doporučuje efektivní HTTP caching a podporuje použití odpovědí 304 Not Modified ke snížení zbytečného zpracování a spotřeby šířky pásma. (developers.google.com)

Nedovolte, aby cache doručovala zastaralý nebo nesprávný obsah procházečům. Zaznamenejte:

• Cache hit nebo miss.
• Stáří cache.
• Umístění edge.
• Doba odezvy originu.
• Verze obsahu.
• Stavový kód.
• Ověřovací hlavičky.

Proč by komprese obrázků měla být spojena s Největším vykreslením obsahu (Largest Contentful Paint)

WebP a AVIF obecně poskytují lepší kompresi než starší obrazové formáty. Menší obrázky mohou snížit dobu přenosu a mohou zlepšit Největší vykreslení obsahu (Largest Contentful Paint), pokud je obrázek elementem Největšího vykreslení obsahu. (web.dev)

Test by měl používat:

• Stejné rozměry obrázků.
• Stejný cíl vizuální kvality.
• Responzivní srcset obrázky.
• Moderní formát s vhodným fallbackem.
• Explicitní hodnoty width a height.
• Žádné líné načítání pro obrázek Největšího vykreslení obsahu (Largest Contentful Paint).
• URL obrázku viditelná v počátečním HTML.

Samotná komprese obrázků nemusí zlepšit Největší vykreslení obsahu (Largest Contentful Paint), pokud skutečné zpoždění pochází z JavaScriptu nebo pozdního objevení zdrojů. Pokyny společnosti Google k výkonu uvádějí, že snížení doby stahování obrázků může pouze přesunout zpoždění na jinou část stránky, pokud je element Největšího vykreslení obsahu odhalen pozdě. (web.dev)

3. Spusťte test dostatečně dlouho

Krátký test může opomenout účinky plánování procházení a obnovy indexu.

Praktický návrh je:

• Dva týdny základního měření.
• Šest až dvanáct týdnů měření ošetření.
• Závěrečné období obrácení nebo zkříženého testování, pokud je to možné.

Pro zkřížený test prohoďte ošetření mezi spárovanými skupinami stránek. Pokud se výkonnostní efekt po odstranění ošetření vytratí, výsledek je silnější než jednoduché srovnání před a po.

Data z terénu Core Web Vitals by měla být vyhodnocována po vhodnou dobu. Zpráva o uživatelské zkušenosti prohlížeče Chrome (Chrome User Experience Report) používá 28denní klouzavou agregaci, takže není navržena tak, aby ukazovala okamžité změny po nasazení. (developer.chrome.com)

4. Změřte celou populaci procházečů

Nezacházejte s veškerým automatizovaným provozem jako s jednou skupinou.

Minimálně oddělte:

Vyhledávací procházeče

• Googlebot.
• Bingbot.

Vyhledávací procházeče umělé inteligence

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

Načítací nástroje na vyžádání uživatele

• Perplexity-User.
• Claude-User.
• Načítací nástroje uživatelů ChatGPT tam, kde jsou identifikovatelné.

Tréninkoví procházeči

• GPTBot.
• ClaudeBot.
• Ovládací prvky Google-Extended.

Tréninkoví procházeči by neměli být používáni jako proxy pro citace vyhledávání umělé inteligence. Anthropic, OpenAI a Google rozlišují mezi procházeči používanými pro trénink, vyhledávání nebo načítání na vyžádání uživatele. Google také uvádí, že Google-Extended neovlivňuje zahrnutí nebo hodnocení ve vyhledávání Google. (help.openai.com)

Perplexity podobně rozlišuje mezi PerplexityBot, který podporuje indexování vyhledávání, a Perplexity-User, který může načíst stránku v reakci na požadavek uživatele. (docs.perplexity.ai)

Ověřte identitu procházeče pomocí publikovaných rozsahů IP adres nebo reverzního DNS tam, kde to poskytovatel podporuje. User-agent řetězce mohou být zkopírovány nesouvisejícími procházeči. Google konkrétně varuje, že user-agent řetězce Googlebotu mohou být zfalšovány. (developers.google.com)

Metriky ke sběru

Výkonnostní metriky

Sbírejte data z laboratoře i od skutečných uživatelů:

• Čas do prvního bytu.
• První vykreslení obsahu.
• Největší vykreslení obsahu.
• Kumulativní posun rozvržení.
• Interakce do dalšího vykreslení.
• Celková hmotnost stránky.
• Velikost počátečního HTML.
• Velikost přenosu obrázku.
• Počet požadavků.
• Čas strávený zpracováním na serveru.
• Čas strávený čekáním na zdroj Největšího vykreslení obsahu (Largest Contentful Paint).
• Protokol HTTP.
• Stav cache.

Google doporučuje přibližný cíl času do prvního bytu 800 milisekund nebo méně, ale čas do prvního bytu sám o sobě není Core Web Vital. (web.dev)

Současné „dobré“ prahové hodnoty Core Web Vitals na 75. percentilu jsou:

• Největší vykreslení obsahu (Largest Contentful Paint): 2,5 sekundy nebo méně.
• Kumulativní posun rozvržení (Cumulative Layout Shift): 0,1 nebo méně.
• Interakce do dalšího vykreslení (Interaction to Next Paint): 200 milisekund nebo méně. (web.dev)

Metriky procházení

Pro každý ověřený požadavek procházeče zaznamenejte:

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

Vypočtěte:

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

Metriky citací umělé inteligence

Použijte pevnou sadu dotazů napříč každou platformou. Sada dotazů by měla zahrnovat:

• Přímé faktické otázky.
• Srovnávací otázky.
• Otázky typu „nejlepší“ nebo doporučení.
• Otázky citlivé na aktuálnost.
• Otázky, u kterých je testovaná stránka nejsilnější odpovědí.
• Otázky, u kterých je testovaná stránka relevantní, ale ne dominantní.

Pro každý dotaz zaznamenejte:

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

Opakujte dotazy, protože odpovědi umělé inteligence se mohou lišit. Použijte pevný rozvrh, například třikrát týdně, a zaznamenejte změny v enginu nebo modelu.

Nástroje Microsoft Bing Webmaster Tools nyní poskytují zprávu o výkonu umělé inteligence (Artificial Intelligence Performance), která ukazuje citované stránky, uzemňující dotazy a trendy citací napříč podporovanými zkušenostmi s umělou inteligencí společnosti Microsoft. Microsoft varuje, že data jsou agregovaná, vzorkovaná a observační; nemohou dokázat, že konkrétní změna stránky způsobila změnu citace. (bing.com)

Google také začal v červnu 2026 zavádět specializované zprávy o výkonu generativní umělé inteligence ve službě Search Console. Zprávy byly zpočátku dostupné pouze pro podmnožinu webových stránek, takže přístup se může lišit. (developers.google.com)

Statistická analýza

Frekvence procházení

Použijte model počtu se smíšenými efekty, například negativní binomický model:

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

Efekty stránky a procházeče jsou důležité, protože některé stránky přirozeně získávají více pozornosti než jiné a různí procházeči mají různé plány.

Objevování a indexování

Použijte analýzu přežití pro:

• Čas od publikace do prvního načtení.
• Čas od publikace do prvního indexování.
• Čas od aktualizace do opětovného procházení.

Klíčovým výsledkem není pouze to, zda byla stránka nakonec procházena. Jde o to, zda ošetření zkrátilo čas potřebný k nalezení a zpracování stránky.

Výběr citací umělou inteligencí

Použijte hierarchický logistický model:

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)

Spusťte dva samostatné modely:

1. Model vyhledávání — Byla stránka nalezena nebo zobrazena jako kandidát?
2. Model citace — Pokud byla nalezena, byla stránka viditelně citována?

Toto rozlišení je zásadní. Vylepšení výkonu, které zvyšuje procházení, ale nikoli vyhledávání, není efektem citace umělé inteligence. Vylepšení výkonu, které zvyšuje vyhledávání, ale nikoli citace, naznačuje, že stránka je zvažována, ale prohrává během výběru zdroje.

Očekávaná zjištění

Toto jsou pracovní hypotézy, nikoli nárokované experimentální výsledky.

Hypotéza 1: Čas do prvního bytu bude mít nejjasnější vliv na procházení

Očekávejte pozitivní vztah mezi nižším časem do prvního bytu a kapacitou procházení, když:

• Web má mnoho stránek.
• Stránky se často mění.
• Původní server je pomalý nebo přetížený.
• Web vrací odpovědi 5xx nebo 429.
• Procházeč stráví značný čas čekáním na odpovědi.

Očekávejte malý měřitelný vliv na malý web s nízkou poptávkou po procházení.

Hypotéza 2: Největší vykreslení obsahu (Largest Contentful Paint) bude důležité prostřednictvím vykreslování a doručování zdrojů

Očekávejte, že nižší Největší vykreslení obsahu (Largest Contentful Paint) pomůže, když:

• Stránka závisí na vykreslování prohlížečem.
• Důležitý obsah je za JavaScriptem.
• Velké obrázky nebo stylové předpisy jsou vyžadovány pro indexování.
• Procházeč načítá mnoho zdrojů stránky.
• Pomalejší ošetření vede k vypršení časového limitu nebo neúplnému vykreslení.

Očekávejte slabý vztah, pokud je důležitý text stránky již přítomen v počátečním HTML.

Hypotéza 3: Kumulativní posun rozvržení (Cumulative Layout Shift) bude mít malý přímý vliv

Neočekávejte žádný smysluplný přímý vztah mezi Kumulativním posunem rozvržení (Cumulative Layout Shift) a frekvencí procházení nebo mírou citací po kontrole struktury stránky a chování JavaScriptu.

Pokud se Kumulativní posun rozvržení (Cumulative Layout Shift) zdá, že předpovídá citace, prozkoumejte, zda nefunguje jako proxy pro:

• Vykreslování na straně klienta.
• Pozdní vkládání obsahu.
• Nestabilní reklamy.
• Skrytý nebo zpožděný text.
• Špatně strukturované HTML.

Hypotéza 4: Samotná rychlost nevygeneruje více citací umělé inteligence

Nejsilnější prediktory výběru citací pravděpodobně zůstanou:

• Relevantnost k dotazu.
• Kvalita obsahu.
• Jasné odpovědi.
• Aktuálnost.
• Autorita a důvěryhodnost.
• Způsobilost pro index vyhledávání.
• Pořadí ve vyhledávání.
• Zda stránka přímo podporuje tvrzení.

Pokyny společnosti Google zdůrazňují užitečný, spolehlivý obsah zaměřený na lidi a uvádí, že funkce vyhledávání umělé inteligence jsou založeny na stávajících vyhledávacích a indexovacích systémech. (developers.google.com)

Rozpočet výkonu vyladěný pro vyhledávání umělou inteligencí

Následuje navrhovaný provozní rozpočet. Není to publikovaný vzorec pro řazení umělou inteligencí.

Aktuální dokumentace společnosti Google uvádí, že Googlebot načítá první 2 megabajty podporovaného souboru a externí skripty a stylové předpisy načítá samostatně. Doporučuje také umístit důležitá metadata a strukturovaná data brzy do HTML. (developers.google.com)

Doporučení pro implementaci

HTTP/3

Použijte HTTP/3, pokud je podporováno poskytovatelem hostingu a sítí pro doručování obsahu.

Měřte:

• Míru vyjednávání HTTP/3.
• Míru fallbacku na HTTP/2.
• Dobu navázání spojení.
• Čas do prvního bytu.
• Výkon podle geografické oblasti.
• Výkon podle procházeče.

Nezacházejte s HTTP/3 jako se zaručenou optimalizací pro vyhledávání nebo umělou inteligenci. Jedná se o vylepšení transportu, které může pomoci pouze klientům, kteří jej používají.

Edge caching sítě pro doručování obsahu (CDN)

Pro veřejné, nepersonalizované stránky:

• Nastavte jasná pravidla Cache-Control.
• Použijte dlouhodobé cachování pro verzované statické assety.
• Použijte krátkodobé, ale užitečné cachování pro často aktualizované HTML.
• Vyhněte se fragmentaci cache způsobené zbytečnými parametry dotazu.
• Zachovejte kanonické URL.
• Podporujte ETag a Last-Modified.
• Testujte stavy studené, teplé a revalidované cache.
• Potvrďte, že požadavky procházeče obdrží stejný důležitý obsah jako lidské požadavky.

Síť pro doručování obsahu by měla snižovat latenci, aniž by vytvářela zastaralé, nekonzistentní nebo bot-specifické verze stránek.

Komprese obrázků

Pro obrázky:

• Použijte AVIF nebo WebP, pokud je vizuální kvalita přijatelná.
• Poskytněte responzivní velikosti obrázků.
• Neposílejte obrázek velikosti pro stolní počítač na malou mobilní obrazovku.
• Nelíněte načítat obrázek Největšího vykreslení obsahu (Largest Contentful Paint).
• Zahrňte rozměry obrázků.
• Umístěte obrázek Největšího vykreslení obsahu (Largest Contentful Paint) do počátečního HTML.
• Použijte fetchpriority="high" pouze tam, kde je to vhodné.
• Důležitá vysvětlení udržujte v textu, spíše než je vkládat pouze do obrázků.

Komprese obrázků je nejcennější, když je obrázek elementem Největšího vykreslení obsahu (Largest Contentful Paint). Nevyřeší stránku, jejíž hlavní zpoždění pochází z vykreslování serverem nebo spouštění JavaScriptu. (web.dev)

Stabilita rozvržení

Pro snížení Kumulativního posunu rozvržení (Cumulative Layout Shift):

• Nastavte atributy šířky a výšky na obrázcích.
• Rezervujte prostor pro reklamy.
• Rezervujte prostor pro vložené video a sociální obsah.
• Vyhněte se vkládání bannerů nad existující text.
• Používejte stabilní strategie načítání fontů.
• Vyhněte se nahrazování velkých bloků serverem vykresleného obsahu po načtení stránky.

Tyto změny zlepšují uživatelskou zkušenost, i když nemají měřitelný vliv na procházení nebo citace. (web.dev)

Nástroje a monitorování

Nástroje pro výkon

Použijte:

• Zpráva o uživatelské zkušenosti prohlížeče Chrome (Chrome User Experience Report) pro Core Web Vitals od skutečných uživatelů.
• API Zprávy o uživatelské zkušenosti prohlížeče Chrome (Chrome User Experience Report application programming interface) pro automatizovaný sběr dat z terénu.
• PageSpeed Insights pro laboratorní audity a data z terénu.
• Lighthouse pro opakovatelné laboratorní testy.
• Lighthouse Continuous Integration pro rozpočty výkonu v pull-requestech.
• WebPageTest pro testy z více lokalit, stavy cache a srovnání protokolů.
• Chrome DevTools pro ladění Největšího vykreslení obsahu (Largest Contentful Paint) a posunu rozvržení.
• Knihovna JavaScriptu web-vitals pro monitorování skutečných uživatelů.

API Zprávy o uživatelské zkušenosti prohlížeče Chrome (Chrome User Experience Report application programming interface) poskytuje agregovaná data z terénu na úrovni stránky a originu, včetně Největšího vykreslení obsahu (Largest Contentful Paint), Kumulativního posunu rozvržení (Cumulative Layout Shift), Interakce do dalšího vykreslení (Interaction to Next Paint) a experimentálního času do prvního bytu. (developer.chrome.com)

Lighthouse Continuous Integration může spouštět kontroly výkonu při každé změně kódu a selhat buildy, když jsou překročeny rozpočty. (github.com)

Monitorování procházečů

Použijte serverové protokoly, edge protokoly a malou sadu syntetických sond.

Příklad sondy:

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

Spusťte stejný test s:

• Googlebot.
• Bingbot.
• OAI-SearchBot.
• PerplexityBot.
• Claude-SearchBot.
• Normálním user-agentem prohlížeče.

Test by měl ověřit:

• Stavový kód.
• Povolení robots.
• Hlavičky odpovědi.
• HTML obsah.
• Verze HTTP.
• Stav cache.
• Doba odezvy.
• Zda je důležitý text přítomen bez JavaScriptu.

Monitorování vyhledávání a indexování

Použijte:

• Statistiky procházení Google Search Console.
• Zprávy o indexování stránek Google Search Console.
• Kontrola URL v Google Search Console.
• Data sitemap Google Search Console.
• Zprávy o generativní umělé inteligenci Google Search Console, pokud jsou dostupné.
• Požadavky na procházení a indexované stránky Bing Webmaster Tools.
• Výkon umělé inteligence Bing Webmaster Tools.
• Denní kontroly sitemapy a lastmod.

API služby Search Console (Search Console application programming interface) může načítat výkonnostní data podle stránky, dotazu, data, zařízení a vzhledu ve vyhledávání, s výhradou svých datových limitů. (developers.google.com)

Monitorování citací

Vytvořte panel citací obsahující 50 až 200 stabilních dotazů na téma. Spouštějte panel podle pevného rozvrhu a zaznamenávejte:

• Zda platforma vyhledávala.
• Které zdroje se objevily.
• Zda byla testovaná URL citována.
• Pořadí citace.
• Datum a čas odpovědi.
• Zda se stránka změnila.
• Zda se změnil model nebo vyhledávací zkušenost.

Neporovnávejte počty citací z různých systémů, jako by byly ekvivalentní. Microsoft uvádí, že aktivita citací není skóre řazení, skóre autority, metrikou návštěvnosti ani skóre kvality. (bing.com)

Pravidla upozornění

Vytvořte upozornění pro:

• Čas do prvního bytu vzrůstající o více než 25 procent.
• Největší vykreslení obsahu (Largest Contentful Paint) přesahující 2,5 sekundy na 75. percentilu.
• Kumulativní posun rozvržení (Cumulative Layout Shift) přesahující 0,1.
• Trvalý nárůst odpovědí 5xx nebo 429.
• Pokles míry úspěšnosti procházeče.
• Změna robots.txt.
• Chyba sitemapy.
• Náhlý pokles indexovaných stránek.
• Náhlý pokles citací umělé inteligence napříč několika platformami.
• Změna objemu citací, která ovlivňuje pouze jednu platformu.

Pokles citací ovlivňující jednu platformu může být způsoben změnou modelu, indexu, dotazu nebo produktu, spíše než problémem s výkonem stránky. Microsoft výslovně varuje, že trendy citací jsou pozorovací a mohou se měnit kvůli aktualizacím obsahu, uživatelské poptávce a změnám systému nebo modelu. (bing.com)

Závěr

Nejobhajitelnější závěr je:

Rychlejší stránky mohou zlepšit efektivitu procházení, zejména pokud jsou limitujícími faktory latence serveru, velikost zdrojů, chyby nebo zpoždění vykreslování. V současné době však neexistuje silný důkaz, že nižší Core Web Vitals přímo způsobují, že systémy umělé inteligence vyberou stránku jako citaci.

Očekávaný kauzální řetězec je:

text Nižší latence → lepší kapacita serveru → méně neúspěšných nebo zpožděných načtení → rychlejší objevování a zpracování → zvýšená šance na indexování a vyhledání → možný nárůst citací

Poslední krok zůstává nejistý, protože výběr citací závisí na relevantnosti, kvalitě, aktuálnosti, autoritě, záměru dotazu, pozici ve vyhledávání a chování každého systému umělé inteligence.

Pro většinu webových stránek tedy správná výkonnostní strategie není izolovaně „optimalizovat pro citace umělé inteligence“. Je to:

1. Udržujte důležitý obsah dostupný v počátečním HTML.
2. Udržujte stabilní čas do prvního bytu.
3. Používejte edge caching pro veřejný obsah.
4. Komprimujte a prioritizujte důležité obrázky.
5. Zabraňte posunům rozvržení.
6. Vrácí spolehlivé stavové kódy.
7. Udržujte sitemapy a interní odkazy aktuální.
8. Povolte správné vyhledávací procházeče.
9. Měřte procházení, indexování, vyhledávání a citování jako samostatné fáze.

Tento přístup vytváří rychlejší web pro lidi, zdravější web pro vyhledávací procházeče a testovatelný základ pro pochopení viditelnosti pro umělou inteligenci.