Studiu de caz
Ce am găsit pe propriul magazin
Înainte să propun ShopMedic altcuiva, l-am folosit pe chinamag.eu — magazinul meu, cu comenzi reale și clienți reali. Mai jos e ce a ieșit, cu cifre și cu metoda de măsurare, ca să poți verifica singur ce citești.
Pe scurt: adminul era rupt de aproape un an, iar toate verificările automate erau verzi. 10 module instalate degeaba. Și 2,8 secunde din viteza fiecărei pagini atârnau de un singur modul, ceea ce am aflat abia după ce am măsurat corect.
Adminul era rupt de 11 luni. Nimic nu semnala nimic.
Magazinul mergea. Paginile se încărcau, clienții comandau, monitorizarea de uptime era verde. Dar zone din panoul de administrare pur și simplu nu mai funcționau — butoane care nu răspundeau, ecrane care rămâneau goale.
Cauza n-avea nicio legătură cu ce se vedea. Cândva, o „optimizare de viteză" tăiase
parametrul ?ver= din adresele fișierelor de script. Parametrul ăla e felul
în care WordPress spune „fișierul s-a schimbat, ia-l din nou". Fără el, stratul de cache
a continuat să servească fișiere de administrare
vechi de unsprezece luni, peste un WordPress actualizat între timp.
Cod nou, scripturi vechi, nimic nu se potrivea.
De ce nu-l vede nicio platformă de monitorizare: nu era nimic „căzut". Serverul răspundea 200. Paginile publice arătau perfect. O comparație de capturi de ecran n-ar fi găsit nimic, fiindcă partea stricată era în spatele autentificării. Ca să dai de asta, trebuie să citești simptomele și să te întrebi de ce — nu să bifezi o listă.
Asta e diferența pe care o vând: nu „te anunț că e roșu", ci „am aflat de ce e roșu".
Zece module pe care nu le folosea nimeni
La inventarul de după: 49 de module active. După ce am verificat unul câte unul ce face și dacă mai e folosit, au rămas 39. Zece bucăți de cod care se încărcau la fiecare vizită, cereau interogări în baza de date și trebuiau actualizate — pentru nimic.
În aceeași rundă au intrat 13 actualizări pe producție, inclusiv saltul la WooCommerce 11. Cu backup verificat înainte, ca de fiecare dată.
2,8 secunde atârnau de un singur modul
Voiam să scot un modul de cache plătit și să mut treaba pe altceva, mai ieftin. Ca să decid onest, trebuia să știu cât face de fapt. Problema: nu poți opri cache-ul pe un magazin viu doar ca să măsori.
Soluția a venit dintr-un detaliu: modulul nu cachează adresele cu parametri. Deci aceeași pagină, cerută cu un parametru în plus, e generată de la zero de WordPress — pe același server, în aceeași clipă. Comparație curată, fără să opresc nimic.
| Pagină | Cu cache | Fără cache | Diferență |
|---|---|---|---|
| Acasă — timp până la primul octet | 0,299 s | 3,127 s | de 10,5× |
| Acasă — încărcare completă | 0,391 s | 3,171 s | +2,78 s |
| Magazin — încărcare completă | 0,367 s | 2,664 s | +2,30 s |
| Coș — încărcare completă | 2,226 s | (nu se poate cacha) | — |
12 cereri per pagină, ca vizitator anonim, mediana raportată — nu media, pe care un singur vârf ar trage-o. Împrăștierea a fost mică, deci cifrele nu sunt noroc.
Verdictul a fost invers față de ce speram: modulul rămâne. Plănuisem să-l scot ca să economisesc. Cifrele au spus altceva, iar cifrele decid. Un raport care îți confirmă mereu ce vrei să auzi nu-ți e de folos.
Aceeași măsurătoare a scos la iveală și adevăratele ținte de lucru, pe care nu le bănuiam: HTML de 1,2–1,4 MB pe pagină și un coș la 2,2 secunde care, prin natura lui, nu poate fi cachat niciodată.
O rundă completă, în 26 de secunde, fără nimeni la tastatură
Asta face agentul acum, singur, fără ca eu să apăs ceva:
| Pas | Rezultat |
|---|---|
| Examinare inițială | WordPress, PHP, WooCommerce, temă, bază de date, spațiu liber |
| Verificare backup | există și e recent — se poate continua |
| Actualizări | aplicate una câte una, cu rezultatul fiecăreia notat |
| Teste pagini | 5/5 sănătoase; prima pagină semnalată ca lentă |
| Comandă de test | plasată pe checkout, verificată, ștearsă, stocul refăcut |
| Emailuri către oameni reali | zero |
Pasul care contează e al cincilea. Toată lumea verifică dacă site-ul se încarcă. Aproape nimeni nu verifică dacă se poate cumpăra. Iar cele mai scumpe defecte nu dau nicio eroare: pagina arată impecabil, butonul „Plasează comanda" pur și simplu nu face nimic, iar tu afli peste trei zile, de la un client care s-a obosit să-ți scrie.
Prima comandă de test a trimis trei emailuri reale
Pun asta aici pentru că e partea din care s-a născut cea mai bună funcție a produsului.
Prima dată când am rulat o comandă de test — pe o clonă, tocmai ca să fie sigur — au plecat trei emailuri adevărate: confirmare de comandă nouă, confirmare de procesare, și un „coș recuperat" vesel de la un modul de marketing, pentru o vânzare care nu existase niciodată. Clona nu izola emailurile, cum credeam.
Pe magazinul unui client, asta ar fi însemnat emailuri false către el, către clienții lui și către contabilitate. Nu e o pagubă mare. E genul de lucru după care nu te mai sună nimeni.
Din greșeala aia a ieșit modul de test protejat: înainte de orice comandă de probă, emailurile magazinului sunt blocate la sursă — nu la trimitere, ci mai devreme, în locul unde se decid. Comanda e marcată ca test, apoi ștearsă, iar stocul revine la loc. Modul se stinge singur după 30 de minute, ca magazinul să nu rămână mut dacă se întrerupe ceva la mijloc.
L-am validat repunând exact condițiile care produseseră emailurile: aceleași module active, aceleași notificări pornite. A doua comandă de test: zero emailuri, confirmat din notele comenzii.
Ce înseamnă asta pentru magazinul tău
Nimic din ce e mai sus nu e neobișnuit. Un cache care servește fișiere vechi, module instalate și uitate, un checkout care se rupe tăcut după o actualizare — astea se întâmplă în fiecare magazin WooCommerce care are câțiva ani și treizeci de module.
Diferența nu e că problemele apar. E că cineva se uită în fiecare săptămână, duce fiecare constatare până la cauză, și îți spune în română ce a găsit.
Toate cifrele de mai sus sunt măsurate pe chinamag.eu între 6 și 7 august 2026. Magazinul e al meu — de asta am putut publica și partea cu greșeala.