Test komprese dat GZIP a Brotli je neodmyslitelnou součástí technických kontrol každého rychlého webu (kompresi GZIP se mimochodem podrobně věnuje tento článek), ale málokdo už řeší, jak přesně komprese na serveru vzniká. Server komprimuje soubory dvěma různými způsoby, což se může citelně projevit na výkonu při vyšší návštěvnosti.
Většina majitelů webu se spokojí s tím, že test potvrdí,, že ke kompresi došlo. Skutečná otázka, jestli server komprimuje soubory znovu při každém požadavku, nebo posílá už jednou hotová data, už přitom zůstává nevyřčená, a přesto zásadně ovlivňuje zátěž serveru.
Co znamená dynamická komprese
Dynamická komprese znamená, že server zkomprimuje soubor až ve chvíli, kdy o něj prohlížeč požádá. Každý požadavek tak spustí kompresní algoritmus znovu, i když jde o naprosto stejný soubor, který server komprimoval už tisíckrát předtím pro jiné návštěvníky.
Obsah
Takový přístup šetří místo na disku, protože server ukládá jen originální nezkomprimovanou verzi souboru. Cenou za úsporu místa je ale opakovaná zátěž procesoru při každém jednotlivém požadavku. U webu s desítkami tisíc denních návštěv se tato zátěž postupně sčítá a stává se citelnou součástí celkového vytížení serveru.
Co znamená statická komprese
Statická komprese funguje tak, že server si předem připraví zkomprimované verze souborů s příponou .gz nebo .br a uloží je vedle originálů. Když pak přijde požadavek od prohlížeče, server jednoduše odešle už hotový zkomprimovaný soubor bez jakéhokoli dalšího zpracování.
Komprese se v tomto případě provede jen jednou, obvykle při nasazení nové verze webu. Všechny následující požadavky na stejný soubor už žádnou výpočetní práci navíc nevyžadují. Server funguje spíš jako jednoduchý distributor předem připravených dat než jako výpočetní jednotka, která soubor při každém požadavku znovu zpracovává.
Proč statická komprese šetří výkon serveru více
Nejlépe srovnání obou metod vynikne u webu s vysokou návštěvností. Při dynamické kompresi musí server u každého požadavku znovu spustit kompresní algoritmus, i když se výsledek od předchozího požadavku vůbec neliší. Tisíce shodných požadavků tak znamenají tisíce zbytečně opakovaných výpočtů.
Statická komprese se bez této zbytečné práce úplně obejde. Soubor se zkomprimuje jednou při buildu nebo nasazení, a server pak už jen odesílá hotová data. Procesor zůstává volný pro jiné úkoly, třeba zpracování dynamického obsahu nebo databázových dotazů, které skutečná dynamická komprese ve skutečnosti vyžaduje.
Rozdíl je ještě výraznější u algoritmu Brotli na nejvyšší úrovni komprese, protože ten je výpočetně mnohem náročnější než Gzip. Dynamické generování takto silně komprimovaných souborů při každém požadavku dokáže server citelně zpomalit. Naproti tomu statická příprava tento náklad přesune mimo běžný provoz. U webu s tisíci souborů se tento rozdíl v úhrnu projeví jako citelná úspora výpočetního výkonu, který server může využít jinde.
Kdy statickou kompresi nasadit
Statická komprese dává největší smysl u souborů, které se nemění při každém požadavku, typicky CSS, JavaScript, fonty nebo statické obrázky ve formátu SVG (o formátu SVG a dalších se více dočtete zde). Tyto soubory zůstávají mezi jednotlivými nasazeními stejné, takže jejich předchozí komprese dává naprostý smysl.
U dynamicky generovaného obsahu, třeba stránek s často se měnícími daty z databáze, statická komprese nefunguje stejně dobře, protože obsah se mění příliš často na to, aby dávalo smysl předem připravovat zkomprimované verze. Zde zůstává dynamická komprese jedinou praktickou volbou.
Vhodným kompromisem bývá kombinace obou přístupů v rámci jednoho webu. Statické soubory, které se mění jen při nasazení nové verze, dostanou předem připravenou kompresi, zatímco dynamicky generovaný obsah se komprimuje za běhu podle aktuální potřeby. Server tak nemusí volit jeden univerzální přístup pro celý web, ale přizpůsobí kompresi typu obsahu, který zrovna odesílá.
Jak nastavení komprese ověřit
Nejsnadnější cestou je test pomocí analyzátoru SEO problémů na platformě TopRankerTools, který ukáže, jestli server u konkrétní adresy kompresi vůbec používá a jaký algoritmus přitom nasazuje.
Test pomůže odhalit i situace, kdy má server kompresi technicky zapnutou, ale kvůli chybné konfiguraci ji u některých typů souborů vůbec nepoužívá. Taková mezera se snadno přehlédne, protože zbytek webu se přitom tváří jako plně optimalizovaný. Stačí přitom zkontrolovat jen pár hlavních typů souborů, aby administrátor rychle zjistil, kde přesně konfigurace pokulhává.
Jak statickou kompresi nastavit
Nastavení statické komprese obvykle probíhá v rámci buildovacího procesu, kdy nástroj po vygenerování finálních souborů automaticky vytvoří i jejich .gz a .br verze vedle originálu. Webserver pak stačí nastavit tak, aby tyto předpřipravené soubory upřednostnil, pokud existují, a teprve v jejich nepřítomnosti se uchýlil k dynamické kompresi.
Moderní nástroje pro sestavení frontendových projektů tuto funkci často nabízejí jako součást standardní konfigurace, takže nastavení nevyžaduje psaní kódu od nuly. Stačí zapnout příslušnou možnost v konfiguračním souboru a nechat build proces zbytek práce zvládnout automaticky při každém nasazení. U starších projektů bez moderního build systému se dá totéž zařídit i samostatným skriptem, který se spustí jako poslední krok nasazení.
Mix statické komprese pro neměnné soubory a dynamické komprese pro zbytek obsahu, dává webu nejlepší poměr mezi rychlostí odezvy a zátěží serveru.