add_action( 'wp_enqueue_scripts', 'dequeue_woocommerce_cart_fragments', 99 );
function dequeue_woocommerce_cart_fragments() {
// Dezactivăm scriptul doar dacă nu suntem pe o pagină WooCommerce reală
if ( function_exists( 'is_woocommerce' ) ) {
if ( ! is_woocommerce() && ! is_cart() && ! is_checkout() && ! is_front_page() ) {
wp_dequeue_script( 'wc-cart-fragments' );
}
}
}Să fim sinceri: WooCommerce e o struțo-cămilă din punct de vedere al performanței. Din fabrică, dacă treci de 2.000 de produse și ai peste 50 de vizitatori simultan pe site, serverul începe să gâfâie serios. Am avut acum câteva luni un client cu 12.000 de SKU-uri și un TTFB mizerabil de 1.8 secunde pe paginile de categorie; după ce am aplicat cele trei optimizări de mai jos, am coborât la 240ms.
Nu există o singură soluție magică, ci un cumul de decizii tehnice luate cu cap. Iată cum am abordat problema.
1. Object Cache cu Redis (Salvarea bazei de date)
Fără un mecanism de cache pentru obiecte, WordPress interoghează baza de date pentru absolut orice rahat la fiecare afișare de pagină: opțiuni, metadate de produs, sesiuni de user. Pe un magazin activ, asta înseamnă sute de miki-query-uri redundante în MySQL.
Am instalat Redis pe VPS-ul clientului și am activat plugin-ul Redis Object Cache (varianta gratuită a lui Till Krüss e excelentă). Rezultatul? Interogările SQL pe pagina de produs au scăzut de la 120 la doar 15.
Trade-off sincer: Redis mănâncă memorie RAM. Dacă rulezi magazinul pe un VPS ieftin de 1GB sau 2GB RAM, s-ar putea ca Redis să-ți mănânce toată memoria și să determine sistemul de operare să oprească procesul MySQL (faimosul Out of Memory killer). Nu te apuca de Redis dacă nu ai cel puțin 4GB RAM pe server și monitorizare activă.
2. Cloudflare APO (Automatic Platform Optimization)
Cloudflare APO costă 5 dolari pe lună și, din punctul meu de vedere, este cea mai ieftină metodă de a face un site WordPress să zboare. APO pune în cache paginile HTML direct în rețeaua globală Cloudflare (la edge). Asta înseamnă că pentru utilizatorii neautentificați, request-ul nici măcar nu mai ajunge la serverul tău fizic.
Totuși, WooCommerce are o mare problemă aici: coșul de cumpărături și widget-urile dinamice. Dacă ai în header un text de genul "Ai 2 produse în coș", Cloudflare va pune în cache acea pagină cu tot cu textul respectiv, iar următorul vizitator va vedea coșul altcuiva.
Soluția este să folosești cookie-uri de bypass (pe care APO le recunoaște nativ) și să muți randarea elementelor dinamice din PHP în JavaScript (via AJAX sau LocalStorage).
3. Query Optimization și oprirea risipei din WooCommerce
Baza de date din WordPress folosește tabela wp_postmeta pentru a stoca atributele produselor. Când ai filtre complexe (preț, mărime, culoare), WordPress face niște JOIN-uri monstruoase care îngenunchează serverul.
Am făcut două modificări critice care au eliberat baza de date:
- Am dezactivat numărarea produselor în filtre: În widget-ul de filtrare implicit din WooCommerce, cel care arată de exemplu "Pantaloni (45)", acel "45" necesită un query SQL extrem de greu. L-am dezactivat complet.
- Am oprit Cart Fragments pe paginile non-shop: WooCommerce rulează un request AJAX numit
wc-ajax=get_refreshed_fragmentspe absolut fiecare pagină a site-ului, inclusiv pe blog sau contact, doar ca să verifice dacă s-a schimbat ceva în coș.
Mai jos ai codul simplu pe care l-am adăugat în functions.php ca să dezactivez această risipă de resurse pe paginile unde nu avem nevoie de informații despre coș.