WebP je formát. Velikost souboru vzniká až při enkodování — kvalita, lossless versus lossy, a to, z čeho převádíte. Google v FAQ na otázku, jestli může WebP narůst nad zdroj, odpovídá ano a vypisuje tři běžné situace. Z koncovky .webp ještě neplyne menší soubor. Plyne z toho jen to, že prohlížeč dostal bitstream, který umí dekódovat.
Formát není výsledek komprese
Koncovka říká kontejner a kodek. Neříká, kolik bajtů v něm leží. Lossy WebP má nastavitelnou kvalitu: malé číslo dá malý soubor a horší obraz, 100 dá nejlepší kvalitu, kterou ten režim umí — a klidně víc bajtů než JPEG, ze kterého jste vyšli. Lossless WebP drží pixely, ne dojem. Google v přehledu formátu uvádí, že lossy WebP v jejich studii průměrně ušetří kolem 30 % proti JPEG a lossless kolem 26 % proti PNG. To je průměr ze studie. Není to slib na váš export z editoru.
Stejné číslo kvality v JPEG a ve WebP není stejný slib. Jsou to stupnice dvou enkodérů. JPEG 80 a WebP 80 si nic nedluží. Když plugin v CMS „převádí do WebP“ na pevné kvalitě 90 nebo 100, neoptimalizuje. Překládá. Překlad může spadnout pod zdroj, nebo nad něj.
Ořez je jiná vrstva. Mění kompozici a teprve potom počet pixelů; postup je v textu proč webová fotka potřebuje ořez, ne jen zmenšení. Tady nejde o to, co v rámu zůstane. Jde o to, kolik bajtů zbude po enkodování už oříznutého snímku. WebP šedý profil z telefonu nespraví; barva je zase jinde, v článku proč fotka z telefonu na webu vypadá šedě.
Tři situace, kdy Google říká, že soubor naroste
FAQ libwebp klade otázku přímo: Can a WebP image grow larger than its source image? Odpověď: ano, obvykle při převodu z lossy do lossless nebo naopak, kvůli rozdílu barevných prostorů YUV420 a ARGB.
První situace: zdroj je bezeztrátové ARGB — typicky PNG s málo barvami. Podvzorkování do YUV420 při lossy WebP zavede nové barvy, které se komprimují hůř. Lossy WebP i lossy JPEG z takového PNG umí vyrůst.
Druhá situace: zdroj je už lossy (JPEG) a vy ho chcete „zachovat“ bezeztrátovým WebP. Lossless kodek se snaží popsat šum a artefakty, které JPEG do snímku už zapsal. Soubor naroste. Totéž se stane při převodu JPEG do PNG. Není to vada WebP. Je to daň za to, že bezeztrátově ukládáte ztrátový originál.
Třetí situace: zdroj je JPEG v kvalitě 80 a vy cílíte WebP na 95. Oba režimy jsou lossy, výstup je přesto větší. Google radí snížit cílovou kvalitu, nebo kvalitu neřešit a jít na cílovou velikost přepínačem -size v cwebp. Cílit třeba 80 % původních bajtů je podle FAQ robustnější než tipovat číslo kvality naslepo.
FAQ dodává, že převod JPEG → lossy WebP a PNG → lossless WebP k takovým překvapením náchylný není. Podmínka je správný režim, ne koncovka. Plugin, který všechno hází do jednoho lossy presetu, tu podmínku neplní.
| Zdroj | Špatný režim | Co z toho plyne |
|---|---|---|
| PNG, málo barev, text, UI | lossy WebP | nové barvy z YUV, soubor může narůst |
| už ztrátový JPEG | lossless WebP | bezeztrátově ukládáte šum, soubor naroste |
| JPEG kvalita 80 | WebP kvalita 95 | vyšší cílový q, větší soubor i v lossy |
| JPEG → lossy WebP, PNG → lossless WebP | — | Google: bez typického nárůstu, pokud režim sedí |
Stejně klamavý je „optimalizátor“ v šabloně, který WebP tvoří až z už zmenšeného JPEG v knihovně. Pracuje s generací, která už ztratila detaily. Když z ní cílí vysoké q, dostanete větší soubor horšího obrazu, než kdybyste šli z originálu do lossy WebP jednou. Jedna generace z originálu, jedno měření bajtů. Druhý převod z převodu je nový experiment, ne záruka úspory.
Co z nálepky WebP ještě neplyne
- Neplyne z ní menší LCP. Prohlížeč stahuje bajty, ne koncovku. Větší WebP je pomalejší než menší JPEG.
- Neplyne z ní, že kvalita 80 ve WebP je totéž co 80 v JPEG. Jsou to jiné stupnice.
- Neplyne z ní, že hromadný převod v CMS je optimalizace. Je to překlad na pevné q.
- Neplyne z ní ostrost na retina displeji. To je počet pixelů po ořezu a zmenšení, ne kodek.
- Neplyne z ní, že jeden soubor obslouží hero i náhled. Tři poměry, tři exporty; formát je až potom.
- Neplyne z ní, že lossless WebP z JPEG ušetří. Google tuto cestu v FAQ označuje jako typický nárůst.
Prakticky: měřte bajty, ne koncovku
Nechte originál originálem. Na web z něj udělejte kopii v poměru boxu, potom zmenšete, potom enkodujte. Lossy foto z JPEG cíle do lossy WebP. Grafiku, screenshot a text z PNG cíle do lossless WebP — nebo nechte PNG, pokud lossless WebP nevyhraje. Porovnejte bajty a obraz vedle sebe. Když WebP prohraje, nechte zdroj. Google k tomu v FAQ neříká „vždy WebP“. Říká, kdy výstup naroste, a nabízí -size místo hádání kvality.
V CMS vypněte „všechno do WebP na 100“. Nastavte strop velikosti nebo nižší q a výjimku pro soubory, které po převodu nabobtnají. Kontrola je v síťovém panelu prohlížeče na živé stránce, ne v knihovně médií, která ukáže náhled bez váhy.
WebP na webu zůstává užitečný. Je to kodek, který při správném režimu často ušetří. Záruka menšího souboru to není. Záruku drží enkodér, zdroj a číslo, které mu dáte — ne písmena v názvu souboru.
Obrázek u článku je ilustrační stock. Nezobrazuje konkrétní značku CMS ani čitelné UI editoru.
Zdroje
- Google Developers: WebP FAQ — „Can a WebP image grow larger than its source image?“ (tři situace, YUV420 vs ARGB,
-size) – https://developers.google.com/speed/webp/faq - Google Developers: cwebp (kvalita 0–100, lossless,
-size,-jpeg_like) – https://developers.google.com/speed/webp/docs/cwebp
