Un site lent nu se repară pornind de la scor
Când o pagină răspunde greu, imaginile apar târziu sau butoanele își schimbă poziția, vizitatorul nu vede un raport tehnic. Simte că site-ul îl încurcă. Poate amâna formularul, poate abandona coșul sau poate presupune că și serviciul oferit va funcționa la fel.
Un test PageSpeed este util, dar nu reprezintă verdictul final. Înainte să modific codul, verific pagina importantă, dispozitivul pe care apare problema și datele utilizatorilor reali. Abia după aceea are sens să aleg optimizarea.
Ce măsoară Core Web Vitals în 2026
Documentația oficială Web Vitals păstrează trei metrici stabile:
- LCP (Largest Contentful Paint): cât durează până devine vizibil elementul principal al paginii;
- INP (Interaction to Next Paint): cât de repede răspunde pagina la interacțiunile utilizatorului;
- CLS (Cumulative Layout Shift): cât de stabil rămâne conținutul în timpul încărcării.
Pragurile recomandate sunt LCP de maximum 2,5 secunde, INP de maximum 200 milisecunde și CLS de maximum 0,1, evaluate la percentila 75. Asta înseamnă că nu judecăm site-ul după cea mai bună încărcare făcută din birou, ci după experiența majorității vizitatorilor, separat pe mobil și desktop.
Aceste valori descriu doar o parte din experiență. Un site poate trece Core Web Vitals și totuși să aibă un formular confuz. Poate avea și un scor modest într-un test de laborator, deși utilizatorii reali nu întâmpină aceeași problemă. Contextul decide ce merită reparat.
Date reale sau test de laborator?
Datele reale arată dacă problema există
Chrome User Experience Report, raportul Core Web Vitals din Search Console și o soluție proprie de Real User Monitoring folosesc experiențe reale. Ele pot arăta diferențe între mobil și desktop sau între grupuri de pagini.
Datele reale au însă nevoie de suficient trafic. Un site nou ori o pagină rar accesată poate să nu aibă informații la nivel de URL. În această situație, datele la nivel de domeniu și măsurarea proprie oferă context, dar nu trebuie prezentate ca și cum ar descrie exact pagina analizată.
Laboratorul ajută la diagnostic
Lighthouse, Chrome DevTools și partea de diagnostic din PageSpeed Insights simulează o încărcare controlată. Sunt bune pentru a identifica resurse mari, cod care blochează firul principal sau elemente care se mută.
Lighthouse nu poate măsura INP real, deoarece testul nu include felul în care vizitatorii folosesc efectiv pagina. Total Blocking Time poate fi un indiciu în laborator, nu un înlocuitor pentru INP.
Cum localizez cauza întârzierii
Pentru LCP, separ timpul total în câteva etape. Ghidul web.dev pentru optimizarea LCP recomandă să fie analizate documentul HTML inițial și resursa care devine elementul LCP.
| Etapă | Ce verific | Exemple de cauze |
|---|---|---|
| Răspunsul inițial | TTFB și redirecționări | server lent, lipsă cache, redirecționări |
| Descoperirea resursei | momentul în care browserul vede imaginea sau fontul | imagine introdusă târziu prin JavaScript, CSS blocant |
| Descărcarea | dimensiune, format și prioritate | imagine prea mare, CDN lent, lipsă preload |
| Randarea | timpul dintre descărcare și afișare | JavaScript, animații sau stiluri care întârzie elementul |
Pentru INP urmăresc interacțiunile lente și activitatea de pe firul principal: scripturi terțe, componente care refac prea multă interfață sau evenimente care pornesc operațiuni costisitoare.
Pentru CLS caut elemente fără dimensiuni rezervate, bannere inserate deasupra conținutului, fonturi care schimbă geometria textului și componente care apar după încărcare.
Ordinea în care merită intervenit
Nu încep cu fiecare avertisment din raport. Aleg întâi paginile care aduc trafic, cereri sau venit și verific dacă problema este repetabilă.
- Confirm problema în date reale, dacă există suficiente date.
- Identific elementul sau interacțiunea afectată.
- Reproduc situația pe dispozitivul și conexiunea relevante.
- Corectez cauza cu impactul cel mai mare.
- Verific să nu fi apărut o regresie pe altă pagină.
- Urmăresc din nou datele reale după ce există suficient trafic.
Articolul despre ce verifică un audit SEO tehnic explică de ce performanța trebuie analizată împreună cu indexarea, arhitectura și paginile importante pentru afacere.
Când nu este nevoie să reconstruiești site-ul
WordPress, un constructor vizual sau o aplicație custom pot fi rapide ori lente. Platforma nu este singură cauza. Uneori sunt suficiente comprimarea imaginilor, eliminarea unui script terț, configurarea cache-ului sau schimbarea modului în care se încarcă elementul principal.
Reconstrucția devine justificată când problemele sunt structurale: tema nu mai poate fi actualizată, extensiile se blochează reciproc, fiecare modificare introduce o regresie sau arhitectura împiedică optimizarea paginilor importante.
Prin serviciul de SEO tehnic, indexare și performanță pot verifica problema punctuală înainte să recomand o intervenție mare. Dacă blocajul ține de întreaga implementare, analiza poate continua în zona de creare și refacere a site-urilor. Decizia ar trebui să urmeze măsurătorile, nu scorul izolat.