Aproape orice investigație despre performanța WooCommerce începe la fel. Proprietarul magazinului s-a mutat deja pe o găzduire mai rapidă, a instalat un plugin de cache și a cumpărat un optimizator de imagini, iar site-ul rămâne lent. Concluzia lui este că WooCommerce este pur și simplu greoi, așa că renunță.

WooCommerce chiar este mai greu decât un site de prezentare, ceea ce nu poate fi evitat atunci când fiecare pagină poate purta un coș. Însă un magazin care se încarcă în șase secunde nu suferă din cauza acestei greutăți de bază. Suferă din cauza a ceva concret, iar din experiența mea este aproape întotdeauna una dintre patru cauze.

Pe scurt: magazinele sunt lente pentru că paginile de coș și de finalizare a comenzii nu pot fi servite dintr-un cache de pagină, pentru că tabela de opțiuni a crescut enorm cu date încărcate automat, pentru că interogările de produse scanează o tabelă de metadate fără indexuri și pentru că treizeci de pluginuri adaugă fiecare propriile scripturi pe orice pagină. Găzduirea este ultimul lucru pe care îl schimbi, nu primul.

De ce un magazin nu se comportă ca un blog

O singură distincție explică cea mai mare parte din comportamentul de performanță al WooCommerce.

Un articol de blog arată la fel pentru orice vizitator, deci poate fi generat o dată și servit tuturor din cache. Din acest motiv site-urile de prezentare sunt rapide aproape indiferent de cum au fost construite. Un magazin nu poate face asta pe fiecare pagină, pentru că un coș este personal. În clipa în care un vizitator adaugă un produs, pagina trebuie să reflecte starea lui, nu o copie comună pentru toată lumea.

Consecința este că paginile de coș, de finalizare și de cont ocolesc complet cache-ul de pagină și execută cod PHP și interogări în baza de date la fiecare cerere. Tot acestea sunt paginile în care lentoarea te costă bani direct. O pagină de categorie lentă pierde vizitatorii care se uită; un checkout lent pierde cumpărătorii.

Prin urmare, întrebarea utilă nu este niciodată dacă site-ul este rapid. Este cât de rapid este site-ul pentru un vizitator autentificat care are ceva în coș. Testează exact această stare, pentru că de ea depind încasările tale și tocmai pe ea o ratează orice test sintetic de viteză.

Cele patru lucruri care chiar sunt în neregulă

O tabelă de opțiuni supraîncărcată. WordPress încarcă un set de opțiuni la fiecare cerere, iar pluginurile scriu acolo fără nicio reținere. Pluginurile dezinstalate își lasă frecvent rândurile în urmă. În magazinele mai vechi această tabelă ajunge la zeci de megaocteți de date încărcate automat și citite la fiecare afișare de pagină, inclusiv la finalizarea comenzii. Este invizibilă, se acumulează an după an și este una dintre reparațiile cu cel mai bun randament disponibil. Verifică întâi dimensiunea totală a opțiunilor încărcate automat; dacă se măsoară în megaocteți și nu în kiloocteți, ai găsit timp real.

Interogări de produse pe metadate fără indexuri. Istoric, WooCommerce a păstrat atributele, prețurile și stocurile produselor într-o tabelă generică de metadate, folosită în comun cu tot restul. Filtrarea sau sortarea unui catalog mare înseamnă alăturarea repetată a acelei tabele. Cu câteva sute de produse nu observă nimeni. Cu zeci de mii, paginile de categorie și de filtre încep să se târască. Versiunile mai noi de WooCommerce au mutat datele comenzilor în tabele dedicate tocmai pentru a reduce această presiune, iar activarea acelui mod de stocare pe un magazin cu istoric lung de comenzi merită de obicei făcută chiar și singură.

Pluginuri și apeluri externe

Proliferarea pluginurilor pe traseul critic. Problema este rareori numărul în sine; este faptul că majoritatea pluginurilor își încarcă fișierele CSS și JavaScript pe fiecare pagină, în loc să o facă doar acolo unde este nevoie. Un plugin de rezervări folosit pe o singură pagină își încarcă fișierele și pe pagina ta de finalizare. Remediul nu are nimic spectaculos: verifici ce încarcă fiecare plugin, scoți fișierele în afara paginilor proprii și elimini orice lucru a cărui funcție nu o poți numi.

Apeluri externe fără cache. Tarifele de livrare în timp real, calculul taxelor, conversia valutară și verificarea stocului într-un sistem extern plasează, toate, o cerere de rețea în mijlocul încărcării paginii. Când acel furnizor este lent, checkout-ul tău este lent, iar când el pică, pică și checkout-ul tău. Orice apel extern aflat pe traseul unei cereri are nevoie de un timp maxim de așteptare, de un cache și de o soluție de rezervă pentru momentele în care serviciul nu răspunde. Ghidul nostru despre integrarea API-urilor terțe arată cum ar trebui construit acest lucru.

Ce ajută cu adevărat, în ordine

Parcurge aceste puncte în ordine, pentru că fiecare schimbă ce îți va spune măsurătoarea următoare.

Cache de obiecte, nu doar cache de pagină. Cache-ul de pagină servește pagini HTML întregi și nu poate ajuta coșul sau finalizarea comenzii. Un cache de obiecte persistent păstrează în memorie rezultatele interogărilor din baza de date și accelerează exact paginile pe care cache-ul de pagină nu le poate atinge. Pentru un magazin, aceasta este de obicei cea mai mare îmbunătățire disponibilă și este totodată pasul cel mai des sărit, pentru că pluginul de cache deja instalat a creat impresia că treaba era gata.

Întreținerea bazei de date. Șterge tranzientele expirate, elimină metadatele orfane rămase de la produse și comenzi șterse și subțiază reviziile articolelor. Într-un magazin care vinde de ani buni, asta elimină în mod obișnuit o parte importantă din baza de date. Programează operațiunea recurent, în loc să o faci o singură dată.

Apoi găzduirea. Odată ce cache-ul și baza de date sunt în ordine, găzduirea chiar contează: versiunea de PHP, memoria disponibilă, dacă baza de date rulează pe aceeași mașină și dacă ești pe găzduire partajată, în competiție cu alți chiriași. Însă mutarea înainte de a repara cele de mai sus doar relochează problema la o adresă mai scumpă.

Resursele statice la final. Formatele de imagine, încărcarea amânată și amânarea scripturilor merită făcute, iar majoritatea ghidurilor încep tocmai cu ele. Îmbunătățesc experiența de încărcare a paginilor care erau oricum servite într-un ritm rezonabil. Fac însă foarte puțin pentru un checkout care petrece patru secunde în PHP înainte de a trimite primul octet.

Cum măsori corect performanța WooCommerce

Scorurile sintetice induc în eroare proprietarii de magazine mai mult decât pe oricine altcineva, așa că măsoară deliberat.

Testează starea autentificată, cu coșul plin. Majoritatea instrumentelor testează un vizitator anonim care ajunge pe pagina principală, adică cel mai rapid traseu posibil prin site, și îți spun aproape nimic despre finalizarea comenzii.

Separă timpul serverului de timpul din browser. Dacă serverul are nevoie de trei secunde ca să producă HTML-ul, nicio optimizare de imagini nu salvează pagina. Timpul până la primul octet îți arată care jumătate a problemei te privește și, prin urmare, care dintre reparațiile de mai sus se aplică.

Folosește date de teren în locul datelor de laborator ori de câte ori poți. Vizitatorii reali, pe conexiuni și telefoane reale, produc o imagine diferită de un test rulat într-un centru de date, iar Core Web Vitals se evaluează pe primele. Ghidul nostru despre auditul de performanță WordPress explică cum se citesc corect aceste valori, iar Core Web Vitals în 2026 arată ce cer de fapt pragurile.

În final, urmărește baza de date direct în timpul unei cereri lente. Un jurnal de interogări care arată aceeași interogare rulată de două sute de ori la o singură încărcare de pagină identifică imediat vinovatul, iar tiparul acesta este extrem de frecvent în magazinele care rulează mai multe pluginuri ce cer fiecare, pe cont propriu, datele produselor.

Cât costă această muncă

Prețurile de mai jos reflectă tarifele obișnuite ale agențiilor britanice pentru un magazin de dimensiune medie.

Un audit de performanță care identifică exact cauzele, cu o listă de reparații prioritizate și cu măsurători înainte și după, ajunge în general între 900 și 2.500 de lire. Este o misiune de diagnostic și merită cumpărată separat, pentru că îți spune dacă munca rămasă înseamnă o săptămână sau o lună.

Implementarea reparațiilor obișnuite, adică cache de obiecte, curățarea bazei de date, verificarea resurselor încărcate de pluginuri și punerea în cache a apelurilor externe, costă de regulă între 2.000 și 6.000 de lire, în funcție de cât s-a adunat.

Munca mai profundă costă mai mult, pentru că este dezvoltare adevărată. Migrarea unui catalog mare către o stocare indexată, reconstruirea unui sistem de filtre care scanează metadate sau înlocuirea unui plugin lent cu o implementare proprie, țintită, se încadrează de obicei între 6.000 și 20.000 de lire.

Cifra care contează mai mult decât toate acestea este cât te costă lentoarea. Abandonul coșului crește măsurabil odată cu timpul de încărcare, așa că un magazin cu o cifră de afaceri serioasă își justifică de obicei auditul doar din pagina de finalizare a comenzii.

Repară magazinul, nu scorul

Mecanik se ocupă de performanța WooCommerce ca parte din serviciul nostru de dezvoltare WordPress , iar noi începem prin a măsura traseul de finalizare a comenzii pentru un utilizator autentificat, nu pagina principală, pentru că acolo pierd magazinele bani cu adevărat.

Ne uităm la opțiunile încărcate automat, la modul de stocare a comenzilor, la tiparele de interogări și la apelurile externe înainte de a recomanda o schimbare de găzduire, și îți dăm măsurătorile atât înainte, cât și după, ca îmbunătățirea să fie verificabilă, nu doar afirmată. Dacă magazinul tău este lent pentru că a depășit platforma, nu pentru că este configurat greșit, îți spunem și asta: comparația noastră între Shopify și comerțul electronic personalizat arată exact unde se află acea linie.

Trimite-ne adresa magazinului și, aproximativ, câte produse și câte comenzi are, iar noi îți spunem cu care dintre cele patru cauze de mai sus ai cele mai mari șanse să te confrunți.

Articole similare: WordPress spart: eliminarea programului malițios , Scalarea unui business de e-commerce în UK: Ghid 2026 , Angajarea unui dezvoltator Drupal: tarife și selecție , Cât costă un site web în Marea Britanie în 2026? .

Întrebări frecvente

De ce este lent site-ul meu WooCommerce chiar și cu un plugin de cache? Cache-ul de pagină nu poate fi aplicat paginilor de coș, de finalizare și de cont, pentru că acestea trebuie să reflecte starea proprie a fiecărui vizitator. Aceste pagini execută cod PHP și interogări în baza de date la fiecare cerere, așa că accelerarea lor cere cache de obiecte și lucru pe baza de date, nu cache de pagină.

Mutarea pe o găzduire mai bună rezolvă performanța WooCommerce? Doar parțial și nu ar trebui să fie primul pas. Dacă tabela de opțiuni este umflată, interogările nu au indexuri, iar pluginurile încarcă resurse peste tot, o găzduire mai bună face aceleași probleme puțin mai rapide, la un cost mai mare. Repară întâi cache-ul și baza de date, apoi reevaluează găzduirea.

Câte pluginuri sunt prea multe pentru WooCommerce? Numărul contează mai puțin decât ce încarcă fiecare. Douăzeci de pluginuri bine crescute, care încarcă resurse doar pe paginile proprii, fac mai puțin rău decât opt care împrăștie scripturi pe tot site-ul. Verifică ce adaugă fiecare la pagina de finalizare și elimină orice lucru al cărui scop nu îl poate formula nimeni.

Cât costă optimizarea vitezei unui magazin WooCommerce? Un audit de diagnostic cu o listă de reparații prioritizate costă de obicei între 900 și 2.500 de lire. Implementarea reparațiilor obișnuite, precum cache de obiecte, curățarea bazei de date și verificarea resurselor, ajunge în general între 2.000 și 6.000 de lire, iar refacerea catalogului sau a filtrelor poate atinge 6.000 până la 20.000 de lire.

Cum testez corect performanța WooCommerce? Testează ca vizitator autentificat, cu produse în coș, nu printr-o vizită anonimă pe pagina principală. Separă timpul de răspuns al serverului de randarea din browser ca să vezi care jumătate este lentă și folosește date de teren de la vizitatori reali, în loc să te bazezi doar pe scorurile de laborator.