Czym są HTTP/2 i HTTP/3? Praktyczny przewodnik dla witryn WordPress

HTTP/2 i HTTP/3 to dwie aktualne wersje Hypertext Transfer Protocol, języka, którym przeglądarki wysyłają żądania stron do serwerów webowych. HTTP/2 został ustandaryzowany w 2015 roku i jest wspierany przez 100% nowoczesnych przeglądarek. HTTP/3, sfinalizowany jako RFC 9114 w 2022 roku, jest wspierany przez każdą główną przeglądarkę od 2024 roku. Oba są bezproblemowymi aktualizacjami nad HTTP/1.1: te same URLe, ten sam HTML, ale znacznie szybsze ładowanie stron, szczególnie na sieciach mobilnych i połączeniach o wysokim opóźnieniu.

Szybka odpowiedź: której wersji powinna używać moja witryna WordPress?

W 2026 roku poprawna odpowiedź to "HTTP/3 z fallbackiem do HTTP/2". Każda przeglądarka negocjuje najwyższą wersję, którą obsługują obie strony, więc nie musisz wybierać. Jeśli twój serwer mówi HTTP/3, nowoczesne przeglądarki go używają; starsze przeglądarki spadają do HTTP/2; bardzo stare klienty spadają do HTTP/1.1. Nie istnieje scenariusz, w którym HTTP/2 lub HTTP/3 jest wolniejszy niż HTTP/1.1 dla rzeczywistej strony WordPress, więc pytanie jest tylko, czy twój stos hostingowy to obsługuje.

Jaki problem rozwiązuje HTTP/2 w porównaniu z HTTP/1.1?

HTTP/1.1, protokół, który napędzał web od 1997 do 2015 roku, ma jedną fatalną wadę na nowoczesnej stronie: otwiera jedno połączenie TCP na zasób i tylko sześć równolegle na domenę. Typowa strona WordPress ładuje od 50 do 150 zasobów (CSS, JS, obrazy, czcionki, skrypty śledzące). W HTTP/1.1 te 100+ żądań szereguje się przez kolejkę sześciu połączeń, każde czeka, aż poprzednie się zakończy. Przeglądarka dosłownie siedzi bezczynnie, czekając, aż zwolnią się sloty.

HTTP/2 rozwiązuje to trzema zmianami:

Multipleksowanie. Jedno połączenie TCP niesie nieograniczoną liczbę równoległych par żądanie/odpowiedź (zwanych strumieniami). Wszystkie 150 zasobów podróżuje jednym połączeniem, przeplatanym.
Kompresja nagłówków (HPACK). Nagłówki HTTP (cookies, User-Agent, referer) często sumują się do kilku KB na żądanie. HPACK je kompresuje i pamięta powtarzające się nagłówki, redukując narzut na żądanie z kilobajtów do bajtów.
Binarne ramki. HTTP/1.1 jest oparty na tekście i niejednoznaczny w parsowaniu. HTTP/2 używa binarnego formatu ramek, szybszego do przetwarzania dla serwerów i proxy, i eliminuje całą klasę ataków typu smuggling i parsowanie.

Efekt netto: strona WordPress, która ładuje się w 4 sekundy po HTTP/1.1, ładuje się typowo w 1,5 do 2,5 sekundy po HTTP/2, na tym samym serwerze. Poprawa jest większa w sieciach mobilnych, ponieważ narzut ustanawiania połączenia jest amortyzowany na wszystkie żądania.

Co HTTP/3 dodaje ponad HTTP/2?

HTTP/3 zachowuje wszystko, co wprowadził HTTP/2 (multipleksowanie, kompresję nagłówków, binarne ramki), ale zastępuje warstwę transportową. Zamiast TCP HTTP/3 działa nad QUIC, protokołem transportowym zbudowanym na UDP. Brzmi jak szczegół implementacyjny, ale naprawia trzy realne problemy wydajności:

Head-of-line blocking na warstwie TCP. HTTP/2 multipleksuje strumienie nad jednym połączeniem TCP, ale samo TCP dostarcza pakiety w kolejności. Jeśli jeden pakiet zostanie zgubiony, wszystkie strumienie na tym połączeniu czekają, aż przyjdzie retransmisja. QUIC obsługuje utratę pakietów per strumień, więc pojedynczy zgubiony pakiet wpływa tylko na strumień, do którego należy.
Szybsze ustanawianie połączenia. Ustanowienie połączenia HTTPS po TCP wymaga trzech round tripów (handshake TCP, potem handshake TLS). QUIC łączy je w jeden round trip dla nowych połączeń i zero round tripów dla powtarzanych połączeń w ciągu kilku minut (zwane 0-RTT). Na połączeniu mobilnym z opóźnieniem 100ms oszczędza to 200-300ms, zanim w ogóle zacznie ładować się pierwszy bajt treści.
Migracja połączenia. Połączenia QUIC są identyfikowane przez ID połączenia, nie IP + port. Gdy telefon przełącza się z Wi-Fi na komórkową, połączenie QUIC przeżywa. Połączenia TCP musiałyby się rekonektować.

Realny zysk ponad HTTP/2: typowo 5-15% szybciej dla pierwszych ładowań stron, więcej w sieciach mobilnych z utratami, mniej na stabilnym połączeniu kablowym.

Jak sprawdzić, której wersji HTTP obecnie używa moja witryna WordPress?

Cztery niezawodne metody, od najszybszej do najbardziej autorytatywnej:

Raport InspectWP. Sekcja Performance każdego raportu InspectWP wymienia wersję HTTP wynegocjowaną dla głównego dokumentu. Jedna linia, bez konfiguracji.
Chrome DevTools. Otwórz DevTools (F12), zakładkę Network, przeładuj stronę, kliknij prawym przyciskiem nagłówek dowolnej kolumny i włącz "Protocol". Kolumna pokazuje h2 dla HTTP/2 i h3 dla HTTP/3 (w niektórych wersjach Chrome także http/3).
Linia komend z curl. Uruchom curl -I --http2 https://twojawitryna.com dla HTTP/2 lub curl -I --http3 https://twojawitryna.com dla HTTP/3 (wymagany curl 7.66+). Linia odpowiedzi pokazuje HTTP/2 200 lub HTTP/3 200.
Publiczne narzędzia testowe. https://http3check.net testuje specyficznie wsparcie HTTP/3. https://tools.keycdn.com/http2-test testuje wsparcie HTTP/2. Oba zwracają wynegocjowaną wersję i nagłówek Alt-Svc (który ogłasza wsparcie HTTP/3).

Pułapka: witryna może ogłaszać HTTP/3 w nagłówku Alt-Svc bez faktycznie działającego HTTP/3. Nagłówek mówi przeglądarce "następnym razem spróbuj HTTP/3 na porcie UDP 443", ale jeśli UDP jest gdziekolwiek po drodze zablokowane, przeglądarka cicho spada do HTTP/2. Zawsze weryfikuj rzeczywistym żądaniem, nie tylko nagłówkiem Alt-Svc.

Jak włączyć HTTP/2 lub HTTP/3 na witrynie WordPress?

Wersje HTTP są negocjowane na poziomie serwera webowego. Sam WordPress nie ma z tym nic wspólnego; wybór odbywa się między twoim stosem hostingowym a przeglądarką. Trzy scenariusze obejmują prawie wszystkie witryny:

Scenariusz 1: zarządzany hosting WordPress

Prawie każdy zarządzany host WordPress (Kinsta, WP Engine, Raidboxes, SiteGround, Pressable, Cloudways) dostarcza HTTP/2 domyślnie od 2018 roku. Wsparcie HTTP/3 jest teraz szeroko rozpowszechnione, ale nie uniwersalne w 2026 roku. Kinsta, Cloudways, SiteGround, Raidboxes i Pressable mają HTTP/3 włączone domyślnie. WP Engine udostępnia je jako przełącznik. Jeśli twojego hosta nie ma na tej liście, zapytaj support; zwykle to zmiana jednym kliknięciem.

Scenariusz 2: hosting współdzielony z cPanel lub Plesk

Hosty cPanel (IONOS, Hostinger, wielu resellerów) typowo dostarczają HTTP/2 domyślnie i HTTP/3 na nowszych kontach. Sprawdź włączając EasyApache 4 z modułem mod_http2, jeśli nie jest jeszcze obecny. HTTP/3 w Apache wymaga modułu mod_http3, który wciąż jest uważany za eksperymentalny. Pragmatyczna droga na hostingu współdzielonym to postawić Cloudflare z przodu (darmowy tier wystarczy) i pozwolić Cloudflare obsługiwać terminację HTTP/3, co jest ich domyślnym ustawieniem od 2019 roku.

Scenariusz 3: samodzielnie zarządzany VPS lub dedykowany serwer

Konfiguracja zależy od twojego serwera webowego:

nginx. HTTP/2 wymaga nginx 1.9.5+ i dyrektywy http2 w linii listen: listen 443 ssl http2;. HTTP/3 wymaga nginx 1.25+ skompilowanego ze wsparciem QUIC: listen 443 quic reuseport; listen 443 ssl; plus add_header Alt-Svc 'h3=":443"; ma=86400';. Flaga reuseport jest krytyczna, w przeciwnym razie HTTP/3 cicho nie uruchamia się.
Apache. HTTP/2 wymaga włączonego mod_http2 i dyrektywy Protocols h2 h2c http/1.1 w twoim virtual hoście. HTTP/3 w Apache wciąż jest eksperymentalne; większość produkcyjnych instalacji Apache zatrzymuje się na HTTP/2 i stawia nginx, Caddy lub Cloudflare z przodu dla HTTP/3.
Caddy. HTTP/3 jest włączony domyślnie od Caddy 2.6. Nic do konfiguracji; jeśli HTTPS działa, HTTP/3 działa.
LiteSpeed i OpenLiteSpeed. Oba dostarczają HTTP/3 domyślnie. Jeden z powodów, dla których LiteSpeed zyskał udział w rynku hostingu WordPress.

Wymaganie, które ludzie często pomijają w samodzielnie zarządzanych instalacjach: HTTP/3 wymaga otwartego portu UDP 443 w twoim firewallu. Wiele domyślnych konfiguracji serwera otwiera tylko TCP 443. Uruchom sudo ufw allow 443/udp na Ubuntu lub ekwiwalent dla twojego stosu firewall.

Jaką rolę odgrywają Cloudflare i inne CDN-y?

CDN stojący przed twoim serwerem źródłowym typowo terminuje nowoczesny protokół na krawędzi, a potem rozmawia z twoim originem po HTTP/1.1 lub HTTP/2. Z perspektywy odwiedzającego, połączenie do węzła brzegowego CDN (często 20-50ms odległości) to HTTP/3, szybkie i nowoczesne. Łącze z CDN do originu odbywa się serwer-do-serwer w sieciach datacenter, gdzie protokół znaczy znacznie mniej. Dlatego postawienie Cloudflare przed hostem współdzielonym działającym tylko na HTTP/1.1 wciąż daje większość zysku prędkości. Odwiedzający nigdy nie dotyka bezpośrednio twojego originu.

Haczyk: jeśli twój origin zwraca nagłówek cache-busting (no-cache, no-store) lub twoja treść jest nieprzychwytywalna w cache (zalogowane strony WordPress, koszyk WooCommerce), CDN musi pobierać z originu przy każdym żądaniu, a wolny hop origin-do-CDN staje się wąskim gardłem. Dla tych przypadków protokół na originie wciąż ma znaczenie.

Częste błędy i jak ich unikać

Traktowanie HTTP/2 jako magicznej kuli dla wolnych witryn. HTTP/2 naprawia narzut połączenia. Nie naprawia wolnego PHP, niezoptymalizowanych zapytań, obrazów hero o rozmiarze 5MB ani blokującego renderowanie JavaScriptu. Jeśli twój TTFB (time to first byte) wynosi 2 sekundy, przejście na HTTP/3 oszczędza 200ms. Pozostałe 1800ms to wciąż PHP i baza danych.
Zapominanie o pozostawieniu HTTP/1.1 włączonego. Crawlery wyszukiwarek, narzędzia monitoringowe i stare biblioteki klienckie czasami mówią tylko HTTP/1.1. Całkowite wyłączenie HTTP/1.1 je psuje. Nowoczesne serwery webowe automatycznie negocjują najwyższą wzajemnie wspieraną wersję; pozostaw wszystkie trzy (h3, h2, http/1.1) włączone.
Łączenie i inlinowanie zasobów z przyzwyczajenia HTTP/1.1. Pod HTTP/1.1 łączenie 30 plików CSS w jeden było dużą wygraną z powodu limitu połączeń. Pod HTTP/2 i HTTP/3 ta optymalizacja przestaje mieć znaczenie i może nawet szkodzić (jeden duży bundle unieważnia cache przy każdej zmianie; 30 małych plików unieważnia tylko te, które się zmieniły). Większość pluginów wydajnościowych WordPress wciąż domyślnie ustawia "łącz wszystko", bo użytkownicy tego oczekują, ale w 2026 roku to już nie jest właściwy default.
Zakładanie, że Alt-Svc oznacza działający HTTP/3. Nagłówek ogłasza wsparcie HTTP/3; nie gwarantuje, że połączenie faktycznie się ustanawia. Zawsze weryfikuj z curl lub DevTools.
Blokowanie UDP na firewallu. Częsta przyczyna cichego niedziałania HTTP/3. Sprawdź zarówno firewall serwera, jak i firewall sieciowy (security group u dostawcy chmurowego, filtrowanie na poziomie ISP na połączeniach konsumenckich).

HTTP/2, HTTP/3 i Core Web Vitals

Core Web Vitals od Google'a mierzą Largest Contentful Paint (LCP), Interaction to Next Paint (INP) i Cumulative Layout Shift (CLS). Z trzech LCP jest najsilniej dotknięty przez wersję HTTP. Element LCP (zwykle obraz hero lub największy blok nad linią zgięcia) musi pobrać się w całości, zanim LCP może zostać zgłoszony, a prędkość pobierania to dokładnie to, co poprawia HTTP/2 i HTTP/3. Witryny przechodzące z HTTP/1.1 na HTTP/2 widzą spadek LCP średnio o 300-800ms. Skok z HTTP/2 na HTTP/3 jest mniejszy, typowo 50-200ms, ale w sieciach mobilnych z utratą pakietów może być większy.

Co sprawdza InspectWP

Sekcja Performance każdego raportu InspectWP pokazuje, która wersja HTTP została wynegocjowana dla głównego dokumentu, plus kodowanie treści (gzip, Brotli) i całkowity rozmiar HTML. Jeśli twoja witryna jest wciąż na HTTP/1.1 w 2026 roku, raport oznacza to jako ostrzeżenie, bo to jeden z najbardziej wpływowych zysków wydajnościowych przy najniższym wysiłku, zwykle pojedynczy przełącznik w panelu hostingu. Jeśli jesteś na HTTP/2, ale nie HTTP/3, to pojawia się jako informacja; HTTP/3 to nowoczesny default, ale HTTP/2 wciąż jest w pełni akceptowalny. Wersja, którą widzi twoja przeglądarka, to wersja, którą otrzymują twoi odwiedzający, więc raport odzwierciedla rzeczywistą wydajność, nie teoretyczną konfigurację.