add_action('wp_print_styles', 'eduardweb_dequeue_cart_fragments', 100);
function eduardweb_dequeue_cart_fragments() {
// Dezactivăm fragmentele doar pe paginile non-shop pentru a salva TTFB
if (function_exists('is_woocommerce') && !is_woocommerce() && !is_cart() && !is_checkout()) {
wp_dequeue_script('wc-cart-fragments');
}
}Să fim serioși, WooCommerce devine un melc imediat ce treci de 100 de comenzi pe zi sau ai peste 5000 de produse în catalog. Am avut recent un proiect cu 15.000 de produse unde timpul de încărcare pe mobil depășea 4.5 secunde, iar clientul pierdea clienți masiv. După ce am aplicat trei chestii simple—Redis, Cloudflare APO și curățenie în query-uri—am coborât sub 1.2 secunde pe mobil și 600ms pe desktop.
Nu e vreo magie la mijloc, ci doar eliminarea blocajelor clasice de care ne lovim toți când platforma începe să fie solicitată.
Redis Object Cache: De ce nu e opțional
Fără un cache de obiecte, WordPress face zeci sau sute de query-uri redundante la fiecare afișare de pagină, mai ales în paginile de categorie unde WooCommerce trage meta-datele fiecărui produs individual. Redis ține toate opțiunile și tranzienții direct în memorie (RAM), scutind baza de date de un efort inutil.
Am folosit pluginul gratuit "Redis Object Cache" de la Till Krüss. Merge excelent, dar are un trade-off sincer: dacă ai în site pluginuri prost scrise care nu folosesc corect API-ul de cache din WordPress, te poți trezi că afișezi stocuri vechi sau prețuri greșite în pagină. Ca regulă de aur, asigură-te că pe server ai alocat destul RAM pentru Redis și că ai setat politica de evicțiune pe allkeys-lru în redis.conf, altfel când se umple memoria o să îți crape site-ul direct.
Cloudflare APO: Performanță masivă cu 5 dolari
Dacă nu vrei să te complici cu configurări avansate de Varnish sau Nginx FastCGI cache pe VPS-ul tău, Cloudflare APO (Automatic Platform Optimization) e aur curat. Costă fix 5 dolari pe lună pe planul gratuit și servește HTML-ul paginilor direct din edge-ul lor global. Practic, obții un TTFB (Time to First Byte) de sub 100ms pentru vizitatorii neautentificați.
Cum funcționează? Când un vizitator adaugă un produs în coș, WooCommerce setează cookie-ul woocommerce_items_in_cart. Cloudflare detectează instant acest cookie și face bypass la cache, trimițând cererile direct către serverul tău pentru a nu strica experiența de checkout.
Trade-off-ul aici apare la widget-urile dinamice. Dacă ai un banner pe prima pagină care se schimbă în funcție de geolocația userului, APO îl va cache-ui agresiv și toți vor vedea aceeași versiune. Soluția e să muți acele secțiuni pe apeluri AJAX după încărcarea paginii.
Optimizarea query-urilor și mizeria numită Cart Fragments
Cel mai mare ucigaș de performanță pe WooCommerce este request-ul AJAX /?wc-ajax=get_refreshed_fragments. Acesta rulează la fiecare încărcare de pagină, chiar și pe un articol de blog care n-are nicio legătură cu magazinul, doar ca să verifice dacă trebuie să actualizeze numărul de produse din iconița de coș. Asta înseamnă că PHP-ul pornește de la zero la fiecare click.
Am rezolvat asta dezactivând scriptul pe paginile care nu sunt de tip magazin. Am economisit cam 30% din resursele CPU ale serverului la un magazin cu 8.000 de utilizatori unici pe zi.
De asemenea, dacă nu ai trecut încă la HPOS (High-Performance Order Storage) în WooCommerce, fă-o acum. Mutarea comenzilor din tabelele wp_posts și wp_postmeta (care devin uriașe din cauza logicii de Custom Post Type) în tabele SQL dedicate reduce dramatic timpul de interogare în panoul de administrare. La un client cu 80.000 de comenzi istorice, timpul de căutare a unei comenzi în admin a scăzut de la 8 secunde la sub o secundă.
Voi cum gestionați problema cu cart fragments în proiectele voastre? Mergeți pe dezactivare completă pe paginile non-shop sau folosiți un script custom în JS?