În acest capitol
01Trei secunde într-o parcare: de ce contează viteza
O persoană e în mașină, în parcarea din fața magazinului tău, și vrea să știe dacă ai deschis. Îți deschide site-ul de pe telefon, cu două liniuțe de semnal. Ecranul rămâne alb. Apoi apare o imagine enormă, apoi textul, apoi o casetă de cookie care împinge totul în jos exact când atinge „Program”: a apăsat „Oferte”. Se întoarce, deschide profilul unui concurent. Trei secunde, și ai pierdut un client care era deja în fața ușii.
Exact această experiență a decis Google să o măsoare cu trei cifre, Core Web Vitals, „semnele vitale” ale unei pagini web. Nu măsoară cât de frumos e site-ul sau cât de bogat: măsoară trei momente precise din experiența celui care îl vizitează.
- Văd ceva util? Asta măsoară LCP.
- Dacă ating, răspunde? Asta măsoară INP.
- Stă pe loc sau îmi fuge de sub deget? Asta măsoară CLS.
Google recomandă deschis să ai Core Web Vitals bune și le consideră parte din experiența paginii pe care sistemele lui o răsplătesc. Dar e onest și în privința celeilalte părți: motorul încearcă mereu să arate conținutul cel mai relevant, chiar și când experiența nu e perfectă. Pe scurt: viteza nu înlocuiește un conținut bun, dar la conținut egal face diferența și, mai ales, face diferența la oameni, care sunt cei care cumpără.
În capitolul despre infrastructura web am explicat TTFB, timpul de care serverul are nevoie ca să înceapă să răspundă. Aici ne uităm la tot ce se întâmplă după, în browser: acolo se decide cea mai mare parte din cele trei cifre.
02Cele trei măsuri și pragurile lor
Fiecare măsură are trei benzi: bună, de îmbunătățit și slabă. Pragurile le publică Google în ghidul pentru dezvoltatori și sunt aceleași pentru orice site, de la magazinul de cartier la marele portal.
De ce 75% și nu media
Media ascunde problemele: zece vizite foarte rapide de pe calculatorul din birou acoperă trei vizite dezastruoase de pe un telefon ieftin, la țară. Percentila 75 este mai severă și mai corectă: spune că trei vizitatori din patru au avut o experiență cel puțin atât de bună. Ca să treci nu ajunge ca site-ul să meargă bine pentru tine; trebuie să meargă bine pentru aproape toți, inclusiv pentru cine are un telefon de acum câțiva ani și o conexiune instabilă.
O măsură ieșită la pensie
Dacă citești ghiduri de acum câțiva ani vei găsi FID (First Input Delay) în locul INP. Din 12 martie 2024 INP l-a înlocuit ca Core Web Vital: FID măsura doar întârzierea primei interacțiuni, INP se uită la reactivitatea întregii vizite și este mult mai sever.
03LCP: când apare conținutul care contează
LCP (Largest Contentful Paint, cea mai mare porțiune de conținut desenată) măsoară când apare pe ecran cel mai mare element vizibil la deschidere: de obicei imaginea principală sau cel mai mare bloc de text, cum ar fi titlul cu paragraful de deschidere. E momentul în care vizitatorul se gândește „gata, a sosit”.
Pentru LCP contează imaginile, imaginile de fundal încărcate din CSS, copertele videoclipurilor și blocurile de text. Un desen vectorial scris direct în pagină, în schimb, nu e candidat. Timpul se numără de când pagina începe să se încarce, deci în LCP intră totul: așteptarea serverului, descărcarea fișierelor, desenarea.
Cauzele cele mai frecvente și remediile
- Imagini prea grele. O fotografie făcută cu telefonul are ușor câțiva megabytes; pe ecranul unui telefon ajung câteva sute de kilobytes. Se redimensionează la mărimea reală de afișare, se comprimă, se folosesc formate moderne ca WebP sau AVIF și se oferă dimensiuni diferite pentru ecrane diferite.
- Imaginea principală „leneșă”. Încărcarea amânată (
loading="lazy") e excelentă pentru imaginile din josul paginii, dar pe imaginea din vârf întârzie tocmai LCP. Aceea se încarcă imediat, ba chiar se anunță cu prioritate ridicată. - CSS și fonturi care blochează. Până când browserul nu a descărcat foile de stil, nu desenează nimic. Puține fișiere, mici, și fonturi încărcate astfel încât textul să apară imediat cu un font de rezervă.
- Un server lent. Dacă TTFB mănâncă deja o secundă, restul are puțină marjă: e partea pe care o povestesc în capitolul despre infrastructură.
- Conținut construit de JavaScript. Dacă textul principal apare doar după ce un script l-a descărcat și l-a montat, LCP așteaptă scriptul. Conținutul important trebuie să sosească deja scris în pagină.
04INP: pagina răspunde când o atingi?
Ți s-a întâmplat vreodată să atingi „Adaugă în coș”, să nu vezi nimic întâmplându-se, să atingi din nou și să te trezești cu două produse? Acea jumătate de senzație de „s-a blocat?” are un nume: INP (Interaction to Next Paint, de la interacțiune la următoarea desenare).
INP observă toate clicurile, atingerile și tastele apăsate în timpul vizitei și măsoară cât timp trece de la fiecare până în momentul în care ecranul arată reacția. Valoarea finală reprezintă, în esență, una dintre cele mai lente interacțiuni ale vizitei. Sub 200 de milisecunde pagina pare imediată; peste 500 pare stricată.
Dușmanul se numește „sarcină lungă”
Browserul are un singur fir principal ca să execute JavaScript și să deseneze pagina. Dacă un script îl ocupă mult timp la rând (se vorbește de sarcini lungi când depășesc 50 de milisecunde), atingerea utilizatorului așteaptă la coadă. Vinovații obișnuiți:
- prea multe scripturi ale terților: chat, contoare, widgeturi sociale, publicitate, fiecare cu greutatea lui;
- page buildere și zeci de pluginuri care își încarcă codul pe fiecare pagină, chiar și acolo unde nu e nevoie. E tema capitolului despre valoarea profesionistului în cod;
- cod care face totul imediat: calcule, animații și încărcări pornite la deschidere, în loc de momentul în care sunt necesare;
- pagini enorme, cu mii de elemente de recalculat la fiecare schimbare.
Remediile urmează: mai puține scripturi, încărcate doar unde e nevoie și după conținut; sarcini sparte în bucăți mici care lasă browserul să respire; un răspuns vizual imediat la atingere (chiar și doar butonul care se aprinde) înaintea calculelor grele.
Quiz
Ce măsură suferă?
Pentru fiecare situație alege măsura care se înrăutățește: explicația apare imediat.
Fotografia de copertă are 4 MB și sosește ultima.
Cea mai mare imagine din vârf este aproape mereu elementul LCP: dacă sosește târziu, LCP crește.
Atingi „Rezervă” și timp de o secundă nu se întâmplă nimic.
E timpul dintre atingere și reacția vizibilă: exact ce măsoară INP.
Un banner apare sus și împinge în jos textul pe care îl citeai.
O deplasare neașteptată a conținutului vizibil face să crească CLS.
Serverul are nevoie de două secunde ca să răspundă.
TTFB face parte din LCP: două secunde de așteptare lasă doar o jumătate de secundă pentru tot restul.
05CLS: pagina care fuge de sub deget
CLS (Cumulative Layout Shift, deplasarea cumulată a așezării în pagină) măsoară cât se mișcă conținutul vizibil fără ca tu să fi făcut ceva. E defectul cel mai iritant dintre cele trei, pentru că te face să greșești: citești un rând și îți fuge, vrei să atingi un buton și îl atingi pe cel care tocmai a ajuns în locul lui.
Cum se calculează, în cuvinte simple
Fiecare deplasare primește un scor dat de doi factori înmulțiți între ei: ce parte din ecran este implicată și cu cât s-au mișcat elementele față de mărimea ecranului. Ghidul Google dă acest exemplu: dacă elementele instabile ocupă 75% din ecran și se deplasează cu un sfert, scorul este 0,75 × 0,25 = 0,1875. Singur, deja peste pragul bun de 0,1.
Deplasările apropiate în timp se adună în „rafale” (cu mai puțin de o secundă între una și alta, pentru maximum cinci secunde), iar CLS-ul paginii este cea mai proastă rafală. Două detalii importante:
- deplasările care au loc la cel mult jumătate de secundă după o atingere sau o tastă nu se iau în calcul: dacă deschizi un meniu și conținutul se mută, e o reacție la care te aștepți;
- animațiile făcute cu transformări (mutarea sau mărirea unui element fără a schimba așezarea din jur) nu produc deplasări: sunt modul corect de a anima.
Remediile, aproape toate gratuite
- Dă mereu lățime și înălțime imaginilor (sau un raport de aspect în CSS): browserul rezervă spațiul chiar înainte să le descarce.
- Rezervă locul pentru tot ce sosește după: bannere, hărți încorporate, videoclipuri, recenzii încărcate din alte servicii.
- Nu insera conținut deasupra celui la care utilizatorul se uită deja, decât dacă l-a cerut el.
- Încarcă fonturile cu judecată, alegând fonturi de rezervă de mărime asemănătoare, astfel încât trecerea de la unul la altul să nu mute rândurile.
Cuvintele capitolului
Micul dicționar al vitezei
Atinge o carte ca s-o întorci.
06Laborator și realitate: două moduri de a măsura
„Am făcut testul și îmi dă 98, de ce spune Google că site-ul e lent?” E una dintre întrebările pe care le aud cel mai des, iar răspunsul este că te uiți la două lucruri diferite.
Date de laborator
- O probă simulată, de exemplu cu Lighthouse: un dispozitiv și o rețea alese în teorie.
- Repetabilă: utilă ca să înțelegi cauzele și să verifici imediat o corectură.
- Nu vede atingerile reale, deci nu poate măsura INP așa cum e în realitate.
- Scorul de la 0 la 100 este un rezumat al laboratorului, nu un Core Web Vital.
Date reale (din teren)
- Colectate de la vizitatorii reali: raportul CrUX al Chrome folosește datele celor care au ales să împărtășească statisticile, pe calculator și Android.
- Sunt cele care contează pentru pragurile Core Web Vitals.
- E nevoie de destule vizite: paginile puțin vizitate nu au date proprii.
- Se văd în PageSpeed Insights și în raportul din Search Console.
Cum citești PageSpeed Insights în trei mișcări
- Uită-te întâi la partea de sus, cea a datelor reale: îți spune dacă pagina trece evaluarea Core Web Vitals. Dacă scrie că nu sunt destule date, pagina are puține vizite și te uiți la datele întregului site.
- Alege fila pentru telefon: pentru o afacere locală e aproape mereu dispozitivul majorității și cel mai sever.
- Folosește laboratorul pentru cauze: secțiunea de diagnostic enumeră imaginile de redus, scripturile care blochează, deplasările, cu fișierele responsabile.
Adevărat sau fals?
Miturile vitezei
Decide pentru fiecare afirmație: adevărat sau fals?
Un scor de 100 în laborator garantează trecerea Core Web Vitals.
Pragurile se evaluează pe datele vizitelor reale, care pot fi mai proaste decât laboratorul.
Un site rapid apare primul pe Google chiar și cu un conținut sărac.
Google caută mereu conținutul cel mai relevant; experiența bună ajută, nu înlocuiește.
Încărcarea amânată pe imaginea principală poate înrăutăți LCP.
Întârzie tocmai elementul pe care îl măsoară LCP: se folosește doar pe imaginile mai de jos.
FID este încă unul dintre cele trei Core Web Vitals.
Din 12 martie 2024 a fost înlocuit de INP.
Declararea lățimii și înălțimii imaginilor reduce CLS.
Browserul rezervă spațiul înainte să le descarce, iar textul nu mai sare.
07Planul de lucru: de unde începi
Îmbunătățirea Core Web Vitals nu este o întrecere de trucuri. Este o muncă ordonată, care pornește de la ce cântărește cel mai mult și măsoară fiecare pas.
1
Măsoară
Date reale și laborator, pe telefon, pentru paginile care contează: prima pagină, servicii, contact, rezervare.
2
Imagini
Dimensiuni corecte, formate moderne, spațiu rezervat, imaginea principală imediat.
3
Scripturi
Scoate-le pe cele inutile, amână-le pe celelalte după conținut, încarcă-le doar unde e nevoie.
4
Server
Cache, compresie, un TTFB sub control: podeaua pe care stă tot restul.
5
Verifică din nou
Datele reale se schimbă încet: după o corectură te uiți din nou la ele în săptămânile următoare.
| Simptom | Măsură | Cauză tipică | Remediu |
|---|---|---|---|
| ecran alb mult timp | LCP | server lent, CSS care blochează | cache, mai puține fișiere, TTFB mai mic |
| fotografie de copertă întârziată | LCP | imagine de megabytes, încărcată cu întârziere | redimensionare, WebP sau AVIF, prioritate ridicată |
| butoane care nu răspund | INP | scripturi grele, widgeturi externe | mai puține scripturi, sarcini sparte |
| meniu care se deschide greu | INP | cod care recalculează toată pagina | cod mai țintit, răspuns vizual imediat |
| text care sare în jos | CLS | imagini fără dimensiuni, bannere întârziate | lățime și înălțime, spațiu rezervat |
| rânduri care se lățesc | CLS | schimbarea fontului la jumătatea încărcării | fonturi de rezervă de mărime asemănătoare |
Pentru o afacere locală, viteza pe telefon cântărește și mai mult: cine caută „lângă mine” o face aproape mereu din mers și alege în câteva secunde. E tema capitolului despre SEO local. Iar dacă site-ul trebuie să devină și o aplicație de ținut pe telefon, Core Web Vitals sunt baza pe care se construiește o PWA care se deschide ca o aplicație adevărată.
Pune-te la încercare
Site-ul tău trece proba parcării?
Întrebări frecvente
Care sunt pragurile bune pentru Core Web Vitals?
LCP sub 2,5 secunde, INP sub 200 de milisecunde, CLS sub 0,1, evaluate la percentila 75 a vizitelor reale, separat pentru telefon și calculator.
Influențează Core Web Vitals poziționarea pe Google?
Google le consideră parte din experiența paginii pe care sistemele lui o răsplătesc și recomandă să fie bune. Precizează însă că arată mereu conținutul cel mai relevant, chiar dacă experiența nu e perfectă: viteza ajută, nu înlocuiește conținutul.
De ce testul îmi dă un scor mare, dar evaluarea e negativă?
Scorul vine dintr-o probă de laborator, evaluarea de la vizitatorii reali. Telefoane mai lente, conexiuni mai proaste și interacțiuni reale pot da rezultate mai slabe decât simularea.
Ce s-a întâmplat cu FID?
Din 12 martie 2024 a fost înlocuit de INP, care măsoară reactivitatea tuturor interacțiunilor din vizită și nu doar întârzierea primei.
De unde merită să începi ca să îmbunătățești?
De la imagini, aproape mereu: dimensiunile corecte, formatele moderne și spațiul rezervat corectează împreună LCP și CLS. Apoi scripturile externe, care apasă pe INP, și în final serverul.
Paginile cu puține vizite au date reale?
Nu întotdeauna: raportul Chrome include doar paginile destul de vizitate. Când lipsesc datele paginii respective, te uiți la datele de ansamblu ale site-ului și folosești laboratorul pentru cauze.
Surse
- web.dev (Google), „Web Vitals”: cele trei măsuri, pragurile și percentila 75.
- web.dev, „Largest Contentful Paint”, „Interaction to Next Paint” și „Cumulative Layout Shift”: definiții, benzi și calculul scorului.
- web.dev, anunțul din 12 martie 2024: INP înlocuiește FID.
- Google Search Central, „Core Web Vitals și rezultatele căutării” și „Experiența paginii”.
- Chrome for Developers, metodologia raportului CrUX: cine este numărat și ce pagini.
- web.dev, ghiduri pentru optimizarea LCP, INP și CLS.
Capitol actualizat în octombrie 2026. Pragurile și definițiile provin din documentația oficială Google; timpii din planșe sunt exemple pentru a arăta proporțiile, nu măsurători ale unui anumit site.