Site-ul tău e lent? Ce sunt Core Web Vitals și cum te costă clienți

Când cineva îți deschide site-ul de pe telefon și ecranul rămâne alb câteva secunde, cel mai probabil apasă „înapoi” și intră la concurent. Nu vei vedea niciodată clientul ăsta în statistici. De aceea viteza nu e un moft tehnic, ci bani.

Google măsoară experiența pe site prin trei indicatori numiți Core Web Vitals. Îi poți verifica gratuit cu scannerul nostru, dar mai întâi hai să vedem ce înseamnă.

Cele trei măsurători Core Web Vitals

Indicator	Ce măsoară	Bun	Slab
LCP (Largest Contentful Paint)	cât durează până apare elementul principal (imaginea mare sau titlul)	sub 2,5 s	peste 4 s
INP (Interaction to Next Paint)	cât de repede reacționează pagina când apeși un buton	sub 200 ms	peste 500 ms
CLS (Cumulative Layout Shift)	cât de mult „sare” conținutul în timp ce se încarcă	sub 0,1	peste 0,25

Google se uită la valorile reale ale vizitatorilor tăi, la percentila 75: adică cel puțin trei din patru vizite trebuie să fie „bune” ca pagina să treacă testul.

LCP: prima impresie

LCP e cel mai vizibil. Dacă imaginea din capul paginii are 3 MB, telefonul o descarcă mult pe o conexiune mobilă obișnuită. Cauzele tipice:

• imagini neoptimizate (JPEG sau PNG uriașe în loc de WebP sau AVIF la dimensiunea corectă);
• slidere în capul paginii care încarcă 5 imagini ca să arate una;
• server lent, care răspunde greu chiar înainte să înceapă încărcarea;
• fonturi și fișiere CSS care blochează afișarea.

INP: senzația de „merge greu”

INP a înlocuit în 2024 vechiul indicator FID. Măsoară cât așteaptă vizitatorul după un click, o atingere sau o tastă. Când pagina încarcă mult JavaScript (pluginuri de chat, slidere, constructori vizuali, zeci de scripturi de tracking), telefonul e ocupat și răspunde cu întârziere.

CLS: butonul care fuge

Ai încercat să apeși un link și, exact atunci, pagina a sărit pentru că s-a încărcat un banner? Asta e CLS. Apare când imaginile nu au dimensiuni declarate, când reclamele sau bannerele de cookies împing conținutul sau când fonturile se schimbă după încărcare.

De ce sunt lente atât de multe site-uri

Majoritatea site-urilor de firmă sunt construite pe teme „all-in-one” cu constructori vizuali. Sunt comode, dar încarcă pe fiecare pagină cod pentru toate funcțiile posibile, folosite sau nu. Adaugă un slider, un plugin de formular, unul de cookies, unul de chat și câteva scripturi de analiză, și ajungi ușor la sute de kilobytes de JavaScript pe care telefonul trebuie să-i proceseze.

Când am analizat vechiul nostru site, făcut pe o asemenea temă, scorul Lighthouse pe mobil era 59, cu LCP de 5,5 secunde. Acesta a fost unul dintre motivele pentru care l-am refăcut de la zero.

Ce poți repara, în ordinea impactului

1. Imaginile. Convertește-le în WebP sau AVIF, redimensionează-le la cât se afișează efectiv și încarcă „leneș” (lazy) tot ce e sub prima ecranare. Doar asta poate tăia jumătate din greutatea paginii.
2. Sliderele și animațiile din capul paginii. Înlocuiește-le cu o imagine statică bine aleasă și un mesaj clar. Convertesc mai bine oricum.
3. Pluginurile și scripturile inutile. Fiecare plugin adaugă cod. Păstrează doar ce folosești cu adevărat.
4. Cache și CDN. Paginile ar trebui servite gata generate, dintr-un server aflat aproape de vizitator.
5. Găzduirea. Dacă serverul răspunde în peste 600 ms, nicio optimizare de front-end nu compensează complet.
6. Dimensiuni pentru imagini și spațiu rezervat pentru bannere, ca să elimini săriturile de conținut.

Când merită refăcut site-ul

Dacă după optimizări scorul pe mobil rămâne sub 50, problema e de obicei arhitectura: tema, constructorul vizual sau zecile de pluginuri. Un site modern, generat static (cum facem cu Next.js), pornește de la scoruri de peste 90 fără eforturi speciale, pentru că pagina ajunge în browser deja construită, cu foarte puțin JavaScript.

Vrei să știi unde stai? Scanează-ți site-ul gratuit: primești în 30 de secunde scorul Lighthouse pe mobil, valorile Core Web Vitals și lista concretă de probleme.