---
title: Prečo bol WordPress e-shop pomalý aj napriek WP Rocket cache? Prípad z praxe - PodNaWeb
description: Rýchlosť webu dnes ovplyvňuje nielen používateľský komfort, ale aj konverzie, SEO a celkový dojem zo stránky. Pri WordPress e-shopoch sa preto často používajú cache pluginy, ktoré dokážu výrazne zrýchliť načítanie stránok.Čo však robiť v situácii, keď je cache zapnutá,
---
# Prečo bol WordPress e-shop pomalý aj napriek WP Rocket cache? Prípad z praxe
: 07. okt 2026
Rýchlosť webu dnes ovplyvňuje nielen používateľský komfort, ale aj konverzie, SEO a celkový dojem zo stránky. Pri WordPress e-shopoch sa preto často používajú cache pluginy, ktoré dokážu výrazne zrýchliť načítanie stránok.
Čo však robiť v situácii, keď je cache zapnutá, stránka je podľa systému „prednačítaná“, no návštevník aj tak pri prvom otvorení čaká niekoľko sekúnd?
Presne takýto problém sme riešili na jednom viacjazyčnom WooCommerce e-shope s kombináciou **WP Rocket, WPML a WooCommerce Multilingual**.
## Cache fungovala – ale nie vždy
Na prvý pohľad bolo všetko nastavené správne.
**WP Rocket vytváral cache súbory** a pri opakovanom načítaní sa stránka dokázala zobraziť približne za desatinu sekundy. Bez cache však generovanie stránky trvalo niekoľko sekúnd.
To samo o sebe nie je až také nezvyčajné. Komplikovanejší WordPress e-shop musí pri každom necachovanom načítaní spracovať množstvo PHP kódu, databázových dotazov, WooCommerce funkcií či prekladov.
Problém bol inde.
WP Rocket mal zapnutý aj **preload**, teda automatické prednačítanie stránok do cache ešte predtým, než ich navštívi zákazník. Preload pritom tvrdil, že stránka je pripravená.
Napriek tomu jej prvé otvorenie návštevníkom trvalo viac sekúnd. Druhé načítanie bolo niekedy opäť pomalé. Až tretie bolo okamžité.
To už naznačovalo, že **problém nebude iba vo výkone servera**.
## Čo sme našli v cache súboroch
Pri kontrole fyzických súborov WP Rocket sa ukázala dôležitá vec. Po preloade existoval napríklad základný cache súbor:
> index-https.html
Po prvom reálnom otvorení stránky však pribudol ďalší:
> index-https-EUR-de.html
alebo pri českej verzii:
> index-https-CZK-cs.html
To už veľmi presne ukázalo, čo sa deje.
WP Rocket totiž dokáže vytvárať rôzne verzie cache podľa hodnôt cookies v prehliadači. WooCommerce Multilingual používa cookies napríklad na zapamätanie meny a jazykovej verzie. A WP Rocket tieto hodnoty používal ako súčasť svojho cache kľúča. Výsledkom bolo, že prednačítaná stránka síce existovala, ale návštevník s nastavenými WCML cookies ju nepoužil.
## Prečo to bolo v tomto prípade zbytočné
Samotný princíp oddelených cache súborov podľa meny je správny. Predstavme si e-shop, kde si návštevník môže manuálne vybrať: EUR, CZK, USD, GBP.
Vtedy musí existovať rozdielna cache pre jednotlivé meny, pretože rovnaká URL môže zobrazovať odlišné ceny.
V našom prípade však bola situácia jednoduchšia. Mena bola pevne viazaná na jazyk webu:
slovenčina → EUR; čeština → CZK; ostatné → EUR
Používateľ si menu nemohol manuálne meniť a nepoužívala sa ani automatická geolokácia podľa krajiny.
Česká URL by teda vždy znamenala český obsah a CZK. Nemecká URL by vždy znamenala nemecký obsah a EUR. Samotná adresa stránky už jednoznačne určovala, akú menu má WordPress zobraziť. Dodatočné rozdeľovanie cache podľa currency cookies preto neprinášalo žiadnu výhodu.
Naopak, spôsobovalo pozorovaný problém.
## Prečo bola stránka niekedy pomalá dokonca dvakrát
Toto bolo na celom probléme najzaujímavejšie.
Pri otvorení českej stránky mohol mať prehliadač ešte cookies z predchádzajúcej slovenskej návštevy. WP Rocket teda najskôr pracoval napríklad s kombináciou EUR + sk, a vytvoril:
> index-https-EUR-sk.html
WooCommerce Multilingual následne zistil, že aktuálna stránka je česká, a zmenil cookies na CZK + cs. Pri ďalšej návšteve preto WP Rocket potreboval inú cache:
> index-https-CZK-cs.html
Tá ešte neexistovala, takže WordPress musel stránku znova kompletne vygenerovať. Až pri ďalšom treťom otvorení už bola správna cache pripravená.
Výsledok pre používateľa teda mohol vyzerať aj takto: **pomaly → pomaly → rýchlo. Hoci WP Rocket preload medzitým tvrdil, že stránka bola dávno pripravená**.
##
## Riešenie nebolo vypnutie WPML ani WP Rocket
Pri podobných problémoch je lákavé začať vypínať pluginy. WPML, WooCommerce Multilingual, cache, Elementor alebo dokonca šablónu. To však často nie je vhodné riešenie, najmä na fungujúcom e-shope.
V tomto prípade nebolo potrebné vypnúť ani viacjazyčnosť, ani viac mien, ani WP Rocket. Upravili sme iba spôsob, akým WP Rocket pracuje s WCML cookies.
Keďže mena bola jednoznačne určená jazykom URL, nebolo potrebné používať cookies pre určovanie jazyka a meny na vytváranie ďalších variantov HTML cache. Po úprave používal návštevník rovnaký základný cache súbor, ktorý už predtým pripravil WP Rocket preload.
Výsledok bol viditeľný okamžite.
Prednačítaná česká stránka sa otvorila **rýchlo už pri úplne prvej návšteve**, zobrazovala správne ceny v CZK a nevznikali žiadne dalšie jazykovo-menové cache súbory. Rovnako fungovali aj ostatné jazykové verzie stránky.
## Čo si z toho môže odniesť majiteľ WordPress webu
Pri problémoch s rýchlosťou nestačí sledovať iba skóre PageSpeed Insights alebo nainštalovať ďalší optimalizačný plugin.
Niekedy môže byť samotná cache technicky funkčná, ale konkrétna kombinácia pluginov spôsobí, že návštevník dostáva inú cache verziu, než akú pripravil preload. Varovným signálom môže byť napríklad situácia, keď sa stránka po vymazaní cache načíta veľmi pomaly, druhý či tretí refresh je výrazne rýchlejší, ale po čase sa problém zopakuje.
Rovnako podozrivé je, ak WP Rocket tvrdí, že preload stránky je dokončený, ale jej **prvá návšteva je napriek tomu pomalá**.
Pri viacjazyčných WooCommerce stránkach sa potom oplatí preveriť nielen WP Rocket, ale aj spôsob práce WPML, WooCommerce Multilingual, cookies, mien a jazykových variantov.
## Optimalizácia WordPressu nie je iba o jednom plugine
Tento prípad dobre ukazuje, prečo môže byť ladenie výkonu WordPressu pomerne komplexné. Jednotlivé pluginy môžu samostatne fungovať správne. Problém vznikne až ich kombináciou.
1. WP Rocket správne vytváral cache.
2. WPML správne určoval jazyk.
3. WooCommerce Multilingual správne určoval menu.
Napriek tomu ich spoločné nastavenie spôsobovalo, že prednačítaná cache **nebola pre reálneho návštevníka efektívne využitá**. Pri optimalizácii webu preto nemusí byť najdôležitejšie pridať ďalši plugin, ale zistiť, **či aktuálne všetko funguje tak ako má**.
Ak riešite pomalý WordPress, WooCommerce, viacjazyčný web, problémy s cache alebo situáciu, keď sa web správa inak, než by podľa nastavení mal, podobné problémy sa dajú často vyriešiť bez prestavby celej stránky. Dôležitá je správna diagnostika a úprava konkrétnej časti systému namiesto náhodného vypínania funkcionalít.
Takýto prístup používam aj pri správe a optimalizácii WordPress a WooCommerce webov – od hľadania príčiny pomalého načítania, cez cache a databázu až po problémy vznikajúce kombináciou šablón, pluginov a viacjazyčných riešení.
**Anton Zaujec**
Webdizajnu a Joomle sa venujem už od vysokej školy. V začiatkoch najmä pre seba, neskôr som začal tvoriť pre jednotlivcov a firmy. Časom sa k tvorbe webstránok pridali ďalšie vedomosti o optimalizácii pre vyhľadávače, marketingu a dizajne. Aj týmto článkom sa snažím zdieľať aspoň časť svojich vedomostí s ľuďmi, ktorých tieto témy zaujímajú, alebo hľadajú pomoc.
[Ozvite sa mi](https://www.podnaweb.sk/kontakt)
### Podobné články
[](https://www.podnaweb.sk/blog/12-vyuzite-spravanie-ludi-v-kamennych-obchodoch-pri-tvorbe-webovej-stranky "Využite správanie ľudí v kamenných obchodoch pri tvorbe webovej stránky")
##### [Využite správanie ľudí v kamenných obchodoch pri tvorbe webovej stránky](https://www.podnaweb.sk/blog/12-vyuzite-spravanie-ludi-v-kamennych-obchodoch-pri-tvorbe-webovej-stranky)
Viete ako sa správajú ľudia v kamenných obchodoch?
Určite áno, veď sami nakupujete.
A viete aj to, ako využiť tieto poznatky pri budovaní vašej nove ...
[](https://www.podnaweb.sk/blog/50-responzivne-stranky-su-googlom-uprednostnovane-pripraveny-na-mobilegeddon "Responzívne stránky začínajú byť Googlom uprednostňované. Pripravený na MOBILEGEDDON?")
##### [Responzívne stránky začínajú byť Googlom uprednostňované. Pripravený na MOBILEGEDDON?](https://www.podnaweb.sk/blog/50-responzivne-stranky-su-googlom-uprednostnovane-pripraveny-na-mobilegeddon)
Na 21.4.2015 ohlásil najväčší vyhľadávač začiatok ďalších veľkých zmien.
Väčších, ako obávané updaty, ktoré každý pozná pod názvami panda či penguin. ...
[](https://www.podnaweb.sk/blog/seo-faktory "Ako som objavil SEO faktory (+ TOP 32 faktorov)")
##### [Ako som objavil SEO faktory (+ TOP 32 faktorov)](https://www.podnaweb.sk/blog/seo-faktory)
Stáli ste už niekedy pred naoko neriešiteľnou úlohou?
Pred úlohou tak veľkou, že pri každom pomyslení na ňu vám prebehol mráz po chrbte?
Či už ste m ...