-- Verifică dimensiunea datelor încărcate automat în wp_options
SELECT SUM(LENGTH(option_value)) / 1024 / 1024 AS autoload_size_mb
FROM wp_options
WHERE autoload = 'yes';
-- Identifică top 10 cele mai mari opțiuni cu autoload
SELECT option_name, LENGTH(option_value) AS length
FROM wp_options
WHERE autoload = 'yes'
ORDER BY length DESC
LIMIT 10;WooCommerce e un tanc: trage bine, dar dacă îi pui prea multe în spate fără să-i ungi roțile, abia se mai mișcă. Am optimizat zeci de shop-uri în ultimii ani și mi-am dat seama că majoritatea devilor se pierd în setări de WP Rocket, când problema e mult mai adâncă, la nivel de infrastructură și query-uri.
Nu există o setare magică, dar există o ierarhie a priorităților. Dacă ai un magazin care trece de 50 de comenzi pe zi, nu te mai poți baza pe shared hosting și un plugin de cache banal. Trebuie să ataci problema pe trei fronturi: cache-ul de obiecte, edge delivery și curățenia în baza de date.
Redis și de ce Object Cache nu e opțional
Am avut un proiect recent cu un magazin de haine, vreo 12k produse și zeci de atribute. Dashboard-ul de admin se încărca în 7-8 secunde, iar în frontend, orice filtrare dura o eternitate. Problema? WooCommerce face mii de interogări către wp_options și metadata la fiecare pagină.
Am instalat Redis pe server și am activat un plugin serios de Object Cache (recomand varianta lui Till Krüss). Rezultatul a fost instant: timpul de execuție PHP a scăzut cu 40%. Redis ține în memorie rezultatele acelor query-uri repetitive, deci baza de date nu mai este lovită la fiecare refresh.
Totuși, mare atenție la trade-off: dacă ai plugin-uri scrise prost care nu folosesc corect API-ul de cache din WordPress, s-ar putea să vezi date vechi în frontend sau prețuri care nu se actualizează imediat în coș. Trebuie să testezi bine fluxul de checkout după ce activezi Redis.
Cloudflare APO: Cheat code-ul de 5 dolari
Pentru site-urile mici și medii, Cloudflare APO (Automatic Platform Optimization) e probabil cea mai bună investiție. La un client cu trafic din toată Europa, am coborât TTFB-ul (Time to First Byte) de la 900ms la sub 100ms global.
APO e diferit de cache-ul standard pentru că „înțelege” WooCommerce. Știe să facă bypass la cache instantaneu când detectează cookie-ul de wp_woocommerce_session_ sau când cineva adaugă un produs în coș. Practic, servești pagini statice din nodurile Cloudflare pentru vizitatorii noi, dar site-ul rămâne dinamic pentru cei care cumpără. E mult mai stabil și mai rapid decât orice soluție de cache locală care trebuie să „trezească” PHP-ul ca să verifice dacă userul e logat.
Query-uri grele și dezastrul din wp_options
Degeaba ai cache dacă baza de date e un haos. Am curățat un site unde tabelul wp_options avea 600MB. Problema era coloana autoload setată pe 'yes' pentru mii de rânduri de la plugin-uri șterse acum 3 ani. La fiecare cerere, WordPress încărca toți acei 600MB în memorie.
Am făcut un script simplu care a identificat opțiunile orfane și am trecut autoload pe 'no' pentru tot ce nu era critic. Am economisit cam 30% din timpul de execuție al PHP-ului doar din asta. Un alt vinovat e Action Scheduler. Dacă nu e curățat periodic, tabelul de log-uri poate ajunge la milioane de rânduri, încetinind orice acțiune de tip cron.
Folosiți Query Monitor. E sfânt. Dacă vezi query-uri care durează mai mult de 0.05s sau care se repetă de 50 de ori, acolo e buba. De multe ori e un plugin de „Related Products” care face interogări complexe pe meta_data fără indexare corectă.
Voi ce folosiți pentru a găsi query-urile care agață în WooCommerce?