/* Identifică cele mai mari opțiuni care se încarcă automat la fiecare request */
SELECT
option_name,
LENGTH(option_value) AS option_value_length
FROM
wp_options
WHERE
autoload = 'yes'
ORDER BY
option_value_length DESC
LIMIT 20;Să fim sinceri: WooCommerce poate deveni un melc obosit extrem de repede dacă îl lași pe setările default și adaugi câteva pluginuri de marketing. Am salvat recent un shop de piese auto cu vreo 14.000 de produse unde timpul de încărcare pe pagina de produs sărise de 6 secunde. Clientul pierdea clienți zilnic din cauza asta, iar serverul (un VPS destul de bunicel) stătea în 100% CPU constant.
După trei optimizări bine țintite, am coborât TTFB-ul (Time to First Byte) la sub 150ms pentru paginile cache-uite și am redus încărcarea pe baza de date cu aproape 70%. Iată exact ce am făcut, fără vrăjeli de marketing.
1. Redis Object Cache: De ce nu e opțional
WooCommerce face sute de interogări în baza de date pentru a asambla o singură pagină de produs: atribute, variații, prețuri, recenzii și metadate. Fără un object cache, MySQL pur și simplu crapă când ai mai mult de 20-30 de utilizatori simultan pe site.
Am instalat Redis pe server și am configurat pluginul Redis Object Cache (varianta gratuită a lui Till Krüss e excelentă). Object caching-ul reține rezultatele interogărilor complexe în memorie (RAM), eliminând complet drumurile repetate către MySQL.
Trade-off sincer: Redis consumă RAM. Mult RAM dacă ai zeci de mii de variații de produse. Pe un VPS de 1GB RAM, dacă pui Redis, riști să-ți crape procesele de PHP din lipsă de memorie (OOM killer). Pentru un magazin mediu, recomand minimum 4GB RAM pe server ca să dormi liniștit noaptea.
2. Cloudflare APO (Automatic Platform Optimization)
Pentru utilizatorii neautentificați (care reprezintă peste 90% din traficul unui magazin), Cloudflare APO este pur și simplu magic. Costă 5 dolari pe lună (dacă ești pe planul free) și livrează HTML-ul paginilor direct din rețeaua lor globală de servere (edge servers).
Înainte de APO, chiar și cu cache pe server (Nginx FastCGI cache), request-ul tot trebuia să ajungă în serverul nostru din București. Acum, un user din Spania primește pagina în 50ms direct dintr-un nod Cloudflare local.
Trade-off-ul: Trebuie să fii extrem de atent la dinamică. APO știe nativ de cookie-urile de sesiune WooCommerce (woocommerce_items_in_cart sau wp_woocommerce_session_), deci când un user adaugă ceva în coș, Cloudflare face bypass la cache. Însă, dacă ai pluginuri de tip "Wishlist" sau "Recent viewed products" care folosesc PHP direct în pagină fără AJAX, APO le va strica. Toate elementele dinamice trebuie încărcate neapărat prin AJAX.
3. Curățenia de primăvară în wp_options
Problema clasică a WordPress-ului: tabela wp_options se umple de gunoi. WooCommerce și diverse pluginuri de analytics sau newsletter salvează mii de rânduri de date temporare (transients) cu opțiunea autoload = 'yes' activată. Asta înseamnă că la absolut fiecare request, WordPress încarcă acele date în memorie.
Am avut cazul unui site unde se încărcau 45MB de date din wp_options la fiecare pagină vizualizată. Am rulat query-ul de mai jos ca să identificăm vinovații. Am găsit mii de transients vechi de la un plugin de curierat dezinstalat acum doi ani. Le-am șters, am limitat autoload-ul doar la ce era strict necesar și am redus dimensiunea tabelei de la 120MB la doar 4MB.
Tu ce soluție folosești pentru baza de date când WooCommerce începe să dea semne de oboseală?