Naše webové stránky obsahují odkazy na partnerské weby. Pokud se prokliknete z našich stránek na stránky partnera a tam si zakoupíte jeho služby, obdržíme za zprostředkování provizi (Zjistit více informací). Tato forma spolupráce nijak neovlivňuje objektivnost našich recenzí. Každým nákupem přes proklik z našich stránek podpoříte naši redakci, abychom i do budoucna mohli tvořit kvalitní a užitečný obsah. Ďekujeme.
Důležité upozornění Všechny naše články píšou skuteční lidé. Nejsou to umělé texty od stroje.
WordPress 7.1 přesouvá zpracování obrázků do prohlížeče. Co to znamená pro váš web
Znáte to: klient nebo kolega nahraje do médií patnáctimegovou fotku z mobilu, chvíli se nic neděje a pak přijde hláška o chybě nahrávání. Nebo rovnou bílá obrazovka. A vy jdete zvedat memory_limit.
WordPress 7.1 tenhle scénář z velké části ruší — přesouvá zpracování obrázků ze serveru do prohlížeče toho, kdo je nahrává. Podíváme se, co to znamená v praxi, kde jsou háčky a co je potřeba otestovat, než aktualizujete.
Proč velké obrázky padaly
Doteď to fungovalo tak, že jste soubor nahráli na server a tam se s ním teprve začalo pracovat. PHP obrázek načetlo do paměti, otočilo podle EXIF dat, zmenšilo, převedlo formát a vygenerovalo všechny náhledy — a těch WordPress dělá u každého obrázku celou řadu.
Problém je, že nekomprimovaná fotka zabere v paměti mnohem víc než na disku. U velkých snímků z moderních mobilů se tak snadno narazí na memory_limit — a když k tomu dojde, nahrávání spadne a hláška vám většinou neřekne nic užitečného.
Co se změnilo v 7.1
Verze 7.1 („Mary Lou“) přináší client-side media processing. Zjednodušeně: obrázek se zpracuje ještě u vás v prohlížeči a na server dorazí až hotové soubory.
Technicky za tím stojí wasm-vips — knihovna libvips přeložená do WebAssembly. Běží ve Web Workeru, takže vám při nahrávání nezamrzne rozhraní. V prohlížeči se odehraje komprese, změna velikosti, převod formátu, rotace i generování náhledů.
Přínosy jsou tři a každý stojí za zmínku zvlášť:
- Mizí chyby z paměti PHP. Zpracování probíhá v paměti prohlížeče, takže limit serveru do toho nemluví. Velké fotky, které dřív spadly, projdou.
- Server má míň práce. Nahrávání obrázků přestává být zátěž pro procesor a paměť hostingu.
- Menší soubory. libvips komprimuje líp než GD i Imagick — u JPEGů jde podle WordPressu zhruba o 15 % úspory díky kódování ve stylu MozJPEG. To se projeví na rychlosti webu pro návštěvníky.
Je tu ještě čtvrtý efekt, méně nápadný, ale příjemný: všichni dostanou stejný výsledek. Dosud záleželo na tom, jestli má hosting GD nebo Imagick a v jaké verzi — kvalita náhledů se web od webu lišila. Teď zpracovává obrázky stejná knihovna pro všechny.
Ještě jedna praktická poznámka k nahrávání: náhledy se posílají na server po jednom, nezávisle na sobě. Když některý požadavek selže, WordPress ho zkusí znovu s postupně delší prodlevou. Na nestabilním připojení to znamená o dost méně nedokončených nahrávání než dřív.
Nové formáty: konečně HEIC z iPhonu
Se změnou přišla i podpora formátů, které dřív dělaly potíže:
- HEIC a HEIF — formát, ve kterém fotí iPhony. Převede se na JPEG ještě před nahráním, takže odpadá věčné „převeď si to nejdřív“.
- AVIF — nahrajete ho i na hosting, který AVIF na straně serveru neumí.
- HDR fotky s gain mapou — HDR data se zachovají i v generovaných náhledech.
- Animované GIFy se navíc převedou na doprovodné video ve formátu MP4 nebo WebM, což je datově nesrovnatelně úspornější.
Háček: zatím to není pro všechny prohlížeče
Tohle je nejdůležitější věta celého článku. Plnou podporu mají jen prohlížeče na Chromiu — Chrome a Edge od verze 137. Firefox a Safari celý řetězec zatím neumí.
Dobrá zpráva je, že se tím nic nerozbije. Na nepodporovaném prohlížeči se automaticky použije původní zpracování na serveru, a to bez jakéhokoli upozornění pro uživatele. Safari navíc zvládne aspoň převod HEIC na JPEG nativně.
Praktický důsledek: pokud redaktoři vašeho webu pracují v Safari, u nich se nic nezmění a staré problémy s pamětí zůstanou. Než začnete slavit, zjistěte si, v čem lidé kolem vašeho webu skutečně pracují.
Na server se zpracování vrátí i v jednom dalším případě — když máte nastavené Content Security Policy bez worker-src 'self' blob:. Web Worker se pak nespustí a WordPress tiše přepne na starý postup.
Co to znamená pro hosting
Tady je změna zajímavější, než se na první pohled zdá. Nahrávání obrázků bylo dlouho jedna z mála běžných činností, která dokázala levný sdílený hosting krátkodobě položit — jeden redaktor, pár velkých fotek a paměťový limit je na dně.
Když se ta práce přesune do prohlížeče, server jen přijímá hotové soubory. Znamená to dvě věci: na slabším tarifu vám přestane docházet paměť kvůli médiím a u redakčních webů s více autory klesne špičková zátěž, protože každý si obrázky zpracuje na svém počítači.
Neznamená to ale, že na hostingu nezáleží. Zmizel jeden konkrétní zdroj problémů, ne všechny — databáze, PHP procesy při návštěvnosti a rychlost disku zůstávají tam, kde byly.
Nahrazuje to plugin na optimalizaci obrázků?
Částečně, ale nespoléhejte na to úplně. WordPress teď komprimuje líp než dřív a u JPEGů ušetří zhruba pětinu velikosti — to je práce, kterou jste možná dělali pluginem.
Co ale nová funkce neřeší: obrázky, které už na webu máte. Zpracování se týká jen nově nahrávaných souborů, takže hromadnou optimalizaci existující knihovny po vás nikdo neudělá. Pokud máte web s tisíci fotek, plugin na dávkovou optimalizaci má dál smysl.
A druhá věc: pokud váš plugin dělá i něco navíc — třeba lazy loading, servírování přes CDN nebo automatický převod na WebP při zobrazení — tohle všechno zůstává jeho práce.
Jak to vypnout, když potřebujete
Někdy je jistota starého chování cennější než úspora. Třeba když máte na zpracování obrázků vlastní řešení nebo plugin, který do procesu zasahuje. Vypnutí je jeden řádek do functions.php nebo do vlastního pluginu:
add_filter( 'wp_client_side_media_processing_enabled', '__return_false' );Po něm se všechno vrátí k původnímu zpracování na serveru.
Druhá změna, na kterou pozor: editor je vždy v iframu
Sedmička jedna přináší ještě jednu věc, která se netýká obrázků, ale může vás zabolet víc. Editor příspěvků je nově vždy v iframu — bez ohledu na to, jakou máte šablonu, jakou verzi Block API používají vaše bloky nebo jestli máte starší meta boxy.
Ve verzi 7.0 se to ještě rozhodovalo podle obsahu konkrétního příspěvku. To skončilo: teď je to natvrdo pro všechno a neexistuje na to vypínací filtr ani přechodová berlička.
Pokud máte vlastní bloky nebo pluginy, které je rozšiřují, je tohle přesně ten případ, kdy se aktualizace nejdřív zkouší na testovacím webu. Nejčastější příčina problémů je kód, který sahá na globální document nebo window místo na dokument uvnitř iframu.
A pozor na jeden omyl: zvýšit u bloku apiVersion na 3 samo o sobě nic neopraví. Je to jen prohlášení, že blok v iframu funguje — skutečná práce je odstranit ty předpoklady o globálním dokumentu.
Co s tím udělat
- Zjistěte, v čem lidé pracují. Chrome nebo Edge znamená, že přínos dostanete hned. Safari a Firefox znamená, že zatím ne.
- Máte vlastní bloky? Testovací web, ne produkce. Iframovaný editor je jediná změna v této verzi, která umí opravdu rozbít redakční rozhraní.
- Máte plugin na optimalizaci obrázků? Ověřte si u autora, jak se chová vedle nového zpracování — a v případě pochyb ho nechte a funkci vypněte filtrem výše.
- Zálohujte před aktualizací. Platí to u každé velké verze a tady dvojnásob.
Shrnutí
Přesun zpracování obrázků do prohlížeče je změna, kterou většina lidí nepozná jinak než tím, že jim přestanou padat nahrávání velkých fotek — a to je přesně ten druh vylepšení, který má smysl. K tomu zhruba 15 % menší obrázky a nižší zátěž serveru, což se hodí hlavně na levnějších tarifech, kde je paměť těsná. Pokud vás zajímá, jaký hosting WordPressu vlastně vyhovuje, máme k tomu samostatný návod.
Rizikem téhle verze nejsou obrázky, ale iframovaný editor. Kdo má web postavený na standardních blocích a běžné šabloně, nemá se čeho bát. Kdo má vlastní bloky, ať si na aktualizaci vyhradí čas a nedělá ji v pátek odpoledne.
