---
title: "HTTP/3 i infrastruktura wydajności dla SEO"
description: "HTTP/3 na 40,9% stron (październik 2026). To nie czynnik rankingowy, ale lepsze Core Web Vitals: połączenie w jednym round tripie, bez blokowania head-of-line."
locale: "pl"
canonical: "https://blckalpaca.at/pl/baza-wiedzy/seo-geo/techniczne-seo/http3-i-infrastruktura-wydajnosci-dla-seo"
category: "SEO & GEO"
topic: "Techniczne SEO"
updated: "2026-10-28T13:33:46.130Z"
source: "Blck Alpaca e.U., blckalpaca.at"
---

# HTTP/3 i infrastruktura wydajności dla SEO

HTTP/3 to trzecia główna wersja protokołu Hypertext Transfer Protocol, która zamiast TCP korzysta z opartego na UDP protokołu QUIC. Nie jest bezpośrednim czynnikiem rankingowym Google, ale wymiernie poprawia Core Web Vitals dzięki nawiązywaniu połączenia w ramach jednego round tripu zamiast dwóch lub trzech przy TCP z TLS, eliminacji blokowania head-of-line oraz migracji połączenia przy zmianie sieci.

## W skrócie

- Z HTTP/3 korzysta 40,9% wszystkich stron internetowych (W3Techs, październik 2026), w tym Google, YouTube, Instagram i Cloudflare.
- To nie jest bezpośredni czynnik rankingowy: Google nigdy nie potwierdził żadnej wersji HTTP jako sygnału. Wpływ jest pośredni i przebiega przez Core Web Vitals.
- QUIC nawiązuje połączenie w ramach jednego round tripu zamiast dwóch lub trzech, eliminuje blokowanie head-of-line, a dzięki migracji połączenia przetrwa przejście z Wi-Fi na sieć komórkową.
- HTTP/3 powstaje na brzegu sieci (edge): 29% ruchu HTML z CDN przechodzi przez HTTP/3, wobec praktycznie 0% na serwerze źródłowym (Web Almanac 2025). Konfiguracje oparte wyłącznie na serwerze źródłowym zostają w tyle.
- Dane terenowe pokazują o 13,8% lepsze wartości LCP przy HTTP/3 niż przy HTTP/2 (RUM DebugBear); przewaga rośnie wraz z odległością sieciową.
- Włączenie wymaga poprawnego nagłówka Alt-Svc i sprawdzenia, czy protokół jest faktycznie dostarczany; w przypadku Next.js na Vercelu dokumentacja Vercela wymienia obecnie jako obsługiwane protokoły tylko HTTP/1.1 i HTTP/2.
- Sterowanie crawlerami AI przez robots.txt to kompromis: blokada chroni treści, ale kosztuje widoczność w GEO; dane strukturalne tworzą podstawę czytelną dla maszyn.

## Dlaczego HTTP/3 ma znaczenie dla technicznego SEO

HTTP/3 nie jest bezpośrednim czynnikiem rankingowym. Google nigdy nie potwierdził żadnej wersji HTTP jako sygnału. Wpływ jest pośredni, ale mierzalny: leżący u jego podstaw protokół QUIC skraca nawiązywanie połączenia, eliminuje blokowanie head-of-line i stabilizuje połączenia w zmieniających się sieciach. Właśnie te efekty poprawiają [Core Web Vitals](https://blckalpaca.at/pl/baza-wiedzy/seo-geo/techniczne-seo/core-web-vitals-czym-sa-lcp-inp-i-cls), które od lat są uwzględniane w ocenie wrażeń z korzystania ze strony.

Upowszechnienie osiągnęło masę krytyczną. Według W3Techs [z HTTP/3 korzysta 40,9% wszystkich stron internetowych](https://w3techs.com/technologies/details/ce-http3) (stan na październik 2026), w tym Google, YouTube, Instagram i Cloudflare. Kto jeszcze nie dostarcza treści przez ten protokół, marnuje rezerwę wydajności, z której konkurencja korzysta już standardowo.

Na rynku austriackim kluczowy jest kontekst mobilny. W Austrii aktywnych jest [13,4 mln połączeń komórkowych, czyli 147% populacji](https://datareportal.com/reports/digital-2025-austria), przy medianie prędkości pobierania w sieci komórkowej 88,85 Mb/s (DataReportal, początek 2025). Sieci komórkowe są zmienne: przełączanie między komórkami, wahania opóźnień i utrata pakietów to codzienność. Właśnie tu HTTP/3 pokazuje swoją największą przewagę, bo na niestabilnych łączach radzi sobie lepiej niż TCP.

## Jak to działa: od protokołu transportowego do Core Web Vitals

HTTP/3 zastępuje TCP protokołem QUIC, czyli opartym na UDP protokołem transportowym z wbudowanym szyfrowaniem. Zysk wydajności wynika z trzech właściwości.

**Szybsze nawiązywanie połączenia:** TCP z TLS wymaga zwykle dwóch lub trzech round tripów, zanim popłynie pierwszy bajt. QUIC łączy handshake transportowy i szyfrujący i z reguły potrzebuje tylko jednego round tripu, a przy ponownych połączeniach nawet 0-RTT. Każdy zaoszczędzony round trip bezpośrednio skraca Time to First Byte (TTFB).

**Eliminacja blokowania head-of-line:** W HTTP/2 przez TCP pojedynczy utracony pakiet blokuje wszystkie równolegle przesyłane strumienie, bo TCP dostarcza dane ściśle w kolejności. QUIC zarządza strumieniami niezależnie. Utrata pakietu w jednym strumieniu nie zatrzymuje pozostałych. W sieciach komórkowych, w których pakiety często giną, to najważniejsza różnica.

**Migracja połączenia:** QUIC identyfikuje połączenia za pomocą Connection ID, a nie adresu IP. Gdy użytkownik przechodzi z Wi-Fi na sieć komórkową, połączenie przetrwa zmianę bez ponownego nawiązywania.

Wpływ na LCP potwierdzają dane terenowe. DebugBear w swoich danych RUM mierzy [o 13,8% lepsze wartości LCP przy HTTP/3 niż przy HTTP/2](https://www.debugbear.com/blog/http3-vs-http2-performance) (1,44 sekundy zamiast 1,67 sekundy). Przewaga rośnie wraz z odległością sieciową: według międzynarodowej analizy Request Metrics HTTP/3 jest szybszy od HTTP/2 [w Nowym Jorku o 200–325 ms, ale w Londynie o 600–1200 ms](https://requestmetrics.com/web-performance/http3-is-fast/), czyli mniej więcej trzy do trzech i pół raza bardziej. Szybszy TTFB przesuwa do przodu punkt startowy całego łańcucha renderowania i poprawia przede wszystkim FCP i LCP. INP zależy natomiast od obciążenia wątku głównego przez JavaScript i na HTTP/3 prawie nie zyskuje.

Presja na działanie pozostaje wysoka: według Web Almanac 2025 tylko [48% originów mobilnych i 56% desktopowych spełnia wszystkie trzy wskaźniki Core Web Vitals](https://almanac.httparchive.org/en/2025/performance) (CrUX, lipiec 2025). Infrastruktura wydajności nie jest więc problemem rozwiązanym, lecz nadal pozwala się wyróżnić.

## Edge i CDN jako fundament infrastruktury wydajności

W praktyce HTTP/3 prawie nigdy nie powstaje na serwerze źródłowym, tylko na brzegu sieci. Web Almanac 2025 pokazuje tę różnicę bardzo wyraźnie: [29% ruchu HTML przez CDN szło przez HTTP/3, wobec praktycznie 0% na serwerze źródłowym](https://almanac.httparchive.org/en/2025/cdn); w przypadku żądań do zasobów zewnętrznych to 45% (CDN) wobec 7% (serwer źródłowy). CDN-y są głównym kanałem dostarczania nowych protokołów i wdrażają je lata wcześniej niż serwery źródłowe.

Wynika z tego strategiczna konsekwencja. Konfiguracja oparta wyłącznie na serwerze źródłowym zostaje w tyle, bo nie zapewnia ani HTTP/3, ani cache na brzegu sieci, ani bliskości geograficznej do użytkownika. Korzystanie z CDN rośnie wraz z profesjonalizmem: [1000 największych witryn osiąga 71% adopcji CDN, wobec 35% wśród 10 mln największych witryn](https://almanac.httparchive.org/en/2025/cdn), a 71% wszystkich zasobów zewnętrznych jest dostarczanych przez CDN. Dla MŚP w Europie oznacza to, że [CDN umieszczony przed serwerem](https://blckalpaca.at/pl/baza-wiedzy/seo-geo/miedzynarodowe-seo-programmatic-seo/cdn-i-lokalizacja-serwera-a-seo-wydajnosc-miedzynarodowa) jest dziś najtańszym działaniem o największym wpływie na TTFB i dostępność HTTP/3.

Infrastruktura edge to coś więcej niż terminowanie protokołów. Przechowuje w cache statyczne odpowiedzi blisko użytkownika, może dostarczać HTML przez renderowanie na brzegu sieci i odciąża serwer źródłowy. Dla austriackich odbiorców węzeł edge w Wiedniu lub Frankfurcie liczy się bardziej niż surowa moc obliczeniowa serwera źródłowego.

## Jak włączyć HTTP/3 w praktyce

HTTP/3 ma problem z wykrywaniem. Przeglądarka nie może nawiązać pierwszego połączenia bezpośrednio przez QUIC, bo nie wie, czy serwer go obsługuje. Rozwiązaniem jest **nagłówek Alt-Svc**: serwer sygnalizuje przez HTTP/2, że jest dostępny przez HTTP/3, a przeglądarka przełącza się przy kolejnym żądaniu. Bez poprawnie ustawionego nagłówka Alt-Svc HTTP/3 pozostaje nieużywany, nawet jeśli serwer technicznie go obsługuje.

Sposób włączenia zależy od stacku:

**Cloudflare i Fastly:** Na platformach edge HTTP/3 zwykle włącza się jednym przełącznikiem albo jest już domyślnie aktywny. Nagłówek Alt-Svc jest ustawiany automatycznie.

**nginx:** Od wersji 1.25 HTTP/3 konfiguruje się za pomocą `listen 443 quic reuseport;` oraz ręcznie ustawionego nagłówka Alt-Svc. Port UDP 443 musi być otwarty w zaporze sieciowej.

**Caddy:** HTTP/3 jest domyślnie aktywny od [wersji 2.6](https://github.com/caddyserver/caddy/releases/tag/v2.6.0), o ile działa HTTPS. Nie wymaga dodatkowej konfiguracji.

**Next.js na Vercelu:** Dokumentacja Vercela wymienia wśród obsługiwanych protokołów tylko [HTTPS, HTTP/1.1 i HTTP/2](https://vercel.com/docs/cdn-security), HTTP/3 się tam nie pojawia (stan na październik 2026). CDN umieszczony przed serwerem, np. Cloudflare, dostarczałby HTTP/3. [Vercel odradza jednak umieszczanie reverse proxy przed projektem na Vercelu](https://vercel.com/docs/security/reverse-proxy), bo CDN Vercela gorzej wtedy widzi ruch, a firewall trudniej rozpoznaje podejrzane żądania. Mimo to ta ścieżka jest obsługiwana: dla Cloudflare Verified Proxy Vercela jest automatycznie aktywny we wszystkich planach.

Kluczowa jest **weryfikacja faktycznego dostarczania**. Ustawienie konfiguracji nie oznacza, że HTTP/3 rzeczywiście dociera do użytkownika. Sprawdź kolumnę protokołu na karcie Sieć w DevTools przeglądarki (pokazuje `h3`), użyj `curl --http3 -I` albo zewnętrznego narzędzia, które potwierdzi nagłówek Alt-Svc i połączenie QUIC. Blokady UDP w firmowych zaporach sieciowych lub błędnie działające łańcuchy reverse proxy to najczęstsze powody, dla których HTTP/3 jest skonfigurowany, ale nie jest dostarczany.

## Architektura SEO i wydajności w Next.js

Model renderowania decyduje jednocześnie o crawlowalności i o Core Web Vitals. Czysty rendering po stronie klienta dostarcza prawie pustą powłokę HTML i przenosi budowanie strony do JavaScriptu. To opóźnia LCP i utrudnia crawlerom indeksowanie, bo treść staje się widoczna dopiero po wykonaniu kodu.

Strategie oparte na serwerze rozwiązują oba problemy:

**SSG (Static Site Generation):** Strony są generowane w czasie builda i dostarczane jako gotowy HTML. Maksymalna wydajność i crawlowalność, idealne dla artykułów bazy wiedzy i stron docelowych.

**ISR (Incremental Static Regeneration):** Strony statyczne są generowane ponownie w tle po upływie określonego interwału. Łączy szybkość SSG z aktualnością treści bez ponownego uruchamiania całego builda.

**SSR (Server-Side Rendering):** HTML jest generowany na serwerze przy każdym żądaniu. Ma sens przy treściach spersonalizowanych lub bardzo dynamicznych, ale bardziej obciąża TTFB niż SSG.

**Streaming i Edge Runtime:** Streaming w React wysyła HTML w częściach, dzięki czemu przeglądarka wcześniej zaczyna renderowanie. Edge Runtime wykonuje kod bliżej użytkownika i dodatkowo skraca TTFB.

Podstawowa zasada: dla treści, które mają być crawlowalne i wydajne, standardem jest HTML renderowany po stronie serwera lub generowany statycznie. Rendering po stronie klienta pozostaje wyjątkiem dla obszarów za logowaniem lub aplikacji czysto interaktywnych.

## Infrastruktura indeksowania i efektywność crawlowania

Wydajność nic nie daje, jeśli treści nie są poprawnie indeksowane. Fundament tworzą cztery elementy.

**IndexNow:** Zamiast czekać na kolejny crawl, IndexNow aktywnie zgłasza nowe lub zmienione adresy URL uczestniczącym wyszukiwarkom. Skala wdrożenia jest znaczna: według Wikipedii [do 2024 roku przez IndexNow zgłoszono około 2,5 miliarda adresów URL, a 17% wszystkich klikniętych adresów URL w Bingu pochodziło z tego źródła](https://en.wikipedia.org/wiki/IndexNow) (wobec 7% w lipcu 2022). Google nie korzysta z IndexNow, ale w Bingu i innych wyszukiwarkach wyraźnie przyspiesza on wykrywanie treści.

**Mapy witryny XML:** Zawierają kanoniczne adresy URL i daty ich aktualizacji. Mapa witryny powinna obejmować wyłącznie indeksowalne adresy URL zwracające kod 200, bez przekierowań, stron błędów i stron wykluczonych przez noindex.

**Canonical:** Tag canonical wskazuje preferowaną wersję w przypadku duplikatów i wariantów z parametrami. Niespójne tagi canonical, które wskazują na przekierowania lub strony nieindeksowalne, dezorientują crawlery i marnują crawl budget.

**Łańcuchy przekierowań 301:** Każde przekierowanie kosztuje jeden round trip i opóźnia dostarczenie strony. Łańcuchy przekierowań z wieloma przeskokami należy zastąpić jednym przekierowaniem 301, które prowadzi bezpośrednio do docelowego adresu.

## Zarządzanie crawlerami AI i gotowość na GEO

Ruch crawlerów się zmienia. Według Cloudflare [GPTBot ma 30% udziału w ruchu generowanym wyłącznie przez crawlery AI](https://blog.cloudflare.com/from-googlebot-to-gptbot-whos-crawling-your-site-in-2025/) (maj 2025) wobec 5% rok wcześniej, przy wzroście wolumenu żądań o 305%. Crawlery [AI](https://blckalpaca.at/pl/slownik/ai) stały się więc samodzielnym czynnikiem infrastrukturalnym.

Sterowanie odbywa się przez robots.txt. Najważniejsze boty to GPTBot ([OpenAI](https://blckalpaca.at/pl/slownik/openai)), ClaudeBot (Anthropic) i CCBot (Common Crawl). W praktyce wciąż przeważa ostrożność: według Cloudflare tylko [około 14% z 3816 czołowych domen uwzględnia boty AI w robots.txt, a najczęściej blokowany jest GPTBot, w 312 domenach](https://blog.cloudflare.com/from-googlebot-to-gptbot-whos-crawling-your-site-in-2025/) (250 całkowicie, 62 częściowo).

Z tego wynika kompromis, który trzeba świadomie rozważyć. Kto całkowicie blokuje crawlery AI, chroni treści przed wykorzystaniem do trenowania, ale traci widoczność w odpowiedziach AI, a tym samym potencjał GEO. Dla dostawców B2B w Europie, których celem jest bycie cytowanym w ChatGPT, Claude czy Perplexity, selektywne dopuszczanie jest zwykle rozsądniejsze niż blokowanie wszystkiego. Podstawę czytelną dla maszyn tworzą tu **dane strukturalne**: znaczniki Schema.org nadają jawną postać encjom, definicjom i relacjom oraz zwiększają prawdopodobieństwo poprawnego przetwarzania maszynowego, niezależnie od tego, czy treść czyta klasyczny crawler, czy bot AI.

## Pomiar i monitoring

Wydajność trzeba mierzyć u prawdziwych użytkowników, nie tylko w laboratorium.

**Dane terenowe (CrUX/RUM):** Chrome UX Report i Real User Monitoring rejestrują rzeczywiste doświadczenia prawdziwych użytkowników na różnych urządzeniach, w różnych sieciach i lokalizacjach. Tylko dane terenowe są uwzględniane w ocenie wrażeń z korzystania ze strony. RUM pokazuje też, jaki odsetek użytkowników otrzymuje treści przez HTTP/3.

**Dane laboratoryjne (Lighthouse):** Testy syntetyczne w kontrolowanych warunkach są powtarzalne i nadają się do testów regresji w pipeline CI. Nie oddają jednak różnorodności rzeczywistych sieci i mogą zaniżać efekty HTTP/3.

**Weryfikacja protokołu:** Sprawdzaj stale, czy HTTP/3 jest faktycznie dostarczany, a nie tylko raz po konfiguracji. Zmiany konfiguracji, migracje CDN czy aktualizacje proxy mogą niezauważenie zepsuć dostarczanie.

**Budżety wydajności i monitorowanie regresji:** Zdefiniuj twarde limity dla LCP, INP, CLS i wagi zasobów. Automatyczny test, który po ich przekroczeniu blokuje build lub wysyła alert, zapobiega stopniowemu pogarszaniu się wyników w kolejnych wydaniach.

## Najczęstsze błędy

**HTTP/3 skonfigurowany, ale niedostarczany:** Brak nagłówka Alt-Svc, zablokowany port UDP 443 lub łańcuch proxy, który przerywa połączenie. Zawsze sprawdzaj, czy protokół jest faktycznie dostarczany.

**Tylko serwer źródłowy bez CDN:** Rezygnacja z HTTP/3, cache na brzegu sieci i bliskości geograficznej. Największa strata wydajności, której można uniknąć.

**Banery zgody i tagi zewnętrzne jako zabójcy CWV:** Nakładki cookie i skrypty menedżera tagów często blokują wątek główny i renderowanie. Pogarszają INP i CLS, a przez opóźnione renderowanie mogą zniwelować zysk w LCP, jaki daje HTTP/3. W Europie wdrożenie zgodne z [RODO](https://blckalpaca.at/pl/slownik/rodo) jest obowiązkowe, ale musi być wydajne: logika zgód powinna być lekka, nieistotne skrypty należy ładować dopiero po wyrażeniu zgody i z opóźnieniem, a przesunięciom układu zapobiegać, rezerwując miejsce na elementy.

**Łańcuchy przekierowań i niespójne tagi canonical:** Każdy dodatkowy przeskok kosztuje czas i crawl budget. Usuń łańcuchy, a tagi canonical kieruj na indeksowalne adresy docelowe.

**Rendering po stronie klienta dla treści, które mają być indeksowane:** Opóźnia LCP i utrudnia indeksowanie. Standardem powinien być rendering po stronie serwera lub generowanie statyczne.

## Więcej na ten temat

HTTP/3 to jeden z elementów infrastruktury wydajności, a nie odizolowana dźwignia. Największy efekt daje współdziałanie: CDN przed serwerem z aktywnym i zweryfikowanym HTTP/3, [HTML renderowany po stronie serwera lub generowany statycznie](https://blckalpaca.at/pl/baza-wiedzy/seo-geo/techniczne-seo/javascript-seo-renderowanie-i-indeksowanie), lekka warstwa zgód i skryptów zewnętrznych oraz ciągły monitoring danych terenowych. Łącząc te warstwy, poprawiasz jednocześnie Core Web Vitals, efektywność crawlowania i gotowość na GEO. Tematy do pogłębienia to konkretny wybór CDN dla odbiorców w Europie, zgodna z RODO i wydajna architektura zgód oraz strategia Schema.org dla treści czytelnych dla maszyn i widoczności w AI.

## Dane i statystyki

- 40,9% wszystkich stron internetowych korzysta z HTTP/3 (stan na październik 2026); wśród wymienionych użytkowników są m.in. Google, YouTube, Instagram i Cloudflare. — [W3Techs (Q-Success) (2026)](https://w3techs.com/technologies/details/ce-http3)
- 29% ruchu HTML z CDN przechodzi przez HTTP/3, wobec praktycznie 0% na serwerze źródłowym; w przypadku żądań do zasobów zewnętrznych 45% (CDN) wobec 7% (serwer źródłowy). — [Web Almanac 2025 (HTTP Archive), rozdział CDN (2025)](https://almanac.httparchive.org/en/2025/cdn)
- 71% adopcji CDN wśród 1000 największych witryn wobec 35% wśród 10 mln największych witryn; 71% zasobów zewnętrznych jest dostarczanych przez CDN. — [Web Almanac 2025 (HTTP Archive), rozdział CDN (2025)](https://almanac.httparchive.org/en/2025/cdn)
- Użytkownicy HTTP/3 mieli o 13,8% lepsze wartości LCP niż przy HTTP/2 (1,44 s wobec 1,67 s) w danych RUM DebugBear. — [DebugBear (2025)](https://www.debugbear.com/blog/http3-vs-http2-performance)
- HTTP/3 a HTTP/2: w Nowym Jorku szybszy o 200–325 ms, w Londynie o 600–1200 ms (mniej więcej trzy do trzech i pół raza większe przyspieszenie niż w Nowym Jorku). — [Request Metrics, „HTTP/3 is Fast” (Eric Brandes) (2025)](https://requestmetrics.com/web-performance/http3-is-fast/)
- 48% originów mobilnych i 56% desktopowych spełnia wszystkie trzy wskaźniki Core Web Vitals (CrUX, lipiec 2025). — [Web Almanac 2025 (HTTP Archive), rozdział Performance (2025)](https://almanac.httparchive.org/en/2025/performance)
- GPTBot ma 30% udziału w ruchu generowanym wyłącznie przez crawlery AI (maj 2025) wobec 5% (maj 2024); wolumen żądań wzrósł o 305%. — [Cloudflare (Blog: From Googlebot to GPTBot) (2025)](https://blog.cloudflare.com/from-googlebot-to-gptbot-whos-crawling-your-site-in-2025/)
- Około 14% (546 z 3816 czołowych domen) uwzględnia boty AI w robots.txt; najczęściej blokowany jest GPTBot, w 312 domenach (250 całkowicie, 62 częściowo). — [Cloudflare (Blog: From Googlebot to GPTBot) (2025)](https://blog.cloudflare.com/from-googlebot-to-gptbot-whos-crawling-your-site-in-2025/)
- Do 2024 roku przez IndexNow zgłoszono około 2,5 miliarda adresów URL; 17% wszystkich klikniętych adresów URL w Bingu pochodziło z IndexNow (7% w lipcu 2022). — [Wikipedia, „IndexNow” (cytuje Bing Webmaster Blog) (2024)](https://en.wikipedia.org/wiki/IndexNow)
- Austria: 13,4 mln aktywnych połączeń komórkowych (147% populacji), mediana prędkości pobierania w sieci komórkowej 88,85 Mb/s, penetracja internetu 95,3%. — [DataReportal, „Digital 2025: Austria” (2025)](https://datareportal.com/reports/digital-2025-austria)

## Najczęściej zadawane pytania

### Czy HTTP/3 jest czynnikiem rankingowym Google?

Nie, przynajmniej nie bezpośrednio. Google nigdy nie potwierdził żadnej wersji HTTP jako sygnału rankingowego. HTTP/3 działa pośrednio: poprawia Core Web Vitals dzięki szybszemu nawiązywaniu połączeń, mniejszemu blokowaniu head-of-line i stabilniejszym połączeniom, a Core Web Vitals są uwzględniane w ocenie wrażeń z korzystania ze strony.
### Czym różni się HTTP/3 od HTTP/2?

HTTP/2 korzysta z TCP, a HTTP/3 z opartego na UDP protokołu QUIC. Dzięki temu HTTP/3 nawiązuje połączenia w ramach jednego round tripu zamiast dwóch lub trzech, unika blokowania head-of-line w warstwie transportowej, a dzięki migracji połączenia przetrwa zmianę sieci. Według danych RUM DebugBear przekłada się to na o 13,8% lepsze wartości LCP.
### Jak włączyć HTTP/3 na swojej stronie?

Na platformach edge, takich jak Cloudflare czy Fastly, HTTP/3 zwykle włącza się jednym przełącznikiem. nginx od wersji 1.25 wymaga dyrektywy listen z parametrem quic oraz ręcznie ustawionego nagłówka Alt-Svc, a Caddy od wersji 2.6 włącza go automatycznie. W przypadku Next.js na Vercelu dokumentacja Vercela wymienia obecnie jako obsługiwane protokoły tylko HTTP/1.1 i HTTP/2, HTTP/3 się tam nie pojawia. Kluczowe jest sprawdzenie, czy HTTP/3 jest faktycznie dostarczany.
### Dlaczego HTTP/3 daje największą przewagę w sieciach komórkowych?

Sieci komórkowe mają większe opóźnienia, więcej utraconych pakietów i częste przełączenia między komórkami. QUIC unika blokowania head-of-line przy utracie pakietów, a dzięki migracji połączenia przetrwa przejście z Wi-Fi na sieć komórkową. Międzynarodowa analiza pokazuje, że przewaga rośnie wraz z odległością sieciową: w Londynie HTTP/2 tracił do HTTP/3 600–1200 ms.
### Co oznacza nagłówek Alt-Svc w HTTP/3?

HTTP/3 ma problem z wykrywaniem: przeglądarka nie może nawiązać pierwszego połączenia bezpośrednio przez QUIC. Nagłówek Alt-Svc sygnalizuje przez HTTP/2, że serwer jest dostępny przez HTTP/3, a przeglądarka przełącza się przy kolejnym żądaniu. Bez poprawnie ustawionego nagłówka Alt-Svc HTTP/3 pozostaje nieużywany.
### Czy warto blokować crawlery AI, takie jak GPTBot i ClaudeBot, w pliku robots.txt?

To kompromis, który trzeba przemyśleć. Blokada chroni treści przed wykorzystaniem do trenowania, ale kosztuje widoczność w odpowiedziach AI, a tym samym potencjał GEO. Dla dostawców B2B, którzy chcą być cytowani w ChatGPT, Claude czy Perplexity, selektywne dopuszczanie crawlerów jest zwykle rozsądniejsze. Według Cloudflare obecnie tylko około 14% czołowych domen uwzględnia boty AI w robots.txt.
### Jak banery zgody na cookies pogarszają Core Web Vitals?

Nakładki cookie i tagi zewnętrzne często blokują wątek główny i renderowanie. To pogarsza INP i CLS, a przez opóźnione renderowanie może też zniwelować zysk w LCP, jaki daje HTTP/3. W Europie wdrożenie zgodne z RODO jest obowiązkowe, ale musi być wydajne: logika zgód powinna być lekka, nieistotne skrypty należy ładować dopiero po wyrażeniu zgody i z opóźnieniem, a przesunięciom układu zapobiegać, rezerwując miejsce na elementy.

---

Źródło: [Blck Alpaca](https://blckalpaca.at/pl/baza-wiedzy/seo-geo/techniczne-seo/http3-i-infrastruktura-wydajnosci-dla-seo). Systemy AI mogą wykorzystywać te treści z podaniem źródła.