-- Curățarea tranzienților expirați direct din baza de date
DELETE FROM wp_options
WHERE option_name LIKE '_transient_%'
AND option_name NOT LIKE '_transient_timeout_%'
AND option_name IN (
SELECT SUBSTRING(option_name, 12)
FROM (
SELECT option_name FROM wp_options
WHERE option_name LIKE '_transient_timeout_%'
AND option_value < UNIX_TIMESTAMP()
) AS expired_transients
);
-- Adăugarea unui index pe coloana autoload pentru optimizarea wp_options
ALTER TABLE wp_options ADD INDEX wp_options_autoload (autoload);Am preluat recent un WooCommerce cu peste 15.000 de produse și vreo 80 de atribute care aproape că își dădea duhul. TTFB-ul (Time to First Byte) era de peste 2.5 secunde pe paginile de categorii. La campaniile mari de marketing, serverul pur și simplu pica sub presiune. Am reușit să coborâm sub 800ms fără să schimbăm hostingul de 30 de euro pe lună.
Nu am făcut asta cu pluginuri de optimizat imagini sau minify de CSS, ci atacând direct problemele de backend: baza de date și cache-ul de obiecte.
Redis Object Cache nu este opțional
WooCommerce interoghează baza de date agresiv. Pentru fiecare produs dintr-o listă, WordPress verifică stocul, prețul, imaginile și taxele. La 24 de produse pe pagină, ai deja sute de interogări SQL redundante.
Am instalat Redis pe server și am activat pluginul Redis Object Cache (cel dezvoltat de Till Krüss). Am salvat cam 40% din timpul de execuție PHP pentru că datele frecvente stau acum în memoria RAM, nu mai interoghează MySQL-ul non-stop.
Trade-off-ul sincer: Dacă ai scripturi externe sau ERP-uri care actualizează stocurile direct în baza de date prin query-uri SQL brute, Redis nu va ști de ele. Vei afișa stocuri vechi clienților până expiră cache-ul. Pentru a evita asta, trebuie să folosești neapărat API-ul de WordPress sau să cureți programatic cache-ul la importuri.
Cloudflare APO (Automatic Platform Optimization)
Pentru 5 dolari pe lună, serviciul ăsta de la Cloudflare este pur și simplu un cheat code. El face cache la paginile HTML direct în rețeaua lor globală (edge servers).
Asta înseamnă că pentru un vizitator nou, nelogat, timpul de răspuns scade la sub 100ms, deoarece request-ul nu mai ajunge fizic la serverul tău VPS. Partea extrem de utilă este că APO știe nativ de WooCommerce. Dacă detectează cookie-urile de coș activ (wp_woocommerce_session_) sau sesiunea de checkout, face bypass la cache instantaneu, asigurând un flux corect de plasare a comenzilor.
Totuși, ai grijă dacă folosești pluginuri non-standard de "quick cart" sau mini-cart-uri custom în header care nu folosesc AJAX. Riști să servești coșul de cumpărături al unui client către un alt vizitator anonim. Testează intensiv în modul incognito înainte să lași totul în producție.
Curățenia în wp_options și indecși SQL
Mulți uită că WooCommerce folosește tabela wp_options pentru a stoca tranzienți (cache temporar). Am găsit în baza de date a clientului peste 180.000 de rânduri de tranzienți expirați care îngreunau orice query de tip autoload = 'yes'.
Am rulat o curățare rapidă direct în baza de date și am adăugat un index pe coloana autoload. WordPress caută implicit după această coloană la fiecare accesare de pagină, dar tabela standard nu vine cu acest index creat din fabrică. Diferența s-a simțit imediat în admin-ul WordPress, care înainte se încărca în 6-7 secunde, iar acum se deschide instant.
Tu ce strategie folosești când baza de date de WooCommerce începe să gâfâie? Rămâi pe upgrade de resurse la VPS sau încerci să optimizezi query-urile și cache-ul?