Optimalizace obrázků ve WordPressu: velikosti, srcset, WebP

Většina pomalých stránek na WordPressu je pomalá kvůli obrázkům a skoro celou jejich váhu jde ušetřit. Postup je vždy stejný. Nejdřív přestaň nahrávat soubory, které jsou mnohem větší, než kolik kdy zobrazí jakákoli obrazovka. Pak ověř, že WordPress každému návštěvníkovi podá rozumně velkou kopii přes srcset. Potom zapni lazy loading pro vše pod první obrazovkou, ale nikdy ne pro hlavní obrázek nahoře. A teprve potom se vyplatí převádět do WebP, což při stejné viditelné kvalitě typicky ušetří čtvrtinu až třetinu dat. Jestli převádět pluginem, nebo offline na vlastním počítači, závisí na počtu obrázků, na tom, jak často přibývají nové, a na tom, kolik CPU dává tvůj tarif. Tento článek projde každý krok s nastavením, filtry a příkazy a otevřeně řekne, kde krok dělá míň, než slibuje jeho reklama.

Odkud se bere váha#

Otevři v prohlížeči panel Network na pomalé stránce WordPressu a seřaď podle velikosti. Obraz bývá stejný: několik obrázků tvoří většinu přenosu - fotka z telefonu o 4000 pixelech jako hlavní banner, PNG screenshot o 2 MB, logo v souboru o 900 KB, galerie dvaceti plnoformátových JPEG zmenšených pomocí CSS. Prohlížeč stáhne každý bajt, i když vykreslí jen 400 pixelů.

Jsou to tři různé problémy a každý se léčí jinak.

• Příliš mnoho pixelů. Obrázek o 4000 pixelech ve sloupci širokém 700 nese zhruba třicetkrát víc pixelů, než jde zobrazit. Řešení: zmenšit rozměry.
• Příliš mnoho bajtů na pixel. JPEG uložený v kvalitě 100 je několikrát větší než verze v kvalitě 80, přitom rozdíl neuvidíš. Řešení: zkomprimovat, nebo použít lepší formát.
• Příliš mnoho obrázků najednou. Stránka se čtyřiceti obrázky nepotřebuje všech čtyřicet, než návštěvník vůbec zascrolluje. Řešení: lazy loading.

Převod do WebP řeší jen druhý problém a sahá se po něm jako po posledním. Když obrázek o 4000 pixelech nabídneš jako WebP, bude soubor menší, ale pořád příliš velký. Článek jak hosting ovlivňuje TTFB a Core Web Vitals vysvětluje, proč je nejvýznamnější obrázek obvykle právě prvek, který měří Largest Contentful Paint, a proč tedy správná práce s obrázky hýbe číslem, na které se dívají vyhledávače. Rychlost serveru to nezachrání: 3 MB je 3 MB na jakémkoli hostingu.

Co WordPress s nahraným souborem dělá sám#

Když přidáš soubor do Media Library, WordPress ponechá originál a vytvoří menší kopie. Výchozí velikosti se nastavují v Nastavení, Média, a šablony a pluginy v kódu registrují další.

Šablony přidávají další přes add_image_size() a každá z nich znásobuje počet souborů na jedno nahrání. Jedno nahrání snadno vytvoří deset až dvacet souborů na disku. Na tom záleží kvůli místu i času převodu, a proto nástroje, které zpracovávají „obrázek“, ve skutečnosti zpracovávají tucet souborů.

Od WordPressu 5.3 existuje i strop. Pokud je nahraný obrázek na delší straně větší než 2560 pixelů, WordPress ho zmenší na tuto velikost, originál nechá na disku a servíruje zmenšenou kopii, jejíž název dostane příponu -scaled. Řídí to filtr, takže práh můžeš snížit nebo zcela vypnout:

// Lower the cap from 2560 to 1920 pixelsadd_filter( 'big_image_size_threshold', function () {    return 1920;} );// Or disable the automatic scaling entirely// add_filter( 'big_image_size_threshold', '__return_false' );

Pro skoro každý web je 1920 lepší strop než 2560, protože jen málo layoutů zobrazuje obrázek širší. Snížení prahu nezmenší to, co jsi nahrál dřív; platí jen pro nová nahrání.

Dva detaily, které lidi překvapují. WordPress při vytváření zmenšených kopií JPEG znovu komprimuje, s výchozí kvalitou 82. To je rozumné výchozí nastavení. A originální soubor zůstává na disku nedotčený, takže složka uploads je těžší než součet toho, co návštěvníci kdy stáhnou.

Rozměry: nenahrávej, co nikdo neuvidí#

Nejlevnější úspora nestojí nic kromě návyku. Před nahráním rozhodni, jak široký bude obrázek maximálně zobrazen, a exportuj ho zhruba ve dvojnásobku pro displeje s vysokou hustotou, ne víc.

Fotografie patří do JPEG nebo WebP. Screenshoty a ploché grafiky s ostrými hranami se často lépe komprimují jako PNG nebo bezeztrátové WebP a PNG s fotografií je téměř vždy chyba, kterou stojí za to opravit. Logo nebo ikona má být SVG; WordPress nahrávání SVG ve výchozím stavu nepovoluje, protože SVG může obsahovat skripty, takže ho zapínej jen přes plugin, kterému věříš, a jen pro administrátory.

Pokud opravuješ existující web a nezačínáš od nuly, kde začít, ukážou čísla. Nejdřív vypiš největší soubory:

$ cd wp-content/uploads$ find . -type f \( -name '*.jpg' -o -name '*.jpeg' -o -name '*.png' \) \    -size +500k -printf '%s %p\n' | sort -rn | head -20

Cokoli nad 500 KB u obrázku v textu je kandidát na opravu. Oprav dvacet nejhorších ručně a obvykle tím sundáš většinu váhy.

Jak funguje srcset a proč potřebuje správné velikosti#

Atribut srcset dovoluje prohlížeči vybrat z několika šířek téhož obrázku a sizes mu říká, jak široký bude zobrazený. WordPress oba přidává automaticky k obrázkům vloženým přes editor a sestavuje je z vytvořených kopií:

<img src="/wp-content/uploads/2026/10/cafe-1024x683.jpg"     srcset="/wp-content/uploads/2026/10/cafe-300x200.jpg 300w,             /wp-content/uploads/2026/10/cafe-768x512.jpg 768w,             /wp-content/uploads/2026/10/cafe-1024x683.jpg 1024w,             /wp-content/uploads/2026/10/cafe-1536x1024.jpg 1536w"     sizes="(max-width: 1024px) 100vw, 1024px"     width="1024" height="683" alt="A cafe interior" loading="lazy">

Prohlížeč přečte nápovědu sizes, vynásobí ji hustotou pixelů displeje a stáhne nejmenšího kandidáta, který je dost široký. Telefon s viewportem 390 pixelů a hustotou 3x chce asi 1170 pixelů; stolní počítač se sloupcem 700 pixelů při 1x chce 700. Šířkový deskriptor (300w) je skutečná šířka souboru v pixelech, díky čemuž může prohlížeč kandidáty porovnávat, aniž by je stahoval.

Pomůže to jen tehdy, když kandidáti existují. Tři časté potíže:

• Velká kopie je jen originál. Pokud šablona neregistruje žádné velikosti mezi 768 a 2560, telefon, který chce 1170 pixelů, dostane kopii o 1536 nebo originál. Přidání velikosti 1200 nebo 1600 pomůže, ale jen u nových nahrání (viz níže regenerace).
• Špatné `sizes`. WordPress odhaduje zobrazenou šířku podle velikosti, kterou jsi vložil. Pokud šablona ukazuje obrázek v úzkém sloupci a sizes říká 100vw, prohlížeč stáhne většího kandidáta, než potřebuje. Vývojáři šablon to opravují filtrem wp_calculate_image_sizes; jako majitel webu vol menší vloženou velikost nebo oprav šablonu.
• Obrázky natvrdo v šablonách nebo v page builderech. Výstup sestavený ze surové URL místo ID přílohy nemá srcset. Použij pole pro obrázek v builderu, které ukládá přílohu, a ne vkládej URL.

Vždy nech v tagu width a height. WordPress je doplňuje z metadat přílohy a díky nim prohlížeč vyhradí místo ještě před načtením obrázku, takže stránka neposkakuje. Je to největší jednotlivá oprava posunu layoutu a už je hotová, pokud builder atributy nevyřezává.

Abys zjistil, jaké velikosti tvůj web skutečně má, a zkontroloval konkrétní obrázek, použij WP-CLI, pokud ho máš:

$ wp media image-size$ wp post meta get 123 _wp_attachment_metadata --format=json | head -c 600

První příkaz vypíše všechny registrované velikosti s rozměry a informací, zda se ořezávají. Druhý ukáže, co se vytvořilo pro přílohu 123.

Regenerace náhledů po změně#

Přidáš velikost, změníš ořez nebo snížíš kvalitu a u už nahraných obrázků se nic nezmění. Kopie na disku vznikly při nahrání. Aby se vytvořily znovu, je potřeba regenerace:

$ wp media regenerate --only-missing --yes

--only-missing vytvoří jen velikosti, které ještě neexistují, což je rychlé a bezpečné. Bez něj WordPress přestaví všechny velikosti všech příloh, což u knihovny o několika tisících obrázků trvá dlouho a hodně zatíží CPU, takže to pusť v tiché hodiny. Bez přístupu do shellu použij regenerační plugin z administrace a počítej s tím, že zpracovává po malých dávkách.

Před úplnou regenerací udělej backup. Soubory nahrazuje a nedokončený běh na malém serveru může nechat některé příspěvky odkazovat na smazané velikosti. Článek backupy, které se opravdu obnoví popisuje, jak si ověřit, že je kopie použitelná, než se na ni spolehneš, a workflow se staging webem je dobré místo pro první průchod.

Také po sobě uklízej. Nepoužívané velikosti ze staré šablony zůstávají na disku navždy. Po změně šablony může regenerace s novou sadou a odstranění sirotků uvolnit gigabajty ve velké knihovně.

Lazy loading a jediný obrázek, který ho nesmí mít#

Lazy loading odloží stažení obrázku, dokud není blízko viditelné oblasti, takže dlouhá stránka nestahuje všechno hned při příchodu. Od WordPressu 5.5 je to výchozí chování: atribut loading="lazy" se přidává k obrázkům a iframe v obsahu, žádný plugin není potřeba. Prohlížeče ho podporují nativně a je levnější a spolehlivější než JavaScriptové lazy-loadery, které tu byly dřív.

Důležitější je opačné pravidlo. Nikdy nepoužívej lazy loading u obrázku nahoře na stránce. Hlavní nebo úvodní obrázek je obvykle prvek Largest Contentful Paint a říct prohlížeči, ať na něj počká, přímo zdržuje to, co se měří. Novější verze WordPressu už loading="lazy" k prvnímu obrázku v obsahu nepřidávají a dávají mu fetchpriority="high", ale šablony a buildery to často přepisují, takže se dívej na vykreslené HTML, nepředpokládej.

Správné značení hlavního obrázku je prosté, s nápovědou priority:

<img src="/wp-content/uploads/2026/10/hero-1600.webp" width="1600" height="900"     alt="Product on a desk" fetchpriority="high" decoding="async">

Výchozí chování můžeš pro konkrétní obrázky vypnout filtrem a stejný systém filtrů ho vypne globálně, pokud se hádá se šablonou:

add_filter( 'wp_img_tag_add_loading_attr', function ( $value, $image, $context ) {    // Return false to omit loading="lazy" for this tag    if ( strpos( $image, 'hero-' ) !== false ) {        return false;    }    return $value;}, 10, 3 );

Vše pod první obrazovkou má být lazy: náhledy v galerii, loga v patičce, avatary v komentářích. Neskládej lazy loading na plugin, který přepisuje stejné tagy: dva systémy, které spolu soupeří, jsou jistý způsob, jak obrázky vůbec nezobrazit. Pokud se obrázky ukazují jako prázdné boxy, dokud nescrolluješ, nebo se nenačtou nikdy, vypni lazy volbu v pluginu a spolehni se na nativní atribut.

Obrázky na pozadí nastavené v CSS loading="lazy" nepokrývá. Banner vytvořený jako CSS pozadí nejde tímto způsobem upřednostnit ani líně načítat, což je další důvod, proč u důležitých obrázků dávat přednost skutečnému tagu img.

WebP: co dává a co ne#

WebP je formát obrázků od Googlu, který podporuje ztrátovou i bezeztrátovou kompresi a průhlednost. Fotografie vycházejí typicky zhruba o 25 až 35 procent menší než ekvivalentní JPEG při podobné viditelné kvalitě a bezeztrátové WebP je obvykle menší než PNG, které nahrazuje. Zobrazují ho všechny současné prohlížeče, takže ho lze brát jako bezpečnou výchozí volbu a nemusíš se starat o návštěvníky, kteří ho nepřečtou. AVIF komprimuje ještě víc, ale kóduje se mnohem déle; WordPress 6.5 a novější nahrání AVIF přijímá, i když ho většina webů nepotřebuje.

WordPress přijímá nahrání WebP od verze 5.8. Soubor .webp můžeš přetáhnout do Media Library a funguje jako každý jiný obrázek: vytvoří se zmenšené kopie a srcset funguje. Zda se zmenšené kopie dají vytvořit, záleží na knihovně pro obrázky na serveru: editor potřebuje GD nebo Imagick sestavené s podporou WebP. Obrazovka Site Health v Nástroje, Stav webu ukáže, co je k dispozici. Pokud hlásí, že podpora WebP chybí, nahrání souborů .webp bude fungovat, ale změněné velikosti se nevytvoří.

Je dobré být upřímný ohledně limitů:

• WebP nespraví příliš velký obrázek. Nejdřív zmenšuj.
• Zisk se liší. Fotografie ušetří hodně; už silně zkomprimovaný obrázek málo; některá malá PNG se zvětší.
• Převedená kopie je druhý soubor na každou velikost. Pokud necháš obojí, spotřeba disku nejdřív vzroste a až pak klesne.
• Při velmi vysoké kvalitě se výhoda zmenšuje. Pro fotografie je užitečný rozsah kvality 75 až 85.

Plugin, nebo konverze offline#

Existují dva přístupy a správný záleží na webu.

Plugin

Pluginy pro obrázky jako ShortPixel, Imagify, EWWW Image Optimizer a Smush převádějí a komprimují při nahrání, hromadně zpracují existující knihovnu a přepíší značení tak, aby návštěvníci s podporou WebP dostali WebP. Některé pracují na tvém serveru pomocí GD nebo Imagicku; jiné pošlou soubor do služby výrobce a stáhnou výsledek, což šetří tvoje CPU, ale znamená to, že obrázky opouštějí tvůj server, a obvykle je tu kvóta nebo placený tarif. Přečti si, co plugin skutečně dělá, než ho zapneš, protože detaily se liší a reklamní stránky je rozmazávají.

Praktické body pro plugin na malém tarifu:

• Hromadný převod je místo, kde tarify trpí. Převod knihovny o několika tisících obrázků je nápor na CPU a paměť PHP. Na RE:NODE je limit CPU pevné škrcení na zakoupený podíl, takže hromadný běh na malém tarifu trvá déle, místo aby selhal, a úloha, která překročí limit paměti, způsobí, že jádro zastaví kontejner a ten se čistě restartuje, místo aby šel do swapu. Nastav plugin na malé dávky a nech ho pracovat přes noc.
• Zkontroluj, jak se WebP servíruje. Pluginy buď přepisují tagy img na WebP, nebo je obalují prvkem picture, nebo se opírají o serverová pravidla, která soubor podle hlavičky Accept zaměňují. První dvě varianty fungují s jakoukoli cache. Poslední potřebuje konfiguraci serveru a hlavičku Vary: Accept, aby cache nepodala WebP prohlížeči, který ho neumí číst.
• Nech si originály. Většina pluginů umí ponechat zálohu originálu; nech to zapnuté, dokud si výsledek neprohlédneš na skutečné stránce.
• Jeden optimalizátor, ne tři. Dva pluginy na obrázky nad stejnými soubory znamenají dvakrát zkomprimované soubory a pravidla, která se perou.

Konverze offline

Pokud je sada obrázků pevná, třeba portfolio, jídelní lístek nebo produktový katalog, který se mění jednou měsíčně, převeď ji na vlastním počítači a nahraj výsledek. Kvalitu řídíš přesně, na serveru nic neběží a neinstaluje se nic, co by se mohlo po aktualizaci pluginu rozbít.

S nástrojem cwebp z balíku libwebp od Googlu nebo s ImageMagickem se složka převede jedním příkazem:

$ for f in *.jpg; do cwebp -q 80 "$f" -o "${f%.jpg}.webp"; done# or with ImageMagick, also resizing to 1600 px wide at most$ mogrify -path out -format webp -quality 80 -resize '1600x>' *.jpg

Znak > v argumentu změny velikosti znamená „zmenšit jen větší“, takže menší soubory zůstanou, jaké jsou. Než zpracuješ celou knihovnu, zkontroluj pár výsledků očima a porovnej velikosti souborů: pokud WebP není menší než zdroj, nech zdroj.

Výsledky nahraj přes správce souborů nebo SFTP. Správce souborů RE:NODE přijímá nahrání složek přetažením a zobrazuje obrázky v prohlížeči, což stačí na namátkovou kontrolu dávky. Soubory vhozené přímo do wp-content/uploads se v Media Library neobjeví, protože knihovna je tabulka v databázi. Soubory, které se musí ukázat v editoru, nahrávej přes samotnou Media Library. Soubory, na které odkazuje jen šablona (pozadí, loga), dej do složky šablony a odkazuj na ně přímo.

Hybrid, který funguje většině lidí: velké obrázky (bannery, hlavičky), u kterých na kvalitě záleží nejvíc, zmenši a zkomprimuj ručně a proud běžných nahrání od redaktorů nech na pluginu.

Servírování WebP se záložní variantou#

Pokud převádíš, ale chceš podporovat prohlížeč, který WebP neumí číst, standardním značením je picture, které prohlížeči dovolí vybrat podle formátu:

<picture>  <source srcset="/wp-content/uploads/2026/10/cafe.webp" type="image/webp">  <img src="/wp-content/uploads/2026/10/cafe.jpg" width="1024" height="683" alt="A cafe"></picture>

V roce 2026 je záloha málokdy nutná a nejjednodušší je jen WebP. Plugin s režimem picture nebo s režimem podle hlavičky Accept řeší problém, který většina webů už nemá, takže vol nastavení, které po sobě zanechá nejméně serverové konfigurace.

Pokud přesto servíruješ podle hlavičky Accept na serveru ve stylu Apache, pravidlo vypadá takto a funguje jen tehdy, když vedle každého originálu leží .webp:

<IfModule mod_rewrite.c>RewriteEngine OnRewriteCond %{HTTP_ACCEPT} image/webpRewriteCond %{REQUEST_FILENAME} \.(jpe?g|png)$RewriteCond %{REQUEST_FILENAME}.webp -fRewriteRule ^(.+)$ $1.webp [T=image/webp,E=WEBP:1,L]</IfModule><IfModule mod_headers.c>Header append Vary Accept env=REDIRECT_accept</IfModule>

Na nginx žádný .htaccess není, takže stejná myšlenka žije v konfiguraci serveru jako map nad $http_accept. Ověř, že server posílá image/webp jako typ obsahu pro soubory .webp. Starým souborům mime.types tento záznam chybí a WebP podaný jako application/octet-stream se stáhne místo zobrazení. Ověř přes curl:

$ curl -sI https://example.com/wp-content/uploads/2026/10/cafe.webp \    | grep -i -E '^(content-type|content-length|cache-control)'

Pak obrázkům nastav dlouhou dobu uložení v cache, protože se pod stejným názvem souboru nemění. O Cache-Control pro statické soubory pojednává článek hlavičky HTTP cache a cache ve WordPressu vysvětluje, proč stránková cache a optimalizace obrázků řeší různé poloviny problému.

Příklad z praxe#

E-shop má na stránce produktu osm fotografií nahraných rovnou z telefonu v rozlišení 4032 na 3024 pixelů, každá asi 3,4 MB. WordPress každou zmenšil na 2560 pixelů, takže největší servírovaný soubor má kolem 1,4 MB, a mřížka je zobrazuje v šířce 380 pixelů.

1. Nastav big_image_size_threshold na 1920 a zaregistruj velikost 760 pixelů pro mřížku (dvojnásobek zobrazené šířky 380).
2. Spusť wp media regenerate --only-missing --yes, aby se nová velikost vytvořila pro existující produkty.
3. Znovu exportuj osm hlavních obrázků na 1600 pixelů jako WebP v kvalitě 80, což dá zhruba 120 až 200 KB na soubor.
4. Ověř, že se ve zdrojovém kódu stránky objevuje srcset a že první obrázek nemá loading="lazy".
5. Změř znovu.

Váha obrázků na stránce klesne zhruba z osmi až jedenácti megabajtů na výrazně méně než dva. Nic z toho nepotřebovalo plugin. Mřížka také zhubla hlavně proto, že prohlížeč teď vybírá kopii o 760 pixelech, a ne o 2560.

Jak změřit, že to zabralo#

Nevěř procentům, která si plugin sám připisuje. Změř stránku před a po stejným nástrojem: panel Network v prohlížeči (vypni cache, pak čti přenesenou velikost obrázků), Lighthouse nebo PageSpeed Insights. Sleduj tři údaje: celkový objem obrázků, prvek LCP a dobu jeho načtení a posun layoutu.

Z příkazové řádky můžeš ověřit, co by dostal konkrétní návštěvník:

$ curl -s -o /dev/null -w '%{size_download} bytes\n' \    -H 'Accept: image/webp,*/*' \    https://example.com/wp-content/uploads/2026/10/cafe.jpg

Spusť to jednou s hlavičkou Accept a jednou bez ní. Pokud se počty bajtů liší, serverové vyjednávání funguje; pokud se shodují, servíruješ všem originál. Pamatuj, že CDN nebo stránková cache před webem může držet starou verzi stránky, takže po změně ji vyprázdni, jinak změříš včerejší HTML.

Krátký kontrolní seznam pro jakýkoli problém s obrázky:

1. Je soubor aspoň dvakrát větší než zobrazená velikost?
2. Má tag srcset, width a height?
3. Je horní obrázek bez loading="lazy"?
4. Hodí se formát k obsahu (fotka, grafika, logo)?
5. Je pro tento typ souborů nastavený dlouhý Cache-Control?

Poznámky k hostingu#

Práce s obrázky je většinou front-end a žádný tarif nevynahradí příliš velké soubory. Hosting rozhoduje o tom, jak pohodlná je mechanika. Na tarifu WordPress od RE:NODE můžeš upravovat .htaccess nebo wp-config.php ve správci souborů, nahrávat složky přes SFTP a před hromadným během udělat backup na kartě Backups. Počet slotů pro backup se liší podle tarifu, takže ho před spoléháním zkontroluj na stránce tarifu. Druhý limit, který stojí za sledování, je místo na disku: každé nahrání se rozmnoží na tucet souborů a plugin, který drží originály vedle kopií WebP, zabere místa víc, ne míň, dokud nepročistíš. Pokud je problémem velká knihovna, přesun médií WordPressu do S3 ji odstraní z disku webového serveru za cenu jedné pohyblivé části navíc.

FAQ#

Je WebP pro WordPress lepší než JPEG?

U fotografií je obvykle o 25 až 35 procent menší při stejné viditelné kvalitě a čtou ho všechny současné prohlížeče. Nepomůže, pokud má obrázek od začátku špatnou velikost, takže nejdřív zmenši a teprve pak převáděj.

Potřebuju plugin, abych mohl používat WebP?

Ne. WordPress přijímá WebP od verze 5.8 a převádět můžeš offline přes cwebp nebo ImageMagick a hotové soubory nahrát. Plugin dává smysl, když nahrává víc lidí a chceš, aby se převod dělal automaticky.

Škodí lazy loading SEO?

Nativní loading="lazy" vyhledávače čtou správně, takže obrázky pod první obrazovkou se indexují. Škodí lazy loading hlavního obrázku nahoře, který zdržuje Largest Contentful Paint. První obrázek nech načítat normálně.

Proč jsou obrázky po optimalizaci pořád velké?

Obvykle stránka používá originál nebo kopii -scaled, protože chybí srcset, šablona nezaregistrovala střední velikosti, nebo je obrázek z CSS pozadí. Zkontroluj ve vykresleném HTML atribut srcset a v panelu Network, jaký soubor se opravdu stahuje.

Musím po změně šablony regenerovat náhledy?

Ano, pokud nová šablona používá jiné velikosti obrázků. Jinak žádá velikosti, které neexistují, a sáhne po větší. Spusť wp media regenerate --only-missing --yes a předtím udělej backup.

Může optimalizace obrázky poškodit?

Ztrátová komprese zahazuje data a nejde vrátit, takže originály si nech, dokud výsledek neověříš na skutečných stránkách. Nikdy nepřepisuj jedinou kopii zkomprimovanou.