WooCommerce lent? 12 cauze și cum le rezolvi

Pe scurt: de ce e WooCommerce lent?

Un magazin WooCommerce lent are aproape mereu aceeași explicație: serverul, baza de date sau browserul fac mai multă muncă decât ar trebui. Cele mai frecvente cauze sunt un hosting prea slab, cache de pagină lipsă sau ocolit, lipsa unui object cache, o bază de date umflată și prea multe scripturi pe fiecare pagină.

WooCommerce nu e lent prin natura lui. Magazine bine construite, cu mii de produse, se încarcă sub o secundă. Măsori întâi, vezi care dintre cele 12 cauze de mai jos se aplică la tine și le rezolvi în ordinea impactului.

De ce devine un magazin WooCommerce tot mai lent în timp?

Un magazin nou, cu 50 de produse și cinci pluginuri, merge repede pe aproape orice hosting. Problemele apar treptat:

• fiecare comandă, sesiune de client și sarcină programată adaugă rânduri în baza de date;
• fiecare plugin nou (curier, facturare, feed, eMAG) poate aduce interogări, setări autoload și scripturi;
• marketingul adaugă pixeli, chat, widgeturi de recenzii;
• vârfurile de trafic de Black Friday scot la iveală limite care existau de la început.

Viteza contează pentru că se vede în bani. Paginile de produs lente strică Core Web Vitals și pozițiile în Google, iar un checkout lent pierde comenzi. Dacă ție magazinul ți se pare lent pe laptop, pentru un client pe un telefon mediu și pe date mobile e și mai lent.

Cum afli de ce e lent magazinul tău WooCommerce

Înainte să schimbi ceva, află unde se duce timpul: pe server sau în browser.

Simptom	Zona probabilă	Unealtă de verificare
TTFB mare pe orice pagină, chiar și din cache	Hosting, DNS, lipsă cache	PageSpeed Insights, WebPageTest
Categorii rapide, coș și checkout lente	PHP, object cache, pluginuri	Query Monitor
Admin lent, lista de comenzi greoaie	Baza de date, acțiuni programate	Query Monitor, WooCommerce → Stare (Status)
TTFB bun, dar LCP slab	Imagini, fonturi, scripturi care blochează	PageSpeed Insights, Chrome DevTools
Lent doar la vârfuri de trafic	Workeri PHP, CPU, conexiuni la baza de date	Grafice de la hosting, loguri

Conform web.dev, un TTFB de 0,8 secunde sau mai puțin este bun. Pentru Core Web Vitals, pragurile „bune” sunt LCP până la 2,5 s, INP până la 200 ms și CLS până la 0,1.

Instalează Query Monitor pe staging (sau temporar pe producție). Îți arată fiecare interogare SQL pe pagină, grupată pe plugin, și le marchează pe cele lente sau duplicate. Deschide și Unelte → Sănătate site (Site Health). Mesaje ca „Ar trebui să folosești un cache persistent pentru obiecte” (în engleză: „You should use a persistent object cache”) sau avertismentul despre opțiunile încărcate automat (în engleză: „Autoloaded options could affect performance”) merită tratate.

Cele 12 cauze pentru care WooCommerce e lent și cum le rezolvi

1. Hosting prea mic sau prea aglomerat

Găzduirea partajată ieftină pune sute de site-uri pe același server. Paginile WooCommerce care nu pot fi puse în cache (coș, checkout, cont, căutare) au nevoie de CPU real și de suficienți workeri PHP.

Soluție: un VPS sau hosting administrat pentru WooCommerce, cu resurse dedicate, PHP 8.3 sau mai nou, OPcache activ și minimum 256 MB memorie PHP, în linie cu recomandările oficiale WooCommerce. Erorile 504 Gateway Time-out sau Allowed memory size of 268435456 bytes exhausted sunt semnale clasice.

2. Lipsă cache de pagină sau cache ocolit mereu

Fără cache, fiecare vizită rulează PHP și zeci de interogări. Cu un cache prost configurat, paginile nu sunt servite din cache din cauza cookie-urilor.

Soluție: cache la nivel de server (Nginx FastCGI cache, Varnish, LiteSpeed) sau un plugin de cache bun. Exclude doar /cos/, /finalizare/ și /contul-meu/ (slug-urile implicite la o instalare în română) sau slug-urile tale reale. Verifică să nu se seteze cookie-ul wp_woocommerce_session_ pentru orice vizitator pe orice pagină.

3. Lipsa unui object cache persistent

Fără un depozit în memorie, WordPress repetă aceleași căutări în baza de date la fiecare cerere.

Soluție: Redis (sau Memcached) pe server, conectat cu un plugin precum Redis Object Cache. Câștigul se vede pe coș, checkout, contul clientului și în admin.

4. Opțiuni autoload umflate

Opțiunile marcate autoload se încarcă la fiecare cerere. Pluginurile dezinstalate lasă adesea în urmă rânduri mari.

Soluție: verifică dimensiunea totală (ajustează prefixul tabelului):

SELECT SUM(LENGTH(option_value)) FROM wp_options WHERE autoload IN ('yes','on','auto','auto-on');

Peste aproximativ 800 KB, Site Health începe să avertizeze. Listează cele mai mari rânduri, identifică pluginul și dezactivează autoload unde nu e necesar.

5. Acțiuni programate restante

WooCommerce și multe pluginuri, inclusiv cele de sincronizare cu eMAG, de feed-uri sau de facturare, folosesc Action Scheduler. Când WP-Cron rulează doar la vizite, sarcinile se adună.

Soluție: deschide WooCommerce → Stare → Acțiuni programate și uită-te la filtrele Restante (Past-due) și Eșuat (Failed). Mii de acțiuni eșuate pe același hook indică un plugin stricat. Dezactivează WP-Cron în wp-config.php cu define('DISABLE_WP_CRON', true); și rulează-l dintr-un cron real de server la fiecare minut. Șterge acțiunile finalizate mai vechi de 30 de zile.

6. Comenzi ținute încă în tabelul de postări

Magazinele mai vechi țin comenzile în wp_posts și wp_postmeta, care cresc enorm. HPOS (High-Performance Order Storage) mută comenzile în tabele dedicate și este implicit pentru magazinele noi din WooCommerce 8.2.

Soluție: WooCommerce → Setări → Avansate → Funcționalități (în engleză: Settings → Advanced → Features), activezi modul de compatibilitate ca să se sincronizeze ambele stocări, verifici că pluginurile de curier și facturare sunt compatibile, apoi treci pe HPOS. Întâi pe staging.

7. Pluginuri care se încarcă peste tot

Un plugin de formulare care își încarcă scripturile pe pagina de produs sau un plugin de rapoarte care rulează interogări grele pe fiecare ecran din admin se adună rapid.

Soluție: în Query Monitor ordonezi pluginurile după timpul de interogare. Scoți ce nu folosești, înlocuiești pluginurile grele și încarci scripturile doar unde e nevoie.

8. Imagini neoptimizate

Pozele de produs urcate direct de la fotograf, de 4–8 MB fiecare, sunt încă frecvente și decid aproape mereu LCP-ul.

Soluție: WebP sau AVIF, redimensionare la mărimea afișată, srcset, lazy loading sub fold și niciodată lazy loading pe imaginea principală a produsului. Un CDN ajută clienții aflați departe de server.

9. Temă grea sau page builder

Temele „multipurpose” și page builderele încarcă sute de kilobytes de CSS și JavaScript pe fiecare pagină, chiar dacă pagina nu le folosește.

Soluție: măsoară codul nefolosit în Chrome DevTools → Coverage. Fie elimini ce nu se folosește, fie treci pe o temă suplă, făcută pentru WooCommerce. Uneori o temă la comandă e mai ieftină decât luni de optimizări.

10. Cart fragments pe fiecare pagină

Cererea wc-ajax=get_refreshed_fragments actualizează mini-coșul și nu poate fi pusă în cache. Din WooCommerce 7.8 scriptul se încarcă doar când e afișat widgetul de coș, dar multe teme îl forțează în header.

Soluție: caută cererea în tabul Network pe pagini unde coșul nu s-a schimbat. Folosește blocul Mini Cart sau încarcă fragmentele doar după ce clientul are ceva în coș.

11. Filtre și căutare lente pe cataloage mari

Navigarea cu filtre pe multe atribute (culoare, material, dimensiune, brand) generează interogări foarte scumpe la mii de produse.

Soluție: activează tabelele de căutare pentru atribute produse din WooCommerce → Setări → Produse → Avansate (în engleză: Product attributes lookup table) și regenerează-le din WooCommerce → Stare → Unelte dacă se desincronizează. La cataloage foarte mari, mută căutarea și filtrele pe un index dedicat (Elasticsearch, OpenSearch, Meilisearch sau Algolia).

12. Scripturi terțe și apeluri live către API-uri

Chatul, heatmap-urile, mai mulți pixeli de reclame și widgeturile de recenzii pot strica INP-ul mai mult decât orice de pe serverul tău. Pe server, apelurile live către API-ul curierului pentru calculul tarifului, către ERP pentru stoc sau către programul de facturare la schimbarea statusului comenzii fac pagina să aștepte serverul altcuiva.

Soluție: curăță tagurile din Google Tag Manager, elimină duplicatele și mută măsurarea server-side unde se poate. Nu apela niciodată sincron un API extern pe pagina de produs sau în coș: stocul și prețurile se sincronizează în fundal și se citesc din baza ta de date, iar facturile și AWB-urile se generează într-o coadă.

Checklist rapid de diagnostic

• TTFB măsurat pe prima pagină, categorie, produs, coș și checkout
• PHP 8.3+, OPcache activ, memorie 256 MB sau mai mult
• Cache de pagină activ, cu coș, checkout și cont excluse
• Redis sau Memcached conectat
• Opțiuni autoload sub ~800 KB
• Fără acțiuni programate restante sau eșuate în masă; cron real activ
• HPOS activat
• Niciun plugin cu interogări lente sau repetate în Query Monitor
• Imagini WebP sau AVIF, imaginea principală fără lazy loading
• Cart fragments doar când e nevoie
• Tabelul de atribute activ pentru filtre
• Scripturi terțe auditate; niciun apel API live la încărcarea paginii

Cât costă să repari un magazin WooCommerce lent?

Estimări pentru piața din România, fără TVA, la un curs aproximativ de 5,3 lei pentru 1 euro:¹

Intervenție	Cost tipic	Observații
Upgrade de hosting (VPS sau administrat)	30–300 €/lună (aprox. 160–1.600 lei)	Cel mai mare câștig pentru majoritatea magazinelor mici
Audit de performanță	300–1.000 € o dată	Trebuie să iasă o listă ordonată de soluții, nu o captură din PageSpeed
Cache, Redis, curățare bază de date, HPOS	500–2.000 € o dată	Depinde de compatibilitatea pluginurilor
Temă nouă sau temă la comandă	2.000–8.000 €	Când tema e blocajul
Index de căutare pentru cataloage mari	1.000–5.000 € plus abonament	Mii de produse cu multe filtre

La Raao, fiecare magazin rulează pe servere cloud, dedicate sau VPS administrate de noi, iar pachetul Launch include CDN, cache și optimizarea imaginilor. Abonamentele de hosting și mentenanță pornesc de la 89 €/lună. Dacă magazinul trebuie refăcut, Starter pornește de la 1.900 €, iar Launch de la 3.900 €; vezi prețurile și serviciul de ecommerce.

Cum am procedat pentru Kuiba

Kuiba vinde peste 10.000 de produse configurabile de la peste 25 de branduri europene, exact genul de catalog care îngenunchează o instalare standard. Kuiba rulează pe o platformă construită la comandă, nu pe WooCommerce, dar principiile sunt aceleași:

• Magazin construit la comandă, optimizat pentru viteză și SEO.
• Căutare facetată instantanee, cu sinonime și rezervă AI, în loc de interogări grele la fiecare filtru.
• Importuri automate de la furnizori pentru branduri precum Bonaldo, Calligaris, Nardi și Miele, care rulează în fundal, nu la încărcarea paginilor.
• GA4 și Meta Conversions API server-side, care scot munca de măsurare din browserul clientului.

Vezi studiul de caz Kuiba. Dacă vrei să ne uităm pe cifrele magazinului tău, programează un apel gratuit de 30 de minute din pagina de contact.