HTTP/3 a výkonnostná infraštruktúra pre SEO

Prečo je HTTP/3 relevantný pre technické SEO

HTTP/3 nie je priamym faktorom rankingu. Google nikdy nepotvrdil žiadnu verziu HTTP ako signál. Účinok sa prejavuje nepriamo, no merateľne: protokol QUIC, na ktorom HTTP/3 stojí, skracuje nadviazanie spojenia, odstraňuje head-of-line blocking a stabilizuje spojenia v meniacich sa sieťach. Práve tieto efekty zlepšujú Core Web Vitals a tie sa už roky započítavajú do hodnotenia skúsenosti so stránkou.

Rozšírenie dosiahlo kritickú masu. Podľa W3Techs používa HTTP/3 40,9 % všetkých webov (stav október 2026), medzi nimi Google, YouTube, Instagram a Cloudflare. Kto protokol ešte nedoručuje, prichádza o výkonnostnú rezervu, ktorú konkurenti už štandardne využívajú.

Pre rakúsky trh je rozhodujúci mobilný kontext. V Rakúsku je aktívnych 13,4 milióna mobilných pripojení, čo zodpovedá 147 % populácie, pri mediánovej rýchlosti mobilného sťahovania 88,85 Mbps (DataReportal, začiatok roka 2025). Mobilné siete sú premenlivé: prepínanie medzi bunkami, kolísajúca latencia a straty paketov sú bežné. Práve tu HTTP/3 uplatní svoju najväčšiu výhodu, pretože na nestabilných spojeniach reaguje odolnejšie ako TCP.

Ako to funguje: od transportného protokolu ku Core Web Vitals

HTTP/3 nahrádza TCP protokolom QUIC, transportným protokolom založeným na UDP so zabudovaným šifrovaním. Výkonnostný zisk vytvárajú tri vlastnosti.

Rýchlejšie nadviazanie spojenia: TCP s TLS zvyčajne potrebuje dva až tri round-tripy, kým začne prúdiť prvý bajt. QUIC spája transportný a šifrovací handshake a spravidla si vystačí s jedným round-tripom, pri opakovaných spojeniach dokonca s 0-RTT. Každý ušetrený round-trip priamo znižuje Time to First Byte (TTFB).

Odstránenie head-of-line blockingu: Pri HTTP/2 cez TCP zablokuje jediný stratený paket všetky paralelne bežiace streamy, pretože TCP doručuje dáta striktne v poradí. QUIC spravuje streamy nezávisle. Strata paketu v jednom streame nezastaví ostatné. V mobilných sieťach so stratou paketov je to najúčinnejší rozdiel.

Connection Migration: QUIC identifikuje spojenia pomocou Connection ID, nie podľa IP adresy. Keď používateľ prejde z Wi-Fi na mobilnú sieť, spojenie zmenu prežije a netreba ho nadväzovať znova.

Vplyv na LCP potvrdzujú terénne dáta. DebugBear meria vo vlastných RUM dátach o 13,8 % lepšie hodnoty LCP pri HTTP/3 oproti HTTP/2 (1,44 sekundy namiesto 1,67 sekundy). Výhoda rastie so sieťovou vzdialenosťou: podľa medzinárodného vyhodnotenia Request Metrics je HTTP/3 v New Yorku rýchlejší o 200 až 325 ms, v Londýne však o 600 až 1 200 ms ako HTTP/2, teda približne trojnásobne až trojapolnásobne. Rýchlejšie TTFB posúva začiatok celého reťazca vykresľovania dopredu a zlepšuje predovšetkým FCP a LCP. INP naopak závisí od záťaže JavaScriptu v hlavnom vlákne a z HTTP/3 takmer neprofituje.

Tlak na konanie zostáva vysoký: podľa Web Almanac 2025 spĺňa všetky tri Core Web Vitals iba 48 % mobilných a 56 % desktopových originov (CrUX, júl 2025). Výkonnostná infraštruktúra teda nie je vyriešený problém, ale stále oblasť, v ktorej sa dá odlíšiť od konkurencie.

Edge a CDN ako základ výkonnostnej infraštruktúry

HTTP/3 v praxi takmer nikdy nevzniká na origin serveri, ale na edge. Web Almanac 2025 ukazuje rozdiel veľmi zreteľne: 29 % HTML prevádzky cez CDN išlo cez HTTP/3 oproti efektívne 0 % pri origin serveroch; pri požiadavkách tretích strán je to 45 % (CDN) oproti 7 % (origin). CDN sú hlavným kanálom na doručovanie nových protokolov a zavádzajú ich roky pred origin servermi.

Z toho vyplýva strategický dôsledok. Riešenie len s origin serverom zaostáva, pretože neponúka ani HTTP/3, ani edge caching, ani geografickú blízkosť k používateľovi. Využívanie CDN rastie s profesionalitou: top 1 000 webov dosahuje 71 % využitia CDN oproti 35 % pri top 10 miliónoch webov a 71 % všetkých zdrojov tretích strán sa doručuje cez CDN. Pre MSP v regióne DACH to znamená: predradené CDN je dnes najlacnejšie opatrenie s najväčšou pákou na TTFB a dostupnosť HTTP/3.

Edge infraštruktúra robí viac než len termináciu protokolu. Cachuje statické odpovede blízko používateľa, dokáže doručovať HTML cez edge rendering a znižuje záťaž origin servera. Pre rakúske cieľové skupiny znamená edge uzol vo Viedni alebo vo Frankfurte viac než hrubý výpočtový výkon pôvodného servera.

Aktivácia HTTP/3 v praxi

HTTP/3 má problém s objavovaním. Prehliadač nemôže prvé spojenie nadviazať priamo cez QUIC, pretože nevie, či ho server podporuje. Riešením je hlavička Alt-Svc: server cez HTTP/2 signalizuje, že je dostupný cez HTTP/3, a prehliadač pri ďalšej požiadavke prepne. Bez správne nastavenej hlavičky Alt-Svc zostáva HTTP/3 nevyužitý, aj keď ho server technicky zvláda.

Aktivácia závisí od stacku:

Cloudflare a Fastly: Na edge platformách sa HTTP/3 väčšinou zapína jedným prepínačom alebo je už predvolený. Hlavička Alt-Svc sa nastaví automaticky.

nginx: Od verzie 1.25 sa HTTP/3 konfiguruje cez listen 443 quic reuseport; a ručne nastavenú hlavičku Alt-Svc. UDP port 443 musí byť vo firewalle otvorený.

Caddy: HTTP/3 je od verzie 2.6 predvolene aktívny, ak beží HTTPS. Nevyžaduje žiadnu ďalšiu konfiguráciu.

Next.js na Verceli: Dokumentácia Vercelu uvádza medzi podporovanými protokolmi iba HTTPS, HTTP/1.1 a HTTP/2, HTTP/3 tam chýba (stav október 2026). Predradené CDN ako Cloudflare by HTTP/3 doručovalo. Vercel však od reverse proxy pred projektom na Verceli odrádza, pretože CDN Vercelu potom vidí prevádzku horšie a firewall ťažšie rozpoznáva podozrivé prístupy. Táto cesta je napriek tomu podporovaná: pre Cloudflare je Verified Proxy od Vercelu automaticky aktívny vo všetkých plánoch.

Rozhodujúce je overenie skutočného doručovania. Nastaviť konfiguráciu ešte neznamená, že HTTP/3 aj naozaj dorazí. V DevTools prehliadača skontroluj na karte Network stĺpec Protocol (zobrazuje h3), použi curl --http3 -I alebo externý nástroj, ktorý potvrdí hlavičku Alt-Svc a spojenie cez QUIC. Blokovanie UDP vo firemných firewalloch alebo chybné reťazce reverse proxy sú najčastejšie dôvody, prečo je HTTP/3 nakonfigurovaný, ale nedoručuje sa.

SEO a výkonnostná architektúra v Next.js

Model vykresľovania rozhoduje zároveň o prehľadávateľnosti aj o Core Web Vitals. Čisté vykresľovanie na strane klienta (Client-Side Rendering) doručí takmer prázdny HTML obal a presunie skladanie stránky do JavaScriptu. To oneskoruje LCP a sťažuje crawlerom indexovanie, pretože obsah je viditeľný až po vykonaní JavaScriptu.

Stratégie orientované na server riešia oboje:

SSG (Static Site Generation): Stránky sa generujú pri builde a doručujú sa ako hotové HTML. Maximálny výkon a prehľadávateľnosť, ideálne pre články znalostnej bázy a vstupné stránky (landing pages).

ISR (Incremental Static Regeneration): Statické stránky sa po uplynutí intervalu na pozadí vygenerujú znova. Spája rýchlosť SSG s aktuálnosťou bez toho, aby bolo nutné spúšťať celý build odznova.

SSR (Server-Side Rendering): HTML sa generuje na serveri pri každej požiadavke. Vhodné pre personalizovaný alebo vysoko dynamický obsah, s vyššou záťažou na TTFB ako pri SSG.

Streaming a Edge Runtime: React streaming posiela HTML po častiach, takže prehliadač začne vykresľovať skôr. Edge Runtime spúšťa kód bližšie k používateľovi a TTFB ďalej skracuje.

Základné pravidlo: pre prehľadávateľný a výkonný obsah je štandardom HTML vykreslené na serveri alebo vygenerované staticky. Vykresľovanie na strane klienta zostáva výnimkou pre časti za prihlásením alebo pre čisto interaktívne aplikácie.

Infraštruktúra indexovania a efektivita crawlovania

Výkon nič neprinesie, ak sa obsah neindexuje správne. Základ tvoria štyri stavebné prvky.

IndexNow: Namiesto čakania na ďalší crawl IndexNow aktívne ohlasuje nové alebo zmenené URL zúčastneným vyhľadávačom. Rozšírenie je značné: podľa Wikipédie bolo do roku 2024 cez IndexNow odoslaných približne 2,5 miliardy URL a 17 % všetkých kliknutých URL na Bingu pochádzalo práve odtiaľ (oproti 7 % v júli 2022). Google IndexNow nepoužíva, pre Bing a ďalšie vyhľadávače však zachytenie obsahu výrazne zrýchľuje.

XML sitemapy: Obsahujú kanonické URL a dátumy ich aktualizácie. Sitemapa by mala obsahovať výlučne indexovateľné URL so stavovým kódom 200, žiadne presmerovania, chybové stránky ani stránky vylúčené cez noindex.

Canonical: Kanonická značka (canonical) určuje preferovanú verziu pri duplikátoch a variantoch s parametrami. Nekonzistentné kanonické značky, ktoré smerujú na presmerovania alebo neindexovateľné stránky, mätú crawlery a plytvajú crawl budgetom.

Reťazce presmerovaní 301: Každé presmerovanie stojí jeden round-trip a oneskoruje doručenie. Reťazce presmerovaní s viacerými skokmi treba zredukovať na jediné presmerovanie 301, ktoré vedie priamo na konečný cieľ.

Správa AI crawlerov a pripravenosť na GEO

Prevádzka crawlerov sa presúva. Podľa Cloudflare má GPTBot 30 % čistej prevádzky AI crawlerov (máj 2025) oproti 5 % v predchádzajúcom roku, pri náraste objemu požiadaviek o 305 %. AI crawlery sú tak samostatným faktorom infraštruktúry.

Riadenie prebieha cez robots.txt. Najdôležitejšie boty sú GPTBot (OpenAI), ClaudeBot (Anthropic) a CCBot (Common Crawl). Prax je zatiaľ zdržanlivá: podľa Cloudflare má pravidlá pre AI boty v robots.txt iba približne 14 % z 3 816 top domén, pričom najčastejšie blokovaným botom je GPTBot, ktorého blokuje 312 domén (250 úplne, 62 čiastočne).

Z toho vyplýva vedomý kompromis. Kto AI crawlery úplne zablokuje, chráni obsah pred použitím na tréning, stráca však viditeľnosť v odpovediach AI, a tým aj potenciál pre GEO. Pre B2B poskytovateľov v regióne DACH, ktorých cieľom je citovanie v ChatGPT, Claude alebo Perplexity, je selektívne povolenie väčšinou rozumnejšie ako plošné blokovanie. Štruktúrované dáta na to tvoria strojovo čitateľný základ: značkovanie Schema.org explicitne pomenúva entity, definície a vzťahy a zvyšuje pravdepodobnosť správneho strojového spracovania bez ohľadu na to, či obsah číta klasický crawler alebo AI bot.

Meranie a monitoring

Výkon treba merať na skutočných používateľoch, nielen v laboratóriu.

Terénne dáta (CrUX/RUM): Chrome UX Report a Real User Monitoring zachytávajú skutočnú skúsenosť reálnych používateľov naprieč zariadeniami, sieťami a lokalitami. Do hodnotenia skúsenosti so stránkou vstupujú iba terénne dáta. RUM navyše ukazuje, akému podielu používateľov sa obsah doručuje cez HTTP/3.

Laboratórne dáta (Lighthouse): Syntetické testy v kontrolovaných podmienkach sú reprodukovateľné a hodia sa na regresné testy v CI pipeline. Nezachytávajú však rozmanitosť reálnych sietí a efekty HTTP/3 môžu podceniť.

Overenie protokolu: Priebežne kontroluj, či sa HTTP/3 naozaj doručuje, nielen raz po nastavení. Zmeny konfigurácie, migrácie CDN alebo aktualizácie proxy môžu doručovanie nepozorovane narušiť.

Výkonnostné rozpočty a sledovanie regresií: Definuj pevné limity pre LCP, INP, CLS a objem zdrojov. Automatická kontrola, ktorá pri prekročení zablokuje build alebo spustí upozornenie, zabráni postupnému zhoršovaniu naprieč mnohými vydaniami.

Časté chyby

HTTP/3 nakonfigurovaný, ale nedoručovaný: Chýbajúca hlavička Alt-Svc, zablokovaný UDP port 443 alebo reťazec proxy, ktorý spojenie preruší. Skutočné doručovanie vždy over.

Len origin bez CDN: Prichádza o HTTP/3, edge caching aj geografickú blízkosť. Je to najväčšia strata výkonu, ktorej sa dá vyhnúť.

Bannery na udelenie súhlasu a tagy tretích strán ako zabijaci CWV: Cookie vrstvy a skripty tag managera často blokujú hlavné vlákno a vykresľovanie. Zhoršujú INP a CLS a cez oneskorené vykresľovanie môžu znehodnotiť zisk v LCP, ktorý prináša HTTP/3. V regióne DACH je implementácia v súlade s GDPR povinná, musí však byť výkonná: logiku súhlasu udržiavaj štíhlu, neesenciálne skripty načítavaj až po udelení súhlasu a s oneskorením, posunom layoutu predchádzaj vyhradenými zástupnými miestami.

Reťazce presmerovaní a nekonzistentné kanonické značky: Každý ďalší skok stojí čas a crawl budget. Reťazce skráť na jedno presmerovanie a kanonické značky nasmeruj na indexovateľné konečné ciele.

Client-Side Rendering pre obsah dôležitý pre index: Oneskoruje LCP a sťažuje indexovanie. Štandardom má byť vykresľovanie na serveri alebo statické generovanie.

Súvisiace témy

HTTP/3 je jedným stavebným prvkom výkonnostnej infraštruktúry, nie izolovanou pákou. Najväčší efekt vzniká v súhre: predradené CDN s aktívnym a overeným HTTP/3, HTML vykreslené na serveri alebo staticky, štíhla vrstva súhlasu a skriptov tretích strán a priebežný monitoring terénnych dát. Kto tieto vrstvy prepojí, zlepší naraz Core Web Vitals, efektivitu crawlovania aj pripravenosť na GEO. Na prehĺbenie sa hodia témy ako konkrétny výber CDN pre cieľové skupiny v regióne DACH, architektúra súhlasu v súlade s GDPR, ktorá je zároveň výkonná, a stratégia Schema.org pre strojovo čitateľný obsah a viditeľnosť v AI.