Guides

Magento Core Web Vitals: Cum ducem magazinele peste 90 și le ținem acolo

9 octombrie 2026 - Alexandru-Manuel Carabus

Core Web Vitals e atât semnal de ranking Google, cât și una dintre cele mai clare pârghii de conversie pe care le ai. Iată ce măsoară de fapt cele trei metrici, de ce magazinele Magento pică din start, cum ducem un magazin peste 90 la PageSpeed și ce presupune să îl ții acolo.

Core Web Vitals e una dintre puținele metrici tehnice care te răsplătește de două ori. Google o folosește ca semnal de ranking, așa că un magazin care trece rankează mai bine decât un magazin identic care pică. Și pentru că aceleași trei metrici măsoară cât de rapid și de stabil se simte pagina pentru un cumpărător real, trecerea lor crește conversia în același timp. Viteza e rara investiție SEO care apare și în cifrele tale de checkout. Iată ce măsoară de fapt metricile, de ce magazinele Magento tind să pice din start și cum ducem un magazin peste 90 și îl ținem acolo.

Cele trei metrici, pe înțelesul tuturor

Sunt trei și fiecare măsoară un tip diferit de durere. Largest Contentful Paint (LCP) măsoară încărcarea: cât durează până când cel mai mare element de pe ecran, de obicei imaginea ta hero sau fotografia de produs, s-a randat efectiv. Google vrea asta sub 2,5 secunde. Interaction to Next Paint (INP), care a înlocuit First Input Delay în 2024, măsoară reactivitatea: când un cumpărător apasă un buton, cât durează până când pagina reacționează vizibil. Bine înseamnă sub 200 de milisecunde. Cumulative Layout Shift (CLS) măsoară stabilitatea: cât de mult sare pagina în timp ce se încarcă, exact lucrul care te face să apeși butonul greșit. Bine înseamnă sub 0,1. Treci toate trei pe date reale și ești în verde.

De ce pică Magento la Core Web Vitals din start

Nu e că Magento ar fi o platformă lentă. E că frontend-ul implicit și grămada tipică de extensii sunt lente. Tema veche Luma a Magento livrează un stack JavaScript greu (jQuery, RequireJS, Knockout) pe care browserele trebuie să îl descarce, parseze și execute înainte ca pagina să se simtă gata. Adaugă imagini mari necomprimate care devin elementul tău LCP, CSS care blochează randarea și fonturi web care ajung târziu și pici la LCP înainte să fie instalată o singură extensie.

Apoi vin extensiile. Fiecare extensie tinde să adauge propriul JavaScript și CSS, iar un magazin care rulează treizeci sau patruzeci dintre ele încarcă treizeci sau patruzeci de seturi de resurse, majoritatea pe fiecare pagină. Peste asta stă stratul de marketing: Google Tag Manager, pixeli de publicitate, un widget de chat, un banner de cookie-uri, un script de recenzii. Fiecare rulează JavaScript pe firul principal, iar firul principal e exact ce măsoară INP. De asta un magazin poate avea un scor Lighthouse decent în laborator și tot să pice la INP pentru utilizatori reali: tag-urile se declanșează doar sub interacțiune reală.

Cum ducem un magazin peste 90

Cea mai mare pârghie e frontend-ul, iar pe Magento asta înseamnă Hyva. Înlocuirea temei Luma cu Hyva (construită pe Tailwind și Alpine.js, livrând o fracțiune din JavaScript) e cel mai mare salt de Core Web Vitals disponibil pe platformă, pentru că șterge cauza de la rădăcină în loc să optimizeze în jurul ei. Am scris despre de ce un magazin Hyva poate fi tot lent când restul stack-ului e neglijat în Ai trecut pe Hyva și magazinul tot e lent, și despre frontend-ul în sine în Hyva Este Acum Complet Open Source. Dacă ești încă pe Luma, aici sunt câștigurile reale.

Următoarea pârghie sunt imaginile, pentru că elementul tău LCP e aproape mereu o imagine. Asta înseamnă să servești formate de nouă generație (WebP sau AVIF), să dimensionezi imaginile corect pentru dispozitiv în loc să trimiți o imagine de 3000 de pixeli către un telefon, să încarci lent tot ce e sub prima vizibilă și să dai singurei imagini LCP de deasupra pliului un priority hint ca browserul să o aducă prima. Făcută corect, doar disciplina imaginilor poate scoate o secundă sau mai mult din LCP.

Backend-ul tot trebuie să reziste sub toate acestea. Un frontend rapid pe un timp de răspuns al serverului lent (TTFB) tot pică la LCP, așa că full-page caching cu Varnish, Redis pentru sesiuni și cache, o bază de date reglată și un CDN în față nu sunt opționale. Iar tag-urile de marketing au nevoie de guvernanță: amână ce poate fi amânat, încarcă scripturile terțe după interacțiune și elimină-le pe cele pentru care nimeni nu poate numi un motiv. Ultimul pas e neglamuros și valorează în mod curent 50 sau mai multe milisecunde de INP.

O disciplină stă la baza tuturor: măsoară utilizatori reali, nu doar laboratorul. Google rankează pe date de teren (Chrome User Experience Report, adunate de la vizitatori reali), în timp ce Lighthouse din browserul tău e un diagnostic, nu scorul care contează. Urmărirea unui 100 perfect în laborator în timp ce INP-ul tău de teren stă în roșu e cel mai comun mod în care echipele irosesc un buget de performanță. Repară ce spun datele de teren că e stricat, în ordinea în care spun că e stricat.

Ce înseamnă de fapt să le menții acolo

Core Web Vitals nu e un proiect de o singură dată pe care îl termini și îl uiți. Fiecare extensie nouă, fiecare tag de marketing adăugat, fiecare imagine mare pe care un editor o încarcă fără să se gândească îl pot regresa în tăcere, iar până apare în ranking ai pierdut deja săptămâni. Ținerea liniei cere un buget de performanță (un plafon dur pe greutatea paginii și numărul de scripturi în care munca nouă trebuie să încapă), monitorizare continuă a datelor de teren și aceeași disciplină de mentenanță care ține restul magazinului sănătos. Am prezentat acea cadență în Ghidul complet de mentenanță Magento. Viteza pe care nu o menții e viteza pe care ești pe cale să o pierzi.

Cum arată asta în practică

Cel mai clar exemplu pe care îl putem împărtăși e Vitacom. Magazinul pe care l-am reconstruit, scorul Google PageSpeed a urcat de la 12 la 100. Nu e un punct de plecare tipic și nu vom pretinde că 100 e rezultatul garantat pentru fiecare magazin, dar e real și a venit exact din secvența de mai sus: frontend-ul Hyva a făcut cea mai mare parte a muncii grele, imaginile disciplinate și guvernanța tag-urilor au făcut pasul următoar, iar un backend cache-uit corect a ținut timpii de răspuns jos ca să ajungă câștigurile de frontend la utilizatori reali.

Pentru majoritatea magazinelor ținta onestă nu e un 100 perfect de laborator, sunt Core Web Vitals în verde pe toate cele trei metrici: LCP sub 2,5 secunde, INP sub 200 de milisecunde, CLS sub 0,1, măsurate pe vizitatori reali. Asta e ce răsplătește Google în ranking și ce simt cumpărătorii tăi la checkout. A ateriza solid în anii 90 cu date de teren verzi bate un 100 fragil care regresează data viitoare când cineva instalează o extensie.

De unde începi

Începe prin a-ți scoate propriile numere: rulează template-urile cheie (acasă, categorie, produs, checkout) prin PageSpeed Insights și citește secțiunea de date de teren, nu doar scorul de laborator. Dacă LCP și INP sunt în roșu și ești încă pe frontend-ul Luma, știi deja unde e primul câștig. Dacă vrei o a doua citire despre care reparație aduce cel mai mult pentru magazinul tău specific, programează un apel de strategie gratuit cu LIQUIDLAB și adu rezultatele tale PageSpeed. Îți vom spune ce merită făcut întâi și ce nu merită făcut deloc.