Magento · 14 august 2026 · 9 min citire
De ce magazinul are scor bun la PageSpeed și e lent la clienți
Scorul din PageSpeed e o simulare pe un telefon care nu există, dintr-o rețea care nu e a nimănui. Datele care contează sunt altele, și sunt gratuite.
Situația e frecventă și derutantă: rulezi PageSpeed, primești 90 și ceva, ești mulțumit. Apoi un client îți spune că magazinul merge greu, iar tu nu ai ce să-i răspunzi.
Amândoi aveți dreptate. Măsurați lucruri diferite.
Două tipuri de date, ușor de confundat
| Date de laborator | Date de teren | |
|---|---|---|
| Ce sunt | O simulare, pe un dispozitiv și o rețea definite de unealtă | Măsurători reale, de la vizitatorii tăi |
| De unde vin | Lighthouse, tabul „Analiză” din PageSpeed | CrUX, raportul Core Web Vitals din Search Console |
| Cât durează | Rezultat imediat | Fereastră mobilă de 28 de zile |
| La ce sunt bune | Depanare: îți arată ce anume încetinește pagina | Adevăr: îți arată ce pățesc clienții tăi |
| Ce folosește Google la clasare | Nimic | Astea |
Scorul de 90 e din prima coloană. Reclamația clientului e din a doua. De asta nu se contrazic.
De ce diferă atât de mult
Telefonul simulat e mai bun decât al clienților tăi
Simularea presupune un dispozitiv de gamă medie. O bună parte din traficul de ecommerce din România vine de pe telefoane mai vechi și mai lente, unde JavaScript-ul se execută de câteva ori mai încet.
Se testează o singură pagină, de obicei prima
Aproape toată lumea rulează testul pe pagina principală, care e cea mai optimizată. Clienții intră pe pagini de produs și de categorie, cu filtre, cu multe imagini, cu module care se încarcă doar acolo.
Testul nu are coș plin și nu e autentificat
În Magento, diferența e uriașă. Un vizitator cu coș plin primește conținut personalizat, care nu poate fi servit din cache. Testul nu vede niciodată situația asta.
Cache-ul e cald la test și rece la client
Când rulezi testul a doua oară, pagina e deja în cache. Clientul care intră primul dimineața, după invalidare, o prinde rece.
Scriptul de marketing adăugat marțea trecută
Cel mai frecvent vinovat. Etichete de urmărire, chat, hărți de căldură, teste A/B — toate adăugate prin manager de etichete, fără să treacă pe la nimeni tehnic. Nu apar în discuții despre performanță pentru că nimeni nu le consideră „cod”.
Ce să te uiți, în ordine
- Raportul Core Web Vitals din Search Console. Gratuit, pe date reale, grupat pe tipuri de pagini. Aici afli adevărul.
- Separă mobilul de desktop. Aproape întotdeauna problema e doar pe mobil, iar media le ascunde.
- Uită-te pe tip de pagină, nu pe site. Pagina principală poate fi verde iar cea de produs roșie.
- Verifică INP, nu doar LCP. LCP măsoară cât durează până vezi ceva. INP măsoară cât durează până răspunde la atingere — și el se strică de la JavaScript.
- Abia apoi rulează Lighthouse, ca să afli de ce. Pe pagina care iese prost în teren, nu pe cea principală.
Ce rezolvă asta, structural
Dacă datele de teren sunt roșii pe mobil și magazinul rulează pe tema standard, cauza e aproape sigur stiva de frontend. Un megabyte și jumătate de JavaScript nu se optimizează, se elimină — asta face Hyvä.
Dacă ești deja pe Hyvä și tot e lent, cauza e altundeva. Am scris separat despre ce se întâmplă în cazul ăsta.