1. Automatické revize a koš: skrytý balast v databázi
WordPress si při každé úpravě článku ukládá revize. To je užitečné, ale u aktivních webů se databáze rychle plní desítkami až stovkami verzí jednoho příspěvku. U menších webů to bývá jen nepořádek, u větších redakčních nebo e-commerce projektů už zbytečná zátěž pro databázové dotazy a zálohy.
Praktický dopad je jednoduchý: čím víc revizí, tím větší databáze a pomalejší práce s administrací. U webu s 2 000 články může mít rozdíl mezi neomezenými revizemi a limitem třeba 5 verzí na příspěvek klidně desítky tisíc řádků v tabulkách navíc.
Řešení je tiché, ale účinné:
- omezit počet revizí v souboru wp-config.php například na 5 až 10;
- vypnout automatické ukládání příliš často, pokud editor nepíše dlouhé texty offline;
- pravidelně čistit koš, spam komentáře a transienty.
Pro čištění databáze se hodí například WP-Optimize, Advanced Database Cleaner nebo přesně cílený zásah přes WP-CLI. Důležité je nechat si před každým zásahem zálohu, protože u některých pluginů je hranice mezi úklidem a smazáním potřebných dat tenká.
2. Heartbeat API: malý detail, který umí přetížit server
Heartbeat API je mechanismus, který WordPress používá pro průběžné ukládání rozpracovaného obsahu, kontrolu přihlášení a některé administrátorské funkce. Ve výchozím stavu posílá požadavky v pravidelných intervalech, což je v praxi pohodlné, ale na slabším hostingu nebo při více současně přihlášených editorech může zbytečně zatěžovat CPU i databázi.
Na běžném firemním webu to nemusí být vidět. Jakmile ale administrace běží na levnějším sdíleném hostingu, mohou se objevit pomalejší reakce v editoru nebo vyšší počet PHP procesů. U redakčního webu s více editory je vhodné intervaly upravit, ne ignorovat.
Doporučení v praxi:
- na administraci interval zpomalit, například z 15 sekund na 30–60 sekund;
- na frontendu Heartbeat omezit nebo vypnout, pokud není nutný;
- sledovat dopad v nástrojích typu Query Monitor nebo v logu hostingu.
Řešení lze provést přes plugin nebo úpravou funkcí v child theme. U webů s WooCommerce je potřeba opatrnost, protože některé části administrace a košíku mohou na Heartbeat nepřímo navazovat.
3. Velikost obrázků a jejich načítání: výkon se láme na detailech
Na mnoha WordPress webech není největší problém samotný kód, ale obrázky. Stačí několik fotografií v původní kvalitě z mobilu a stránka má rázem několik megabajtů. Z hlediska Core Web Vitals je to zásadní: zbytečně těžké obrázky zpomalují LCP, zvyšují CLS při špatně nastavených rozměrech a prodlužují první vykreslení obsahu.
Praktické nastavení, které má smysl hlídat:
- používat WebP nebo AVIF, kde to hosting a šablona podporují;
- neukládat do knihovny médií obrázky větší, než web skutečně potřebuje;
- nastavit správné rozměry v šabloně, aby se layout nepřeskakoval;
- zapnout lazy loading u obrázků pod foldem, ale ne u hlavního hero vizuálu;
- u produktových a článkových náhledů generovat více velikostí podle použití.
Konkrétní číslo z praxe: zmenšení hlavního banneru z 2,8 MB na 180 KB umí na mobilu zkrátit načítání o několik sekund, zvlášť na 4G síti. Nástroje jako ShortPixel, Imagify nebo Smush pomohou, ale nejlepší efekt přináší už správná práce při nahrávání obsahu.
4. Cache a minifikace: není důležité mít všechno, ale mít správně
Cache je jedno z nejčastěji zmiňovaných témat, ale v praxi se často nastaví špatně. Buď je vypnutá, nebo je naopak přehnaně agresivní a rozbije šablonu, formulář či košík. Cílem není „zapnout všechno“, ale snížit počet opakovaných výpočtů a požadavků.
Na WordPressu se vyplatí rozlišit tři vrstvy: stránkovou cache, objektovou cache a cache pro statické soubory. U běžného webu s obsahem je největší přínos stránková cache. U náročnějších projektů, zejména WooCommerce nebo webů s filtrováním obsahu, pomůže i objektová cache přes Redis nebo Memcached.
Co má smysl zkontrolovat:
- zda hosting podporuje serverovou cache na úrovni Nginx, LiteSpeed nebo Varnish;
- zda se cache neukládá i pro přihlášené uživatele, kde to škodí;
- zda se necacheují dynamické části jako košík, formuláře nebo personalizovaný obsah;
- zda minifikace CSS a JS neblokuje kritické skripty.
U pluginů jako WP Rocket, LiteSpeed Cache nebo W3 Total Cache platí jednoduché pravidlo: méně zapnutých funkcí, ale správně otestovaných. Každou změnu je vhodné ověřit v PageSpeed Insights, Lighthouse nebo přes GTmetrix.
5. XML sitemap, robots.txt a indexace: aby Google neplýtval rozpočtem
Mnoho webů má technicky správný obsah, ale špatně nastavenou indexaci. Výsledek je známý: Google prochází zbytečné URL, indexuje duplicity nebo naopak přehlíží důležité stránky. U WordPressu se to často děje kvůli archívům, tagům, parametrům a stránkám, které nemají vyhledávací hodnotu.
Dobře nastavený web má jasně říct, co má být v indexu a co ne. To je důležité nejen pro SEO, ale i pro výkon crawl budgetu. U menších webů je to méně viditelné, u rozsáhlejších projektů už zásadní.
Kontrolní body:
- v XML sitemapě nechat jen URL, které mají být skutečně indexované;
- vypnout indexaci tenkých tagů, autorů bez obsahu nebo interních archívů;
- zkontrolovat, zda robots.txt neblokuje důležité CSS, JS nebo obrázky;
- v Search Console sledovat hlášky o vyloučených stránkách a duplicitách.
U většiny webů pomůže jednoduchý audit v Google Search Console a export URL z pluginu jako Yoast SEO nebo Rank Math. Důležité je, aby sitemap odrážela skutečný obsahový záměr, ne jen technický seznam všech veřejných adres.
6. Aktualizace, pluginy a role uživatelů: tichá obrana proti problémům
WordPress bývá stabilní, dokud se nezačne hromadit příliš mnoho pluginů, starých šablon a nejasně nastavených oprávnění. Každý další plugin znamená další kus kódu, další možné konflikty a často i další požadavky do databáze nebo na externí služby. Na reálném webu je rozdíl mezi 12 a 28 aktivními pluginy často vidět nejen na rychlosti, ale i na počtu chyb po aktualizaci.
Bezpečnost a výkon spolu v WordPressu úzce souvisejí. Zastaralý plugin může zpomalovat web, ale také zvýšit riziko kompromitace. Napadený web pak trpí úplně jinak: neobvyklý provoz, spam, přesměrování, ztráta indexace i zhoršení reputace.
Praktická pravidla:
- ponechat jen pluginy, které mají jasnou funkci a aktivní podporu;
- testovat aktualizace nejdřív na stagingu;
- omezit počet administrátorských účtů;
- pro editory nastavit role přesně podle potřeby, ne „všichni správci“;
- pravidelně kontrolovat, zda pluginy nevolají zbytečné externí skripty.
Na bezpečnostní dohled se hodí Wordfence nebo Solid Security, na technickou kontrolu potom Query Monitor a serverové logy. U větších projektů se vyplácí také měsíční audit pluginů: co se nepoužívá, to odinstalovat, ne jen deaktivovat.
7. Cron úlohy a zálohy: když běží tiše, web má méně problémů
WordPress používá vlastní pseudo-cron systém pro plánované úlohy: publikování článků, kontroly aktualizací, mazání dočasných dat nebo odesílání e-mailů. Problém je, že WP-Cron neběží jako skutečný systémový cron, ale spouští se při návštěvě webu. Na malém webu to stačí, na větším už může způsobovat nepravidelnosti a zbytečné zpomalení při zátěži.
Pokud web roste, vyplatí se WP-Cron vypnout a nahradit ho serverovým cronem. Tím se plánované úlohy spouštějí přesněji a bez závislosti na návštěvnosti. Týká se to hlavně publikování, e-mailových front a automatických údržbových procesů.
Stejně důležité jsou zálohy. Nejde jen o to je mít, ale mít je:
- automatické;
- uložené mimo hosting;
- testované obnovou;
- oddělené pro soubory a databázi;
- časově rozumně nastavené podle frekvence změn webu.
U e-shopu se denní záloha často ukáže jako minimum, u obsahového webu může stačit týdenní plná a denní inkrementální. Nástroje jako UpdraftPlus, BlogVault nebo zálohy přímo od hostingu jsou použitelné, ale důležitější než značka je pravidelné ověření obnovy. Web totiž nezachraňuje záloha, která existuje jen na papíře.
