HTTP/2 to druga główna wersja protokołu Hypertext Transfer Protocol, sfinalizowana w maju 2015 roku jako RFC 7540. Była to pierwsza znacząca aktualizacja HTTP od standaryzacji HTTP/1.1 w 1997 roku i rozwiązała fundamentalne problemy wydajności, które trapiły sieć przez prawie dwie dekady. Jeśli Twoja witryna WordPress nadal serwuje treści przez HTTP/1.1, prawdopodobnie tracisz znaczące korzyści wydajnościowe.
Protokół wyrósł z eksperymentalnego protokołu SPDY Google, który był w użyciu od 2012 roku i udowodnił, że kluczowe idee stojące za HTTP/2 (multiplexing, kompresja nagłówków, priorytetyzacja) działają dobrze w praktyce. Gdy IETF standaryzował HTTP/2, SPDY został wycofany, a jego idee stały się podstawą nowego standardu.
Główne ulepszenia w stosunku do HTTP/1.1
Aby zrozumieć, dlaczego HTTP/2 ma znaczenie, najpierw musisz wiedzieć, co było nie tak z HTTP/1.1. Pod starym protokołem każde połączenie TCP mogło przetwarzać tylko jedno żądanie na raz. Jeśli Twoja przeglądarka musiała załadować 40 zasobów (typowa strona WordPress), musiała otwierać wiele połączeń (przeglądarki zwykle pozwalają na 6 na domenę) i kolejkować pozostałe żądania. To tworzyło sztuczne wąskie gardła, które spowalniały każde ładowanie strony.
HTTP/2 rozwiązuje to i więcej:
Multiplexing: to absolutnie najważniejsze ulepszenie. HTTP/2 pozwala na to, by wiele żądań i odpowiedzi było w drodze jednocześnie przez jedno połączenie TCP. Twoja przeglądarka może jednocześnie zażądać Twojego pliku CSS, trzech plików JavaScript i dziesięciu obrazów, wszystko przez jedno połączenie. Brak czekania, brak kolejkowania, brak sztucznych limitów. Serwer wysyła odpowiedzi z powrotem, gdy tylko są dostępne, a przeglądarka je składa. Ta pojedyncza zmiana może drastycznie skrócić czasy ładowania dla witryn WordPress bogatych w zasoby.
Kompresja nagłówków (HPACK): nagłówki HTTP są wysyłane z każdym żądaniem i odpowiedzią. W HTTP/1.1 te nagłówki są zwykłym tekstem i często powtarzające się. Te same ciasteczka, ciągi user-agent i nagłówki accept są wysyłane raz po raz. HTTP/2 używa algorytmu kompresji HPACK, który utrzymuje współdzieloną tabelę typowych pól nagłówków między klientem a serwerem. Po pierwszym żądaniu kolejne nagłówki muszą wysyłać tylko różnice. Dla witryny WordPress ładującej ponad 50 zasobów na stronę może to zaoszczędzić dziesiątki kilobajtów na ładowanie strony.
Binary framing: HTTP/1.1 to protokół oparty na tekście, co oznacza, że parser musi szukać końców linii, obsługiwać różne kodowania tekstu i radzić sobie z różnymi edge case'ami. HTTP/2 używa warstwy binary framing, która pakuje całą komunikację w dobrze zdefiniowane ramki. Dane binarne są szybsze do parsowania, mniej podatne na błędy i bardziej kompaktowe. Jako użytkownik tego nie zauważasz, ale obniża to narzut przetwarzania zarówno na serwerze, jak i kliencie.
Priorytetyzacja strumieni: HTTP/2 pozwala przeglądarce powiedzieć serwerowi, które zasoby są ważniejsze. Na przykład przeglądarka może wskazać, że główny plik CSS powinien zostać dostarczony przed obrazami tła. Serwer może wtedy odpowiednio przydzielić przepustowość. W praktyce implementacje priorytetyzacji w przeglądarkach się różnią, a nie wszystkie serwery obsługują to idealnie, ale dla wielu witryn nadal przynosi znaczące poprawy.
Server Push: ta funkcja pozwala serwerowi wysyłać zasoby do przeglądarki, zanim ta o nie poprosi. Gdy przeglądarka żąda strony HTML, serwer może już wysłać pliki CSS i JavaScript, o których wie, że przeglądarka będzie ich potrzebować dalej. Eliminuje to opóźnienie round-trip, gdzie przeglądarka musi najpierw odkryć, że potrzebuje zasobu, a następnie go zażądać. W praktyce jednak Server Push miał ograniczone przyjęcie. Trudno go poprawnie zaimplementować (przesyłanie zasobów, które przeglądarka już ma w cache, marnuje przepustowość), a niektóre CDN-y wycofały jego wsparcie. Chrome usunął Server Push w wersji 106 (2022). Koncepcja żyje dalej w mechanizmie 103 Early Hints, który jest prostszy i bardziej praktyczny.
Dlaczego domain sharding nie jest już potrzebny
W erze HTTP/1.1 deweloperzy webowi używali sztuczki zwanej domain sharding, aby obejść limit sześciu połączeń na domenę. Serwowali obrazy z img1.example.com, CSS z cdn.example.com, a fonty z jeszcze innej subdomeny. W ten sposób zwielokrotniali liczbę równoległych połączeń, które przeglądarka mogła otworzyć.
Z HTTP/2 domain sharding jest nie tylko niepotrzebny, ale wręcz przeciwprodukcyjny. Ponieważ HTTP/2 multiplexuje wszystkie żądania przez jedno połączenie, dzielenie zasobów na wiele domen zmusza przeglądarkę do otwierania dodatkowych połączeń TCP i handshake'ów TLS. Każde nowe połączenie dodaje opóźnienie. Witryna WordPress zoptymalizowana pod HTTP/1.1 z domain shardingiem powinna skonsolidować swoje zasoby na mniejszej liczbie domen przy przejściu na HTTP/2.
Podobnie łączenie plików CSS i JavaScript w jeden bundle (inna powszechna optymalizacja HTTP/1.1) staje się mniej ważne z HTTP/2. Wysyłanie wielu mniejszych plików działa wydajnie dzięki multiplexingowi i ma dodatkową zaletę, że cache działa lepiej: jeśli zmieni się jeden mały plik, tylko ten plik musi zostać ponownie pobrany, a nie cały połączony bundle.
HTTP/2 praktycznie wymaga HTTPS
Specyfikacja HTTP/2 technicznie nie wymaga szyfrowania. Może działać przez zwykły TCP (h2c, czyli HTTP/2 cleartext). Jednak wszystkie główne przeglądarki (Chrome, Firefox, Safari, Edge) zdecydowały się implementować HTTP/2 tylko przez TLS (h2). Oznacza to, że we wszystkich praktycznych przypadkach potrzebujesz certyfikatu SSL/TLS, aby używać HTTP/2.
To w zasadzie nie jest już ograniczeniem. Bezpłatne certyfikaty od Let's Encrypt sprawiły, że HTTPS jest dostępny dla każdego, a większość dostawców hostingu WordPress włącza certyfikaty SSL do swoich pakietów. Jeśli Twoja witryna WordPress nadal jest na zwykłym HTTP, przejście na HTTPS jest warunkiem wstępnym dla HTTP/2 i przynosi własne korzyści bezpieczeństwa.
HTTP/3 i QUIC: następny krok
HTTP/3 (RFC 9114, sfinalizowane w czerwcu 2022) to następna ewolucja. Podczas gdy HTTP/2 działa na TCP, HTTP/3 całkowicie zastępuje TCP nowym protokołem transportowym zwanym QUIC. QUIC jest zbudowany na UDP i integruje szyfrowanie TLS 1.3 bezpośrednio w warstwie transportowej. Główne zalety HTTP/3 nad HTTP/2 to:
- Szybsze nawiązywanie połączenia: QUIC łączy handshake TCP i handshake TLS w jeden round-trip, co skraca nawiązanie połączenia. Dla powracających odwiedzających można nawet osiągnąć wznawianie zero-round-trip.
- Brak head-of-line blocking: w HTTP/2 nad TCP, jeśli jeden pakiet zostanie utracony, wszystkie strumienie na tym połączeniu zatrzymują się, dopóki pakiet nie zostanie ponownie wysłany. QUIC obsługuje utratę pakietów per strumień, więc jeden utracony pakiet spowalnia tylko dotknięty strumień, a nie wszystko.
- Lepsza wydajność mobilna: QUIC płynniej obsługuje zmiany sieci (jak przełączenie z Wi-Fi na mobilny internet), ponieważ połączenia są identyfikowane przez connection ID zamiast adresu IP i portu.
Główni dostawcy CDN, tacy jak Cloudflare i Fastly, już wspierają HTTP/3. Większość dostawców hostingu jest jeszcze w trakcie wdrażania. Dla właścicieli witryn WordPress wsparcie HTTP/3 jest głównie sprawą po stronie serwera; nie musisz nic zmieniać w samym WordPressie.
Jak sprawdzić, czy Twój host wspiera HTTP/2
Jest kilka sposobów, by zweryfikować, czy Twoja witryna WordPress jest serwowana przez HTTP/2:
- DevTools przeglądarki: w Chrome DevTools otwórz zakładkę Network, kliknij prawym na nagłówki kolumn i włącz kolumnę "Protocol". Powinieneś zobaczyć
h2przy żądaniach HTTP/2. - Narzędzia online: strony takie jak test HTTP/2 KeyCDN lub HTTP/2 checker na tools.keycdn.com mogą zweryfikować wsparcie HTTP/2 dla dowolnego URL.
- Linia poleceń: uruchom
curl -I --http2 -s https://twojastrona.pli szukajHTTP/2 200w odpowiedzi. - InspectWP: raport wymienia wykrytą wersję HTTP Twojej witryny WordPress.
Jeśli Twój host nie wspiera HTTP/2, przed Twoją stroną można umieścić CDN taki jak Cloudflare, by zapewnić HTTP/2 (i HTTP/3), nawet jeśli Twój serwer origin mówi tylko HTTP/1.1. CDN obsługuje połączenie HTTP/2 z przeglądarką odwiedzającego i komunikuje się z Twoim serwerem origin przez protokół, który ten obsługuje.
Implikacje wydajności WordPress
Typowa strona WordPress ładuje od 20 do 80 osobnych zasobów: arkusze stylów motywu i wtyczek, pliki JavaScript, webfonty, obrazy i czasem zewnętrzne zasoby z CDN i usług stron trzecich. Pod HTTP/1.1 ładowanie wszystkich tych zasobów było główną przyczyną czasu ładowania, z powodu ograniczeń połączeń i kolejkowania.
Po przejściu na HTTP/2 większość witryn WordPress widzi znaczące poprawy w Time to First Contentful Paint i ogólnym czasie ładowania strony. Dokładna poprawa zależy od tego, ile zasobów ładuje Twoja strona, ale redukcje 20-50% w czasie ładowania są częste dla witryn, które wcześniej były na HTTP/1.1. Najbardziej zyskują witryny z wieloma małymi zasobami (typowe dla WordPressa z wieloma aktywnymi wtyczkami).
Pamiętaj, że HTTP/2 nie zastępuje innych optymalizacji wydajności. Nadal potrzebujesz poprawnego cache, optymalizacji obrazów i wydajnego kodu. Ale HTTP/2 usuwa ważne wąskie gardło infrastrukturalne, którego nie można naprawić żadną wtyczką WordPress.
Co sprawdza InspectWP
InspectWP wykrywa wersję protokołu HTTP używaną przez Twoją witrynę WordPress, analizując nagłówki odpowiedzi. Jeśli Twoja strona jest serwowana przez HTTP/1.1, raport sygnalizuje to jako problem wydajnościowy i zaleca aktualizację do HTTP/2. Jeśli wykryto HTTP/2 lub HTTP/3, jest to wymienione jako pozytywne. Wersja HTTP jest pokazywana w sekcji wydajności raportu, obok innych statystyk na poziomie serwera, takich jak kompresja i nagłówki odpowiedzi.