Magazinul e pe Hyvä și tot e lent. De unde vine problema

Primim frecvent întrebarea asta de la magazine pe care nu le-am construit noi: au migrat pe Hyvä, au plătit licența, iar PageSpeed arată tot roșu. Frustrarea e legitimă — dar Hyvä nu a promis niciodată ce cred mulți că a promis.

Hyvä rezolvă frontend-ul. Nu are cum să repare un backend lent, un hosting subdimensionat sau 40 de module scrise prost.

Iată cele cinci cauze pe care le găsim, în ordinea frecvenței.

1. TTFB mare — problema e în server, nu în temă

Time To First Byte măsoară cât durează până serverul trimite primul octet. Dacă TTFB-ul tău e peste 600 ms, tema nu contează: pagina începe să se încarce târziu indiferent cât de ușor e frontend-ul.

• Verifică dacă Varnish e activ și chiar servește din cache, nu doar instalat.
• Verifică dacă Redis e configurat pentru sesiuni și cache, nu doar pornit.
• Uită-te la indexarea Magento — indexuri blocate sau în mod „update on save” pe un catalog mare ucid performanța.
• Verifică resursele reale ale serverului. Magento pe hosting partajat nu are cum să fie rapid.

2. Module care injectează JavaScript

Hyvä scoate Knockout și RequireJS din temă. Nu poate scoate scripturile pe care le adaugă modulele terțe. Un modul de chat, unul de recenzii și trei de marketing pot reintroduce exact balastul pe care tocmai l-ai eliminat.

Verificarea e simplă: deschide fila Network, filtrează pe JS și uită-te ce se încarcă înainte de primul paint. Ce nu e esențial pentru randare trebuie amânat sau scos.

3. Imagini neoptimizate

Cauza cea mai banală și cea mai frecventă. O imagine de produs de 800 KB servită la 400 px lățime strică LCP-ul de una singură, indiferent de temă.

• Servește WebP sau AVIF, cu fallback.
• Dimensionează imaginile la ce se afișează efectiv, nu la ce a încărcat clientul în admin.
• Pune width și height pe fiecare imagine — altfel plătești în CLS.
• Încarcă amânat tot ce e sub fold, dar niciodată imaginea principală de produs.

4. Third-party scripts

Google Tag Manager cu 15 tag-uri, pixel Meta, hărți de căldură, chat, testare A/B. Fiecare pare inofensiv. Împreună adaugă secunde.

Măsoară-le: dezactivează temporar GTM și compară. De multe ori, jumătate din problema de viteză stă în lucruri pe care le-a adăugat echipa de marketing, nu cea de dezvoltare.

5. Implementarea Hyvä în sine

Se întâmplă și asta: o migrare făcută în grabă, în care s-au portat componente vechi în loc să fie rescrise, sau în care s-a păstrat compatibilitatea cu module Luma prin straturi de compat. Rezultatul e Hyvä pe hârtie și Luma în practică.

Semnul clar: dacă în bundle-ul de JS mai apar requirejs sau knockout, migrarea nu e completă.

Cum afli care dintre cele cinci e cazul tău

1. 01Măsoară TTFB separat de restul. Dacă e mare, oprește-te aici — restul nu contează până nu îl rezolvi.
2. 02Rulează PageSpeed pe date de teren, nu de laborator. Datele de laborator mint frumos.
3. 03Deschide Network și sortează după dimensiune. Primele cinci resurse îți spun de obicei tot.
4. 04Compară cu și fără GTM.
5. 05Caută requirejs în sursa paginii.

Ce facem când preluăm un Hyvä lent

Începem cu analiza de cod: ce module ai, ce injectează fiecare, ce s-a portat prost la migrare. Din raport iese lista de intervenții, în ordinea impactului asupra vânzărilor — nu în ordinea în care sunt ușor de făcut.

Dacă magazinul are nevoie de întreținere continuă, nu doar de o reparație, abonamentul de mentenanță include monitorizarea Core Web Vitals, ca să nu ajungi din nou în situația asta peste un an. Mai multe despre ce facem pe pagina de Hyvä și despre optimizarea de performanță.