-- Șterge toate transient-urile expirate din wp_options care blochează DB-ul
DELETE a, b FROM wp_options a
LEFT JOIN wp_options b ON b.option_name = CONCAT('_transient_timeout_', SUBSTRING(a.option_name, 12))
WHERE a.option_name LIKE '_transient_%'
AND b.option_value < UNIX_TIMESTAMP();Să fim sinceri: WooCommerce e o struțo-cămilă. E genial că e gratis și flexibil, dar când treci de 5.000 de produse și ai și variații, baza de date devine un coșmar de query-uri lente. Am avut anul trecut un proiect de migrare și optimizare pentru un magazin cu vreo 12.000 de produse active și peste 150 de atribute de filtrare.
Inițial, TTFB-ul (Time to First Byte) era undeva la 2.8 secunde pe paginile de categorie. Adică groaznic. După ce am aplicat cele trei tactici de mai jos, am coborât la 180ms pe paginile cache-uite și sub 1 secundă pe procesul de checkout.
Redis Object Cache – Salvarea bazei de date
WooCommerce interoghează baza de date pentru orice prostie: opțiuni, metadate de produs, stocuri, sesiuni. Fără un cache de obiecte, MySQL-ul tău va transpira masiv la fiecare pagină vizualizată.
Am instalat Redis pe server (un VPS de 15 euro pe lună pe server propriu) și am configurat plugin-ul gratuit Redis Object Cache (cel dezvoltat de Till Krüss). Ce face el? Salvează rezultatele query-urilor repetitive în memorie (RAM), în loc să bată în disc la fiecare refresh.
Trade-off-ul sincer: Redis mănâncă RAM cu pâine. Dacă ai un server mic, de 1-2 GB RAM total, te poți trezi oricând cu procesul MySQL omorât de sistem (OOM - Out of Memory). Trebuie neapărat să limitezi memoria alocată în /etc/redis/redis.conf folosind directiva maxmemory 256mb (sau cât îți permiți) și politica maxmemory-policy allkeys-lru ca să șteargă automat cheile vechi.
Cloudflare APO (Automatic Platform Optimization)
Pentru 5 dolari pe lună, serviciul ăsta de la Cloudflare e aproape magie curată pentru site-urile pe WordPress. Pe scurt, el cache-uiește paginile HTML direct în rețeaua lor globală de servere (Edge) pentru vizitatorii anonimi. Când un user nou dă click pe o categorie, request-ul nici măcar nu mai ajunge la serverul tău VPS. TTFB-ul scade instant la sub 100ms.
Unde e capcana: În momentul în care un utilizator adaugă un produs în coș, Cloudflare detectează cookie-ul de sesiune specific WooCommerce (wp_woocommerce_session_) și dă complet bypass la cache-ul din edge. Asta înseamnă că paginile de Cart, Checkout și Contul Meu vor rula mereu direct din serverul tău fizic. De asta ai nevoie în continuare de Redis și de optimizarea interogărilor; APO doar ascunde problema pentru utilizatorii care doar navighează.
Query Optimization și curățenia în wp_options
Structura de date din WordPress (EAV - Entity-Attribute-Value) e groaznică pentru magazine online mari. Totul e aruncat în wp_postmeta și wp_options. Dacă ai pluginuri de filtre care fac căutări complexe după atribute fără indexuri adecvate, baza de date va face „table scans” la greu.
Primul pas a fost să curăț mizeria acumulată. WooCommerce lasă în urmă mii de transient-uri expirate și sesiuni vechi în wp_options. Am rulat un query SQL direct în phpMyAdmin (vezi codul de mai jos) ca să scap de reziduuri.
Al doilea pas a fost instalarea unui plugin numit Index WP MySQL For Speed. Acesta adaugă indexuri compuse pe tabelele de meta, lucru care a redus timpul query-urilor de filtrare de la 1.2s la sub 0.1s. Diferența e masivă când ai 10 useri care filtrează simultan produsele după mărime și culoare.
Voi cum gestionați WooCommerce-urile mari? Ați trecut la tabele custom (Custom Product Tables) sau preferați să aruncați hardware mai scump în problemă?