WordPress může být pomalý i při nízké návštěvnosti. Důvodem nemusí být „slabý server“: každý požadavek může spouštět PHP, databázi a několik pluginů, zatímco velké obrázky prodlužují načítání v telefonu. Nejdřív zjistěte, kde vzniká prodleva. Cache pomáhá hlavně tam, kde návštěvníci opakovaně čtou stejný obsah, ale špatné nastavení může ukazovat starý článek nebo cizí přihlášený obsah.
Jak poznat, co je pomalé
Otestujte víc než úvodní stránku: nový článek, starší článek s obrázky, archiv rubriky a případně vyhledávání. Porovnejte mobil a desktop. PageSpeed Insights ukazuje laboratorní diagnostiku i údaje skutečných uživatelů, pokud jsou dostupné; tyto dvě části mají jiný účel. Jediné laboratorní skóre není měření celého webu ani důkaz, že server potřebuje dražší tarif.
| Příznak | První podezření | Co ověřit |
|---|---|---|
| Dlouho se čeká na první odpověď | PHP, databáze, hosting, chybějící page cache | TTFB více typů stránek, logy a vytížení |
| Stránka se vykresluje dlouho po odpovědi | Velké obrázky, skripty, fonty | Objem přenosu a blokující soubory |
| Pomalá jen administrace | Pluginy, databáze, plánované úlohy | Konkrétní akce v administraci a logy |
| Výpadky při automatické publikaci | Současné požadavky, cron, PHP procesy | Čas zátěže a chybové odpovědi API |
| Problém po nasazení cache | Špatné vyloučení dynamických stránek | Přihlášený a anonymní pohled |
Zaznamenejte výchozí stav: konkrétní URL, datum, mobilní či desktopový test, odezvu serveru a přenesená data. Pak měňte jednu věc po druhé. Pokud zároveň změníte hosting, šablonu, CDN a tři pluginy, nezjistíte, co pomohlo a co zhoršilo funkčnost.
Čtyři různé vrstvy cache
Page cache ukládá hotové HTML stránky pro anonymní návštěvníky. Server tak nemusí pro každé zobrazení znovu spouštět celý WordPress. Object cache drží opakovaně potřebná data a dotazy, často v Redis či podobné službě. Cache prohlížeče dovoluje návštěvníkovi znovu použít statické soubory. CDN může přiblížit obrázky a další soubory návštěvníkům a někdy drží i celé HTML. Tyto vrstvy mají různé účely a různá pravidla mazání.
| Typ cache | Co zrychluje | Typická podmínka nebo riziko |
|---|---|---|
| Page cache | Opakované čtení veřejných stránek | Vyloučit přihlášené a personalizované odpovědi |
| Object cache | Opakované výpočty a databázové dotazy | Vyžaduje podporu hostingu; měřit přínos |
| Cache prohlížeče | Opakované načítání obrázků, CSS a JS | Správná délka a verze souborů |
| CDN | Doručení statických souborů, někdy HTML | Správné čištění po publikaci a pravidla přístupu |
Pokud hosting už nabízí serverovou page cache, neinstalujte automaticky druhé řešení bez znalosti vzájemného chování. Dvě vrstvy mohou fungovat dobře, ale musíte vědět, která vrací starý obsah a jak ji vyčistit. Cache není záloha: obsah v ní může být kdykoli smazán a znovu vytvořen.
Praktické nastavení pro obsahový magazín
- Ověřte u hostingu, zda běží serverová page cache a které stránky z ní vylučuje.
- Na testovacím webu zapněte jednu jasně spravovanou page cache pro anonymní články a rubriky.
- Vylučte administraci, přihlášené uživatele, náhledy a personalizované stránky. U e-shopu i košík a pokladnu.
- Publikujte testovací článek, upravte jej a ověřte, že se změna zobrazí veřejně bez ručního čekání.
- Ověřte formuláře, vyhledávání a komentáře. Následně porovnejte odezvu před a po změně.
U webu, kde se články tvoří přes REST API, je zásadní čištění cache po API publikaci. Některé kombinace pluginu, serverové cache a CDN aktualizují homepage až se zpožděním. Testujte skutečný způsob publikování, který používáte; ručně napsaný článek v administraci nemusí odhalit stejnou chybu. Při síti mnoha magazínů otestujte společnou konfiguraci na jednom webu a pak zavádějte po skupinách.
Obrázky často přinesou víc než další plugin
Pro hlavní fotografii nepoužívejte zbytečně obrovský originál. Připravte vhodné rozměry, moderní formát a rozumnou kompresi; zachovejte poměr stran. WordPress vytváří varianty, ale šablona musí pro dané místo vybrat odpovídající velikost. Zkontrolujte, zda telefon nestahuje několikamegabajtový soubor určený pro velkou obrazovku. Lazy loading pomůže u obrázků níže na stránce; obrázek hned v horní viditelné části naopak potřebuje načíst včas.
Podívejte se také na externí reklamy, měření a vložené prvky. Skript třetí strany může brzdit interakci i tehdy, když server odpovídá rychle. Každou optimalizaci poměřte s účelem: odstranění důležitého analytického nebo obchodního prvku jen kvůli skóre nemusí dávat smysl.
Kdy řešit hosting, PHP a databázi
Jestli je pomalá i stránka s malým objemem dat a správně nastavenou cache, sledujte limity CPU, paměti, PHP procesů, diskového I/O a databáze. Sdílený hosting může být vhodný pro malý web, ale desítky instalací a současné úlohy vytvářejí jinou zátěž než jedna doména. Žádejte od poskytovatele konkrétní údaj o překročeném limitu a čas události, ne pouze obecnou informaci „web přetěžuje server“. Při úvaze o změně tarifu porovnejte limity webhostingů pro jeden web, nejen cenu za první rok.
Aktuální PHP a OPcache mohou výkonu pomoci, změnu však proveďte podle aktualizačního postupu. Persistentní object cache dává smysl, pokud hosting poskytuje odpovídající službu a měření ukazuje opakované drahé dotazy. Nepřidávejte Redis jen proto, že ho doporučuje obecný seznam optimalizací. U vlastní databáze sledujte pomalé dotazy, velikost tabulek a pluginy ukládající velké množství do nastavení.
Jak hledat drahý plugin a pomalý dotaz
Pokud je po zapnutí cache veřejný článek rychlý, ale administrace stále pomalá, zaměřte se na práci, kterou cache neobchází. Zkontrolujte PHP chybové logy, pomalé databázové dotazy a změny po instalaci pluginu. Diagnostický plugin nebo serverový profiler může ukázat náročné dotazy a funkce, ale používání takových nástrojů samo vytváří zátěž. Na živém webu je zapínejte krátce a s vědomím hostingu; výsledek si zaznamenejte.
Deaktivace pluginu jako test může přerušit formulář, reklamu nebo měření. Na produkci proto nejprve použijte staging, pokud je dostupný. Porovnejte čas stejné akce před a po vypnutí, ne jen subjektivní pocit. Jestli plugin potřebujete, hledejte jeho nastavení, aktualizaci nebo náhradu. U pomalé databáze zkoumejte také automaticky načítané položky a expirované přechodné záznamy; hromadné mazání tabulek bez zálohy a znalosti dopadů není vhodná optimalizace.
Jak nezkazit výkon při přidávání dalších webů
Čtyřicet samostatných WordPressů neznamená čtyřicet stejných zátěží. Jeden obrázkový magazín může využívat hlavně disk a přenos, jiný může mít náročné importy přes API a třetí časté cron úlohy. Sepište pro každý web průměrnou návštěvnost, velikost souborů a databáze, frekvenci publikace a největší pravidelné úlohy. Zátěž pak posuzujte v čase: pokud všechny weby publikují nebo zálohují ve stejnou minutu, mohou narazit na limit současných procesů i při nízké celkové návštěvnosti. U většího počtu instalací ověřte také podmínky společného multihostingu a sdílení prostředků mezi weby.
Pomoci může rozložit plánované úlohy, správně nastavit cache a oddělit externí zálohování od publikačních špiček. Nejde o důkaz, že levný hosting postačí navždy; získáte však konkrétní podklady pro jednání s poskytovatelem. Při přesunu na jiný tarif srovnejte rezervu kapacity, podporu více databází a domén, pravidla záloh a cenu správy. Výkon posuzujte na vlastních typických stránkách a postupech, ne pouze podle deklarovaného počtu webů.
Jak poznat, že zásah pomohl
- Porovnejte stejné stránky a stejný způsob testu před i po změně.
- Sledujte nejen rychlost, ale i chybové stavy, publikační zpoždění a funkci formulářů.
- Ověřte nový článek ihned po publikaci a po následné opravě.
- Na telefonu zkontrolujte obrázky, menu a případné vizuální posuny.
- Vraťte změnu, která zrychlí skóre, ale rozbije důležitou funkci.
Pro dlouhodobý přehled spojte měření rychlosti s monitoringem výpadků. Jednorázový rychlostní test nezachytí špičku při hromadném vydání článků ani noční selhání plánované úlohy.
Modelová diagnostika pomalého magazínu
Představte si magazín s nízkou návštěvností, který má přesto občas chybu 503. Veřejný článek se při opakovaném načtení otevře rychle, ale přes REST API se ve stejnou hodinu nahrávají fotografie, vytváří několik článků a běží úplná záloha. První závěr by neměl být „všechno přestěhovat“. Zapište přesné časy požadavků a chyb, zeptejte se hostingu na PHP procesy a I/O v daném okně a ověřte délku zálohovací úlohy.
Pak zkuste rozložit neurgentní úlohy a snížit velikost nahrávaných obrázků. Zachovejte pořadí: změnit jednu věc, sledovat chyby v podobném provozním dni, zaznamenat výsledek. Pokud limity zůstávají vyčerpány i po úpravě, máte věcný podklad pro vyšší tarif nebo samostatné prostředí. Pokud chyba zmizí, ušetřili jste stěhování, ale dál sledujte rezervu kapacity. Jde o modelový příklad, nikoli o změřený výkon konkrétního hostingu.
Časté otázky před přidáním další optimalizace
Pomůže další cache plugin?
Nejdřív zjistěte, zda už cache neposkytuje hosting nebo CDN. Druhý plugin může přidat správu či jiný typ cache, ale také prodloužit cestu k odstranění starého obsahu. Přínos posuďte měřením stejné stránky a kontrolou po publikaci.
Je vždy lepší CDN?
CDN může zrychlit doručování obrázků a odlehčit serveru, zvlášť při geograficky rozptýlené návštěvnosti. U lokálního malého webu se přínos může lišit. Po nasazení ověřte správné URL médií, HTTPS, cache pravidla a cenu přenosu.
Co když je pomalý jen editor?
Page cache editor nezrychlí, protože přihlášené stránky se běžně negenerují z veřejné cache. Zaměřte se na náročné pluginy, databázi, serverové limity a chyby v logu. Změřte konkrétní akci, například otevření editoru dlouhého článku.
Má cenu honit skóre 100?
Ne jako samostatný cíl. Sledujte zkušenost skutečných návštěvníků, funkci stránek a stabilitu. Menší laboratorní rozdíl může být méně důležitý než oprava velkého obrázku nebo výpadku během publikace.
