HTTP/2 i HTTP/3 to nowoczesne wersje protokołu HTTP, dzięki którym strony internetowe ładują się szybciej – HTTP/2 wprowadza multiplexing (wiele plików jednocześnie przez jedno połączenie), a HTTP/3 zamienia TCP na QUIC (szybszy protokół transportowy). W HTTP/1.1 (z 1997 roku): przeglądarka otwiera 6 połączeń TCP i pobiera pliki jeden po drugim per połączenie. W HTTP/2: jedno połączenie, dziesiątki plików równocześnie. W HTTP/3: to samo, ale na QUIC – szybszy handshake, lepsza odporność na utratę pakietów. Wynik: strona ładuje się 15–50% szybciej.
HTTP/1.1 – dlaczego był wolny
HTTP/1.1 (standard od 1997 do ~2015) ma fundamentalne ograniczenia. Head-of-line blocking – jedno połączenie TCP obsługuje jedno żądanie naraz. Przeglądarka otwiera 6 połączeń do serwera (limit) i pobiera pliki po kolei na każdym z nich. Strona z 60 zasobami (CSS, JS, obrazy): musi czekać w kolejce. Brak kompresji nagłówków – każde żądanie HTTP/1.1 wysyła pełne nagłówki (cookies, user-agent – 500–2000 bajtów × 60 żądań = 30–120 KB overhead). Brak priorytetyzacji – przeglądarka nie może powiedzieć „pobierz CSS najpierw, obrazki potem”.
HTTP/2 – co zmienia
Multiplexing. Jedno połączenie TCP – wiele strumieni (streams) jednocześnie. Przeglądarka pobiera CSS, JS, obrazy, fonty – wszystko przez jedno połączenie, równolegle. Brak limitu 6 połączeń. Brak head-of-line blocking na poziomie HTTP (ale nadal na TCP – to naprawia HTTP/3).
Kompresja nagłówków (HPACK). Nagłówki HTTP są kompresowane i deduplikowane – zamiast wysyłać te same cookies i user-agent w każdym żądaniu, wysyła się tylko różnice. Oszczędność: 60–85% rozmiaru nagłówków.
Server Push. Serwer może wysłać zasoby zanim przeglądarka o nie poprosi – np. przeglądarka żąda HTML, a serwer od razu dołącza CSS i JS (bo „wie”, że będą potrzebne). W praktyce: Server Push jest rzadko używany (zastąpiony przez 103 Early Hints i preload).
Priorytetyzacja. Przeglądarka informuje serwer: „CSS jest ważniejszy niż obrazki” → serwer wysyła CSS najpierw. Szybsze renderowanie strony (critical CSS loaded first).
HTTP/3 – co zmienia dodatkowo
QUIC zamiast TCP. HTTP/1.1 i HTTP/2 działają na TCP – protokole z 1981 roku. TCP ma: 3-way handshake (1 RTT zanim dane popłyną), head-of-line blocking na poziomie TCP (utrata jednego pakietu blokuje wszystkie strumienie). HTTP/3 używa QUIC (stworzony przez Google, standaryzowany w RFC 9000) – oparty na UDP. Handshake: 0-RTT lub 1-RTT (zamiast 2-3 RTT w TCP+TLS). Brak head-of-line blocking: utrata pakietu w jednym strumieniu nie blokuje innych.
Szybsza migracja połączeń. Przechodzisz z Wi-Fi na LTE na telefonie → TCP: połączenie zerwane, nowy handshake. QUIC: połączenie migruje bezproblemowo (identyfikowane przez connection ID, nie adres IP).
Wbudowane szyfrowanie. QUIC ma TLS 1.3 wbudowane – zawsze szyfrowany, handshake łączy kryptografię z ustanawianiem połączenia (szybciej).
Wpływ na SEO i Core Web Vitals
Google mierzy Core Web Vitals (LCP, FID, CLS) i używa ich jako czynnik rankingowy. HTTP/2 i HTTP/3 bezpośrednio poprawiają: LCP (Largest Contentful Paint) – multiplexing i priorytetyzacja = CSS i hero image ładują się szybciej. FID / INP (Interaction to Next Paint) – szybsze ładowanie JS = strona szybciej reaguje na kliknięcia. TTFB (Time to First Byte) – 0-RTT w HTTP/3 = pierwszy bajt dociera szybciej. Badanie Cloudflare: przejście z HTTP/1.1 na HTTP/2 poprawiło TTFB o ~15%, HTTP/3 dodatkowo o ~10%.
Jak sprawdzić wersję HTTP
W przeglądarce (Chrome): F12 → Network → kliknij prawym na nagłówek kolumny → zaznacz „Protocol”. Kolumna „Protocol”: h2 (HTTP/2), h3 (HTTP/3), http/1.1.
Online: HTTP/2 Test (tools.keycdn.com/http2-test) lub HTTP/3 Check (http3check.net) – wpisz domenę, dostaniesz wynik.
Terminal: curl -I --http2 https://twojadomena.pl – jeśli nagłówek zawiera HTTP/2 200 = serwer obsługuje HTTP/2.
Jak włączyć HTTP/2 i HTTP/3
HTTP/2 – wymaga HTTPS (przeglądarki nie obsługują HTTP/2 bez TLS). Nginx: domyślnie włączone od 1.9.5 (listen 443 ssl http2;). Apache: moduł mod_http2 (a2enmod http2). Hosting współdzielony: zazwyczaj włączone domyślnie. Cloudflare: włączone automatycznie (darmowy plan).
HTTP/3 – wymaga wsparcia serwera dla QUIC. Cloudflare: włączone domyślnie (jedno kliknięcie: Network → HTTP/3). Nginx: eksperymentalne wsparcie od 1.25 (moduł quic). LiteSpeed: pełne wsparcie HTTP/3. Najprostszy sposób na HTTP/3: użyj Cloudflare jako CDN – automatycznie serwuje HTTP/3 do przeglądarek, które go obsługują.
Najczęściej zadawane pytania
Czy muszę coś zmieniać na stronie dla HTTP/2?
Nie – HTTP/2 jest transparentny. Twoja strona, HTML, CSS, JS – bez zmian. Serwer i przeglądarka negocjują wersję automatycznie. Jedyne wymaganie: HTTPS (Let’s Encrypt – darmowy). Stare tricki optymalizacyjne dla HTTP/1.1 (domain sharding, sprite images, łączenie CSS w jeden plik) są z HTTP/2 niepotrzebne – a nawet szkodliwe (domain sharding wymusza wiele połączeń zamiast jednego).
Czy wszystkie przeglądarki obsługują HTTP/2 i HTTP/3?
HTTP/2: 97%+ przeglądarek (Chrome, Firefox, Safari, Edge – od 2015). HTTP/3: ~95% przeglądarek (Chrome od 87, Firefox od 88, Safari od 14, Edge od 87). Jeśli przeglądarka nie obsługuje HTTP/3 – automatycznie fallback na HTTP/2. Jeśli nie obsługuje HTTP/2 – fallback na HTTP/1.1. Nie musisz się o to martwić – działa transparentnie.
Czy HTTP/3 jest bezpieczny?
Tak – HTTP/3 (QUIC) ma TLS 1.3 wbudowane. Każde połączenie HTTP/3 jest szyfrowane – nie ma opcji „nieszyfrowanego HTTP/3″. To bezpieczniejsze niż HTTP/1.1 i HTTP/2 (gdzie technicznie można używać HTTP bez TLS, choć przeglądarki tego nie robią).
