Cache je jen poslední vrstva, ne lék na pomalý web
U WordPressu se často opakuje stejný scénář: web je pomalý, takže se nainstaluje cache plugin, zapne se minifikace a očekává se zázrak. Jenže cache řeší hlavně opakované načítání už hotové stránky nebo části obsahu. Nezrychlí ale to, co se děje předtím: výpočet na serveru, nadměrný počet dotazů do databáze, těžký frontend, render-blocking skripty nebo přetížené externí služby.
V praxi to znamená, že cache dokáže zkrátit TTFB nebo serverovou odezvu, ale pokud má stránka 4 MB obrázků, 20 JS souborů a 80 pluginem generovaných dotazů, výsledná rychlost zůstane slabá. U Core Web Vitals se to projeví hlavně na LCP a INP, tedy na rychlosti zobrazení hlavního obsahu a interaktivitě. Google navíc vyhodnocuje výkon v reálných podmínkách, ne jen na lokálním testu s aktivní cache.
Největší brzdy: šablona, builder a přebytečné pluginy
Nejčastější příčinou pomalého WordPressu není hosting, ale přetížená šablona. Mnoho multipurpose theme načítá desítky funkcí, knihoven a stylů pro všechny možné scénáře, i když web využívá jen zlomek z nich. Typický rozdíl je vidět na počtu requestů a velikosti CSS/JS. Jednodušší, dobře napsaná šablona může mít při stejné funkčnosti o 30–60 % menší front-endovou zátěž než „all-in-one“ téma.
Velký problém bývají také page buildery. Elementor, WPBakery nebo Divi nejsou samy o sobě špatné, ale při nevhodné konfiguraci generují zbytečně hluboké DOM struktury, nadbytečné wrappery a mnoho inline stylů. To zpomaluje renderování a zhoršuje INP. Pokud máte na jedné stránce 2 000+ DOM elementů, browser už musí pracovat výrazně víc. Pro rychlejší web bývá výhodnější kombinace lehké šablony, blokového editoru Gutenberg a jen několika cílených rozšíření.
Další klasika jsou pluginy. Nejde jen o počet, ale o kvalitu a překryv funkcí. Často se stává, že jeden plugin řeší cache, druhý minifikaci, třetí lazy load, čtvrtý SEO schema, pátý bezpečnost a šestý optimalizaci obrázků — a každý z nich přidává vlastní skripty, administrativní zátěž nebo cron úlohy. Na auditovaných webech není výjimkou, že 10–15 pluginů je v pohodě, zatímco 25–40 pluginů už často znamená konflikty, duplicitní funkce a pomalejší backend.
Praktický postup je jednoduchý:
- deaktivujte pluginy, které nepřinášejí měřitelnou hodnotu;
- nahraďte více pluginů jedním kvalitním řešením;
- zkontrolujte, zda plugin nenačítá skripty na všech stránkách zbytečně;
- u komerčních pluginů sledujte, zda nevolají externí API při každém načtení;
- projděte administraci přes Query Monitor a hledejte pomalé hooky a dotazy.
Obrázky, fonty a skripty: nejčastější problém na frontendu
Na řadě WordPress webů je problém vidět hned v Lighthouse nebo PageSpeed Insights: hlavní obsah se zobrazí pozdě, protože stránku blokují obrázky, fonty a JavaScript. Z praxe vychází, že největší dopad na LCP mívá hero obrázek nebo slider, ne cache. Pokud má úvodní vizuál 800 kB až 2 MB, je to pro mobilní síť a slabší zařízení zásadní problém.
Co funguje nejlépe:
- používat WebP nebo AVIF místo JPEG/PNG, ideálně s responzivními velikostmi;
- nastavit správné rozměry obrázků, aby se nenačítaly větší než je potřeba;
- u obrázků pod foldem používat lazy load, ale ne u hlavního vizuálu;
- komprimovat hero media tak, aby mělo rozumnou velikost, ideálně pod 200–300 kB, pokud to vizuál dovolí;
- omezit sliderové pluginy, které načítají několik variant obrázků a skriptů najednou.
Stejně důležité jsou fonty. Pokud web používá 3 rodiny písma, každou ve 4 řezech, může to znamenat 12 souborů a další blokování renderu. Lepší je držet se jedné až dvou rodin, využít font-display: swap a ideálně self-hosting místo načítání z externích CDN, pokud to dává smysl z pohledu GDPR i výkonu.
JavaScript je další častý viník. Mnoho webů načítá analytiku, chat widget, heatmapy, cookie lištu, recenze, mapy, social embed a remarketing už na úvodní stránce. Každý z těchto prvků přidává síťové požadavky a může blokovat interakci. V GTmetrix nebo WebPageTest sledujte waterfall a hledejte skripty s vysokým blokujícím časem. U WordPressu často pomůže odložit načítání skriptů, přesunout je do footeru nebo je podmíněně spouštět jen tam, kde jsou skutečně potřeba.
Databáze, wp-cron a administrace: pomalý web nezačíná jen v prohlížeči
WordPress je dynamický systém a bez dobré databáze se časem zpomalí i web, který má na frontendu rozumný kód. Typické problémy jsou revize příspěvků, transienty, spam komentáře, dočasná data pluginů a zbytečně velké tabulky v wp_options. U některých webů bývá právě autoloaded options tak objemný, že zpomaluje každé načtení stránky.
Pro audit je velmi užitečný plugin Query Monitor, který ukáže počet dotazů, pomalé SQL query, HTTP requesty i problémy s hooky. Pokud stránka generuje třeba 150 dotazů místo 30–40, je to jasný signál, že něco není v pořádku. Často pomůže:
- vyčistit revize a transienty;
- omezit počet automatických revizí;
- zkrátit nebo optimalizovat autoload data;
- použít kvalitní objektovou cache, například Redis, pokud je web datově náročný;
- vypnout nebo nahradit pluginy, které generují zbytečné dotazy na každé zobrazení.
Podceňovaný problém je také wp-cron. WordPress nespouští úlohy jako klasický systémový cron, ale často je kontroluje při návštěvě webu. Na vytížených webech to může přidávat zbytečnou zátěž, naopak na méně navštěvovaných webech se úlohy zpožďují. Lepší praxe je vypnout interní wp-cron a nahradit ho skutečným serverovým cronem, který spouští plánované úlohy pravidelně a bez závislosti na návštěvnosti.
Externí služby, hosting a technické limity, které cache neschová
I perfektně optimalizovaný WordPress může být pomalý, pokud je špatně nastavený hosting nebo je web závislý na externích službách. Sdílený hosting s přetíženým CPU, pomalým diskem nebo omezeným PHP workers často způsobí, že se stránka načítá nevyrovnaně. V praxi je rozdíl mezi levným sdíleným hostingem a kvalitním managed WordPress hostingem klidně stovky milisekund až několik sekund na TTFB, hlavně při zátěži.
Hlídejte zejména:
- PHP verzi – moderní PHP 8.1/8.2 bývá znatelně rychlejší než starší verze;
- OPcache – bez něj zbytečně kompilujete PHP při každém requestu;
- serverový stack – LiteSpeed, Nginx nebo dobře nakonfigurovaný Apache mají velký vliv na odezvu;
- limity hostingu – počet procesů, memory limit, I/O, CPU throttling;
- externí API – mapy, recenze, platební brány, chaty, tracking a embed obsahy.
Častý příklad z praxe: web má skvělou cache, ale na homepage načítá 8 externích skriptů, které se tahají z různých domén. Jen DNS lookup, TLS handshake a síťová latence mohou přidat několik set milisekund. Pokud navíc některý z těchto skriptů selže nebo je pomalý, zdržuje i vykreslení hlavního obsahu. Proto je dobré externí prvky načítat asynchronně, minimalizovat jejich počet a kritické funkce hostovat co nejblíže vlastnímu serveru.
Jak poznat skutečný problém a neoptimalizovat naslepo
Pokud chcete web zrychlit efektivně, měřte vždy konkrétní vrstvu problému. Cache plugin je až poslední krok, ne výchozí řešení. Nejprve si v PageSpeed Insights a Lighthouse ověřte, co brzdí LCP, INP a CLS. Pak použijte WebPageTest pro detailní waterfall, Query Monitor pro backend a Search Console pro sledování reálných CWV dat z uživatelů.
Dobrá pracovní metodika vypadá takto:
- změřit stav před změnou;
- identifikovat největší bottleneck: obrázky, JS, pluginy, databáze, hosting;
- provést jednu změnu po druhé;
- znovu změřit dopad;
- teprve potom ladit cache, minifikaci a preloady.
Největší posun obvykle přináší kombinace několika relativně malých zásahů: odlehčení šablony, redukce pluginů, optimalizace obrázků, lepší práce s fonty, čistší databáze a kvalitnější hosting. Cache pak funguje jako násobič už dobře nastaveného systému. Když je ale web od začátku těžký, cache jen zamaskuje problém pro část návštěvníků a při první zátěži nebo na mobilu se vše vrátí zpět.
