add_action('wp_enqueue_scripts', 'dequeue_woocommerce_cart_fragments', 11);
function dequeue_woocommerce_cart_fragments() {
if (is_front_page() || is_single() || is_page()) {
wp_dequeue_script('wc-cart-fragments');
}
}WooCommerce e genial până când treci de 1000 de produse și încep să se adune comenzile. Am avut recent un magazin cu vreo 12.000 de produse active unde checkout-ul dura și 6 secunde. Clientul pierdea bani zilnic, așa că a trebuit să fac curățenie în query-uri, cache și CDN.
Dacă ai lăsat WooCommerce pe setările default, practic îți rogi serverul să moară în chinuri. Iată cum am abordat problema și ce a funcționat cu adevărat.
Redis Object Cache nu e opțional
WordPress face mii de interogări în baza de date pentru fiecare afișare de pagină, mai ales din cauza structurii din wp_postmeta. Redis salvează aceste rezultate direct în memorie (RAM). La proiectul de care zic, activarea Redis Object Cache (folosind pluginul gratuit al lui Till Krüss) a redus timpul de răspuns al serverului (TTFB) de la 1.8s la sub 300ms pentru utilizatorii autentificați.
Trade-off-ul: Redis mănâncă RAM. Dacă ai un VPS ieftin de 1GB, o să-ți crape baza de date când ai un vârf de trafic. Ai nevoie de cel puțin 4GB RAM pe server ca să dormi liniștit și să aloci măcar 512MB pentru Redis.
Cloudflare APO: $5 care fac minuni
Pentru vizitatorii neautentificați, Cloudflare APO (Automatic Platform Optimization) e sfânt. Cachează paginile HTML direct la edge-ul lor, în toată lumea, detectând automat când un user are produse în coș prin cookie-uri. Când vine un user nou, pagina se încarcă instant din CDN, fără să mai atingă serverul tău.
Am obținut un timp de încărcare de 0.8 secunde pentru homepage din orice colț al țării.
Trade-off-ul: Devine problematic dacă folosești pluginuri de dynamic pricing sau geo-locație care schimbă prețurile în funcție de IP-ul vizitatorului. Cloudflare va servi aceeași pagină cache-uită tuturor, indiferent de țară, dacă nu configurezi reguli custom de bypass (ceea ce anulează parțial beneficiul APO).
Curățenia în baza de date și mizeria numită "cart fragments"
WooCommerce salvează totul ca postmeta: prețuri, stocuri, atribute. Când ai variații multe, baza de date explodează. Primul pas a fost să curăț manual tranzienții expirați și să șterg logurile vechi de sesiuni din wp_options. Am salvat cam 1.2GB de date complet inutile care îngreunau indexarea.
Apoi, am rezolvat cea mai mare problemă de frontend: request-ul de wc-ajax=get_refreshed_fragments. Chestia asta rulează pe fiecare pagină (chiar și pe articolele de blog) ca să actualizeze numărul de produse din coș. Blochează randarea paginii și durează adesea peste o secundă.
Am scris o funcție simplă în functions.php care dezactivează complet acest script pe paginile non-shop, îmbunătățind masiv scorul de Mobile.
Voi cum gestionați cache-ul pe WooCommerce când aveți clienți cu mii de variații de produse? Rămâneți pe Redis sau ați trecut deja pe soluții headless?