Proč se WordPress weby nejčastěji zpomalují a jak to opravit

Proč WordPress zpomaluje: problém bývá v ekosystému, ne v jádru

WordPress sám o sobě není pomalý systém. Naopak: při rozumné konfiguraci umí být velmi svižný, škálovatelný a dobře optimalizovatelný pro SEO i výkon. Zpomalení většinou vzniká až v praxi, když se na web naskládá příliš mnoho pluginů, těžká grafická šablona, nekvalitní hosting nebo neoptimalizovaný obsah. V běžné praxi je rozdíl mezi „rychlým“ a „pomalým“ WordPressem často 2 až 5 sekund v načítání, což je zásadní pro konverze i Core Web Vitals.

Google dlouhodobě pracuje s metrikami jako LCP, INP a CLS. Pokud je například hlavní obsah stránky viditelný až po 3,5 sekundách, uživatelé i vyhledávače to vnímají jako slabý signál kvality. U e-shopů nebo leadgen webů přitom i zrychlení o 1 sekundu často znamená měřitelný nárůst konverzí. Proto má smysl řešit výkon systematicky, ne jen „přidat cache plugin“.

1. Těžká šablona a přebujelý frontend

Nejčastější brzda WordPress webů je vizuálně atraktivní, ale technicky těžká šablona. Mnoho moderních builderů a multipurpose theme balí do jedné instalace desítky funkcí, animací, ikon fontů, sliderů a skriptů, které web vůbec nepotřebuje. Výsledkem je vysoký počet HTTP požadavků, velký objem CSS/JS a špatné metriky v PageSpeed Insights.

Typický příklad: homepage s 12 MB dat, 180 požadavky a několika externími skripty může na desktopu působit „v pohodě“, ale na mobilu s pomalejším připojením začne být problém. Z hlediska SEO je to zásadní, protože Google dnes hodnotí mobilní verzi jako primární.

• Ověřte velikost stránky v nástroji WebPageTest nebo Lighthouse.
• Zkontrolujte počet požadavků – ideálně držet co nejníže, zejména na homepage.
• Odstraňte nevyužité CSS a JS pomocí nástrojů typu Perfmatters nebo Asset CleanUp.
• Zvažte lehkou šablonu jako GeneratePress, Astra nebo block-based přístup s Gutenbergem.

Prakticky: pokud máte web postavený na builderu a načítá se přes 30 externích skriptů, často je levnější a efektivnější redesign než nekonečné „lepení“ optimalizací. U menších webů bývá přechod na lehčí theme nejrychlejší cesta ke zkrácení LCP o stovky milisekund až jednotky sekund.

2. Pluginy: největší zdroj technického dluhu

Pluginy jsou síla WordPressu, ale zároveň jeho nejčastější slabina. Každý plugin přidává vlastní PHP logiku, databázové dotazy, skripty nebo styly. Problém není počet jako takový, ale jejich kvalita, překryv funkcí a dopad na frontend i backend. V praxi bývá běžné, že 2–3 pluginy dělají stejnou věc, například cache, optimalizaci obrázků nebo formuláře.

Na pomalejším webu se vyplatí udělat audit pluginů podle skutečného přínosu. Zvlášť pozor si dejte na pluginy, které:

• načítají skripty na každé stránce, i když jsou potřeba jen na jedné,
• posílají množství externích requestů,
• přidávají vlastní databázové tabulky a cron úlohy,
• jsou dlouhodobě neaktualizované nebo konfliktní s novější verzí PHP.

Pro diagnostiku použijte Query Monitor, který ukáže pomalé dotazy, hooky a PHP chyby. Pokud zjistíte, že jeden plugin přidává 200–300 ms na každé načtení stránky, je to jasný kandidát na náhradu. U WooCommerce webů bývá častým problémem i kombinace marketingových pluginů, page builderu a sledovacích skriptů, které dramaticky zvyšují INP.

3. Hosting, cache a databáze: technický základ výkonu

I perfektně postavený web bude pomalý na nekvalitním hostingu. WordPress je náročný hlavně na správnou kombinaci PHP verze, serverové cache, databáze a diskové odezvy. Pokud běží na sdíleném hostingu s přetíženým CPU a bez objektové cache, výkon se bude zhoršovat zejména při návštěvnosti nebo při administraci.

Pro běžný firemní web doporučuji minimálně hosting s PHP 8.2+, podporou OPcache, HTTP/2 nebo HTTP/3, serverovou cache a kvalitním CDN napojením. U větších webů nebo e-shopů je ideální i Redis object cache. Ta výrazně pomáhá při opakovaných dotazech do databáze a zkracuje odezvu administrace i frontendu.

Databáze bývá další skrytý problém. WordPress si časem ukládá revize, transienty, staré logy a zbytky po odstraněných pluginech. U webu s tisíci články může neoptimalizovaná databáze znamenat zbytečně pomalé dotazy, které prodlužují TTFB. Ověřte velikost tabulek, odstraňte zbytečné revize a nastavte pravidelný úklid pomocí nástrojů jako WP-Optimize nebo Advanced Database Cleaner.

• TTFB by u dobře nastaveného webu měl být ideálně pod 500 ms, u kvalitního hostingu často i výrazně níž.
• Cache musí být nastavená serverově, ne jen jako doplněk v pluginu.
• CDN pomáhá hlavně u obrázků, CSS, JS a globální návštěvnosti.

4. Obrázky, fonty a skripty třetích stran

Na mnoha webech nejsou problémem jen pluginy, ale hlavně media a externí služby. Obrázky v původní velikosti 4K, nahrané bez komprese, dokážou zpomalit načítání výrazně víc než samotný WordPress. Stejně tak webové fonty, chat widgety, heatmapy, remarketingové skripty nebo embedded videa často blokují vykreslení a zhoršují LCP i INP.

Praktické minimum pro každý WordPress web:

• Obrázky ve WebP nebo AVIF, ideálně správně dimenzované podle reálného použití.
• Lazy loading pro obsah pod přehybem, ale ne pro hlavní hero obrázek.
• Preload klíčových fontů a omezení počtu řezů fontů.
• Odložené načítání marketingových a analytických skriptů, pokud to neohrozí měření.

Častá chyba je například nahrát na web 8 řezů jednoho fontu, 3 různé ikony knihovny a k tomu video z YouTube vložené přímo v obsahu. Výsledek? Web sice vizuálně působí moderně, ale uživatel čeká příliš dlouho. V praxi se často vyplatí nahradit externí embed náhledem s kliknutím až pro skutečné přehrání. Tím lze ušetřit stovky kilobajtů až megabajty dat.

5. Jak výkon měřit a co opravit jako první

Bez měření je optimalizace jen odhad. Nejlepší postup je začít u tří nástrojů: Google PageSpeed Insights, Lighthouse a Search Console. PageSpeed ukáže Core Web Vitals a doporučení, Lighthouse pomůže s diagnostikou frontendu a Search Console ukáže, zda jsou problémy systémové na více URL. Pro hlubší analýzu použijte WebPageTest, který odhalí waterfall, TTFB i blokující skripty.

Priorita oprav by měla být vždy podle dopadu, ne podle pocitu. Typicky doporučuji tento postup:

1. Zrychlit server a cache – hosting, PHP, object cache, CDN.
2. Odlehčit šablonu – méně JS/CSS, méně builder závislostí.
3. Projít pluginy – odstranit duplicity a konflikty.
4. Optimalizovat média – obrázky, fonty, videa, iframe.
5. Čistit databázi a zjednodušit administraci.

U většiny WordPress webů lze po těchto krocích dosáhnout citelného zlepšení. Není výjimkou snížení LCP z 4–5 sekund na pod 2,5 sekundy, pokud byl problém hlavně v šabloně a médiích. A právě to je hranice, kde už web působí rychle nejen pro uživatele, ale i z pohledu SEO a konverzního výkonu.

Co dává největší smysl v praxi

Pokud máte omezený rozpočet, neoptimalizujte „všechno najednou“. Začněte tím, co má největší návratnost: hosting, cache, obrázky a odstranění zbytečných pluginů. U firemních webů často stačí několik cílených zásahů a web se zrychlí o desítky procent. U e-shopů je to ještě důležitější, protože každé zpomalení se násobí v nákupním procesu.

Největší chyba je spoléhat na jeden cache plugin jako na univerzální řešení. Výkon WordPressu je součet více vrstev: server, PHP, databáze, šablona, pluginy, média a externí služby. Jakmile některá z nich výrazně zaostává, pocítí to uživatel i vyhledávač. Proto má smysl pracovat s daty, pravidelně měřit a optimalizovat web průběžně, ne až ve chvíli, kdy začne padat organická návštěvnost nebo konverze.