-- Verifică dimensiunea totală a datelor încărcate automat la fiecare request
SELECT
ROUND(SUM(LENGTH(option_value)) / 1024 / 1024, 2) AS total_autoload_mb
FROM wp_options
WHERE autoload = 'yes';
-- Identifică primii 10 consumatori masivi din wp_options
SELECT
option_name,
ROUND(LENGTH(option_value) / 1024, 2) AS size_kb
FROM wp_options
WHERE autoload = 'yes'
ORDER BY LENGTH(option_value) DESC
LIMIT 10;Anul trecut am preluat un magazin WooCommerce cu vreo 14.000 de produse care făcea meltdown la fiecare campanie de reduceri. TTFB-ul pe paginile de produs era undeva la 1.8 - 2.2 secunde, iar baza de date înghițea 90% din resursele serverului. În postarea asta vă arăt exact cum am coborât TTFB-ul sub 200ms combinând Redis, Cloudflare APO și un pic de curățenie în query-uri.
Redis Object Cache: salvați RAM-ul, dar setați limite
WordPress face sute de interogări SQL pe fiecare request dacă nu aveți un persistent object cache. Pe magazinul respectiv, o simplă afișare de produs rula peste 180 de query-uri. După ce am configurat Redis și pluginul Redis Object Cache (am folosit varianta Pro pentru bucățile specifice de WooCommerce, dar și varianta free își face treaba), numărul de interogări care atingeau efectiv MySQL a scăzut la 22 per request.
Atenție totuși la un trade-off clasic: Redis stochează totul în memorie. Dacă aveți transients generate aiurea de plugin-uri de marketing, Redis vă va mânca 2-4GB RAM în câteva ore și va pica service-ul. Setați o politică de eviction clară în redis.conf (maxmemory-policy allkeys-lru) ca să nu aveți surprize noaptea.
Cloudflare APO: HTML livrat direct din Edge
Cache-ul la nivel de Nginx sau LiteSpeed e excelent, dar Cloudflare Automatic Platform Optimization (APO) duce pagina direct în serverele lor Edge. Costă $5/lună și știe să facă bypass automat în momentul în care detectează cookie-urile dinamice de WooCommerce (woocommerce_items_in_cart sau wp_woocommerce_session_).
Rezultatul? Un utilizator neautentificat care intră pe o pagină de categorie primește HTML-ul instant în ~30-50ms direct din POP-ul din București sau Frankfurt. Problema apare când aveți plugin-uri prost scrise care setează cookie-uri de sesiune WooCommerce pentru toti vizitatorii anonimi, anulând complet cache-ul. Verificați mereu header-ul cf-cache-status (trebuie să fie HIT pe paginile publice de catalog).
Query optimization și capcana din wp_options
Degeaba aveți Redis dacă opțiunea wp_options încarcă 12MB de date la FIECARE request din cauza opțiunilor cu autoload = 'yes'. La proiectul ăsta am găsit peste 25MB de transients expirate și loguri vechi puse pe autoload de un plugin de curierat.
De asemenea, activarea HPOS (High-Performance Order Storage) este obligatorie pe orice WooCommerce modern. Mutarea comenzilor din wp_posts și wp_postmeta în tabelele dedicate (wp_wc_orders) a redus dimensiunea bazei de date cu 40% și a tăiat timpii de procesare la checkout la jumătate pe un istoric de 60k comenzi.
Uitați mai jos interogarea SQL pe care o rulez mereu prima dată când aud că "se mișcă greu site-ul":
Ați făcut deja tranziția la HPOS pe proiectele clienților sau încă vă loviți de plugin-uri terțe incompatibile?