Viteza site-ului și Google: ce sunt Core Web Vitals, pe înțelesul tuturor

Viteza site-ului contează când întârzierea îl împiedică pe om să vadă conținutul, să apese un buton sau să completeze formularul. Core Web Vitals traduc trei părți ale acestei experiențe în metrici: încărcarea, reacția la interacțiune și stabilitatea vizuală.

Google folosește Core Web Vitals în sistemele sale de clasare, dar spune și că o experiență bună nu garantează poziții de top. Pagina relevantă poate rămâne competitivă chiar dacă nu are cele mai bune valori. Scopul nu este un cerc verde decorativ, ci un site pe care clienții îl pot folosi.

Această diferență schimbă ordinea deciziilor. Nu începi cu întrebarea „cum ajung la 100?”, ci cu „ce experiență lentă afectează o pagină care aduce cereri?”. Apoi separi măsurarea de depanare: datele reale arată dacă vizitatorii întâlnesc problema, iar testul de laborator te ajută să o reproduci. Abia după ce știi pagina, metrica și elementul vinovat alegi între o imagine mai mică, cod mai puțin, cache, găzduire sau o schimbare de șablon.

De ce îi pasă lui Google de viteza site-ului tău

Google încearcă să ofere rezultate utile și o experiență bună. Core Web Vitals fac parte din semnalele de experiență, alături de alte aspecte. Ele nu înlocuiesc relevanța, conținutul sau autoritatea. În documentația actuală despre page experience, Google precizează că sistemele sale folosesc mai multe semnale și că rezultatele bune din rapoarte nu garantează o poziție de top. Tot acolo explică faptul că relevanța poate prevala când o pagină răspunde mai bine întrebării.

Separă două întrebări:

• SEO: pagina este suficient de bună tehnic pentru a nu pierde avantajul când alte rezultate sunt similare?
• Business: utilizatorul poate înțelege oferta și finaliza acțiunea fără fricțiune?

A doua întrebare este adesea mai importantă. Un formular care reacționează târziu sau un buton care sare sub deget poate pierde cereri chiar dacă schimbarea de poziție nu poate fi izolată. De aceea legăm performanța și de optimizarea conversiilor, nu doar de SEO.

Pentru o afacere locală, diferența dintre „rapid” și „lent” trebuie tradusă în momente concrete. Clientul venit de pe mobil poate încerca să vadă tariful, să deschidă meniul, să apese numărul de telefon sau să trimită un formular. O pagină poate afișa repede fundalul, dar să întârzie exact elementul care explică oferta. Poate părea încărcată, dar să nu răspundă când utilizatorul selectează un serviciu. Sau poate muta butonul după ce apare bannerul de cookie.

Folosește următoarea triere înainte să deschizi un ticket tehnic:

Această triere păstrează investiția proporțională. O pagină informativă fără trafic nu are aceeași prioritate ca formularul folosit de campanii. Un scor slab într-o simulare nu are aceeași greutate ca o problemă repetată în date reale pe paginile cu venit.

Ce măsoară de fapt indicatorii de experiență

Pragurile curente sunt explicate de web.dev în metodologia Core Web Vitals și sunt evaluate la percentila 75. Mobilul și desktopul trebuie citite separat, pentru că dispozitivul, rețeaua și tiparul de utilizare pot produce experiențe diferite.

LCP nu înseamnă „pagina s-a încărcat complet”; măsoară apariția celui mai mare element vizibil relevant. INP urmărește latența interacțiunilor pe durata vizitei. CLS adună schimbările neașteptate de poziție.

LCP: când devine vizibil conținutul principal

Largest Contentful Paint marchează momentul la care cel mai mare element eligibil din zona vizibilă a fost randat. Poate fi imaginea hero, un bloc mare de text sau un poster video. Ghidul web.dev pentru LCP arată că metrica depinde de întregul lanț: răspunsul serverului, descoperirea resursei, descărcarea ei și întârzierea de randare.

De aceea, „comprimăm imaginea” este doar una dintre ipoteze. Dacă imaginea LCP este descoperită târziu din JavaScript, dacă are prioritate mică sau dacă CSS-ul blochează randarea, o reducere modestă a fișierului poate să nu schimbe suficient experiența. Notează în audit elementul LCP și descompunerea timpului, nu doar valoarea totală.

INP: cât așteaptă omul după ce face ceva

Interaction to Next Paint evaluează latența interacțiunilor de tip clic, atingere și tastare și reține o valoare reprezentativă pentru vizită. Explicația tehnică pentru INP separă întârzierea de intrare, timpul de procesare și întârzierea până la următorul cadru afișat. Această separare contează: problema poate fi un task JavaScript început înainte de clic, un handler lent sau prea multă muncă de layout și randare după handler.

Pe o pagină comercială, testează interacțiuni reale, nu doar încărcarea: meniul mobil, selectorul de variantă, acordeonul de preț, validarea formularului și butonul de trimitere. Dacă raportul de laborator nu generează acea interacțiune, absența unui avertisment nu demonstrează că fluxul este rapid.

CLS: cât de stabil rămâne ecranul

Cumulative Layout Shift cuantifică deplasările neașteptate ale elementelor vizibile. Documentația CLS distinge deplasările produse la încărcare de cele apărute după interacțiuni sau în timpul unei sesiuni mai lungi. Cele din urmă pot lipsi dintr-un test scurt de laborator.

Sursele tipice sunt previzibile: imagini și iframe-uri fără spațiu rezervat, bannere inserate deasupra conținutului, fonturi care schimbă dimensiunea textului sau componente care apar după răspunsuri asincrone. Soluția nu este să ascunzi tot, ci să rezervi spațiul corect și să controlezi momentul în care elementul intră în layout.

Pragurile nu sunt note școlare pe un test singular. Conform documentației, o pagină trece dacă toate cele trei metrici ating țintele la percentila 75. Asta înseamnă că trebuie să te uiți la majoritatea experiențelor reale, nu la cel mai rapid telefon din birou.

Mai există o nuanță importantă: valoarea la percentila 75 nu este media. Ea indică pragul sub care se află aproximativ trei sferturi dintre experiențele observate. O medie bună poate ascunde un segment consistent de utilizatori cu rețele sau dispozitive mai slabe; de aceea raportarea procentilei este mai utilă pentru controlul calității experienței.

Cum testezi viteza site-ului în cinci minute

Deschide PageSpeed Insights și testează o pagină comercială importantă, nu doar homepage-ul. Google explică în documentația PageSpeed Insights că instrumentul combină date reale din Chrome UX Report cu diagnostice de laborator generate de Lighthouse. Cele două secțiuni răspund la întrebări diferite și nu trebuie amestecate.

1. Introdu URL-ul complet.
2. Citește întâi secțiunea cu date reale, dacă există.
3. Separă mobilul de desktop.
4. Notează care dintre LCP, INP și CLS nu trece.
5. Folosește diagnosticul de laborator pentru ipoteza tehnică, nu ca rezultat de business.

Datele de teren provin din Chrome User Experience Report și reflectă utilizatori reali eligibili într-o perioadă agregată. Datele de laborator sunt o simulare reproductibilă și ajută la depanare. Un site cu trafic insuficient poate să nu aibă date de teren la nivel de URL; asta nu înseamnă că este rapid sau lent.

Fluxul recomandat de web.dev pentru instrumentele Core Web Vitals pornește de la datele de teren, apoi folosește PageSpeed Insights, Search Console și DevTools pentru a localiza cauza. Aceasta este și ordinea sănătoasă pentru buget: întâi demonstrezi unde apare fricțiunea, apoi plătești depanarea.

Testează cel puțin tipurile principale de șablon:

• homepage;
• pagină de serviciu;
• articol;
• categorie sau produs, pentru ecommerce;
• pagină cu formular ori element interactiv.

Nu rula o singură dată și nu compara scoruri obținute în condiții diferite. Pentru o verificare reproductibilă, păstrează URL-ul, data, profilul mobil sau desktop, versiunea publicată și rezultatele metrice. Rulează de câteva ori laboratorul dacă urmărești o schimbare mică; variațiile de rețea, CPU și servicii terțe pot muta scorul. Compară mediana rulărilor controlate, dar folosește datele reale pentru efectul trăit de public.

Fișa minimă de măsurare poate arăta astfel:

1. URL și tip de șablon: serviciu, produs, articol sau formular.
2. Sursa datelor: CrUX URL, CrUX origine, Lighthouse ori RUM propriu.
3. Dispozitiv și segment: mobil sau desktop, țară, browser, după caz.
4. LCP, INP și CLS, fiecare cu starea și elementul ori interacțiunea asociată.
5. Data implementării și descrierea exactă a schimbării.
6. Rulare de control după publicare și fereastră ulterioară pentru date reale.
7. Indicator comercial observat separat: trimitere formular, apel, checkout sau venit.

Această fișă previne două erori frecvente: atribuirea unui rezultat unui plugin instalat împreună cu alte schimbări și compararea unui test mobil cu unul desktop. Dacă măsurarea nu este comparabilă, diferența nu poate susține o concluzie operațională.

Ce probleme încetinesc cel mai des site-urile

Fără date proprii verificate nu pretindem o frecvență pentru România. Practic, diagnosticul pornește de la elementul care produce metrica slabă.

Un plugin de cache poate ajuta, dar nu rezolvă orice cauză. Uneori imaginea principală este încărcată greșit, alteori tema execută prea mult JavaScript. Reparația trebuie să corespundă diagnosticului.

Pentru LCP, separă lanțul în patru întrebări. Serverul răspunde târziu? Browserul descoperă târziu resursa principală? Descărcarea durează din cauza dimensiunii sau conexiunii? Elementul este disponibil, dar randarea este blocată? Fiecare răspuns conduce la alt proprietar: infrastructură, HTML, media sau front-end.

Pentru INP, deschide panoul Performance și reproduce acțiunea lentă. Chrome arată metricile live și permite înregistrarea unei interacțiuni, astfel încât programatorul poate vedea taskurile lungi, handlerul și munca de randare. Raportul trebuie să numească interacțiunea, nu doar să spună „JavaScript prea mult”.

Pentru CLS, urmărește elementul care s-a mutat și cauza mișcării. Imaginea fără dimensiuni, fontul sau bannerul sunt cauze; elementul mutat poate fi doar victima. Această distincție evită reparații cosmetice aplicate componentei greșite.

O matrice de responsabilitate scurtează discuția cu furnizorii:

O sursă românească precum manualul GUN Media despre Core Web Vitals acoperă contextul și verificările locale, iar auditul de viteză Shopify în limba română explică de ce viteza nu este o singură măsură. Folosește-le pentru orientare, dar păstrează definițiile și pragurile legate de documentația primară.

Ce poți remedia fără să reconstruiești site-ul

Începe cu schimbările reversibile și cu impact vizibil:

• redimensionează și comprimă imaginile la dimensiunea de afișare;
• folosește formate moderne și evită o imagine uriașă pentru un card mic;
• elimină scripturile și widgeturile care nu aduc valoare;
• setează dimensiuni explicite pentru imagini și embeduri;
• încarcă mai târziu elementele aflate sub primul ecran;
• păstrează prioritar elementul principal al paginii;
• verifică fonturile și bannerele care mută conținutul.

Ordinea contează. Optimizează întâi traseul critic al paginii, apoi elementele secundare. O imagine din primul ecran nu trebuie tratată la fel ca o galerie aflată mult mai jos. Ghidul MDN despre lazy loading descrie amânarea resurselor necritice, însă aplicarea fără discernământ poate întârzia tocmai imaginea LCP. Pentru aceasta din urmă ai nevoie de descoperire și prioritate timpurie, nu de amânare.

Remedieri pe care le poți pregăti fără cod

• exportă imaginile la dimensiunea reală de afișare și păstrează originalele separat;
• elimină embedurile, caruselele și scripturile fără rol în decizia clientului;
• inventariază fonturile, greutățile și variantele încărcate de fiecare șablon;
• marchează widgeturile externe și proprietarul lor de business;
• selectează paginile comerciale care trebuie retestate după orice schimbare;
• păstrează capturi și valori înainte de intervenție.

Remedieri care cer de regulă programator

• prioritizarea corectă a resursei LCP și reducerea lanțurilor de requesturi;
• împărțirea taskurilor JavaScript și reducerea muncii pe main thread;
• încărcarea condiționată a scripturilor terțe și a componentelor grele;
• rezervarea spațiului pentru conținut dinamic, bannere și iframe-uri;
• cache la nivel de aplicație sau server, compresie și configurare CDN;
• monitorizare RUM care păstrează pagina, metrica și segmentul fără date personale inutile.

Nu transforma lista într-un pachet universal. Un site static cu imagine hero grea nu are aceeași cauză ca un magazin cu filtre și scripturi de tracking. Prioritatea vine din măsurare, iar implementarea trebuie verificată pe pagina publică.

Fă o schimbare, retestează și notează rezultatul. Dacă instalezi simultan trei pluginuri, schimbi tema și muți găzduirea, nu vei ști ce a ajutat sau ce a stricat. Pentru contextul tehnic mai larg, citește ce este SEO tehnic. Dacă pagina nu apare deloc în rezultate, începe cu diagnosticul de indexare, nu cu viteza. Pentru o evaluare la nivelul întregului site, folosește auditul SEO.

Aplică schimbarea mai întâi într-un mediu de test când afectează tema, cache-ul sau checkout-ul. Verifică apoi nu doar metricile, ci și funcțiile: formulare, tracking, consimțământ, plată, căutare internă și afișarea pe mobil. O optimizare care îmbunătățește scorul, dar rupe măsurarea sau conversia, nu este o economie.

Când viteza devine o problemă de afacere

Prioritatea crește când pagina importantă pică pe date reale și când fricțiunea apare exact înaintea acțiunii comerciale. Leagă diagnosticul de măsurare:

Nu atribui automat creșterea conversiei unei singure remedieri. Sezonul, campaniile și schimbările de ofertă pot interveni. Marchează data implementării și compară perioade similare în instrumentele de măsurare.

Un backlog de performanță devine util când fiecare rând are dovadă și efect așteptat:

Pentru dovada internă Amplify, registrul disponibil nu precizează încă numărul testelor rulate pe site-uri de clienți și nici o cohortă comparabilă înainte/după. De aceea articolul nu afirmă o frecvență a cauzei principale și nu atribuie o modificare a conversiei unei remedieri. Când cifra și metodologia sunt furnizate, studiul poate fi adăugat separat, cu tipurile de pagini, dispozitivele, intervalul și schimbările concomitente.

Un cadru simplu de prioritizare

1. Critic: problema apare în date reale pe un flux de venit și poate bloca acțiunea.
2. Ridicat: problema apare pe un șablon important și laboratorul identifică o cauză repetabilă.
3. Mediu: există numai în laborator, dar remedierea este sigură și ajută experiența.
4. Scăzut: urmărește un scor perfect, fără efect vizibil sau date reale suficiente.
5. De monitorizat: nu există încă un eșantion suficient, iar echipa păstrează măsurarea până apar date comparabile.

Acest cadru nu este un verdict automat. El obligă echipa să păstreze împreună pagina, sursa măsurării, riscul și costul. În lipsa unuia dintre aceste elemente, prioritatea rămâne o ipoteză.

Întrebări frecvente

De la ce valori începe Google să considere site-ul lent?

Pentru experiență bună, țintele actuale sunt LCP de cel mult 2,5 secunde, INP de cel mult 200 ms și CLS de cel mult 0,1, evaluate la percentila 75. Zona „slab” începe peste 4 secunde, 500 ms și, respectiv, 0,25.

Valorile dintre aceste limite intră în zona „necesită îmbunătățire”. Citește fiecare metrică separat; evaluarea generală nu îți spune care experiență trebuie reparată.

Schimb găzduirea sau problema este în tema site-ului?

Nu decide înainte de diagnostic. Un timp mare până la primul răspuns poate indica serverul; JavaScript-ul greu și instabilitatea vizuală indică mai des tema, pluginurile sau implementarea paginii.

Scorul 100 garantează poziții mai bune?

Nu. Google spune că rezultatele relevante pot apărea chiar dacă valorile Core Web Vitals sunt slabe și că o experiență bună nu garantează primele poziții.

De ce nu văd date reale în PageSpeed Insights?

Este posibil ca URL-ul sau originea să nu aibă suficiente date eligibile în Chrome User Experience Report. Folosește laboratorul pentru diagnostic și implementează monitorizare proprie dacă pagina este critică.

De ce diferă rezultatul pe mobil față de desktop?

Profilul de dispozitiv, puterea procesorului, rețeaua și chiar structura interfeței diferă. Analizează separat cele două segmente și prioritizează dispozitivul folosit în fluxul comercial, fără să ignori celălalt.

Cât durează să se vadă o remediere în datele reale?

Laboratorul poate arăta efectul imediat după publicare. Datele CrUX sunt agregate într-o fereastră mobilă și nu se actualizează ca un test instant; păstrează data schimbării și urmărește evoluția, nu o singură captură.

Repară experiența, nu culoarea raportului

Măsoară pe șabloanele care aduc cereri, identifică metrica și elementul vinovat, aplică o remediere controlată, apoi verifică datele reale. Acesta este traseul care transformă viteza din obsesie tehnică în decizie de business.

Dacă site-ul are mai multe probleme simultan, începe cu paginile și interacțiunile care susțin venitul. Cere ca fiecare recomandare să includă sursa măsurării, cauza observată, proprietarul tehnic și controlul de după publicare. Astfel, viteza nu mai este o listă generică de pluginuri, ci un proces măsurabil.

Viteza este numai una dintre componentele explicate în fundamentele SEO. Dacă ai nevoie de prioritizarea ei împreună cu indexarea, conținutul și autoritatea, pornește de la serviciul SEO, cu paginile comerciale și datele reale în aceeași fișă de lucru.

Păstrează în handoff patru lucruri:

• URL-ul și șablonul afectat;
• metrica, elementul sau interacțiunea observată;
• schimbarea publicată și proprietarul ei;
• retestarea tehnică, funcțională și comercială.