Protokół HTTP i jego rola w komunikacji sieciowej
HTTP, czyli Hypertext Transfer Protocol, to podstawowy protokół, którym przeglądarka rozmawia z serwerem: wysyła żądanie o plik i dostaje odpowiedź z treścią. Obecnie w użyciu są trzy główne wersje: HTTP/1.1, HTTP/2 z dokumentu RFC 9113 i HTTP/3 z RFC 9114, oba wydane przez IETF w czerwcu 2022 roku. Każda kolejna zmienia sposób przesyłania danych, co wpływa na szybkość ładowania, a pośrednio na SEO.
Wersja decyduje, jak dane płyną między klientem a serwerem: od pojedynczych zapytań w kolejce, przez wiele strumieni w jednym kanale TCP, po transport QUIC oparty na UDP. Różnice są techniczne, ale użytkownik odczuwa je jako czas oczekiwania na stronę, zwłaszcza przy słabym zasięgu.
Trzy pokolenia protokołu HTTP: charakterystyka i mechanizmy działania
Poszczególne generacje różnią się przede wszystkim tym, ile żądań mieści jedno połączenie i jaki mechanizm transportowy je przenosi. Główne cechy każdej z nich:
- HTTP/1.1 działa na TCP i w jednym połączeniu zwraca odpowiedzi sekwencyjnie, więc następny plik czeka na poprzedni. Opóźnienie tego typu nazywa się blokowaniem początku kolejki (head-of-line blocking) i spowalnia większe podstrony.
- HTTP/2 wprowadza multipleksowanie: wiele zapytań leci naraz przez jeden kanał TCP, a obrazki, arkusze CSS i skrypty pobierają się równolegle.
- HTTP/3 opiera się na QUIC (RFC 9000 z maja 2021 roku), który działa na UDP zamiast TCP. Skraca to zestawianie łącza i usuwa blokowanie w warstwie transportowej, co pomaga przy niestabilnym zasięgu.
Multiplexing i kompresja nagłówków w HTTP/2
W drugiej wersji wiele strumieni dzieli jedno połączenie TCP, a każdy zasób (obrazek, plik CSS, skrypt JavaScript) dostaje osobny kanał. Przeglądarka nie musi więc otwierać kilku równoległych sesji do tej samej domeny.
Dodatkowo h2 kompresuje nagłówki algorytmem HPACK, co zmniejsza rozmiar metadanych przy setkach podobnych żądań do jednego hosta. W praktyce zyskują podstrony z dużą liczbą zasobów, na przykład galerie zdjęć albo panele administracyjne aplikacji SaaS.
Protokół QUIC i eliminacja opóźnień w HTTP/3
Największa zmiana w trzeciej wersji dotyczy warstwy transportowej: QUIC zastępuje TCP i działa na UDP. Główną zaletą jest brak blokady całego połączenia po zgubieniu pakietu, bo pozostałe strumienie docierają niezależnie.
QUIC łączy szyfrowanie TLS 1.3 z otwarciem sesji. Według RFC 9001 większość nowych połączeń bez utraty pakietów zestawia się w jednym obiegu (1-RTT), a przy powrocie do tego samego serwera klient często wysyła dane od razu (0-RTT). Telefon, który przechodzi z Wi-Fi na sieć komórkową, nie traci łącza dzięki identyfikatorom, co RFC 9000 nazywa migracją.
Wpływ wersji HTTP na wskaźniki SEO
Wersja protokołu nie jest czynnikiem rankingowym, ma natomiast wpływ na szybkość ładowania strony, a ta przekłada się na Core Web Vitals. Dokumentacja Google dla robotów mówi wprost, że indeksowanie przez HTTP/2 może oszczędzić zasoby serwera i Googlebota, ale nie zwiększa pozycji w wyszukiwarce. Zysk dla SEO jest więc pośredni: szybciej dostarczone pliki oznaczają lepsze metryki u realnych użytkowników.
- Core Web Vitals to trzy wskaźniki: LCP (wczytywanie), INP (reakcja na interakcję) i CLS (stabilność układu). Time to Interactive (TTI) do tego zestawu nie należy, a INP zastąpił w nim FID w marcu 2024 roku.
- Nowsze wersje przesyłają dane sprawniej, co poprawia doświadczenie użytkownika, zwłaszcza na telefonach z gorszym zasięgiem.
- Przejście na nowszy protokół to jedna z kilku zmian po stronie serwera; obok niej liczy się waga obrazów, ilość skryptów i czas odpowiedzi hostingu.
Core Web Vitals i protokół HTTP
Z trzech metryk Core Web Vitals sposób przesyłania danych najmocniej wpływa na LCP, czyli czas wyświetlenia największego elementu widocznego na ekranie. Google podaje próg dobrego wyniku do 2,5 sekundy, a h2 i h3 przyspieszają dostarczanie zasobów potrzebnych do tego obrazu albo bloku tekstu.
INP mierzy opóźnienie reakcji na kliknięcie albo dotknięcie i według Google powinien być krótszy niż 200 milisekund. Ten wskaźnik zależy głównie od pracy JavaScriptu w przeglądarce, więc wersja protokołu zmienia go mniej niż LCP. CLS, z granicą 0,1, opisuje przesunięcia układu i z transportem danych prawie nie ma związku.
Wpływ na indeksowanie stron przez Googlebot
Googlebot pobiera strony przez HTTP/2 od połowy listopada 2020 roku, co Google ogłosiło na blogu Search Central 17 września 2020 roku. Według aktualnej dokumentacji roboty Google obsługują HTTP/1.1 i HTTP/2, domyślną wersją jest HTTP/1.1, a protokół wybierają tak, by indeksowanie działało najsprawniej. Właściciel, który nie chce wizyt Googlebota przez h2, może kazać serwerowi zwracać kod 421.
Trzecia wersja nie pojawia się na liście obsługiwanych przez roboty Google. Wdrożenie QUIC przyspiesza więc stronę dla użytkowników z nowymi przeglądarkami, ale nie zmienia sposobu, w jaki Googlebot ją pobiera.
Porównanie wersji HTTP pod kątem technologii i wsparcia
Tabela zestawia, czym trzy wersje różnią się w transporcie, szyfrowaniu i obsłudze przez Google.
| Parametr | HTTP/1.1 | HTTP/2 | HTTP/3 |
|---|---|---|---|
| Protokół transportowy | TCP | TCP | QUIC (UDP) |
| Żądania w jednym połączeniu | Odpowiedzi po kolei | Wiele strumieni naraz (multiplexing) | Wiele strumieni bez blokady |
| Szyfrowanie | TLS opcjonalnie | Przy TLS wersja 1.2 lub wyższa (RFC 9113) | TLS 1.3 wbudowany w QUIC |
| Kompresja nagłówków | Brak | HPACK | QPACK (RFC 9204) |
| Nawiązanie połączenia | Uzgadnianie TCP, potem TLS | Uzgadnianie TCP, potem TLS | 1-RTT, przy powrocie 0-RTT |
| Bezpośredni wpływ na ranking Google | Nie | Nie | Nie |
| Pobieranie przez Googlebota | Tak, domyślnie | Tak, od listopada 2020 | Brak na liście w dokumentacji |
Konfiguracja serwera pod HTTP/2 i HTTP/3
Włączenie h2 na serwerze wymaga w praktyce certyfikatu SSL, a RFC 9113 dla połączeń przez TLS określa minimum w wersji 1.2. Nginx ma odpowiedni moduł od wydania 1.9.5, Apache od 2.4.17, obsługuje go też LiteSpeed.
Nginx: aktywacja HTTP/2
W Nginx od wersji 1.25.1 drugą generację włącza osobna dyrektywa http2 w bloku server:
listen 443 ssl;http2 on;
Przy budowaniu ze źródeł potrzebny jest parametr --with-http_v2_module, bo Nginx nie kompiluje tej części domyślnie. Po przeładowaniu konfiguracji działanie protokołu sprawdzisz w narzędziach deweloperskich przeglądarki, w zakładce Network i kolumnie Protocol.
Apache: moduł mod_http2
W Apache trzeba włączyć mod_http2:
a2enmod http2
Następnie w pliku konfiguracyjnym VirtualHost dodajemy dyrektywę:
Protocols h2 http/1.1
Dzięki temu Apache uzgadnia h2 przez TLS (rozszerzenie ALPN), a klient bez jego obsługi dostaje odpowiedź w starszej wersji. Wariant h2c, czyli bez szyfrowania, dokumentacja Apache opisuje osobno.
Wdrożenie HTTP/3: CloudFlare i własne serwery
Najprostsza droga do HTTP/3 prowadzi przez sieć CDN, która obsługuje QUIC po swojej stronie, na przykład Cloudflare, Fastly albo Google Cloud CDN. Serwer źródłowy może wtedy dalej działać na starszej wersji.
Na własnym Nginx trzecią generację zapewnia rozszerzenie dostępne od wydania 1.25.0, opisane w dokumentacji jako eksperymentalne. Potrzebna jest kompilacja z parametrem --with-http_v3_module, biblioteka OpenSSL 1.1.1 lub nowsza oraz w bloku server dodatkowa dyrektywa listen 443 quic reuseport;.
Migracja z HTTP/1.1 do HTTP/2: co się zmienia w optymalizacji
Przejście z HTTP/1.1 na HTTP/2 nie wymaga poprawek w kodzie HTML, CSS ani JavaScript, bo cała zmiana zachodzi na serwerze. Część sztuczek z czasów starszej wersji staje się jednak zbędna albo wręcz szkodliwa.
Koniec z domain sharding
Domain sharding polegał na rozrzuceniu zasobów statycznych (obrazy, CSS, JS) na kilka subdomen, na przykład a.cdn.pl i b.cdn.pl, żeby obejść limit równoległych połączeń do jednego hosta. Przy multipleksowaniu ta technika działa na szkodę: każdy dodatkowy adres to osobne uzgadnianie TLS, a h2 i tak pobiera wszystko wspólnym kanałem.
Sprite'y CSS i łączenie plików
Sklejanie dziesiątek małych plików CSS i JS w jeden duży pakiet przestaje być konieczne, bo h2 radzi sobie z wieloma drobnymi żądaniami. Mniejsze fragmenty lepiej też korzystają z pamięci podręcznej: zmiana pojedynczego komponentu nie wymusza ponownego pobrania całości.
Testowanie i weryfikacja wersji protokołu HTTP
Wersję protokołu sprawdzisz w 3 krokach w narzędziach deweloperskich przeglądarki albo w zewnętrznym teście online.
DevTools w Chrome i Firefox
Otwórz zakładkę Network (Sieć), przeładuj stronę i kliknij prawym przyciskiem myszy nagłówek tabeli. Włącz kolumnę Protocol: przy każdym żądaniu zobaczysz oznaczenie http/1.1, h2 (HTTP/2) albo h3 (HTTP/3).
Narzędzia online
Testy takie jak HTTP/2 Test (tools.keycdn.com/http2-test) albo HTTP/3 Check (http3check.net) pokazują obsługę protokołu bez instalowania programów. Z wiersza poleceń to samo da curl -I --http2 z adresem strony.
Bezpieczeństwo i szyfrowanie a wersja HTTP
Trzecia wersja zawsze działa przez szyfrowane połączenie, bo QUIC ma wbudowany TLS, a h2 na stronach www pracuje zwykle przez HTTPS, więc wdrożenie obu oznacza także certyfikat SSL/TLS. Taki krok poprawia przy okazji ochronę danych użytkowników.
Google ogłosił HTTPS jako sygnał rankingowy 7 sierpnia 2014 roku, opisując go wtedy jako lekki czynnik wpływający na mniej niż 1% zapytań na świecie. Od lipca 2018 roku Chrome 68 oznacza każdą stronę na HTTP jako "Niezabezpieczona". Wdrożenie h2 lub h3 zamyka więc temat certyfikatu przy okazji przyspieszenia.
TLS 1.3 w HTTP/3
W trzeciej wersji szyfrowanie TLS 1.3 jest częścią QUIC, co daje krótsze zestawianie połączeń i ochronę przed podsłuchem w drodze (man-in-the-middle). Uzgodnienie kluczy odbywa się razem z otwarciem sesji, bez osobnego etapu jak w TCP z TLS.
Wydajność mobilna i HTTP/3
Na telefonach h3 daje najwięcej, bo połączenie QUIC przetrwa zmianę sieci, na przykład przejście z Wi-Fi na LTE. Dzięki identyfikatorom sesja pozostaje aktywna mimo innego adresu IP, czyli działa connection migration.
Przykład z życia: osoba przeglądająca sklep w pociągu przechodzi między stacjami bazowymi, a ładowanie listy produktów nie zaczyna się od nowa. Dla właściciela strony oznacza to mniej przerwanych wizyt i lepsze dane o czasie wczytywania zbierane od realnych użytkowników.
