1. Přemíra pluginů a jejich „tichý“ dopad na výkon

Nejčastější problém WordPressu není samotný WordPress, ale skladba pluginů. Každý další plugin může přidat vlastní JavaScript, CSS, databázové dotazy, externí API volání nebo admin skripty, které se načítají i tam, kde vůbec nejsou potřeba. V reálných auditech není výjimkou web s 25–40 pluginy, kde 5 až 7 z nich dělá 80 % zátěže.

Typický scénář: plugin pro formuláře načítá skripty na každé stránce, plugin pro popupy přidá další knihovnu a plugin pro statistiky zapisuje do databáze při každém zobrazení. Výsledek? Delší LCP, vyšší INP a často i horší stabilita webu při vyšší návštěvnosti.

Co dělat v praxi:

• Projděte pluginy a u každého si položte otázku: Je opravdu nutný?
• Odstraňte duplikace funkcí. Například SEO plugin, schema plugin a plugin na breadcrumbs často překrývají část funkcí.
• Na diagnostiku použijte Query Monitor, WP Hive nebo měření v Chrome DevTools.
• U pluginů, které potřebujete jen na části webu, omezte jejich načítání na konkrétní stránky.

Praktické pravidlo: pokud plugin přidává front-end skripty na celý web, ale využijete ho jen na jedné landing page, je to kandidát na nahrazení lehčí alternativou nebo custom řešením.

2. Obrázky bez komprese, bez rozměrů a bez moderních formátů

WordPress weby bývají vizuálně bohaté, ale obrázky jsou stále jeden z největších zdrojů zpomalení. Velké JPG o velikosti 2–5 MB, chybějící lazy loading nebo nevhodně vložené bannery umí zničit LCP i mobilní UX. Google v praxi preferuje stránky, které mají klíčový obsah dostupný rychle, a těžké obrázky jsou přesně to, co tomu brání.

Častá chyba je i absence správných rozměrů. Když má obrázek v HTML nastavenou šířku a výšku jinak, než je jeho skutečná velikost, vzniká poskakování layoutu a roste CLS. To je problém nejen pro SEO, ale i pro konverze.

Co zkontrolovat:

• Všechny obrázky převádět do WebP nebo AVIF, kde to dává smysl.
• Komprimovat automaticky pomocí nástrojů jako ShortPixel, Imagify nebo Smush.
• U důležitých obrázků nastavit správné rozměry a preload pro hlavní vizuál nad přehybem.
• Používat srcset a sizes, aby mobil nestahoval desktopovou variantu.

U e-shopů a magazínů je často rozdíl mezi „jen“ optimalizovanými a skutečně odlehčenými obrázky 0,5 až 1,5 sekundy na mobilu. To je v Core Web Vitals obrovský rozdíl.

3. Téma a builder, které přidávají zbytečný kód

Na první pohled působí moderní page builder jako rychlá cesta k hezkému webu. Z hlediska výkonu ale často generuje hlubokou DOM strukturu, desítky wrapperů, inline stylů a přebytečný JavaScript. To zpomaluje vykreslení a zhoršuje i práci s obsahem při editaci.

Stejný problém mají některá „multipurpose“ témata, která chtějí obsáhnout vše od blogu po e-shop. Výsledkem bývá, že načítají styly a skripty pro funkce, které na konkrétním webu vůbec nejsou aktivní. U WordPressu je to běžný důvod, proč web na PageSpeed Insights vypadá dobře jen na desktopu a na mobilu padá do šedého průměru.

Jak postupovat:

• Preferujte lehká témata, například GeneratePress, Astra nebo vlastní šablonu s minimem závislostí.
• Omezte používání builderů na skutečně nutné landing pages.
• Prověřte, zda téma neimportuje více fontů, ikon a knihoven, než opravdu potřebujete.
• V DevTools sledujte počet požadavků, velikost JS bundle a dobu blokování hlavního threadu.

Pokud web běží na builderu, ale zároveň má být rychlý, často pomůže přejít na blokový editor Gutenberg a složitější komponenty řešit jako lehké bloky nebo vlastní patterny.

4. Databáze, která roste bez kontroly

WordPress si v databázi ukládá revize, autoload optiony, transienty, spam, dočasná data pluginů a často i zbytky po odinstalovaných rozšířeních. Malý web to nemusí poznat hned, ale u webu s dlouhou historií se databáze snadno nafoukne na desítky až stovky megabajtů. Pak se zpomaluje administrace, dotazy trvají déle a některé pluginy začnou selhávat.

Největší problém bývá tabulka wp_options, hlavně položky s autoload = yes. Pokud je těchto položek moc nebo jsou příliš velké, WordPress je načítá při každém requestu. To je přesně typická „neviditelná“ brzda webu.

Praktický postup:

• Projděte databázi pomocí phpMyAdmin, Adminer nebo WP-CLI.
• Vyčistěte revize příspěvků, spam komentáře a transienty.
• Zkontrolujte velikost autoload dat; u menších webů by neměla bezdůvodně růst do stovek kilobajtů až megabajtů.
• Po odinstalaci pluginu vždy ověřte, zda nezůstaly jeho tabulky nebo optiony.

U větších webů je vhodné nastavit pravidelnou databázovou údržbu a zálohy před každým čištěním. V opačném případě je snadné smazat data, která web skutečně potřebuje.

5. Aktualizace odkládané „na později“

WordPress, pluginy i témata se aktualizují z dobrého důvodu: bezpečnostní záplaty, opravy chyb a kompatibilita s novými verzemi PHP. Když se aktualizace odkládají měsíce, zvyšuje se riziko zranitelnosti i technického dluhu. Nejčastější útoky na WordPress míří na známé slabiny v rozšířeních, ne na samotný core.

Bezpečnostní problém není jen teoretický. Stačí jedna zranitelná verze pluginu a útočník může získat přístup přes formulář, nahrávání souborů nebo administrátorské rozhraní. V praxi je proto důležité sledovat nejen WordPress core, ale i pluginy s vyšším rizikem: formuláře, page buildery, e-shopy, cache a importní nástroje.

Co zavést:

• Pravidelný update režim: ideálně týdně kontrola, u kritických záplat okamžitě.
• Staging prostředí pro test kompatibility před nasazením na produkci.
• Automatické zálohy před aktualizací, například přes hosting nebo nástroje jako UpdraftPlus.
• Sledování bezpečnostních databází, například Wordfence, Patchstack nebo WPScan advisories.

Nejde jen o bezpečnost. Zastaralý plugin často znamená i horší výkon, konflikty s novým PHP a vyšší pravděpodobnost chyb, které zpomalují celý web.

6. Chybný hosting, cache a serverová konfigurace

I dobře postavený WordPress může být pomalý, pokud běží na nevhodném hostingu. Sdílený server s přetíženým CPU, starší verzí PHP nebo bez objektové cache dokáže srazit výkon i u jinak čistého webu. Rozdíl mezi průměrným hostingem a dobře nastaveným prostředím bývá v TTFB klidně stovky milisekund, někdy i více než sekunda.

Velmi častý problém je špatně nastavená cache. Někde chybí page cache úplně, jinde se cache obchází kvůli cookies, WooCommerce nebo nevhodným pravidlům. Další slabina je absence serverové cache nebo objektové cache typu Redis, která výrazně pomáhá u dynamických webů s vyšší návštěvností.

Kontrolní seznam:

• PHP verze minimálně 8.1 nebo novější, podle kompatibility pluginů.
• HTTP/2 nebo HTTP/3, aktivní Brotli nebo Gzip komprese.
• Page cache, browser cache a ideálně i object cache.
• Výkon měřit přes WebPageTest, Lighthouse a serverové logy.

Pokud TTFB dlouhodobě přesahuje zhruba 600–800 ms u jednoduchého webu, problém už často není v obsahu, ale v hostingu, cache nebo databázi.

7. Slabé zabezpečení, které zpomaluje i ničí důvěru

Bezpečnost a výkon spolu souvisí víc, než se zdá. Napadený web bývá pomalý, protože útočník přidá škodlivé skripty, spamové odkazy, skryté redirecty nebo těžké požadavky na externí domény. Někdy se web zpomalí už jen tím, že běží na kompromitovaném serveru nebo má přetížené procesy kvůli brute-force útokům.

Riziková místa jsou dobře známá: slabá hesla, administrátor bez dvoufaktorového ověření, otevřené XML-RPC, nechráněné přihlašování a nulová kontrola souborových práv. V praxi pak stačí jedno úspěšné přihlášení a web začne generovat redirecty, rozesílat spam nebo být označený v Safe Browsingu.

Co má smysl zavést hned:

• 2FA pro administrátory a editory.
• Omezení pokusů o přihlášení a ochranu proti brute-force útokům.
• Pravidelnou kontrolu změn souborů pomocí bezpečnostních pluginů nebo serverových nástrojů.
• Správně nastavené role uživatelů a minimum administrátorských účtů.
• SSL certifikát, bezpečné hlavičky a zálohy mimo produkční server.

Bezpečný WordPress není jen o ochraně dat. Je to i stabilnější, rychlejší a důvěryhodnější web, který se lépe indexuje, lépe konvertuje a méně často padá do problémů s reputací domény.