HTTP/2 i HTTP/3 to nowoczesne wersje protokołu HTTP. Strony ładują się na nich szybciej, bo HTTP/2 wprowadza multiplexing (wiele plików równocześnie przez jedno połączenie), a HTTP/3 zamienia stare TCP na QUIC. W HTTP/1.1 (z 1997 roku) przeglądarka otwierała 6 połączeń TCP i pobierała pliki jeden po drugim na każdym z nich. W HTTP/2 wystarcza jedno połączenie i kilkadziesiąt plików leci równolegle. HTTP/3 robi to samo, tylko na QUIC: szybszy handshake, lepsza odporność na utratę pakietów. W praktyce strona ładuje się 15 do 50% szybciej.
Dlaczego HTTP/1.1 był wolny
HTTP/1.1 obsługiwał internet od 1997 do mniej więcej 2015. Miał trzy fundamentalne ograniczenia.
Head-of-line blocking. Jedno połączenie TCP obsługuje jedno żądanie naraz. Przeglądarka otwierała 6 połączeń do serwera (limit) i pobierała pliki po kolei na każdym z nich. Strona z 60 zasobami (CSS, JS, obrazy) musiała stać w kolejce.
Brak kompresji nagłówków. Każde żądanie HTTP/1.1 wysyłało pełne nagłówki: cookies, user-agent, czyli 500 do 2000 bajtów na żądanie. Pomnóż przez 60 plików i masz 30 do 120 KB samego overheadu nagłówków.
Brak priorytetyzacji. Przeglądarka nie mogła powiedzieć serwerowi „weź pobierz CSS najpierw, obrazki potem”. Wszystko leciało chaotycznie.
Co zmienia HTTP/2
Multiplexing. Jedno połączenie TCP, dziesiątki strumieni równocześnie. Przeglądarka pobiera CSS, JS, obrazy i fonty przez ten sam kanał, równolegle. Limit 6 połączeń znika. Head-of-line blocking na poziomie HTTP też. Co prawda zostaje na poziomie TCP (i to dopiero HTTP/3 załatwia).
Kompresja nagłówków (HPACK). Nagłówki HTTP są kompresowane i deduplikowane. Zamiast wysyłać te same cookies w każdym żądaniu, leci tylko różnica. Oszczędność rzędu 60 do 85% rozmiaru nagłówków.
Server Push. Serwer może wysłać zasoby zanim przeglądarka o nie poprosi. Przeglądarka żąda HTML, a serwer od razu doczepia CSS i JS, bo wie, że za chwilę będą potrzebne. W praktyce mało kto tego dziś używa, zastąpiło to 103 Early Hints i preload.
Priorytetyzacja. Przeglądarka mówi serwerowi: CSS jest ważniejszy niż obrazki. Serwer wysyła CSS pierwszy. Strona renderuje się szybciej, bo critical CSS dociera od razu.
Co dorzuca HTTP/3
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 cokolwiek popłynie) i head-of-line blocking na poziomie pakietów: utrata jednego pakietu blokuje wszystkie strumienie. HTTP/3 używa QUIC (Google, RFC 9000), opartego na UDP. Handshake schodzi do 0-RTT lub 1-RTT zamiast 2-3 RTT. Utrata pakietu w jednym strumieniu nie blokuje pozostałych.
Migracja połączeń. Przechodzisz z Wi-Fi na LTE w pociągu. Na TCP połączenie jest zerwane, idzie nowy handshake. Na QUIC migruje bezproblemowo, bo identyfikatorem jest connection ID, nie adres IP.
Wbudowane szyfrowanie. QUIC ma TLS 1.3 w środku. Połączenie jest szyfrowane zawsze, a handshake łączy kryptografię z ustanawianiem połączenia, więc dochodzi tu jeszcze trochę szybkości.
Wpływ na SEO i Core Web Vitals
Google mierzy Core Web Vitals i używa ich jako czynnik rankingowy. HTTP/2 i HTTP/3 wpływają bezpośrednio na trzy najważniejsze metryki.
LCP (Largest Contentful Paint) skraca się, bo multiplexing i priorytetyzacja sprawiają, że CSS oraz hero image dolatują wcześniej. INP (zastąpiło FID) poprawia się, bo JavaScript ładuje się szybciej i strona wcześniej reaguje na kliknięcia. TTFB (Time to First Byte) mocno zyskuje na 0-RTT w HTTP/3. Cloudflare publikował dane: przejście z HTTP/1.1 na HTTP/2 poprawiło TTFB o około 15%, a samo HTTP/3 dorzuciło kolejne 10%.
Jak sprawdzić, jaką wersję serwujesz
W Chrome: F12, zakładka Network, prawy klik na nagłówek kolumny i zaznacz „Protocol”. W kolumnie zobaczysz h2 (HTTP/2), h3 (HTTP/3) albo http/1.1.
Online: tools.keycdn.com/http2-test albo http3check.net. Wpisujesz domenę, masz wynik.
W terminalu: curl -I --http2 https://twojadomena.pl. Jeśli odpowiedź zaczyna się od HTTP/2 200, serwer obsługuje HTTP/2.
Jak włączyć HTTP/2 i HTTP/3
HTTP/2 wymaga HTTPS, bo przeglądarki nie negocjują HTTP/2 bez TLS. Nginx ma to domyślnie od 1.9.5 (listen 443 ssl http2;). Apache wymaga modułu mod_http2 (a2enmod http2). Hosting współdzielony zwykle ma to włączone, Cloudflare również, na każdym planie łącznie z darmowym.
HTTP/3 wymaga, żeby serwer rozumiał QUIC. Najprościej rozwiązuje to Cloudflare: jedno kliknięcie w panelu (Network, HTTP/3) i działa. Nginx ma eksperymentalne wsparcie od wersji 1.25, LiteSpeed obsługuje HTTP/3 natywnie. W praktyce sam wpinam strony w Cloudflare i mam HTTP/3 za darmo, bez grzebania w konfigu serwera.
Najczęściej zadawane pytania
Czy muszę coś zmieniać na stronie dla HTTP/2
Nie. HTTP/2 jest transparentny. HTML, CSS, JS zostają bez zmian, serwer i przeglądarka same negocjują wersję protokołu. Jedyne wymaganie to HTTPS, czyli darmowy Let’s Encrypt. Co ważne: stare tricki optymalizacyjne pod HTTP/1.1 (domain sharding, sprite images, łączenie wszystkiego w jeden plik CSS) z HTTP/2 są niepotrzebne, a domain sharding wręcz szkodzi, bo wymusza wiele połączeń zamiast jednego.
Czy wszystkie przeglądarki obsługują HTTP/2 i HTTP/3
HTTP/2: ponad 97% przeglądarek (Chrome, Firefox, Safari, Edge od 2015). HTTP/3: około 95% (Chrome od 87, Firefox od 88, Safari od 14, Edge od 87). Jeśli przeglądarka nie obsługuje HTTP/3, automatycznie schodzi do HTTP/2. Jeśli nie obsługuje HTTP/2, leci po HTTP/1.1. Działa to transparentnie, nie musisz się tym martwić.
Czy HTTP/3 jest bezpieczny
Tak. HTTP/3 (QUIC) ma TLS 1.3 wbudowane na sztywno. Każde połączenie HTTP/3 jest szyfrowane, nie istnieje „nieszyfrowany HTTP/3”. To bezpieczniejsze niż HTTP/1.1 i HTTP/2, gdzie teoretycznie można było jechać bez TLS (przeglądarki tego nie robiły, ale formalnie się dało).
