/**
* Dezactivează scripturile și stilurile WooCommerce pe paginile non-shop
*/
add_action('wp_enqueue_scripts', 'eduardweb_dequeue_woocommerce_styles_scripts', 99);
function eduardweb_dequeue_woocommerce_styles_scripts() {
if (function_exists('is_woocommerce')) {
if (!is_woocommerce() && !is_cart() && !is_checkout() && !is_account_page()) {
wp_dequeue_style('woocommerce-layout');
wp_dequeue_style('woocommerce-general');
wp_dequeue_style('woocommerce-smallscreen');
wp_dequeue_script('wc-cart-fragments');
wp_dequeue_script('woocommerce');
wp_dequeue_script('wc-add-to-cart');
}
}
}Să fim sinceri: WooCommerce poate deveni un monstru dacă îl lași de capul lui. Am preluat recent un magazin cu vreo 15.000 de produse și un istoric de 5 ani de comenzi, unde timpul de încărcare pe mobil trecea lejer de 4 secunde. Clientul voia deja să arunce cu bani într-un VPS de 120€ pe lună, deși problema era în altă parte.
Nu serverul era prea mic, ci baza de date era sufocată de interogări redundante, iar PHP-ul compila aceleași pagini la fiecare request. Iată ce am făcut ca să aducem TTFB-ul sub 100ms pentru vizitatori și sub 1.2s pe paginile dinamice, fără să schimbăm hostingul de 15€.
Redis Object Cache: Salvarea bazei de date
De fiecare dată când un user intră pe o pagină de produs, WordPress interoghează baza de date pentru opțiuni, metadate, taxonomii și meniuri. Sunt sute de query-uri identice rulate la fiecare accesare. Redis salvează rezultatele acestor interogări direct în memoria RAM.
Am instalat plugin-ul gratuit Redis Object Cache (cel scris de Till Krüss) și am activat extensia din server. Rezultatul? Numărul de interogări SQL pe pagina de categorie a scăzut de la 120 la doar 15. Baza de date pur și simplu a început să respire.
Trade-off-ul sincer: Redis e genial, dar dacă ai un volum uriaș de comenzi simultane (de exemplu, de Black Friday), trebuie să fii foarte atent la invalidarea cache-ului. Altfel, riști ca un client să vadă produsul „în stoc” când el de fapt tocmai s-a epuizat din cauza unei comenzi plasate cu 2 secunde în urmă.
Cloudflare APO: Pagini servite în 80ms
Pentru vizitatorii neautentificați, cel mai bun PHP e cel care nu rulează deloc. Cloudflare APO (Automatic Platform Optimization) costă 5$ pe lună pentru planurile gratuite și face un lucru simplu: stochează paginile HTML direct în rețeaua lor globală de servere (edge servers).
Când un user din Timișoara accesează site-ul găzduit în Frankfurt, Cloudflare îi livrează pagina direct din nodul de la București. TTFB-ul a scăzut instant de la 1.1 secunde la sub 80 de milisecunde pentru paginile de categorie și produs.
Unde e capcana? APO funcționează doar pentru vizitatorii care nu au produse în coș și nu sunt logați. În secunda în care un user adaugă ceva în coș, Cloudflare detectează cookie-ul de sesiune WooCommerce și trimite toate request-urile direct către serverul tău. Deci, pentru checkout și contul de client, tot de optimizarea bazei de date ai nevoie.
Curățenia în baza de date și eliminarea scripturilor inutile
WooCommerce are prostul obicei să încarce scripturi peste tot, chiar și pe pagina de Contact sau pe Homepage unde nu ai produse. Am folosit un snippet simplu în functions.php pentru a opri încărcarea stilurilor și scripturilor WooCommerce pe paginile unde nu avem elemente de magazin. Am economisit cam 30% la build-time-ul paginii de start.
Apoi, am trecut la baza de date. Tabelele wp_options și wp_postmeta erau pline de transients expirate și sesiuni vechi de WooCommerce de acum 3 ani. Am curățat aceste date reziduale și am activat HPOS (High-Performance Order Storage) în setările WooCommerce. Mutarea comenzilor în tabele dedicate, optimizate pentru citire/scriere rapidă, a redus timpul de procesare a unei comenzi în wp-admin cu aproape 50%.
Voi ce soluții de cache folosiți când magazinul începe să gâfâie?