-- 1. Verifică dimensiunea totală a datelor Autoloaded în wp_options
SELECT SUM(LENGTH(option_value)) / 1024 / 1024 AS autoload_size_mb
FROM wp_options
WHERE autoload = 'yes';
-- 2. Identifică cele mai mari opțiuni care se încarcă la fiecare request
SELECT option_name, LENGTH(option_value) AS option_size_bytes
FROM wp_options
WHERE autoload = 'yes'
ORDER BY option_size_bytes DESC
LIMIT 10;
-- 3. Curăță transients expirate răsfiate prin wp_options
DELETE FROM wp_options
WHERE option_name LIKE '_transient_timeout_%'
AND CAST(option_value AS UNSIGNED) < UNIX_TIMESTAMP();Am avut recent un proiect pentru un client cu un magazin WooCommerce ce trecuse de 40.000 de produse și vreo 150.000 de comenzi în istoric. Pagina de produs se încărca în aproape 3.5 secunde, iar TTFB-ul oscila între 1.5s și 2.2s pe un VPS destul de bănos. După trei zile de tweaking, am coborât TTFB-ul la sub 220ms pe paginile dinamice și sub 40ms pe cele servite din cache.
Dacă te lupți cu viteza pe Woo, uită de plugin-urile minune de tip „all-in-one speed up”. Problema e aproape mereu în baza de date și în modul în care WordPress procesează request-urile PHP.
1. Object Cache cu Redis (Salvarea bazei de date)
WordPress rulează zeci de interogări SQL doar ca să-ți afișeze un produs simplu cu câteva variații, atribute și recenzii. Pe un magazin cu trafic, MySQL devine rapid bottleneck-ul principal.
Am instalat Redis server pe VPS și am configurat drop-in-ul de object-cache.php. Ce face concret? Salvează interogările complexe și transients-urile direct în memoria RAM. Pe proiectul de care vă spun, numărul de interogări DB per request pe pagina de produs a scăzut de la 180+ la doar 14.
Trade-off sincer: Redis consumă RAM. Dacă ești pe un VPS ieftin de 2GB și ai trafic mare, Redis va atinge limita de memorie și va începe să șteargă chei sau, mai rău, va prăbuși PHP-FPM-ul din cauză de OOM Kill. Trebuie configurată atent directiva maxmemory în redis.conf și pusă o politică de evicțiune de tip allkeys-lru.
2. Cloudflare APO (Edge Caching pentru e-commerce)
Servirea paginilor din CDN pentru WordPress era un coșmar în trecut din cauza cookie-urilor WooCommerce (coș, sesiune user, articole recente). Dacă făceai cache agresiv, un utilizator vedea coșul altuia.
Cloudflare APO (Automatic Platform Optimization) costă 5$ pe lună și rezolvă exact asta. Cachează tot HTML-ul generat direct la nivel de Edge Node, iar în secunda în care detectează cookie-ul woocommerce_items_in_cart sau un utilizator autentificat, face bypass automat către serverul tău de origine.
Rezultatul? Un vizitator nou care vine din Google pe o categorie primește HTML-ul în 35ms direct din POP-ul Cloudflare din București sau Frankfurt, fără ca PHP-ul sau MySQL-ul tău să miște vreun deget.
3. Curățenie în wp_options și interogări lente
Asta e o zonă pe care mulți o ignoră. Am intrat în baza de date și am verificat mărimea datelor autoload = 'yes' din tabela wp_options.
Scenariul groazei: aveam 18 MB de date care se încărcau la FIECARE request PHP, indiferent că omul era pe checkout sau pe o pagină de contact. Multe pluginuri vechi sau dezinstalate își lasă opțiuni uriașe setate pe autoload.
Am curățat transients expirate și am schimbat flag-ul de autoload pe no pentru opțiunile mari care nu aveau nevoie să fie încărcate global. De asemenea, dacă folosiți WooCommerce 8+, activați neapărat High-Performance Order Storage (HPOS). Mută comenzile din wp_posts și wp_postmeta în tabele dedicate, optimizate SQL, ceea ce taie masiv din timpul de procesare pe checkout.
Voi ce setup folosiți pe producție pentru magazine mărișoare? Mergeți pe Nginx microcaching sau soluții SaaS la nivel de DNS/Edge?