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í.