Proč se výkon WordPressu láme právě na pluginech

WordPress je modulární systém a to je jeho síla i slabina. Každý plugin může přidat vlastní PHP kód, databázové dotazy, externí požadavky na API, CSS, JavaScript nebo cron úlohy. Když se těchto zásahů sejde víc, web začne zpomalovat nejen na homepage, ale i v administraci, v nákupním procesu nebo při vykreslení mobilní verze.

V praxi často neplatí, že „web je pomalý“. Přesnější je, že jedna nebo dvě konkrétní funkce dělají zbytečně moc práce. Typický příklad: kontaktní formulář, který na každé stránce načítá 6 skriptů; builder, který vkládá globální CSS i tam, kde není použit; nebo analytický plugin, který při každém requestu zapisuje do databáze. Pokud se výkon zhorší o 300 až 800 ms TTFB nebo LCP vyskočí nad 3,5 s, bývá pluginová vrstva velmi častý viník.

Nejprve ale potřebujete měřit. Bez dat se ladění výkonu mění v dohadování.

Jak poznat, že problém nedělá hosting, ale konkrétní plugin

Základní test je jednoduchý: porovnejte stav před a po deaktivaci podezřelého pluginu. Pokud se čas načtení zlepší o desítky procent, máte jasný signál. V ideálním případě měřte ve třech vrstvách: laboratorně přes Lighthouse nebo WebPageTest, reálně přes PageSpeed Insights a serverově přes Query Monitor nebo server logy.

• Lighthouse ukáže dopad na LCP, INP a CLS.
• WebPageTest odhalí počet requestů, velikost stránky a waterfall.
• Query Monitor ukáže pomalé SQL dotazy, hooks a HTTP požadavky z pluginů.
• GTmetrix je užitečný pro rychlé srovnání před/po.

Na co se dívat konkrétně? Pokud plugin přidá více než 100–200 KB JS/CSS na každé stránce, je to první varovný signál. Pokud generuje desítky dotazů do databáze nebo způsobuje opakované volání externích služeb, problém bude ještě větší. U e-shopů bývá kritické i to, zda plugin zasahuje do checkoutu: tam se každá desetina sekundy promítá do konverzí.

Velmi užitečný postup je také porovnání aktivní vs. deaktivovaná funkce. Ne vždy je nutné odinstalovat celý plugin; někdy stačí vypnout konkrétní modul, widget nebo skript. Například plugin pro sdílení na sociální sítě nemusí načítat všechny sítě na každé stránce, ale jen pod článkem. Rozdíl v rychlosti bývá okamžitý.

Pět pluginů, které nejčastěji zpomalují web

Ne všechny pluginy jsou problematické, ale existuje pět kategorií, které v audittech výkonu vycházejí opakovaně jako nejslabší místo.

1. Page buildery a jejich doplňky

Elementor, WPBakery, Divi nebo jejich add-ony často přidávají nadbytečné wrappery, globální styly a skripty. Na jednoduché stránce pak běží kód určený pro desítky modulů, které vůbec nepoužíváte. U větších webů se to projeví především na mobilu, kde se zbytečný JS podepíše na INP a zpomalí interakci.

Co s tím: vypněte nepoužívané widgety, použijte asset manager nebo funkci pro podmíněné načítání skriptů. Pokud web stojí na builderu, je vhodné měřit každou šablonu zvlášť. U některých projektů lze snížit počet requestů o 20 až 40 % jen tím, že se omezí globální knihovny.

2. Bezpečnostní a firewall pluginy

Bezpečnost je důležitá, ale některé pluginy kontrolují každé načtení stránky příliš agresivně. Skenery, ochrana proti brute force útokům nebo realtime firewall mohou přidávat zpoždění, hlavně pokud běží na sdíleném hostingu nebo bez cache vrstvy. Někdy je problém i v tom, že plugin zapisuje do logů při každém requestu.

Co s tím: zkontrolujte, zda plugin nepoužívá externí API na každé načtení stránky. Pokud ano, nastavte cache, prodlužte intervaly nebo část ochrany přesuňte na úroveň hostingu či CDN. U webů s vyšší návštěvností je vhodné porovnat TTFB před a po aktivaci modulu. Rozdíl 100–300 ms je běžný a na Core Web Vitals už znatelný.

3. Statistiky, trackovací a marketingové pluginy

Analytické pluginy, heatmapy, A/B testovací nástroje a remarketingové integrace často přidávají více skriptů, než si správce webu uvědomuje. Problém není jen v samotném JavaScriptu, ale i v tom, že některé pluginy vytvářejí další databázové tabulky nebo ukládají detailní logy o návštěvnících.

Co s tím: zvažte přesun měření do Google Tag Manageru a načítání skriptů podmíněně. U menších webů často stačí GA4 přes GTM a žádný další plugin není potřeba. Pokud používáte heatmapy, testujte jejich dopad přes WebPageTest: některé nástroje přidají 200–400 KB a několik externích požadavků, což je na mobilu znatelné.

4. Formulářové a CRM pluginy

Kontaktní formuláře, lead capture a napojení na CRM bývají skryté zdroje zpomalení. Kromě skriptů často řeší validaci, anti-spam ochranu, reCAPTCHA a automatické odesílání dat do externích systémů. Pokud je formulář na každé stránce, načítá se i tam, kde ho uživatel nikdy nepoužije.

Co s tím: formulář načítejte jen tam, kde je potřeba. Zvažte lehčí alternativy, vypněte zbytečné integrace a reCAPTCHA nahraďte méně náročným řešením, například honeypotem nebo server-side validací. U kontaktních stránek se vyplatí měřit i celkovou interaktivitu: když formulář blokuje hlavní thread, zhorší INP a uživatelé mají pocit, že web „zamrzá“.

5. WooCommerce rozšíření a produktové add-ony

U e-shopů bývají největším problémem pluginy pro upsell, cross-sell, dynamické ceny, varianty, dopravu nebo platební brány. Každý další modul může přidat SQL dotazy, AJAX požadavky a složitější výpočet ceny. U katalogů s tisíci produktů pak i malý pluginový problém naroste do výrazného zpomalení administrace i frontendu.

Co s tím: zkontrolujte, zda rozšíření neběží globálně na všech stránkách. Na produktové kartě je běžné, že plugin přidá 10–15 dalších requestů, které nejsou nutné na homepage. U WooCommerce doporučuji sledovat hlavně checkout, cart fragments a dynamické filtry. Právě tady se nejlépe ukáže, jestli plugin přináší užitek, nebo jen náklady na výkon.

Jak udělat rychlý audit bez zbytečného chaosu

Nejpraktičtější je postupovat systematicky. Nejprve si udělejte seznam všech aktivních pluginů a rozdělte je podle funkce: výkon, bezpečnost, marketing, obsah, e-commerce. Pak si u každého položte tři otázky: používá se na každé stránce, zapisuje do databáze a načítá externí skripty? Pokud je odpověď ano alespoň na dvě otázky, stojí za hlubší kontrolu.

• Deaktivujte plugin dočasně a změřte rozdíl v Lighthouse.
• Prohlédněte network waterfall v DevTools a sledujte, co přibylo.
• Zkontrolujte SQL dotazy v Query Monitoru.
• Ověřte, zda skripty běží podmíněně jen na relevantních stránkách.
• Porovnejte mobilní a desktopovou verzi, protože na mobilu bývá problém výraznější.

V praxi se často stává, že jeden plugin nepřidá sám o sobě velké zpomalení, ale v kombinaci s dalšími třemi vytvoří kritickou zátěž. Proto je důležité sledovat i kumulativní efekt. Když například page builder, bezpečnostní plugin a marketingový tracker dohromady přidají 18 requestů a 600 KB dat, web už začne být pomalý i na kvalitním hostingu.

Kdy plugin odstranit, kdy nahradit a kdy jen omezit

Ne každý pomalý plugin je třeba okamžitě smazat. Rozhodnutí by mělo vycházet z poměru přínos vs. náklad. Pokud plugin přináší zásadní obchodní funkci, ale je těžký, hledejte lehčí alternativu nebo upravte načítání. Pokud jde o doplněk s minimálním přínosem a vysokým dopadem na výkon, je odstranění nejlepší volba.

Praktické pravidlo: jestli plugin zpomaluje LCP o více než 0,3 s, zvyšuje počet requestů o více než 10 nebo vytváří zbytečné dotazy v administraci, zaslouží si zásah. U menších webů to může být jen otázka jednoho nebo dvou pluginů. U rozsáhlejších WordPress instalací bývá problém v pěti typech doplňků, které se opakují stále dokola: builder, bezpečnost, marketing, formuláře a WooCommerce rozšíření.

Jakmile tyto oblasti podchytíte, výkon webu se obvykle zlepší rychleji než po jakékoli „obecné optimalizaci“. A právě to je důvod, proč se při ladění WordPressu vyplatí začít tam, kde se chyba skrývá nejčastěji: v pluginech, které sice přidávají funkce, ale zároveň si berou největší kus výkonového rozpočtu.