Komprese GZIP a Brotli patří mezi optimalizace, o kterých správci webu často jen slyšeli, aniž by si ověřili, jestli na jejich vlastním serveru skutečně běží. Přitom právě tenhle předpoklad, že to "hosting určitě řeší sám", bývá důvodem, proč web zbytečně přenáší data ve větším objemu, než by musel.
Proč automatické zapnutí komprese neznamená, že funguje pořád
Podle nedávného přehledu tipů na zrychlení WordPressu má většina moderních hostingů GZIP nebo Brotli aktivní ve výchozím nastavení už při založení webu, takže se o kompresi na první pohled nemusíte starat vůbec. Instalace nového cache pluginu, změna serverové konfigurace nebo přechod na jiný webserver ale dokáže tohle výchozí nastavení nenápadně vypnout, aniž by si toho někdo všiml, protože web dál funguje normálně, jen se o něco pomaleji načítá.
Jak kompresi rychle ověřit
Podle stejného přehledu stačí ke kontrole online nástroj typu checkgzipcompression.com nebo přímo výstup z Google PageSpeed Insights, který mezi doporučeními upozorní na chybějící kompresi textových souborů. GZIP podle tohoto zdroje typicky zmenší přenášená data až o sedmdesát procent, Brotli dosahuje ještě o něco lepšího poměru. Pokud kontrolní nástroj kompresi nenajde, dalším krokem je kontaktovat podporu hostingu, protože zapnutí u většiny poskytovatelů zabere jen pár minut na jejich straně.
Co dělá s kompresí vrstva CDN před hostingem
Pokud web běží za CDN, kompresi často neřeší jen samotný hosting, ale přebírá ji síť pro doručování obsahu jako celek. Podle přehledu o tom, jak funguje CDN a proč zrychlí i malý web, umí CDN zapnout Brotli kompresi a optimalizovat přenos pomocí HTTP/3 či QUIC bez ohledu na to, jestli má tuhle schopnost nastavenou i zdrojový server, protože kompresi provádí až na úrovni edge serverů blíž k návštěvníkovi.
Proč to snižuje zátěž hostingu, ne jen objem přenosu
Podle stejného zdroje CDN typicky přebírá osmdesát až devadesát pět procent veškerého provozu, zejména u statických souborů jako CSS, JavaScript nebo obrázky, takže původní server obsluhuje jen zlomek požadavků. Komprese na úrovni CDN tak přináší dvojí úsporu: menší objem dat pro návštěvníka a výrazně menší zátěž pro hosting, který by jinak musel kompresi provádět sám u každého jednotlivého požadavku. Web tak může běžet na levnějším plánu, aniž by to návštěvníci poznali na rychlosti načítání.
Jak vyjednávání mezi prohlížečem a serverem probíhá v praxi
Předchozí článek o kontrole GZIP a Brotli komprese podrobně popsal, jak prohlížeč v hlavičce Accept-Encoding nabídne podporované metody a server podle svých možností vybere tu nejvhodnější, kterou pak v odpovědi označí hlavičkou Content-Encoding. Tenhle proces probíhá stejně bez ohledu na to, zda kompresi provádí přímo hosting nebo vrstva CDN před ním, takže z pohledu návštěvníka je výsledek nerozeznatelný. Rozdíl je jen v tom, kde se komprimovaná data reálně vytvoří a kdo za výpočetní náklady komprese nese odpovědnost.
Které soubory se komprimovat nevyplatí
Textové soubory jako HTML, CSS a JavaScript obsahují opakující se vzory, takže komprese ušetří desítky procent jejich velikosti. Obrázky ve formátu JPEG, PNG nebo WebP, videa a fonty ve formátu woff2 jsou už samy o sobě komprimované vlastním algoritmem, takže opakovaná komprese na úrovni serveru ubere jen zlomek procenta navíc, zatímco spotřebuje výpočetní výkon zbytečně. Správně nastavená komprese proto tyhle typy souborů z procesu rovnou vynechává podle jejich MIME typu, obvykle nastavením seznamu přípon nebo typů obsahu, které se mají zpracovat.
Předkomprimování při buildu jako alternativa k výpočtu za běhu
U statických webů nebo souborů generovaných při buildu (typicky výstup nástrojů jako Webpack nebo Vite) dává smysl vytvořit komprimovanou verzi souboru už při nasazení, ne až ve chvíli, kdy o ni požádá první návštěvník. Server pak jen odešle předem připravený soubor s příponou .br nebo .gz, aniž by musel kompresi počítat opakovaně u každého požadavku. Tenhle přístup se hodí hlavně u souborů, které se mezi nasazeními nemění, protože jednou vytvořená komprimovaná verze zůstává platná až do další aktualizace.
Co online nástroj na kontrolu GZIP a Brotli komprese usnadní
Nástroj po zadání adresy stránky ověří, kterou kompresní metodu server aktuálně používá, a upozorní na typy souborů, u kterých komprese chybí, i když by u nich měla fungovat. Výsledek dostanete bez přístupu k serverové konfiguraci nebo k administraci CDN, takže kontrolu zvládnete i u webu, který spravuje někdo jiný, nebo u webu na hostingu, kde nemáte přístup k pokročilému nastavení.
Co se děje s vyplněnými údaji
Nástroj pracuje jen s adresou stránky, kterou zadáte do formuláře, a žádný soubor z webu se nikam nestahuje ani neukládá k dalšímu použití. Výsledek kontroly zmizí ihned po zavření stránky, bez jakékoliv stopy uložené na serveru nástroje.
Krátké shrnutí na závěr
Výchozí zapnutá komprese u hostingu je dobrý začátek, ne trvalá záruka. Změna pluginu, migrace na jiný server nebo přidání CDN vrstvy dokáže nastavení ovlivnit tak, že si toho nikdo nevšimne, dokud web nezačne zbytečně pomaleji načítat obrázky, styly a skripty. Pravidelná kontrola, která metoda aktuálně běží a na jaké soubory se vztahuje, patří mezi rychlé úkony, které se vyplatí zopakovat po každé větší změně na serveru, ať už jde o migraci hostingu, výměnu šablony nebo nasazení nové vrstvy CDN.
Loading...