1. Přetížený hosting a slabý server

První brzda bývá často skrytá už pod webem samotným: hosting. WordPress je dynamický systém, takže při každé návštěvě server generuje stránku, sahá do databáze a obsluhuje skripty. Pokud běží na sdíleném hostingu s omezeným výkonem, reaguje pomalu i tehdy, když je šablona dobře napsaná a pluginů není mnoho.

V praxi se to projeví hlavně na metrikách TTFB a LCP. Pokud má server čas odezvy přes 600 ms, je problém na straně infrastruktury velmi pravděpodobný. U méně zatížených webů bývá reálný cíl pod 200–300 ms. Testovat lze přes PageSpeed Insights, WebPageTest nebo serverové logy v hostingu.

Co pomáhá:

  • přechod na kvalitnější hosting s PHP 8.2+ a HTTP/2 nebo HTTP/3,
  • zapnutí serverového cache, ideálně na úrovni hostingu,
  • použití objektové cache, pokud web pracuje s větším množstvím dotazů,
  • oddělení náročného webu od levného sdíleného řešení.

U e-shopů na WooCommerce je rozdíl obvykle výrazný. Při stejném obsahu může přechod z levného hostingu na optimalizovaný server zkrátit načítání o 1 až 2 sekundy, někdy i víc.

2. Těžká šablona a vizuální buildery

Druhou častou brzdou je šablona, která je vizuálně atraktivní, ale technicky přetížená. Mnoho prémiových témat a drag-and-drop builderů přidává desítky CSS a JavaScript souborů, často i na stránkách, které je vůbec nepotřebují. Výsledek: delší render, vyšší INP a horší mobilní UX.

Typický problém vzniká ve chvíli, kdy web používá builder pro každý blok obsahu. Na homepage běží slider, animace, tři fonty, ikonové sady a několik externích knihoven. Uživatel pak vidí stránku až po několika sekundách, i když server odpovídá relativně rychle.

Jak poznat problém:

  • v nástroji GTmetrix nebo WebPageTest sledujte počet požadavků a velikost CSS/JS,
  • v Chrome DevTools zkontrolujte, co se načítá na první pohled a co je blokující,
  • porovnejte výkon homepage a podstránek – někdy je zpomalení jen na jedné šabloně.

Praktické řešení bývá jednoduché: používat lehčí téma, omezit builder jen na nutné stránky, vypnout nepoužívané moduly a odstranit efekty, které nepřinášejí konverzi. V mnoha projektech stačí výměna přetíženého tématu za minimalistické řešení a web začne fungovat citelně rychleji bez zásahu do obsahu.

3. Pluginy, které dělají víc škody než užitku

WordPress je populární právě díky pluginům, ale každá další instalace je potenciální riziko pro výkon. Neplatí přitom jednoduché pravidlo, že „čím víc pluginů, tím pomalejší web“. Rozhoduje kvalita kódu, způsob načítání a duplicita funkcí. Jeden špatně napsaný plugin může zpomalit web víc než deset dobře optimalizovaných.

Nejvíc problémů obvykle způsobují pluginy na:

  • tvorbu formulářů s těžkým JS,
  • galerie a slider moduly,
  • statistiky a heatmapy,
  • bezpečnostní skenery běžící na každém requestu,
  • page builder add-ony a balíčky s „desítkami funkcí v jednom“.

Užitečný postup je audit pluginů po třech krocích: zkontrolovat, zda je plugin opravdu aktivně používaný, ověřit jeho dopad přes Query Monitor a porovnat, zda stejnou funkci neumí řešit jádro WordPressu nebo lehčí alternativa. V praxi se často najdou tři pluginy, které dělají totéž. Po jejich redukci klesne počet HTTP požadavků i zátěž databáze.

Pokud web používá WooCommerce, vyplatí se hlídat zejména doplňky pro filtraci produktů, dynamické ceny a personalizaci. Tyto nástroje bývají užitečné obchodně, ale bez limitů mohou zpomalit katalog i košík.

4. Obrázky bez komprese a moderních formátů

Obrázky patří mezi nejčastější důvody špatného skóre Core Web Vitals. V redakční praxi je stále běžné, že se na web nahrávají fotografie o velikosti 4–8 MB, přestože na stránce jsou zobrazené jen v náhledu. To je zbytečná zátěž pro mobilní připojení i pro server.

Největší problém nebývá jen samotná velikost, ale i to, že WordPress bez správného nastavení nenačítá efektivně formáty WebP nebo AVIF. Pokud je navíc zapnuté lazy loading bez rozmyslu, může dojít k paradoxu: některé důležité vizuály se načítají pozdě a zhoršují LCP.

Doporučený postup:

  • nahrávat obrázky už předem zmenšené na reálný rozměr,
  • komprimovat je před uploadem nebo pomocí pluginu,
  • používat WebP/AVIF tam, kde to prohlížeče podporují,
  • nastavit správné rozměry width a height, aby se minimalizoval CLS,
  • lazy loading vypnout u hlavního hero obrázku nad přehybem.

Pro kontrolu se hodí Squoosh, ShortPixel, Imagify nebo TinyPNG. V dobře nastaveném webu by hlavní obrázek neměl být zbytečně větší než několik stovek kilobajtů. U běžného obsahu často platí, že úspora 70–90 % oproti původní fotce není problém.

5. Databáze plná balastu

WordPress databáze se časem zanáší revizemi, transienty, dočasnými záznamy, spam komentáři a stopami po odinstalovaných pluginech. U menších webů to nemusí být kritické hned, ale po roce až dvou je rozdíl znatelný. Pomalejší dotazy znamenají delší generování stránky a vyšší zátěž serveru.

Typická situace: web má několik stovek článků, ale databáze je několikanásobně větší, protože obsahuje tisíce revizí a dočasných dat. Pak i jednoduchá administrace začne reagovat pomaleji. U e-shopu je navíc problém u produktových filtrů, objednávek a session dat.

Co má smysl pravidelně čistit:

  • staré revize příspěvků,
  • automatické koncepty,
  • expirující transienty,
  • spam a koš v komentářích,
  • zbytky po neaktivních pluginech.

Pro údržbu lze použít WP-Optimize nebo ruční zásah přes databázový nástroj, pokud je k dispozici zkušený správce. Pozor ale na agresivní čištění: některé transienty a tabulky používají pluginy funkčně, takže se vyplatí předem udělat zálohu. U větších webů má smysl sledovat i pomalé SQL dotazy pomocí Query Monitor nebo logů na serveru.

6. Pomalé skripty třetích stran a reklamní kód

Web často nezpomaluje jen to, co běží přímo na WordPressu. Velkou část problémů způsobují externí skripty: měřicí kódy, chat widgety, reklamní sítě, remarketing, mapy, sociální embed prvky nebo video přehrávače. Každý z nich přidává další požadavky a může blokovat vykreslení stránky.

V analýzách výkonu se to projeví jako vysoký počet third-party requests. U některých webů tvoří externí skripty většinu načítaných dat. To je problém zejména na mobilu, kde uživatel čeká déle a zároveň má slabší připojení. Google navíc hodnotí interaktivitu a stabilitu rozhraní, takže přetížený web hůř obstojí i v SEO.

Praktická opatření:

  • načítat externí skripty asynchronně nebo odloženě,
  • ponechat jen opravdu nutné nástroje,
  • omezit počet marketingových pixelů,
  • u mapy nebo videa použít náhled a načíst je až po kliknutí,
  • kontrolovat, zda se stejná měření nespouštějí duplicitně přes plugin i přes Google Tag Manager.

U firemních webů bývá častý paradox: přidává se každý nový marketingový nástroj, ale nikdo neřeší jeho dopad na rychlost. Výsledkem je stránka, která sice měří vše, ale prodává hůř, protože se načítá pomalu.

7. Chybějící cache a špatně nastavené ukládání do paměti

Poslední velká brzda je absence cache nebo její chybné nastavení. Bez cache musí WordPress při každé návštěvě znovu skládat stránku, i když se její obsah často nemění. To je zbytečná práce pro server i databázi. Správně nastavená cache přitom dokáže zkrátit načítání z několika sekund na zlomek času.

Rozlišují se hlavně tři úrovně: cache stránky, objektová cache a prohlížečová cache. Každá řeší jiný problém. U obsahu, který se mění zřídka, je nejdůležitější stránková cache. U dynamických webů a WooCommerce pak pomáhá i objektová cache, například přes Redis nebo Memcached.

Co zkontrolovat jako první:

  • jestli je cache plugin vůbec aktivní a správně vyladěný,
  • zda se necacheují stránky, které se nemají ukládat, například košík nebo účet,
  • jestli server podporuje moderní cache vrstvy,
  • zda se hlavičky cache skutečně posílají do prohlížeče.

Mezi běžné nástroje patří WP Rocket, LiteSpeed Cache nebo serverová cache na úrovni hostingu. Pokud je web na správné technologii a cache funguje dobře, rozdíl je měřitelný okamžitě. U některých webů se počet serverových dotazů sníží o desítky procent a výkon se zlepší i bez dalších zásahů.

WordPress zpomaluje nejčastěji v kombinaci více drobných chyb, ne jedním jediným problémem. Kdo začne hostingu, šablonou, pluginy, obrázky, databází, externími skripty a cache v tomto pořadí, obvykle najde největší úspory rychleji než při nahodilém „ladění výkonu“.