Core Web Vitals în 2026: cum citești LCP, INP și CLS și ce chiar mișcă cifrele

Core Web Vitals sunt cei trei indicatori prin care Google descrie experiența unei pagini: cât de repede apare conținutul principal, cât de repede răspunde interfața la o acțiune și cât de mult se deplasează elementele în timpul încărcării.

Din martie 2024, setul este format din LCP, INP și CLS. FID a fost retras, iar INP a luat locul lui pentru că măsoară toată durata interacțiunii, nu doar întârzierea primului răspuns. Pentru un site de prezentare sau pentru un magazin online, aceste praguri nu sunt o formalitate de raport: descriu direct dacă omul apasă butonul sau închide fila.

01. Ce sunt Core Web Vitals în 2026

Google notează experiența reală a utilizatorilor din Chrome prin Chrome UX Report (CrUX). Datele sunt colectate continuu, agregate pe ultimele 28 de zile și evaluate la percentila 75. Altfel spus, un indicator este „bun” doar dacă 75% dintre vizitele reale îl încadrează în prag, nu dacă media arată bine.

Al patrulea număr util nu este un Core Web Vital oficial, dar este cel mai bun instrument de diagnostic: TTFB. El arată cât așteaptă browserul până la primul octet de la server. Dacă TTFB este mare, nici cea mai bine comprimată imagine nu poate salva LCP.

Există două surse de date care nu trebuie confundate. Datele de teren vin din browserul oamenilor și reflectă telefoane, rețele și obiceiuri reale. Datele de laborator vin dintr-un test controlat, rulat de obicei pe un server stabil, și sunt utile pentru a reproduce o problemă, nu pentru a decide dacă site-ul este rapid.

02. LCP: prima impresie se decide pe server

LCP se împarte în patru etape, iar fiecare etapă are un vinovat diferit: TTFB, întârzierea până la pornirea descărcării resursei, durata descărcării și întârzierea randării elementului. Dacă știi în care etapă pierzi timpul, nu mai optimizezi la întâmplare.

Cauze frecvente

• Server lent sau fără cache: interogări grele la fiecare vizită, PHP fără OPcache, baze de date fără indecși.
• CSS și JavaScript care blochează randarea: fișiere uriașe în <head>, încărcate sincron.
• Imagine principală neoptimizată: câteva megabiți trimiși pe mobil, fără width, height sau srcset.
• Fonturi web: textul așteaptă descărcarea fontului, iar fallback-ul nu este pregătit.
• Randare pe client: HTML-ul sosește aproape gol, iar conținutul apare după ce rulează JavaScript-ul.
• Lazy-load aplicat greșit: imaginea principală este amânată ca și cum ar fi sub pliul ecranului.

Ce funcționează cu adevărat

• Cache de răspuns și CDN: HTML-ul cache-uit la marginea rețelei, nu doar imaginile.
• Compresie modernă: Brotli pentru HTML, CSS și JavaScript.
• Imagine responsivă: AVIF sau WebP, dimensiuni corecte, srcset și fetchpriority="high" pe elementul LCP.
• Preload doar pentru ce contează: imaginea principală și fontul principal, nu zeci de resurse „preventiv”.
• CSS critic inline: restul foilor de stil se încarcă fără să blocheze prima randare.
• Randare pe server: HTML complet la primul răspuns, indiferent de tehnologia folosită.

Înainte de a schimba ceva, deschide DevTools, rulează un profil de performanță pe mobil și identifică elementul LCP real. Uneori nu este imaginea, ci un titlu mare care așteaptă un font sau un bloc de text randat abia după hidratare.

03. INP: viteza reală se măsoară în firul principal

INP nu întreabă cât de repede se încarcă pagina, ci cât de repede reacționează după ce utilizatorul face ceva. Include timpul până când browserul poate începe să proceseze evenimentul, timpul de execuție al funcției care tratează evenimentul și timpul până la următorul cadru vizibil. Un singur click care blochează firul principal pentru 600 de milisecunde strică indicatorul pentru toată sesiunea.

Unde se pierde timpul

• Sarcini lungi: orice bucată de JavaScript care ține firul principal ocupat peste 50 de milisecunde.
• Pachete JavaScript umflate: biblioteci întregi încărcate pentru o singură funcție.
• Scripturi terțe: chat, hărți de căldură, teste A/B, bannere de consimțământ și pixeli care rulează înaintea conținutului.
• Hidratare costisitoare: componente mari care re-execută logica pe client la fiecare încărcare.
• Funcții de tratare costisitoare: recalculări de aspect, filtre aplicate sincron la fiecare tastă, liste uriașe re-randate integral.

Ce reduce INP-ul cu adevărat

Prima intervenție este să scoți din calea interacțiunii tot ce nu este necesar. A doua este să împarți codul, astfel încât pagina să descarce doar ce folosește. A treia este să predai controlul browserului între bucățile grele de muncă, ca să poată randa un cadru.

button.addEventListener('click', async () => {
    // cedăm controlul înainte de o operație grea
    if ('scheduler' in window && 'yield' in scheduler) {
        await scheduler.yield();
    }

    renderResults();
});

Restul măsurilor sunt la fel de concrete: încarcă scripturile terțe după prima interacțiune sau după consimțământ, folosește defer și importuri dinamice, mută calculele grele în Web Workers și evită citirea dimensiunilor din pagină în funcțiile care tratează derularea. Pentru formulare și liste lungi, limitarea frecvenței apelurilor și delegarea evenimentelor reduc numărul de execuții, nu doar durata lor.

04. CLS: spațiul rezervat bate orice efect vizual

CLS nu măsoară cât de mult durează încărcarea, ci cât de agresiv se mișcă elementele sub degetul utilizatorului. Un buton care fuge cu 80 de pixeli în jos exact când omul vrea să apese este o problemă de conversie, nu doar de scor.

Cauze frecvente

• Imagini fără dimensiuni: browserul nu știe ce spațiu să rezerve până la descărcare.
• Fonturi care schimbă metrica: textul se rearanjează când apare fontul personalizat.
• Reclame și conținut încorporat: iframe-uri fără înălțime fixă, spații publicitare completate târziu.
• Bannere injectate: notificări de consimțământ sau promoții care împing conținutul în jos.
• Conținut adăugat deasupra: mesaje de eroare, alerte sau componente încărcate asincron peste zona vizibilă.

Ce funcționează cu adevărat

• Dimensiuni explicite: width și height pe imagini, aspect-ratio pe containere.
• Spațiu rezervat: înălțime minimă pentru reclame, conținut încorporat, carduri și zone care se încarcă asincron.
• Fonturi disciplinate: font-display: swap sau optional, plus un fallback cu metrici apropiate prin size-adjust.
• Bannere ca suprapunere: mesajul de consimțământ nu trebuie să împingă conținutul, ci să stea deasupra lui.
• Animații pe transform: transform și opacity nu declanșează reflow, spre deosebire de top sau height.

Un truc util în audit: rulează pagina cu rețeaua încetinită și cu cache-ul gol, apoi urmărește succesiunea de cadre. Deplasările care apar în primele secunde sunt cele care contează pentru CLS, chiar dacă utilizatorul nu apucă să le vadă pe un calculator rapid.

05. Cum măsori corect

Ordinea corectă este simplă: întâi datele de teren, apoi segmentarea, apoi laboratorul pentru reproducere. Dacă începi cu Lighthouse, riști să repari un simptom care nu apare la utilizatorii reali și să ignori problema care chiar îi afectează.

Când compari rezultate, păstrează constant contextul: același tip de dispozitiv, aceeași rețea, aceeași versiune de pagină. Altfel, diferența dintre două rapoarte poate veni din condițiile de test, nu din codul tău.

06. Note de platformă: Laravel și WordPress

Aceleași principii se aplică oriunde, dar uneltele diferă. În Laravel ai control direct asupra lanțului de livrare. În WordPress, de multe ori moștenești decizii luate de plugin-uri pe care nu le controlezi.

Laravel

Începe cu răspunsul serverului: OPcache activ, interogări indexate, încărcarea anticipată a relațiilor și un strat de cache pentru paginile care nu depind de sesiune. Apoi intră în Vite. Fișierul de manifest și importurile dinamice îți permit să trimiți doar JavaScript-ul necesar paginii, iar modulele se încarcă nativ cu defer. Nu aduna toată interfața într-un singur pachet „ca să fie simplu”.

Pentru imagini, generează variante AVIF și WebP la încărcare, într-un proces din coadă, și salvează în baza de date dimensiunile reale. Șablonul trebuie să emită srcset corect, nu o singură imagine de 3000 de pixeli redimensionată cu CSS. Adaugă un CDN în fața aplicației și antete de cache pentru resursele cu amprentă în nume.

Atenție la componentele interactive de deasupra pliului: dacă hidratarea lor blochează firul principal, LCP-ul și INP-ul au de suferit împreună. Izolează-le și încarcă-le după ce conținutul principal este vizibil.

WordPress

Problema nu este WordPress în sine, ci stratul de plugin-uri și constructoare de pagini adăugat peste el. Fiecare plugin care încarcă CSS și JavaScript global pe toate paginile crește costul pentru vizitator, chiar dacă funcția lui este folosită pe o singură pagină.

• Elimină plugin-urile duplicate și cele care încarcă resurse pe tot site-ul.
• Verifică ce fonturi și seturi de iconițe sunt încărcate de temă și de constructorul de pagini.
• Activează un cache de pagină și, dacă ai trafic autentificat, un cache de obiecte.
• Folosește un CDN și comprimare la nivel de server, nu doar un plugin de „optimizare”.
• Testează pe un mediu de test fiecare modificare, pentru că un plugin de cache poate masca o problemă de cod.

07. Checklist practic

Ordinea contează. Nu optimiza imagini înainte să știi dacă serverul răspunde în două secunde, pentru că vei măsura din nou aceeași problemă.

08. Ce faci luni dimineață

Dacă nu ai timp pentru tot procesul, începe cu cele trei intervenții care au cel mai mare efect: cache și CDN pentru TTFB, o imagine principală corect dimensionată și eliminarea scripturilor terțe din calea primei interacțiuni. Apoi măsori din nou, în teren, pe mobil.

Nu căuta o singură soluție miraculoasă. Core Web Vitals sunt rezultatul unor decizii mici luate consecvent: fiecare imagine are dimensiuni, fiecare script are un motiv să existe, fiecare componentă se încarcă atunci când este nevoie. Așa se construiește un site care rămâne rapid și după ce adaugi funcționalități noi.

Dacă vrei o evaluare pe cod, cu priorități clare și fără rapoarte umflate, putem porni de la o optimizare de viteză pentru site-ul tău sau de la o discuție directă despre ce se poate repara în arhitectura actuală.