Ai intrat vreodată pe un site, ai vrut să apeși pe un buton și, exact în acea clipă, pagina s-a mutat și ai apăsat pe altceva? Sau ai așteptat câteva secunde în fața unui ecran alb și ai închis pagina? Clienții tăi fac la fel.

Google măsoară aceste lucruri pe vizitatorii reali ai fiecărui site, cu trei indicatori numiți Core Web Vitals. Nu trebuie să fii programator ca să-i înțelegi și nici ca să-ți verifici site-ul.

Cele trei măsurători

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

Un site trece testul dacă cel puțin 75% dintre vizite se încadrează la „bun”, la toți cei trei indicatori1. Măsurătorile vin de la vizitatorii reali care folosesc Chrome, nu dintr-un test de laborator, așa că reflectă telefoanele și conexiunile reale ale clienților tăi.

FID a fost înlocuit

Dacă ai citit despre Core Web Vitals acum câțiva ani, poate îți amintești de FID. Din martie 2024 a fost înlocuit de INP, care măsoară reacția paginii pe toată durata vizitei, nu doar la prima atingere.

De ce contează

Pentru Google. Google spune explicit că sistemele lui de clasare folosesc Core Web Vitals. Spune însă la fel de clar că un scor bun nu garantează primul loc: conținutul relevant rămâne pe primul plan2. Altfel spus, între două pagini la fel de bune, cea rapidă are un avantaj.

Pentru clienți. Aici efectul e mai direct. Vodafone a testat două variante ale aceleiași pagini, identice ca aspect: cea cu LCP-ul mai bun cu 31% a adus cu 8% mai multe vânzări3. Un studiu Deloitte pentru Google a găsit că, la magazinele online, o pagină mai rapidă cu o zecime de secundă a crescut conversiile cu 8,4%4.

Pentru concurență. Potrivit Web Almanac 2025, doar 48% dintre site-uri trec testul pe mobil5. Cel mai des pică la LCP: conținutul principal apare prea târziu. Un site rapid te scoate, încă de acum, în fața a jumătate dintre concurenți.

Cum îți verifici singur site-ul

  1. Deschide PageSpeed Insights și introdu adresa site-ului (completă, așa cum apare în bara de adrese a browserului).
  2. Uită-te întâi la partea de sus, cu datele de la utilizatorii reali. Acolo vezi dacă site-ul trece testul Core Web Vitals, pe mobil și pe desktop.
  3. Abia apoi la scorul de mai jos (0–100). E un test de laborator, făcut pe loc, util ca să găsești problemele, dar nu e ce folosește Google la clasare.
  4. Dacă ai Google Search Console, raportul „Core Web Vitals” îți arată ce pagini au probleme și de ce tip.

Nu ai date de la utilizatori reali?

Site-urile cu puține vizite nu au întotdeauna suficiente date reale. În acest caz, scorul de laborator pe mobil e cel mai bun indiciu. Un scor de peste 90 e bun; sub 50 înseamnă că vizitatorii tăi chiar așteaptă.

Ce strică de obicei scorul

Când LCP-ul e slab (conținutul apare târziu):

  • imagini mari, neoptimizate, mai ales imaginea principală din capul paginii;
  • slidere care încarcă cinci imagini ca să arate una;
  • găzduire lentă sau un server prea departe de vizitatori;
  • fonturi și scripturi care blochează afișarea paginii.

Când INP-ul e slab (pagina reacționează greu):

  • prea mult JavaScript: teme încărcate, zeci de module, constructoare vizuale de pagini (de exemplu Elementor, Divi, WPBakery sau platformele de tip Wix și Squarespace);
  • scripturi externe: chat, pixeli de reclame, hărți, widgeturi de social media;
  • meniuri și filtre care recalculează toată pagina la fiecare click.

Când CLS-ul e slab (conținutul sare):

  • imagini și videoclipuri fără dimensiuni declarate;
  • bannere, reclame sau ferestre care apar deasupra conținutului deja afișat;
  • fonturi care se schimbă după încărcare și mută textul.

Multe dintre acestea se repară relativ ușor. Altele, cum ar fi o temă care încarcă un megabyte de JavaScript pe fiecare pagină, țin de fundația site-ului și nu se pot repara fără să refaci o parte din el.

Cum facem noi site-uri rapide

Viteza nu se adaugă la final, ca un strat de vopsea. Se decide de la început, prin felul în care e construit site-ul:

  • paginile sunt generate pe server, ca HTML curat, fără să aștepte după JavaScript (evităm framework-urile de tip React, Angular sau Vue folosite pentru a construi pagina în browser, care încarcă mult JavaScript de la început);
  • imaginile sunt convertite automat în formate moderne (AVIF și WebP), la mai multe dimensiuni, ca telefonul să descarce doar cât îi trebuie;
  • fonturile sunt găzduite pe același server și reduse la caracterele necesare;
  • JavaScript-ul e puțin și se încarcă doar unde e nevoie;
  • fiecare imagine are dimensiunile declarate, ca pagina să nu sară.
Raportul Lighthouse pentru prima pagină a site-ului Simplix, pe mobil: 100 la performanță, accesibilitate și bune practici
Raportul Lighthouse pentru prima pagină a site-ului nostru, pe mobil: conținutul principal apare în 1,4 secunde, iar pagina practic nu se mișcă la încărcare

Rezultatul se vede în raportul de mai sus: 100 la performanță pe mobil, conținutul principal în 1,4 secunde și o pagină care stă pe loc. Testăm fiecare pagină nouă în același fel, înainte să o publicăm.

Vrei să afli de ce e lent site-ul tău și ce se poate repara?

Cere un audit de performanță

  1. web.dev, How the Core Web Vitals metrics thresholds were defined. ↩

  2. Google Search Central, Understanding page experience in Google Search results. ↩

  3. web.dev, Vodafone: A 31% improvement in LCP increased sales by 8%. ↩

  4. Deloitte și Google, Milliseconds make millions, 2020. ↩

  5. HTTP Archive, Web Almanac 2025: Performance, date din iulie 2025. ↩

Imaginea de copertă: Jamie Street, Wikimedia Commons (CC0)