add_action('wp_enqueue_scripts', function () {
// Oprim cart-fragments pe paginile non-shop dacă nu există produse în coș
if (function_exists('is_woocommerce') && !is_woocommerce() && !is_cart() && !is_checkout()) {
if (function_exists('WC') && WC()->cart && WC()->cart->is_empty()) {
wp_dequeue_script('wc-cart-fragments');
}
}
}, 99);Un magazin WooCommerce cu un catalog de peste 10.000 de produse și TTFB de 1.5 - 2 secunde e o fabrică de pierdut bani. Am preluat recent un shop cu vreo 14.000 de SKU-uri unde fiecare accesare de pagină punea baza de date în genunchi, mai ales când intrau 40-50 de useri simultan. Vă las mai jos pașii exacți prin care am stabilizat magazinul la ~180ms TTFB, fără să aruncăm bani pe servere dedicate de 300 de euro.
1. Redis Object Cache: dincolo de simplul "install plugin"
Cea mai mare greșeală pe care o văd este instalarea unui plugin generic de Redis lăsat pe setările implicite. WooCommerce face sute de apeluri pentru transients, variații și opțiuni de configurare la un singur request. Fără persistent object cache, MySQL muncește de două ori pentru aceleași date.
Am folosit extensia phpredis din server și pluginul Redis Object Cache (sau LiteSpeed Cache dacă sunteți pe stack-ul lor). Secretul stă în parametrul WP_CACHE_KEY_SALT din wp-config.php pentru a evita coliziunile dacă rulați staging pe același server, plus alocarea strictă a memoriei în redis.conf (maxmemory 512mb și maxmemory-policy allkeys-lru).
Trade-off sincer: dacă aveți pluginuri proaste care fac wp_cache_set cu date masive fără expirare, Redis va umple RAM-ul rapid și va începe să șteargă chei la întâmplare sau chiar să blocheze PHP workerii.
2. Cloudflare APO: salvarea paginilor pentru vizitatori anonimi
Cloudflare Automatic Platform Optimization (APO) costă 5$/lună pe planul Free sau vine inclus la Pro. Pentru WooCommerce face o chestie genială: servește paginile de categorii și produse direct din edge-ul Cloudflare (cache full-page), dar știe nativ să facă bypass când detectează cookie-urile specifice WooCommerce (woocommerce_items_in_cart sau sesiuni de client autentificat).
Înainte de APO, un vizitator anonim care naviga prin pagini rula tot stack-ul PHP-MySQL. După activare, 85% din traficul anonim nici măcar nu mai atinge serverul de origine. TTFB-ul global a picat instant la sub 60ms pentru utilizatorii din România.
Nuanța neplăcută? Dacă folosiți pluginuri de multicurrency sau detectare de locație care folosesc cookie-uri proprii fără să trimită header-uri corecte de cache, APO le va servi aceeași pagină cache-uită tuturor. Trebuie configurate excepții manuale în Cloudflare Page Rules sau transformat widgetul de monedă într-o cerere AJAX asincronă.
3. Bombele din wp_options și wp-cart-fragments
Când am inspectat baza de date cu Query Monitor, am găsit aproape 4.8 MB de date încărcate pe absolut fiecare pagină prin autoload = 'yes' în tabela wp_options. Tabela avea zeci de transients orfane lăsate de pluginuri dezinstalate de 2 ani.
Curățarea autoload-ului și adăugarea unui index compus pe tabele a redus interogările MySQL de la 180 la vreo 45 per pagină. Apoi am lovit a doua problemă clasică: wc-cart-fragments prin admin-ajax.php. Pe fiecare pagină încărcată, WooCommerce trimitea un apel AJAX greoi ca să vadă dacă s-a schimbat numărul de produse din mini-cart, omorând conexiunile concurente pe mobil.
Soluția simplă: dequeuiezi scriptul de cart fragments pe paginile unde utilizatorul nu are produse în coș sau pe landing page-uri statice.
Voi cum gestionați fragmentarea de coș și cache-ul pe magazinele mari? Mergeți pe Varnish customizat sau vă bazați tot pe CDN edge cache?