Ai trecut pe Hyvä și magazinul tot e lent. De ce?

Ai făcut ce trebuia. Ai renunțat la Luma, ai plătit pentru o implementare Hyvä și ai așteptat să se miște cifrele. Nu s-au mișcat. Magazinul tot merge greu, scorul pe mobil tot e jenant, iar cineva din echipă începe să întrebe dacă a meritat Hyvä.

A meritat. Doar că tema aproape niciodată nu e motivul pentru care un magazin Magento e lent, iar asta nu ți-a spus-o nimeni înainte să semnezi.

Hyvä nu garantează performanța. Implementarea o garantează.

Hyvä înlocuiește frontend-ul. Îți dă un layer de template curat, fără bagajul de JavaScript al Luma, și face dezvoltarea sensibil mai ieftină, pentru că nu mai lupți cu Knockout și cu RequireJS la fiecare schimbare.

Ce nu îți dă Hyvä e un scor. Dacă te uiți la magazinele Hyvä din HTTP Archive, scorul median Lighthouse e în jur de 47,5. Nu 90, nu 100. Mediana aceea e exact argumentul: aceeași temă, pe mâini diferite, dă rezultate complet diferite. „Am instalat Hyvä” nu e un răspuns la întrebarea „cât de rapid e magazinul meu”.

Partea pe care Hyvä nu o atinge e tot ce se întâmplă înainte ca browserul să primească primul byte. Dacă serverului îi trebuie opt secunde ca să producă HTML-ul, cea mai rapidă temă din ecosistem tot îți va livra o pagină lentă. Hyvä a rezolvat partea pe care o vedeai. Partea pe care nu o vedeai nu a fost atinsă niciodată.

Ce înseamnă de fapt „tot e lent”

În magazinele pe care le preluăm, cauza e aproape întotdeauna una dintre trei, și de obicei toate trei simultan.

• Module terțe pe care nu le-a auditat nimeni. Fiecare extensie instalată ca să rezolve o problemă mică rulează în continuare la fiecare request, inclusiv cele pe care nu le mai folosești de doi ani.
• O bază de date care muncește mult mai mult decât are nevoie pagina. Interogările necachate se înmulțesc discret. Am deschis o singură pagină de produs și am numărat 15 milioane de operațiuni în baza de date, niciuna venind de la Magento.
• Un server configurat pentru altceva. Redis, Varnish și layerele de cache sunt de obicei instalate și de obicei prost configurate, așa că magazinul plătește pentru infrastructură pe care nu o folosește.

Nimic din toate astea nu e o problemă de Hyvä. Toate supraviețuiesc neatinse unei schimbări de temă, și toate rămân acolo după ce factura pentru temă a fost plătită.

Cum verifici dacă o cifră de performanță e reală

Cifrele de performanță sunt ușor de afirmat și greu de verificat. Un scor bun poate veni dintr-o singură rulare, pe o pagină aleasă cu grijă, într-o zi bună. Ce contează nu e cifra în sine, ci dacă poți ajunge singur la ea.

Înainte să crezi orice cifră, a noastră inclusiv, cere patru lucruri.

• Date de teren, nu de laborator. Un scor PageSpeed e un test unic, pe o rețea simulată, și se schimbă de la o rulare la alta. Chrome UX Report și raportul Core Web Vitals din Search Console măsoară utilizatori reali, pe telefoanele lor reale.
• Originea măsurată și fereastra de timp. CrUX raportează percentila 75 pe o fereastră glisantă de 28 de zile, pentru o origine anume. Dacă nu ți se spune care origine și care fereastră, cifra nu înseamnă nimic.
• Înainte și după, pe aceeași proprietate. Comparația are valoare doar dacă ambele capete vin din aceeași sursă, pentru același domeniu, măsurate la fel.
• Data la care a fost citită. Datele de teren se schimbă săptămânal. O cifră fără dată e o cifră fără garanție.

Dacă o cifră trece cele patru teste, o poți verifica singur, fără noi. Dacă nu le trece, nu e o măsurătoare, e o afirmație. De aceea cifrele de mai jos vin cu metoda lângă ele.

Dovada noastră, cu metoda la vedere

Equitana vindea echipament ecvestru pe Magento 1, la șase ani după finalul oficial al platformei. Am reconstruit magazinul pe Magento 2, Hyvä și Liquid Framework și am mutat peste 14.500 de produse, peste 300 de categorii, peste 3.400 de conturi de clienți și peste 12.000 de comenzi.

Cifrele de mai jos sunt percentila 75 din Chrome UX Report pentru originea www.equitana.ro, citite pe 29 septembrie 2026. „Înainte” e ultima fereastră cu trafic doar pe Magento 1, 19 iulie până la 15 august 2026. „După” e fereastra 30 august până la 26 septembrie 2026, integral pe magazinul nou.

• LCP pe mobil: 4.234 ms înainte, 1.109 ms după. Cât așteaptă un vizitator real până vede conținutul principal.
• Răspunsul serverului pe mobil: 3.653 ms înainte, 344 ms după. Exact partea pe care o schimbare de temă nu o atinge.
• LCP pe desktop: 3.502 ms înainte, 1.001 ms după. Iar saltul de layout pe mobil a trecut de la 0,07 la 0.

Raportul Core Web Vitals din Search Console, pentru proprietatea de domeniu equitana.ro, citit pe 4 octombrie 2026, spune același lucru altfel. Pe mobil, înainte: 3 adrese bune, 1.194 care aveau nevoie de îmbunătățiri, 198 slabe. După: 1.761 de adrese bune și zero în celelalte două categorii. Adică 0,2% din adrese erau bune înainte, și 100% după.

Studiul de caz complet, cu graficele săptămânale și sursa fiecărei cifre, e aici: Equitana, de la Magento 1 la Hyvä.

Magazinul care era deja pe Hyvä

Equitana venea de pe o platformă moartă, deci era un caz ușor de explicat. Vitacom nu era.

Vitacom vinde electronice pe B2C, B2B și export, și e pe piață din 1991. Când au venit la noi, magazinul era deja pe Hyvä. Și era în continuare lent, fragil și expus. După logica obișnuită, Hyvä eșuase.

Nu am schimbat platforma și nu am înlocuit tema. Am securizat serverul și am adus Magento la zi cu toate patch-urile, am curățat stratul de module terțe, am reconstruit modulele proprii care puteau corupe date, am mutat căutarea pe OpenSearch și am refăcut layerele de date și de cache. Aceeași platformă, aceeași temă, trei magazine care merg: public, B2B și export.

Măsurat pe utilizatori reali, tot din Chrome UX Report, percentila 75 pentru originea www.vitacom.ro, cifre citite pe 30 septembrie 2026. În fereastra de 28 de zile încheiată pe 27 decembrie 2025, LCP pe telefon era 3,08 s și răspunsul serverului 2,34 s. În fereastra încheiată pe 26 septembrie 2026, LCP pe telefon era 1,35 s și răspunsul serverului 0,67 s. Tema a fost aceeași tot timpul. S-a schimbat ce era sub ea.

Hyvä nu a fost niciodată problema. Implementarea a fost.

Proiectul e documentat în studiul de caz Vitacom, iar funcționalitatea de catalog B2B închis construită acolo a ajuns să fie prezentată la Florența și la Paris, în fața comunității Magento și Hyvä. Am scris despre ea aici.

Testul pe care îl poți face în cinci minute

Încarcă o pagină de produs și uită-te la timpul până la primul byte, nu la scorul general. Dacă e sub 200 ms și scorul tot e slab, merită investigat frontend-ul. Dacă se măsoară în secunde, nicio muncă pe frontend nu te salvează, iar cine îți propune o refacere a temei îți vinde altceva decât ai nevoie.

Un avertisment la testul de mai sus. Dacă Varnish servește pagina din cache, timpul până la primul byte arată excelent și nu îți spune nimic despre magazin. Testează o pagină pe care cache-ul nu o are, de exemplu un produs pe care nu l-a mai deschis nimeni azi, sau adaugă un parametru fără sens la finalul adresei ca să forțezi o generare nouă. Diferența dintre pagina din cache și pagina generată e exact munca pe care tema nu o face. Dacă prima e rapidă și a doua ia secunde, ai găsit problema.

Apoi fă și verificarea pe date reale, pentru domeniul tău. Raportul Core Web Vitals din Search Console îți arată câte adrese sunt bune, câte au nevoie de îmbunătățiri și câte sunt slabe, separat pe telefon și pe desktop. Dacă ai trecut pe Hyvä acum câteva luni și coloana „bune” de pe telefon nu s-a mișcat, ăsta e răspunsul: schimbarea nu a ajuns la utilizatorii reali.

Asta e diferența dintre un magazin care are nevoie de optimizare și unul care are nevoie de salvare. Dacă vrei metoda pas cu pas pe Core Web Vitals, e într-un articol separat.

De ce să ne crezi pe noi

LIQUIDLAB lucrează doar cu Magento. Suntem partener Hyvä din 2024 și primul partener Hyvä certificat oficial din România. Nu folosim doar Hyvä și Magento, contribuim și la ele: modulele și corecțiile pe care le punem în comunitate sunt publice, pe github.com/liquidlab-agency. Tot ce susținem mai sus poate fi verificat independent.

Ce faci mai departe

Dacă cifrele de mai sus îți sună cunoscut, pune pe cineva să se uite serios la cod și la server înainte să mai cheltui ceva pe frontend. Analiza noastră completă de cod și server costă 999 EUR și include 30 de zile de suport după. Rezultatul e un plan de recuperare și modernizare care îți aparține și care funcționează cu orice agenție, inclusiv cu cea pe care o ai deja. Nu există lock-in, și asta e intenționat.

Dacă vrei ca aceeași echipă să ducă și planul la capăt, oferim servicii Magento complete, de la audit și preluare până la mentenanță cu SLA.

Tehnologia nu a fost niciodată ce ținea magazinul pe loc. Află ce a fost: rezervă o discuție de 30 de minute, fără obligații.