-- Verifică ce opțiuni încarcă cele mai multe date 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 15;Am lucrat recent la un magazin online cu vreo 5000 de produse unde checkout-ul dura aproape 7 secunde. Clientul era disperat, pierdea comenzi pe bandă rulantă și nicio extensie de cache „minune” nu părea să ajute. Problema cu WooCommerce e că, pe măsură ce crește numărul de produse și de comenzi, baza de date devine un câmp de luptă, iar WordPress începe să facă mii de interogări inutile la fiecare refresh.
Nu există o soluție magică dintr-un singur click, dar am aplicat o strategie în trei pași care a redus timpul de răspuns al serverului (TTFB) de la 1.8s la sub 200ms. Iată ce am învățat din experiența asta.
Redis și Object Cache: De ce nu e opțional
Fără un Object Cache serios, WordPress interoghează baza de date pentru orice bucată de metadate, opțiuni sau transients la fiecare încărcare de pagină. La un proiect cu 8k useri pe lună, asta înseamnă un load imens pe CPU-ul bazei de date. Am instalat Redis și am activat Object Cache-ul prin plugin-ul de la Redis Object Cache.
Rezultatul? Am economisit cam 30% la build time-ul paginii fiindcă majoritatea datelor care nu se schimbă des sunt servite direct din RAM. Trade-off-ul sincer aici: dacă ai un server cu RAM puțin (sub 2GB), Redis o să-ți mănânce resursele și s-ar putea să te trezești cu erori de tip „OOM” (Out Of Memory). Verifică mereu cât îi aloci.
Cloudflare APO – Cei mai bine cheltuiți 5 dolari
Mulți folosesc Cloudflare doar pentru DNS sau proxy de bază, dar Cloudflare APO (Automatic Platform Optimization) e alt nivel pentru WordPress. Practic, îți stochează întregul HTML al paginilor pe serverele lor edge. Vizitatorul primește pagina direct de la cel mai apropiat nod Cloudflare, fără ca cererea să mai ajungă la serverul tău de hosting.
Am pățit ca un site să stea în picioare în timpul unei campanii de marketing agresive doar datorită acestui serviciu. Totuși, mare atenție la „Cart Fragments”. WooCommerce are prostul obicei să facă un request AJAX (/?wc-ajax=get_refreshed_fragments) pe fiecare pagină pentru a vedea dacă ai ceva în coș. Asta poate omorî performanța chiar și cu cache. Eu prefer să dezactivez fragmentele pe paginile statice și să le activez doar unde e strict necesar.
Curățenia în wp_options și interogările SQL
Cea mai mare problemă la magazinele vechi e tabelul wp_options. Am găsit la un client 40MB de date marcate cu autoload='yes'. Asta înseamnă că la absolut fiecare request, WordPress încarcă în memorie 40MB de date inutile, de la plugin-uri șterse acum 3 ani până la log-uri uitate.
Am rulat câteva query-uri manuale să văd care sunt cei mai mari consumatori și am trecut pe autoload='no' tot ce nu era esențial pentru încărcarea inițială. De asemenea, dacă folosiți filtre complexe (brand, preț, mărime), asigurați-vă că aveți indexi pe coloanele de meta. WooCommerce a mai îmbunătățit asta cu „High-Performance Order Storage” (HPOS), pe care vă recomand să-l activați imediat ce plugin-urile voastre sunt compatibile. Mută comenzile în tabele dedicate și nu mai poluează wp_posts.
La final de zi, viteza în WooCommerce nu e despre ce plugin de optimizare imagini folosești, ci despre cât de puțin pui serverul să muncească pentru a genera HTML-ul. Voi ce scoruri aveți în PageSpeed Insights pe paginile de produs?