Proč WordPress zpomaluje právě sám sebe
WordPress jako systém není ze své podstaty pomalý. Problém vzniká ve chvíli, kdy se na sebe navrství šablona, desítky pluginů, externí služby a mizerně nastavený hosting. Výsledek pak vypadá typicky: homepage se načítá 4 až 8 sekund, administrace reaguje pomalu a Core Web Vitals ukazují vysoký LCP i INP.
Podle praxe u běžných firemních webů bývá největší problém v tom, že výkon nikdo neměří systematicky. Lidé řeší „pocitovou rychlost“, ale nevidí, že třeba jen jeden slider, chat widget nebo font z externího zdroje přidává 300–800 ms k načítání a blokuje vykreslení stránky. A v SEO je to znát: horší rychlost znamená slabší UX, nižší engagement a často i horší konverze.
Nejčastější viník: šablona, která dělá moc práce za vás
Velká část problémů začíná u šablony. Moderní prémiové WordPress šablony často nabízejí desítky funkcí, které vypadají skvěle v demu, ale v reálném provozu generují zbytečný JavaScript, CSS a databázové dotazy. Typický scénář: téma načítá 2–4 MB dat, několik knihoven pro animace a builder, i když web ve skutečnosti potřebuje jen jednoduchý obsahový layout.
Co si pohlídat:
- Počet a velikost CSS/JS souborů – ideálně minimální počet, ne desítky malých souborů bez důvodu.
- Page builder – pokud je web postavený na těžkém builderu, často přidává nadbytečný markup i skripty.
- Fonty a ikony – externí Google Fonts nebo celé knihovny ikon mohou zpomalovat první vykreslení.
- Animace a efekty – parallax, slider, video backgroundy a efekty na scroll bývají drahé hlavně na mobilu.
Praktický test: otevřete web v PageSpeed Insights a sledujte sekci „Eliminate render-blocking resources“ a „Reduce unused JavaScript“. Pokud je zde šablona nebo její knihovna opakovaně uváděná jako problém, máte jasného kandidáta na optimalizaci. U projektů, kde se přešlo z těžké multipurpose šablony na lehčí custom theme, není výjimkou pokles LCP o 1 až 2 sekundy.
Pluginy nejsou problém samy o sobě. Problém je jejich skladba
Často se říká, že „moc pluginů zpomaluje WordPress“. To je zjednodušení. Dva weby s 25 pluginy mohou mít úplně jiný výkon podle toho, co ty pluginy dělají. Jeden plugin na SEO nebo cache bývá zanedbatelný. Naopak jediný plugin, který načítá externí API, obsluhuje formuláře, statistikou trackuje každou návštěvu a přidává vlastní skripty do hlavičky, může být výkonově horší než deset drobných utilit.
Největší viníci bývají:
- Page builder addony – přidávají další vrstvy CSS a JS.
- Pluginy na statistiky a heatmapy – pokud se používají současně s GA4, GTM a dalšími měřiči, přetěžují frontend.
- Bezpečnostní pluginy s agresivním skenováním – zvyšují zátěž serveru, hlavně na shared hostingu.
- WooCommerce doplňky – filtry, cross-sell, mini-cart, live search a dynamické ceny často generují náročné dotazy do databáze.
Doporučený postup je jednoduchý: vezměte Query Monitor, sledujte pomalé dotazy, hooks a HTTP požadavky. Pokud plugin generuje opakovaně pomalé dotazy nebo volá externí služby při každém načtení stránky, je kandidátem na výměnu nebo vypnutí na úrovni konkrétních šablon. U větších webů se vyplatí test „plugin-by-plugin“: vypnout, změřit, porovnat.
Hosting, databáze a cache: když web brzdí infrastruktura
I perfektně nastavený WordPress bude pomalý na slabém hostingu. Pokud běží na přetíženém sdíleném serveru, kde je limitovaný CPU a paměť, projeví se to hlavně při vyšší návštěvnosti nebo v administraci. V praxi je rozdíl mezi levným hostingem a kvalitním managed WordPress hostingem často vidět na TTFB, které může klesnout například z 800–1200 ms na 150–300 ms.
Za pozornost stojí tři oblasti:
- PHP verze – PHP 8.1 a 8.2 bývá výrazně svižnější než starší verze; pokud web běží na 7.4, je to častý brzdič.
- Objektová cache – u větších webů pomůže Redis nebo Memcached, zejména při častých databázových dotazech.
- Page cache – bez ní WordPress při každé návštěvě generuje stránku znovu, což je zbytečné u statického obsahu.
Pro měření použijte GTmetrix, WebPageTest a Chrome DevTools. Sledujte TTFB, počet requestů a velikost přenesených dat. Pokud homepage posílá 4–6 MB dat a má přes 100 requestů, problém není „jen v hostingu“, ale v kombinaci obrázků, skriptů a neefektivní cache. V ideálním stavu by běžný firemní web měl mít homepage výrazně pod 2 MB a počet requestů držet rozumně nízko, zvlášť na mobilu.
Skryté brzdy: obrázky, externí skripty a zbytečný obsah v každé stránce
Velmi častý důvod zpomalení není vidět na první pohled. Je to obsah, který se načítá všude, i když je potřeba jen na jedné stránce. Typicky jde o chat widget, mapu, recenze, embed z Instagramu, video z YouTube nebo remarketingové skripty. Každý takový prvek přidává další DNS lookup, TLS handshake nebo blokující skript.
Obrázky jsou samostatná kapitola. Web může mít skvěle napsaný kód, ale pokud používá hero obrázek o velikosti 3 MB, je po výkonu. Praktické minimum:
- používat WebP nebo AVIF,
- připravovat správné rozměry pro mobil i desktop,
- zapnout lazy loading pro obrázky pod ohybem,
- u hlavního nadpisového obrázku naopak hlídat preload, pokud je součástí LCP.
Externí prvky je vhodné načítat podmíněně. Například mapu zobrazit až po kliknutí, chat až po určitém čase nebo po scrollu a videa nahradit náhledem s tlačítkem. Tím se dá reálně ušetřit několik stovek kilobajtů i desítky milisekund hlavního threadu. U content-heavy webů je to často rozdíl mezi „použitelným“ a „rychlým“ webem.
Jak najít skutečného viníka a co udělat jako první
Největší chyba je začít slepým čištěním pluginů. Lepší je jít postupně a měřit. Doporučený workflow vypadá takto:
- 1. Změřte výchozí stav – PageSpeed Insights, WebPageTest, Search Console, případně Lighthouse.
- 2. Zjistěte, co blokuje vykreslení – CSS, JS, fonty, externí skripty.
- 3. Zkontrolujte databázi a dotazy – Query Monitor, zpomalující pluginy, transients.
- 4. Otestujte cache – page cache, browser cache, object cache.
- 5. Zredukujte zátěž na homepage i šablonách – ne vše musí být všude.
Pokud chcete rychlý efekt, začněte těmito kroky v tomto pořadí: aktualizace na moderní PHP, zapnutí cache, komprese a optimalizace obrázků, vypnutí zbytečných skriptů na jednotlivých stránkách, kontrola těžkých pluginů a teprve potom úprava šablony. U řady webů to přinese zlepšení Core Web Vitals během několika hodin až dnů, ne týdnů.
WordPress si web nezpomaluje „sám od sebe“ náhodou. Většinou je to součet malých rozhodnutí, která se časem nasčítají: těžká šablona, několik přebytečných pluginů, slabý hosting, bezhlavě přidané skripty a chybějící cache. Jakmile ale změříte konkrétní brzdy a odstraníte je systematicky, WordPress umí být velmi rychlý i na náročnějším webu.