Core Web Vitals în 2026 — de ce viteza este design, nu optimizare

Viteza nu este o etapă a proiectului. Este consecința unor decizii luate în prima săptămână, cu mult înainte ca cineva să deschidă un instrument de măsurare.

Core Web Vitals nu sunt un scor abstract. Fiecare metrică descrie un moment precis din experiența unui om real care așteaptă în fața unui ecran.

LCP — Largest Contentful Paint

Momentul în care cel mai mare element vizibil din prima fereastră termină de randat: de obicei imaginea de hero, uneori blocul de titlu. Prag bun: sub 2,5 secunde. Peste 4 secunde ești în roșu. LCP nu întreabă cât de repede a răspuns serverul, ci cât de repede a apărut ceva ce contează pentru vizitator.

INP — Interaction to Next Paint

Metrica de responsivitate care a înlocuit FID. Măsoară latența dintre o interacțiune — tap, clic, tastă — și următorul cadru pictat de browser, ținând cont de cele mai proaste interacțiuni dintr-o sesiune, nu doar de prima. Bun: sub 200 ms. Slab: peste 500 ms. Este metrica pe care JavaScript-ul o pedepsește cel mai dur: dacă firul principal e ocupat cu hidratare sau cu un script terț, degetul utilizatorului apasă în gol.

CLS — Cumulative Layout Shift

Cât de mult sare conținutul sub degetul omului. Prag bun: sub 0,1. Nu este o problemă de viteză, ci de igienă a layout-ului: imagini fără dimensiuni declarate, fonturi care schimbă metrica textului la swap, bannere injectate deasupra unui paragraf pe care cineva tocmai îl citea.

Toate trei se raportează la percentila 75 a vizitatorilor reali, separat pe mobil și pe desktop. Nu contează cum se simte site-ul pe laptopul tău. Contează al treilea vizitator din patru, pe un telefon mediu, pe o rețea mediocră.

Există convingerea larg răspândită că performanța se rezolvă la final, printr-un pas de optimizare. Nu se rezolvă. Până la finalul proiectului, deciziile scumpe sunt deja luate și au devenit identitatea vizuală a site-ului. Nimeni nu mai taie hero-ul cu o săptămână înainte de lansare.

Trei lucruri se hotărăsc în ziua întâi:

• Strategia de imagine. Un video de fundal de 8 MB sau o fotografie necomprimată de 4 MB pe o conexiune mobilă înseamnă secunde, nu milisecunde. Nicio configurare de CDN nu repară o decizie de direcție artistică ce cere un fișier uriaș deasupra pliului.
• Fonturile. Fiecare familie, fiecare greutate, fiecare set de caractere este o cerere în plus pe calea critică. Două familii cu două greutăți fiecare sunt un buget sănătos. Cinci greutăți plus un font de afișaj plus unul de accent sunt o promisiune de LCP slab și de text care sare.
• Stabilitatea layout-ului. Dacă designul prevede un slot de banner, un widget de recenzii sau o hartă încorporată, spațiul trebuie rezervat în machetă, cu dimensiuni fixe. Altfel CLS-ul e scris în design înainte să fie scris în cod.

Un site rapid nu se obține tăind lucruri la final. Se obține alegând mai puține lucruri la început.

Aceeași logică se aplică arhitecturii. Alegerea dintre randare pe server și o aplicație grea de client este o decizie de performanță, nu una de gust — compromisurile sunt detaliate în articolul despre server components și arhitectură.

Aici e nevoie de onestitate, nu de statistici împrumutate. Mecanismul se înțelege și fără procente.

Un vizitator care așteaptă are trei opțiuni: să aștepte, să apese din nou, sau să plece. Pe mobil, unde atenția e fragmentată și butonul de înapoi e la un centimetru distanță, a treia opțiune este cea mai ieftină pentru el. Fiecare secundă în plus adaugă oameni care nu au apucat să vadă oferta.

Costul se propagă:

• Traficul plătit devine mai scump. Plătești clicul indiferent dacă pagina s-a încărcat. O pagină de destinație lentă transformă buget de reclamă în abandon măsurat.
• Conversia se erodează tăcut. Un formular care îngheață o fracțiune de secundă la fiecare tastă nu generează o reclamație, generează un formular abandonat.
• Poziția în căutare se pierde marginal. Core Web Vitals sunt un semnal real, dar secundar. Nu bat relevanța conținutului. Însă între două pagini comparabile, cea rapidă câștigă — iar infrastructura contează la fel de mult ca textul, așa cum arată partea tehnică a SEO.

Cea mai frecventă confuzie din discuțiile despre performanță.

Lighthouse este laborator: o simulare pe un dispozitiv și o rețea inventate, cu rezultat repetabil. Este un instrument de diagnostic excelent. Nu este realitate.

CrUX — Chrome User Experience Report — este teren: măsurători agregate de la utilizatori reali, pe telefoanele și rețelele lor, pe o fereastră de 28 de zile. Asta vede motorul de căutare și asta contează.

Consecința practică: Lighthouse îți spune de ce e lent, CrUX îți spune dacă e lent. Nu urmări scorul de 100. Urmărește ca percentila 75 pe mobil să fie verde la toate trei. Și ai răbdare — datele de teren se mișcă în săptămâni, nu în ore, deci un deploy bun nu se vede a doua zi.

După destule audituri, lista vinovaților devine plictisitor de constantă.

• Imaginea de hero. Servită fără AVIF sau WebP, fără srcset, uneori la rezoluție de retina pentru un telefon care nu are nevoie de ea. Este cauza numărul unu a unui LCP prost.
• Fonturile web. Încărcate târziu, fără preload pe fișierul critic, fără font-display corect, fără un fallback cu metrici apropiate. Rezultatul: text invizibil, urmat de o săritură de layout.
• Tag manager-ul. Un singur container prin care se injectează, în timp, șase scripturi pe care nimeni nu le mai revizuiește. Fiecare consumă fir principal și strică INP-ul.
• Embed-urile și bannerele. Hărți, playere video, widget-uri de recenzii, casete de consimțământ care apar după o secundă și împing pagina în jos. CLS garantat.
• Hidratarea excesivă. Pagini în care nouă zecimi din conținut este static, dar întregul arbore devine interactiv la încărcare.

• Stabilește un buget de performanță înainte de design: greutate maximă pe prima fereastră, număr maxim de fonturi, listă de scripturi terțe aprobate.
• Servește imaginea de hero în format modern, dimensionată pe breakpoint, cu width și height declarate și cu preload pe varianta critică.
• Rezervă spațiu pentru tot ce se încarcă asincron, prin aspect-ratio sau min-height.
• Amână orice script terț care nu e necesar pentru primul cadru și cere justificare pentru fiecare adăugare ulterioară.
• Mută munca de pe firul principal: mai puțin JavaScript trimis, componente interactive doar acolo unde există efectiv interacțiune.
• Monitorizează în teren, continuu. O regresie de performanță vine mereu din direcția pe care nu o urmărești.

Aceeași disciplină — mai puțin, dar corect — produce și interfețe accesibile; accesibilitatea și performanța se susțin reciproc.

Nu vorbi în metrici. Vorbește în consecințe.

Un client nu simte 2,8 secunde de LCP. Simte că site-ul concurentului pare mai serios. Traducerea corectă sună așa: fiecare element adăugat deasupra pliului costă timp de așteptare, iar timpul de așteptare costă clienți. Nu spunem nu pentru că nu se poate, spunem că fiecare lucru are un preț în secunde, iar bugetul de secunde este finit.

Apoi arată, nu explica. Un test pe un telefon real, pe date mobile, cu site-ul clientului lângă al concurenței, încheie discuția în treizeci de secunde. Dacă vrei să vezi disciplina asta aplicată, proiectele noastre sunt construite pe aceleași reguli.