import { onCLS, onINP, onLCP } from 'web-vitals';
function sendToAnalytics(metric) {
// Trimitem date doar pentru 10% din sesiuni ca să nu încărcăm baza de date
if (Math.random() > 0.1) return;
const body = JSON.stringify({
name: metric.name,
value: metric.value,
id: metric.id,
path: window.location.pathname,
// Putem adăuga informații despre conexiune
connection: navigator.connection ? navigator.connection.effectiveType : 'unknown'
});
if (navigator.sendBeacon) {
navigator.sendBeacon('/api/analytics/vitals', body);
} else {
fetch('/api/analytics/vitals', { method: 'POST', body, keepalive: true });
}
}
onCLS(sendToAnalytics);
onINP(sendToAnalytics);
onLCP(sendToAnalytics);Ne batem capul cu Core Web Vitals de ani de zile, dar în 2026 lucrurile s-au complicat serios. Google a tăiat complet toleranța pentru delay-urile pe mobil. Dacă încă te bazezi doar pe testele sintetice din Lighthouse sau pe tabul de Core Web Vitals din Search Console care îți arată date agregate cu o întârziere de 28 de zile, pierzi useri și SEO rank fără să înțelegi de unde ți se trage.
Hai să vedem cum monitorizăm LCP, INP și CLS direct pe useri reali în producție, fără să plătim mii de dolari pe lună pe tool-uri enterprise.
Realitatea din teren: INP și LCP pe telefoane ieftine
La un proiect recent cu 45k de utilizatori unici pe lună (un e-commerce construit pe Next.js), aveam toate scorurile verzi în Lighthouse. Totul părea perfect în CI/CD. Când m-am uitat prima dată pe datele de monitorizare din producție, am avut un șoc: INP (Interaction to Next Paint) era complet în aer, sărea frecvent de 380ms pe dispozitivele Android din gama de buget.
De ce s-a întâmplat asta? Pentru că Lighthouse testează site-ul pe o conexiune emulată și pe un procesor simulat de pe laptopul tău de dev de ultimă generație. În realitate, un user care folosește o rețea 4G aglomerată și un telefon de 800 de lei experimentează un lag masiv când apasă pe butonul de adăugare în coș. Fără Real User Monitoring (RUM) ești complet orb la ce se întâmplă cu adevărat.
Vercel Analytics vs RUM Custom
Dacă rulezi aplicația pe Vercel, tentația e uriașă să bifezi "Enable Web Analytics". Am făcut-o și eu, recunosc. E genial de simplu: dai un click în dashboard și ai imediat graficele în față.
Dar aici intervine un trade-off sincer: Vercel Analytics e excelent pentru un overview rapid și te scapă de configurări, însă devine foarte scump dacă ai volum mare de trafic și e complet inutil când vrei să debughezi de ce a crăpat INP-ul. Nu îți spune ce element HTML a declanșat layout shift-ul (CLS) sau care funcție JS a blocat main thread-ul.
Pentru a rezolva asta, am preferat să folosesc librăria oficială web-vitals de la Google și să trimit datele direct în backend-ul propriu. Am implementat o logică de sampling de 10% din trafic. Astfel, am economisit în jur de 150 de dolari pe lună și am obținut exact datele brute de care aveam nevoie pentru debugging.
Cum prinzi vinovatul în producție
Nu vrei doar o valoare medie a CLS-ului în dashboard. Vrei să știi exact ce element s-a deplasat pe ecran în momentul în care userul a dat scroll. Codul de mai jos rulează direct în client și trimite metricele esențiale către API-ul nostru doar pentru eșantionul selectat.