-- Identifică cele mai mari opțiuni încărcate automat la fiecare request (autoload = 'yes')
SELECT option_name, length(option_value) AS option_size_bytes
FROM wp_options
WHERE autoload = 'yes'
ORDER BY option_size_bytes DESC
LIMIT 15;Am preluat acum două luni un magazin WooCommerce cu ~12.000 de produse și peste 80k vizite lunare care se mișca groaznic. TTFB-ul pe paginile de categorie depășea lejer 2.8 secunde, iar serverul de BD pur și simplu gâfâia. Fără să schimbăm abonamentul de hosting (un VPS mediu de 45$/lună), am coborât TTFB-ul la sub 350ms folosind o combinație de Redis, Cloudflare APO și puțină curățenie în baza de date.
1. Redis Object Cache (unde se greșește cel mai des)
WooCommerce este notoriu pentru modul în care interoghează baza de date. La fiecare pagină de produs afișată, WordPress execută zeci de interogări doar pentru opțiuni, atribute și transiente. Fără un persistent object cache, serverul SQL procesează aceleași date din nou și din nou.
Am instalat Redis și am activat pluginul Redis Object Cache. Atenție mare la trade-off aici: Redis salvează totul în RAM. Dacă aveți un magazin mare și nu setați o politică de maxmemory (de exemplu allkeys-lru), serverul va intra în OOM (Out Of Memory) și va pica. De asemenea, dacă găzduiți mai multe site-uri pe același server Redis, trebuie să setați un WP_CACHE_KEY_SALT unic în wp-config.php. Am pățit-o acum câțiva ani când un client vedea coșul altui client dintr-un alt site instalat pe aceeași mașină.
2. Cloudflare APO (5$ care fac diferența)
Pentru site-uri dinamice precum cele de Woo, un CDN clasic ajută doar la imagini și asset-uri statice. Paginile HTML rămân dinamice și trec direct prin server. Cloudflare APO (Automatic Platform Optimization) schimbă jocul pentru că știe să facă cache la nivel de edge pentru tot HTML-ul, fără să strice funcționalitatea de e-commerce.
Cum funcționează? APO detectează automat cookie-urile specifice WooCommerce (woocommerce_items_in_cart sau wp_woocommerce_session_). Dacă vizitatorul este anonim și are coșul gol, Cloudflare îi servește pagina direct din edge-ul cel mai apropiat în < 50ms. În momentul în care userul adaugă ceva în coș, se setează cookie-ul, iar APO face bypass automat către serverul vostru pentru toate cererile ulterioare.
Câștigul direct: am tăiat 80% din traficul neautentificat care atingea PHP-ul și baza de date.
3. Igiena din wp_options și interogările grele
Redis rezolvă multe, dar dacă tabelul wp_options este imens, primul request care populează cache-ul va fi tot lent. La proiectul de care vă ziceam, am găsit 18MB de date marcate cu autoload = 'yes'. Asta înseamnă că la absolut orice request HTTP, WordPress trăgea 18MB de text din MySQL în RAM.
Am rulat un query simplu să văd ce ocupă atâta spațiu și am descoperit zeci de mii de transients expirate lăsate în urmă de un plugin vechi de filtru, plus session data vechi de 2 ani. După ce am curățat mizeria și am redus autoload-ul sub 1MB, timpul de executare al interogărilor SQL principale a scăzut cu 60%.
Trade-off-ul la WooCommerce rămâne mereu același: paginile de Checkout și Cart nu pot fi cache-uite complet. Dar eliminând presiunea pe 90% din traficul de browsing (categorii, produse, homepage), serverul are resurse arhi-suficiente să proceseze rapid checkout-ul când cumpărătorul e gata să plătească.
Voi ce abordare folosiți pentru magazinele mari pe Woo? Preferați soluții la nivel de server (Nginx FastCGI cache) sau mergeți tot pe variante cloud / CDN ca Cloudflare?