Co należy wdrożyć najpierw: gzip czy HTTP/3?

Jeśli odpowiedzi tekstowe nie są kompresowane, zwykle rozsądniej jest najpierw sprawdzić kompresję treści, taką jak gzip lub Brotli. Jeżeli kompresja już działa prawidłowo, HTTP/3 może zapewnić dodatkową poprawę w sieciach z utratą pakietów lub wysokimi opóźnieniami oraz przy wielu równoległych żądaniach. Rzeczywisty priorytet zależy jednak od tego, czy większym wąskim gardłem są obraz LCP, blokujący renderowanie CSS lub JavaScript, czy TTFB.

Czy nadal potrzebuję gzip, jeśli używam HTTP/3?

Tak. QPACK w HTTP/3 to metoda kompresji nagłówków HTTP, natomiast gzip jest kodowaniem treści kompresującym treści odpowiedzi, takie jak HTML, CSS, JavaScript i JSON. Działają na różnych warstwach i mogą być używane razem.

Czy zastosowanie gzip do obrazów przyspieszy ich ładowanie?

Zasadniczo nie. Pliki już skompresowane, takie jak JPEG, WebP, AVIF, wideo i audio, zwykle zyskują niewiele po ponownej kompresji gzip, a może ona jedynie dodać narzut przetwarzania. Dla wydajności obrazów ważniejsze jest użycie odpowiednich wymiarów i formatu oraz nadanie priorytetu obrazom, które są potrzebne.

Czy HTTP/3 zawsze skraca czas ładowania dla każdego użytkownika?

Nie zawsze. Dzięki niezależnym strumieniom QUIC HTTP/3 może ograniczać zakres, w jakim utrata pakietów wpływa na inne strumienie, ale nie rozwiązuje bezpośrednio problemu wolnego przetwarzania po stronie serwera, dużych obrazów, zasobów blokujących renderowanie ani czasu wykonywania JavaScriptu. HTTP/2 i HTTP/3 należy mierzyć osobno w środowiskach rzeczywistych użytkowników.

Czy mogę udostępniać tylko Brotli zamiast gzip?

Obsługa Brotli jest powszechna w nowoczesnych przeglądarkach, ale serwery muszą sprawdzać nagłówek żądania Accept-Encoding i wybierać kodowanie akceptowane przez klienta. W praktyce często udostępnia się Brotli, zachowując gzip jako zgodny mechanizm awaryjny.

Czym są gzip i HTTP/3 oraz co najpierw poprawić, aby zwiększyć wydajność ładowania stron?

Autor 쉬었음.comOpublikowano 12 września 2026

gzip to sposób na zmniejszenie ilości danych, które trzeba przesłać, poprzez kompresję plików tekstowych strony internetowej, natomiast HTTP/3 jest protokołem, który zmienia sposób obsługi wielu żądań i utraty pakietów, dostarczając HTTP przez QUIC. Oba mogą pomóc w ładowaniu strony, ale nie rozwiązują tego samego problemu. Zamiast pytać: „Co jest szybsze: gzip czy HTTP/3?”, trafniej jest najpierw ustalić, gdzie znajduje się wąskie gardło bieżącej strony: w liczbie przesyłanych bajtów, utracie pakietów w sieci, odpowiedzi serwera, obrazach, renderowaniu czy JavaScripcie.www.rfc-editor.org datatracker.ietf.org

Jednym z najczęstszych błędnych przekonań w praktyce jest to, że włączenie HTTP/3 automatycznie przyspiesza całą witrynę. HTTP/3 może być ważnym usprawnieniem bazowym, ale nie zastępuje rozwiązań dla nadmiernie dużego obrazu widocznego bez przewijania, blokującego renderowanie CSS lub JavaScriptu ani powolnej odpowiedzi serwera. Z kolei jeśli witryna w ogóle nie kompresuje odpowiedzi tekstowych, włączenie gzip lub Brotli może wyraźnie zmniejszyć wolumen transmisji przy stosunkowo niewielkiej zmianie konfiguracji.web.dev developer.mozilla.org

Czym dokładnie jest gzip?

gzip to powszechnie używane kodowanie treści (Content-Encoding) dla HTTP. Serwer kompresuje oryginalne HTML, CSS, JavaScript, JSON, SVG i podobne treści w formacie gzip przed ich wysłaniem, a przeglądarka je dekompresuje i korzysta z oryginalnej treści. Specyfikacja HTTP Semantics definiuje gzip jako kodowanie treści wykorzystujące kompresję z rodziny LZ77 oraz 32-bitowy CRC.www.rfc-editor.org www.rfc-editor.org

Kluczowe jest to, że logiczny typ pliku się nie zmienia. Na przykład nawet gdy serwer dostarcza app.js z gzip, przeglądarka ostatecznie wykonuje ten sam JavaScript. Zmienia się liczba bajtów przesyłanych przez sieć. Gdy plik jest mniejszy, pobranie go przy ograniczonej przepustowości zajmuje mniej czasu, a także może zmniejszyć zużycie danych mobilnych użytkownika.www.rfc-editor.org developer.chrome.com

Jak przeglądarki i serwery wybierają metodę kompresji?

Przeglądarki używają nagłówka żądania Accept-Encoding, aby wskazać formaty kompresji, które potrafią zdekodować. Na podstawie tej listy i jej priorytetów serwer wybiera odpowiednią reprezentację i dodaje do odpowiedzi nagłówek taki jak Content-Encoding: gzip lub Content-Encoding: br. br oznacza Brotli.www.rfc-editor.org developer.mozilla.org

Jeżeli serwer lub CDN udostępnia różne odpowiedzi dla tego samego URL zależnie od metody kompresji, zwykle wysyła się Vary: Accept-Encoding, aby pamięci podręczne je rozróżniały. W przeciwnym razie skompresowana reprezentacja zapisana dla jednego klienta mogłaby zostać nieprawidłowo użyta ponownie dla żądania o innych warunkach.www.rfc-editor.org

Poniżej znajduje się koncepcyjny przebieg procesu:

Przeglądarka deklaruje obsługiwane formaty, na przykład Accept-Encoding: br, gzip.
Serwer lub CDN wybiera jedną z wersji pliku: Brotli, gzip lub nieskompresowaną.
Wskazuje wybrany format w Content-Encoding obok treści odpowiedzi.
Przeglądarka dekompresuje odpowiedź podczas odbierania lub po jej odebraniu, a następnie kontynuuje analizowanie HTML, stosowanie CSS i wykonywanie JavaScriptu.

gzip może skrócić czas transmisji w tym procesie, ale nie eliminuje czasu, jaki przeglądarka poświęca na analizowanie i wykonywanie JavaScriptu. Kompresja jest jednym z elementów wydajności, a nie rozwiązaniem każdego źródła opóźnień.developer.chrome.com web.dev

Które pliki zyskują na gzip?

gzip szczególnie dobrze nadaje się do tekstu zawierającego wiele powtarzających się ciągów i struktur. Dane z dużą liczbą powtórzeń, takie jak znaczniki HTML, selektory CSS, identyfikatory i składnia JavaScriptu oraz nazwy pól JSON, po kompresji mogą być znacznie mniejsze w transmisji. Ogólne wytyczne dotyczące wydajności stron zalecają też stosowanie kompresji do zasobów tekstowych i wykluczanie zasobów, które są już skompresowane.developer.mozilla.org web.dev

Typ zasobu	Ogólna ocena dla gzip	Obszary o wyższym priorytecie do zbadania
HTML	Zwykle odpowiedni	Czas odpowiedzi serwera, cache, rozmiar dokumentu
CSS	Zwykle odpowiedni	Usunięcie nieużywanego CSS, zarządzanie krytycznym CSS
JavaScript	Zwykle odpowiedni	Podział kodu, usunięcie nieużywanego kodu, czas wykonywania
JSON i odpowiedzi API	Zwykle odpowiedni	Projekt odpowiedzi, cache, usunięcie zbędnych pól
SVG	Zwykle odpowiedni	Oczyszczenie i uproszczenie SVG
JPEG, WebP, AVIF	Zwykle nieodpowiedni	Wymiary obrazów, format, responsywne dostarczanie
MP4 i audio	Zwykle nieodpowiedni	Przepływność, streaming, lazy loading

Dla formatów, które już same stosują kompresję, takich jak JPEG, WebP, AVIF, wideo, audio i skompresowane archiwa, ponowne użycie gzip może przynieść niewielkie korzyści. To samo dotyczy małych plików. web.dev wyjaśnia, że zasoby mniejsze niż około 1 KiB mogą kompresować się nieefektywnie albo nie zapewniać istotnych oszczędności.developer.mozilla.org web.dev

Ważne jest tu rozróżnienie między rozmiarem transmisji a rozmiarem oryginalnym. W panelu Network narzędzi deweloperskich można porównać skompresowany rozmiar pobrania z rozmiarem nieskompresowanym, a także sprawdzić nagłówek odpowiedzi Content-Encoding, aby potwierdzić, czy kompresja została faktycznie zastosowana.developer.chrome.com

Czym różnią się gzip i Brotli?

Brotli nie jest następcą gzip; to inny algorytm, który można wybierać obok gzip do kompresji treści HTTP. We współczesnym internecie często nadaje się priorytet Brotli dla zasobów tekstowych, jednocześnie udostępniając gzip klientom, które nie mogą użyć Brotli. Ponieważ przeglądarki wysyłają Accept-Encoding, a serwery negocjują wynik, dla tego samego URL mogą być wysyłane różne skompresowane reprezentacje zależnie od klienta.developer.mozilla.org developer.mozilla.org

Ogólnie Brotli może dawać mniejsze wyniki niż gzip dla tekstu internetowego. Nie oznacza to jednak zawsze proporcjonalnej poprawy ogólnej, odczuwalnej szybkości strony. Jeśli oszczędność bajtów jest niewielka albo wąskim gardłem są obrazy, przetwarzanie po stronie serwera lub wykonywanie JavaScriptu, przejście z gzip na Brotli może mieć ograniczony efekt. Na serwerach kompresujących dynamicznie ustawienia zwiększające współczynnik kompresji mogą również zwiększać użycie CPU i opóźnienie odpowiedzi. Zasoby statyczne należy więc wstępnie kompresować na etapie buildu lub CDN, zaś odpowiedzi dynamiczne dostrajać na podstawie rzeczywistego obciążenia.web.dev web.dev

Innymi słowy, kryteria wyboru są bliższe poniższym niż stwierdzeniu „Brotli jest zawsze lepsze”:

Jeśli zasoby tekstowe są duże i jest wielu użytkowników odwiedzających witrynę po raz pierwszy, rozważ obsługę zarówno Brotli, jak i gzip.
Jeżeli CDN już zapewnia odpowiednią kompresję, nie kompresuj ponownie tej samej treści w aplikacji.
Dla dynamicznej usługi z ograniczonym CPU serwera zmierz równowagę między poziomem kompresji a TTFB.
Jeśli obrazy i wideo stanowią dużą część strony, optymalizacja mediów może mieć pierwszeństwo przed kompresją tekstu.

Co zmienia HTTP/3?

HTTP/3 to standard, który zachowuje semantykę żądanie–odpowiedź HTTP, ale zastępuje TCP przez QUIC jako podstawę transportu. QUIC działa przez UDP, lecz nie jest po prostu sposobem wysyłania HTTP przez UDP. Zapewnia funkcje takie jak ustanawianie połączenia, szyfrowanie, niezawodność, kontrola przeciążenia i multipleksowane strumienie, a HTTP/3 wykorzystuje je do dostarczania wiadomości HTTP.datatracker.ietf.org developer.mozilla.org

HTTP/1.1 miał istotne ograniczenia w obsłudze żądań przez pojedyncze połączenie, dlatego powszechne stało się równoległe używanie wielu połączeń TCP. HTTP/2 poprawił ten stan przez multipleksowanie wielu żądań w jednym połączeniu TCP. Jednak ponieważ TCP gwarantuje dostarczanie odebranych danych w kolejności, po utracie pakietu w połączeniu dane, które przychodzą później, nie mogą zostać przekazane aplikacji w odpowiedniej kolejności, dopóki utrata nie zostanie naprawiona. W HTTP/2 to opóźnienie na poziomie TCP może wpływać na wiele strumieni HTTP.datatracker.ietf.org www.rfc-editor.org

QUIC w HTTP/3 zarządza niezawodnym dostarczaniem danych w kolejności dla każdego strumienia. W efekcie utrata danych w jednym strumieniu nie musi wymagać zatrzymania także niepowiązanych strumieni. RFC 9000 wyjaśnia, że po utracie pakietu tylko strumienie zawierające dane z tego pakietu są blokowane do czasu retransmisji, podczas gdy inne strumienie mogą kontynuować działanie.www.rfc-editor.org

Na ile trafne jest stwierdzenie „eliminuje blokowanie head-of-line”?

HTTP/3 przede wszystkim ogranicza blokowanie head-of-line na warstwie transportowej w całym połączeniu. Nieprawidłowe jest interpretowanie tego tak, jakby wszelkie oczekiwanie całkowicie znikało.

Po pierwsze, kolejność nadal ma znaczenie w pojedynczym strumieniu. Jeśli wcześniejsza część zostanie utracona w tym samym strumieniu, na przykład treść dokumentu HTML albo jednego dużego obrazu, późniejszych danych z tego strumienia nie można w pełni wykorzystać, dopóki wymagana kolejność nie zostanie przywrócona. Po drugie, jeśli dane z wielu strumieni zostały zawarte w jednym pakiecie QUIC, utrata tego pakietu może jednocześnie opóźnić kilka z tych strumieni.www.rfc-editor.org

Korzyści z HTTP/3 mogą być więc szczególnie widoczne w sieciach, w których występuje utrata lub zmiana kolejności pakietów. Natomiast przy oglądaniu małej strony przez przewodowe połączenie o niskich opóźnieniach i małej utracie pakietów różnica względem HTTP/2 może być mała lub różnić się zależnie od warunków pomiaru. Wynika to z tego, że HTTP/3 nie jest technologią, która magicznie zmniejsza liczbę bajtów; to architektura ograniczająca zakres rozprzestrzeniania się oczekiwania podczas transportu.datatracker.ietf.org www.rfc-editor.org

Czym QPACK w HTTP/3 różni się od gzip?

HTTP/3 obejmuje mechanizm kompresji nagłówków o nazwie QPACK. Może to łatwo prowadzić do błędnego wniosku, że HTTP/3 zawiera gzip, ale dotyczą one różnych celów. QPACK zaprojektowano do wydajnej reprezentacji pól nagłówków w żądaniach i odpowiedziach HTTP, takich jak Cookie, Content-Type i Cache-Control. gzip i Brotli są kodowaniami treści, które kompresują ciała odpowiedzi, takie jak HTML, CSS i JavaScript.datatracker.ietf.org www.rfc-editor.org

HPACK w HTTP/2 opiera się na założeniu, że stan kompresji nagłówków jest dostarczany sekwencyjnie, ale zastosowanie tego założenia bez zmian jest trudne w niezależnej architekturze strumieni QUIC. QPACK używa oddzielnych jednokierunkowych strumieni do zarządzania stanem tablic dynamicznych, co pozwala implementacjom równoważyć wydajność kompresji z ryzykiem blokowania nagłówków.datatracker.ietf.org datatracker.ietf.org

Z perspektywy rzeczywistej wydajności strony warto myśleć o ich rolach następująco:

gzip i Brotli: zmniejszają wolumen transmisji tekstowych treści odpowiedzi.
QPACK: poprawia wydajność transmisji nagłówków żądań i odpowiedzi.
HTTP/3 i QUIC: ograniczają zakres, w jakim opóźnienia transportowe związane z wieloma żądaniami i utratą pakietów rozprzestrzeniają się na inne żądania.
Cache: zapobiega ponownemu przesyłaniu zasobów, które zostały już odebrane.
Optymalizacja obrazów i kodu: zmniejsza ilość pracy, którą trzeba w ogóle pobrać i przetworzyć.

Nie są to konkurencyjne opcje, z których należy wybrać jedną; to uzupełniające się podejścia do różnych wąskich gardeł.

Jakie są większe wąskie gardła odczuwalnej szybkości strony?

Szybkość ładowania postrzegana przez użytkowników nie jest pojedynczą liczbą. Czas, po którym serwer wyśle pierwszy bajt, czas, po którym stanie się widoczna główna treść bez przewijania, oraz czas, po którym przyciski i pola wejściowe zaczną reagować, mogą być opóźniane przez różne przyczyny. W szczególności LCP (Largest Contentful Paint) oznacza moment wyrenderowania największego obrazu, bloku tekstu lub filmu w obszarze widoku, dlatego jest przydatny do oceny doświadczenia z początkowego ładowania strony.web.dev

Wolne LCP nie zawsze oznacza, że przyczyną jest kompresja sieciowa. web.dev zaleca rozdzielanie TTFB, opóźnienia ładowania zasobu, czasu ładowania zasobu i opóźnienia renderowania elementu podczas diagnozowania LCP. Na przykład nawet jeśli obraz pobiera się szybko, duży CSS może blokować renderowanie albo główny wątek może być zbyt zajęty długimi zadaniami JavaScript, aby wyświetlić obraz.web.dev

Gdy wąskim gardłem jest obraz widoczny bez przewijania

Największym elementem widocznym bez przewijania często jest obraz, na przykład duże zdjęcie produktu na stronie szczegółów produktu, zdjęcie główne na stronie głównej serwisu informacyjnego albo baner na stronie turystycznej. W takiej sytuacji włączenie gzip nie pomaga zbyt wiele samym plikom JPEG, WebP czy AVIF. Skuteczniejsze jest dostarczanie obrazów w rozmiarach odpowiadających ich wymiarom wyświetlania, stosowanie odpowiednich nowoczesnych formatów oraz unikanie opóźniania obrazu LCP przez loading="lazy". W razie potrzeby można wskazać priorytet za pomocą fetchpriority="high", lecz bezkrytyczne nadanie wysokiego priorytetu wielu obrazom może zamiast tego tworzyć konkurencję.web.dev web.dev

Gdy wąskim gardłem są CSS i JavaScript

CSS ma cechy blokujące renderowanie, ponieważ zapobiega pojawieniu się treści bez stylów. Jednak nadmiernie duży CSS, CSS niepotrzebny w początkowym widoku oraz skrypty ładowane synchronicznie mogą opóźniać wyświetlenie głównej treści. Nawet po zakończeniu transmisji duże bundlery JavaScriptu wykorzystują główny wątek przeglądarki do analizy, kompilacji i wykonywania, więc samo zmniejszenie rozmiaru pobierania za pomocą gzip może nie wystarczyć.developer.chrome.com web.dev

Wydajność JavaScriptu należy więc analizować niezależnie od kompresji. Możliwe działania obejmują usunięcie nieużywanego kodu, lazy loading funkcji niepotrzebnych w początkowym widoku, dzielenie długich zadań oraz, gdzie to możliwe, użycie renderowania po stronie serwera lub prerenderingu, aby początkowy HTML ujawniał kluczową treść i zasoby do wykrycia. Renderowanie po stronie serwera może jednak także wydłużyć czas przetwarzania serwera i wpłynąć na TTFB, dlatego zmiany architektoniczne należy oceniać za pomocą pomiarów.web.dev

Gdy wąskim gardłem są odpowiedź serwera i cache

Gdy TTFB jest długie, przeglądarka ma trudność z wykrywaniem kolejnych zasobów, zanim otrzyma HTML. Typowe przyczyny obejmują odległe położenie serwera, długie przetwarzanie bazy danych i personalizację, niepotrzebne przekierowania oraz niewykorzystane możliwości cache. HTTP/3 może poprawić część etapu transmisji w tej sytuacji, ale nie skraca bezpośrednio czasu potrzebnego serwerowi na wygenerowanie pierwszej odpowiedzi.web.dev

Cache ma inny charakter niż pozostałe usprawnienia wydajności. gzip wysyła te same dane w mniejszej postaci, HTTP/3 zmienia charakterystykę połączenia używanego do dostarczania danych, a cache zapobiega ponownemu wysyłaniu danych podczas kwalifikujących się kolejnych wizyt. W przypadku usługi o wysokim udziale powracających użytkowników odpowiednia polityka cache może wywołać większą odczuwalną różnicę niż zmiana algorytmów kompresji. Strategie cache dla odpowiedzi często zmieniających się lub zależnych od użytkownika, takich jak HTML, muszą jednak być projektowane ostrożniej.www.rfc-editor.org developer.chrome.com

Jaki jest praktyczny ranking usprawnień wydajności według odczuwalnego wpływu?

Nie ma stałego rankingu, który dotyczy każdej witryny. Wyniki różnią się zależnie od składu strony, udziału użytkowników nowych i powracających, sieci użytkowników, lokalizacji serwerów oraz istniejącej konfiguracji. Mimo to w przypadku typowych stron treściowych, e-commerce i usługowych, na których pozostają główne wąskie gardła, praktyczna jest następująca kolejność analizy.

Znajdź czynnik opóźniający kluczową treść widoczną bez przewijania. Najpierw zbadaj rozmiar, czas wykrycia i priorytet obrazu LCP; CSS blokujący renderowanie; synchroniczny JavaScript; oraz niepotrzebne renderowanie po stronie klienta.web.dev
Sprawdź czas odpowiedzi serwera i cache. Zweryfikuj TTFB, przekierowania, lokalizację CDN, cache zasobów statycznych i opóźnienia przetwarzania backendu.web.dev www.rfc-editor.org
Sprawdź kompresję tekstu dla HTML, CSS, JavaScriptu i JSON. Jeśli nie są skompresowane, zastosowanie gzip lub Brotli ma wysoki priorytet. Jeśli są już poprawnie kompresowane, dodatkowe zyski w tym samym obszarze mogą być ograniczone.developer.mozilla.org developer.chrome.com
Zmniejsz całkowity wolumen transmisji i zoptymalizuj strukturę żądań. Oczyść duże obrazy, skrypty i zasoby zewnętrzne oraz odraczaj żądania, aż będą faktycznie potrzebne. Duże ładunki sieciowe są związane z długim czasem ładowania.developer.chrome.com developer.chrome.com
Udostępnij HTTP/3, zachowaj awaryjnie HTTP/2 i zweryfikuj działanie na rzeczywistym ruchu. Porównaj wyniki przed i po, szczególnie w środowiskach mobilnych, o wysokich opóźnieniach i utracie pakietów, a także na stronach z wieloma równoczesnymi żądaniami.datatracker.ietf.org www.rfc-editor.org

Ten ranking ma ważne wyjątki. Jeśli aplikacja ma nieskompresowane odpowiedzi tekstowe większe niż 1 MB, zastosowanie gzip lub Brotli w kroku 3 może być największym usprawnieniem krótkoterminowym. Z kolei gdy obraz główny ma kilka MB, a tekst jest już kompresowany Brotli, priorytet ma optymalizacja obrazu. Jeśli serwer nie może wygenerować HTML przez kilka sekund, prace nad backendem i cache mają pierwszeństwo przed HTTP/3.developer.mozilla.org web.dev developer.chrome.com

Jeśli porównujesz tylko gzip i HTTP/3

Jeśli wybierasz tylko między tymi dwiema technologiami, decyzja jest stosunkowo prosta.

Gdy tekst nie jest kompresowany: gzip lub Brotli zwykle powinny być pierwsze. Zmniejszają ilość danych do przesłania, więc korzyści można oczekiwać na każdym obsługiwanym połączeniu.
Gdy kompresja już działa poprawnie: względna wartość HTTP/3 rośnie. Rzeczywista poprawa zależy jednak od jakości sieci i struktury żądań.
Dla stron bogatych w obrazy i wideo: ani gzip, ani HTTP/3 samodzielnie prawdopodobnie nie rozwiążą większego problemu. Najpierw należy zoptymalizować media.
Dla dużych aplikacji JavaScript: gzip jest jedynie punktem wyjścia. Aby uzyskać trwałą odczuwalną poprawę, trzeba również zbadać koszty wykonywania po transmisji.
Dla usług z wieloma powracającymi wizytami: współczynniki trafień cache mogą być większą zmienną niż zmiana metod kompresji.

Dlatego ani wniosek „gzip zawsze wyprzedza HTTP/3”, ani „HTTP/3 jest nowsze, więc zawsze jest lepsze” nie jest trafny. Precyzyjniej można powiedzieć: kompresja treści jest bazowym priorytetem dla nieskompresowanego tekstu, natomiast HTTP/3 jest usprawnieniem bazowym, które może zapewnić dodatkowe korzyści zależnie od warunków transportu i wzorców żądań.

Jakie ograniczenia uwzględnić podczas wdrażania HTTP/3?

Aby udostępniać HTTP/3, serwery, CDN, load balancery, firewalle i narzędzia obserwowalności muszą prawidłowo obsługiwać ruch QUIC i UDP. Ponieważ niektórzy klienci lub ścieżki mogą nie móc korzystać z HTTP/3, zwykle właściwe jest stopniowe wdrożenie, które nadal udostępnia HTTP/2 lub HTTP/1.1. Standard HTTP/3 opiera się na QUIC i definiuje proces, w którym klient wykrywa serwer HTTP/3, a następnie ustanawia połączenie QUIC.datatracker.ietf.org

Z perspektywy operacyjnej ważne jest, aby nie oceniać powodzenia wyłącznie na podstawie przełączenia protokołu. Monitoruj łącznie udział połączeń HTTP/3, wskaźniki błędów i ponownych prób, TTFB, LCP, wskaźniki błędów oraz użycie CPU. W szczególności gdy przed originem znajduje się CDN lub proxy, protokół widoczny na serwerze origin może różnić się od protokołu faktycznie użytego przez przeglądarkę użytkownika końcowego, dlatego należy uwzględnić także obserwację po stronie klienta.developer.chrome.com developer.chrome.com

Czy kompresja wiąże się z kwestiami bezpieczeństwa?

Tak. Nawet przy HTTPS, jeżeli dane wejściowe kontrolowane przez atakującego oraz tajne wartości są kompresowane razem w tym samym kontekście kompresji, atakujący może być w stanie wywnioskować sekret, obserwując różnice w długości szyfrogramu. Specyfikacje HTTP Semantics i HTTP/3 ostrzegają przed sytuacjami, w których dane wrażliwe i dane kontrolowane przez atakującego są kompresowane razem, oraz wskazują wyłączenie kompresji dla danych wrażliwych lub rozdzielenie kontekstów kompresji jako najbardziej niezawodne środki łagodzące.www.rfc-editor.org www.rfc-editor.org

Nie oznacza to, że każda odpowiedź gzip jest niebezpieczna. Kluczowe pytanie brzmi, czy jednocześnie występują odzwierciedlone dane wejściowe użytkownika, sekrety związane z uwierzytelnianiem oraz warunki pozwalające atakującemu wielokrotnie wysyłać żądania i obserwować rozmiary odpowiedzi. Dla wrażliwych procesów, takich jak logowanie, płatności i odzyskiwanie konta, nie należy mechanicznie stosować tych samych zasad kompresji co dla ogólnych zasobów statycznych; powinny być one analizowane wraz z projektem bezpieczeństwa.www.rfc-editor.org datatracker.ietf.org

Co mierzyć w swojej witrynie?

Bezpieczniej jest weryfikować usprawnienia wydajności przez doświadczenie rzeczywistych użytkowników niż przez pojedynczy wynik laboratoryjny. Lighthouse jest przydatny do szybkiego wykrywania potencjalnych problemów, ale nie reprezentuje wszystkich rzeczywistych użytkowników korzystających z różnych sieci, urządzeń, stanów cache i regionów. Używanie narzędzi deweloperskich wraz z monitorowaniem rzeczywistych użytkowników ułatwia oddzielenie hipotez od wyników.developer.chrome.com developer.chrome.com

Wydajność można analizować w następującej kolejności:

Sprawdź bieżący stan transmisji. W panelu Network przejrzyj Content-Encoding, rozmiar transmisji i rozmiar oryginalny dla kluczowych odpowiedzi HTML, CSS, JS i JSON.developer.chrome.com
Sprawdź protokół. W kolumnie Protocol potwierdź, czy rzeczywiste żądania używają h3, h2 lub http/1.1.
Segmentuj kluczowe metryki użytkowników. Porównaj TTFB, LCP i metryki interakcji według pierwszej i powracającej wizyty, urządzeń mobilnych i komputerów, regionu oraz typu sieci.web.dev web.dev
Zmieniaj jedną rzecz naraz. Jeśli jednocześnie wdrożysz włączenie gzip, obsługę Brotli, zastąpienie obrazów, podział JavaScriptu i włączenie HTTP/3, trudno będzie ustalić, która zmiana przyniosła efekt.
Zapisuj także skutki uboczne. Monitoruj również CPU serwera, wskaźniki błędów, współczynniki trafień cache oraz wskaźniki błędów połączeń HTTP/3 lub przejścia awaryjnego.

Na przykład jeśli przełączenie nieskompresowanego bundla JavaScriptu na gzip zmniejsza rozmiar transmisji, ale prawie nie zmienia LCP, następnym wąskim gardłem prawdopodobnie jest duży obraz, CSS albo wykonywanie JavaScriptu, a nie kompresja. Z kolei jeśli po wdrożeniu HTTP/3 poprawia się długi ogon LCP dla użytkowników sieci mobilnych, możesz zidentyfikować korzyści w środowiskach o dużej utracie pakietów i wysokich opóźnieniach, oprócz analizy średnich. Takie wnioski zaczynają się od zmierzonych wąskich gardeł, a nie od nazwy technologii.web.dev www.rfc-editor.org

Podsumowanie: traktuj gzip i HTTP/3 jako role uzupełniające się, a nie konkurs rankingowy

gzip i HTTP/3 są oba użyteczne dla wydajności stron, lecz podstawa ich porównywania jest inna. gzip zmniejsza liczbę przesyłanych bajtów dla odpowiedzi tekstowych, natomiast HTTP/3 może ograniczać wpływ utraty pakietów na wiele żądań dzięki multipleksowanym strumieniom opartym na QUIC. QPACK w HTTP/3 jest kompresją nagłówków; nie zastępuje kompresji treści realizowanej przez gzip i Brotli.www.rfc-editor.org datatracker.ietf.org datatracker.ietf.org

Najbardziej praktyczny priorytet to najpierw określenie rzeczywistego wąskiego gardła wśród LCP, TTFB, blokowania renderowania, JavaScriptu, obrazów i cache; uzupełnienie bazowej kompresji tekstu, jeśli jej brakuje; a następnie sprawdzenie HTTP/3 w warunkach rzeczywistych użytkowników. Wydajność nie polega na dodaniu jednej najnowszej technologii — polega na skróceniu najdłuższej ścieżki, na którą musi czekać użytkownik.web.dev developer.chrome.com

Dalsza lektura

Specyfikacje HTTP Semantics i kodowania treściwww.rfc-editor.org
Standard HTTP/3datatracker.ietf.org
Standard kompresji nagłówków QPACKdatatracker.ietf.org
Specyfikacja transportu QUICwww.rfc-editor.org
Wytyczne dotyczące wydajności stron i optymalizacji LCPweb.dev
Omówienie kompresji HTTPdeveloper.mozilla.org