// Adăugat în wp-config.php pentru a izola cache-ul Redis și a seta timeout-ul corect
define('WP_CACHE_KEY_SALT', 'magazin_prod_');
define('WP_REDIS_SELECTIVE_FLUSH', true);
define('WP_REDIS_TIMEOUT', 1);
define('WP_REDIS_READ_TIMEOUT', 1);
// Evităm stocarea sesiunilor WooCommerce în baza de date clasică
define('WP_REDIS_SESSION_MAX_LIFETIME', 86400);Am preluat anul trecut un magazin pe WooCommerce cu vreo 12.000 de produse active și un istoric de 80.000 de comenzi. Proprietarul se plângea că în timpul campaniilor de newsletter site-ul pur și simplu murea, iar baza de date atingea 100% utilizare CPU instant. Timpul de răspuns (TTFB) trecea lejer de 3 secunde pe paginile de categorie.
Dacă ai lucrat cu WooCommerce, știi deja că soluțiile clasice de page cache gen WP Rocket rezolvă doar problema vizitatorilor anonimi. Cum adaugă cineva un produs în coș sau se loghează, cache-ul de pagină devine inutil. Am rezolvat problema asta combinând trei modificări majore: Redis, Cloudflare APO și curățarea interogărilor SQL.
Redis Object Cache: Salvarea bazei de date
Cea mai mare greșeală pe care o văd la magazinele medii e lipsa unui persistent object cache. Fără el, WordPress interoghează baza de date pentru aceleași opțiuni și transient-uri la fiecare încărcare de pagină.
Am instalat Redis pe VPS și am configurat pluginul Redis Object Cache (varianta de la Till Krüss). Rezultatul a fost imediat. Interogările către baza de date pe paginile de produs au scăzut de la 120 la doar 15 per request. Baza de date a început în sfârșit să respire, iar utilizarea generală a procesorului pe server a scăzut cu 40%.
Trade-off: Redis stochează totul în memorie (RAM). Dacă ai un site masiv și puțin RAM pe server, te poți trezi că serviciul Redis dă crash și îți blochează site-ul. Pentru proiectul ăsta cu 8k useri zilnici, am alocat 512MB RAM dedicați pentru Redis și a fost mai mult decât suficient.
Cloudflare APO (Automatic Platform Optimization)
Mulți pun Cloudflare doar pentru DNS și proxy de bază. APO costă 5 dolari pe lună pentru planurile free, dar rulează pe edge-ul Cloudflare și știe nativ cum funcționează cookie-urile de WordPress și WooCommerce.
Practic, livrează paginile HTML direct din cel mai apropiat server Cloudflare pentru utilizatorii ne-autentificați. Când un user adaugă ceva în coș, Cloudflare detectează cookie-ul woocommerce_items_in_cart și face bypass la cache instantaneu. TTFB-ul pe paginile de categorie a scăzut de la 1.2 secunde la 90ms pentru vizitatorii noi.
Trade-off: Devine enervant când faci modificări în CSS sau în structura paginilor. Trebuie să golești manual cache-ul din Cloudflare, iar uneori pluginurile de stocuri terțe nu declanșează purge-ul automat, lăsând prețuri vechi afișate câteva minute.
Optimizarea query-urilor și monstrul numit wp_postmeta
WooCommerce folosește arhitectura EAV (Entity-Attribute-Value) prin tabela wp_postmeta. Când ai filtre complexe de produse (mărime, culoare, preț), WordPress face JOIN-uri multiple pe tabela asta gigantă. La noi, tabela avea peste 2 milioane de rânduri.
Am făcut două chestii. În primul rând, am activat obligatoriu HPOS (High-Performance Order Storage) de la WooCommerce, care mută comenzile în tabele dedicate, reducând masiv presiunea pe wp_posts. În al doilea rând, am adăugat constante specifice în config pentru a izola cache-ul și a preveni blocajele.
Cu aceste trei optimizări, magazinul a rezistat la o campanie de Black Friday cu peste 400 de utilizatori simultani pe checkout, fără ca serverul să mai dea vreo eroare 502.
Voi cum abordați optimizarea pe WooCommerce când baza de date începe să gâfâie? Mergeți pe tabele custom sau preferați să aruncați hardware mai scump în problemă?