import { onINP, onLCP, onCLS } from 'web-vitals';
function sendToAnalytics({ name, value, id }) {
const body = JSON.stringify({ name, value, id });
// Folosim sendBeacon pentru a nu bloca navigarea sau thread-ul principal
if (navigator.sendBeacon) {
navigator.sendBeacon('/api/vitals', body);
} else {
fetch('/api/vitals', { body, method: 'POST', keepalive: true });
}
}
// Monitorizăm interacțiunile reale ale userilor
onINP(sendToAnalytics);
onLCP(sendToAnalytics);
onCLS(sendToAnalytics);Am trecut demult de faza aia romantică în care rulam un Lighthouse în Chrome, vedeam totul verde și ciocneam o bere că site-ul e „rachetă”. În 2026, dacă te bazezi doar pe mediul tău de dev cu procesor M3 și fibră de 1Gbps, te minți singur. Am pățit-o la un proiect de e-commerce cu vreo 12k vizitatori unici pe zi: în local totul zbura, dar în Google Search Console eram pe „roșu” la greu.
Problema cea mai mare acum nu mai e LCP-ul (Largest Contentful Paint), pe care l-am cam învățat toți să-l dresăm cu un fetchpriority="high" și ceva optimizare de imagini. Marea bătaie de cap e INP (Interaction to Next Paint). De când a înlocuit oficial FID-ul, ne-a arătat cât de prost stau site-urile noastre la capitolul reactivitate reală.
De ce INP-ul e noul „bau-bau”
Recent, am lucrat la un dashboard complex unde userii făceau multe filtrări client-side. Pe laptop-ul meu de muncă, filtrarea dura 100ms. Pe un telefon mid-range de acum trei ani, același script bloca main thread-ul aproape 600ms. Lighthouse nu prinde asta pentru că el nu „apasă” pe butoane ca un om.
Aici intervine monitorizarea în producție. Dacă nu ai date de la utilizatori reali (RUM - Real User Monitoring), ești orb. Am observat că o îmbunătățire a INP-ului de la 450ms la sub 200ms a dus la o creștere de 12% în rata de conversie pe acel funnel. Oamenii nu mai simțeau că interfața „agață” și nu mai dădeau rage-click.
Vercel Analytics vs. Soluții RUM Custom
Mulți folosim Vercel pentru că e comod. Vercel Speed Insights e drăguț, e integrat, dar are o mare problemă: costul la scară. Când am sărit de 500k de datapoints, factura a început să arate destul de urât pentru niște grafice pe care le puteam obține și altfel.
Trade-off-ul e simplu:
- Vercel Analytics e bun dacă vrei să pornești la drum în 5 minute și ai buget. E „set and forget”.
- Sentry sau Datadog îți dau detalii chirurgicale, poți să vezi exact ce funcție JS a blocat thread-ul, dar te costă timp să le configurezi calumea.
- Soluția custom (librăria
web-vitals+ un endpoint de Beacon API) e cea mai ieftină. Am implementat asta pe un proiect de conținut și am redus costurile de monitorizare cu 80%, trimițând datele direct în BigQuery.
Cum monitorizezi fără să strici performanța
E ironic să adaugi scripturi de monitorizare care să scadă performanța, nu? Am văzut setup-uri unde scriptul de analytics mănâncă 150ms din TBT (Total Blocking Time). Folosiți întotdeauna requestIdleCallback pentru a trimite metricile către server. Nu vrei ca telemetria să se bată pe resurse cu randarea paginii.
La un proiect cu Next.js, am mutat logica de trimitere a metricilor într-un Web Worker. Rezultatul? Impact zero asupra main thread-ului și date precise de la 95% dintre utilizatori.
Nu uitați de CLS (Cumulative Layout Shift). Chiar și în 2026, încă văd fonturi care se încarcă târziu și împing tot conținutul 20 de pixeli mai jos. E o chestie de 5 minute să pui un font-display: swap și dimensiuni clare pe containere, dar mulți uită.
Voi ce folosiți pentru a urmări INP-ul în „sălbăticie”? Vă bazați pe ce zice Search Console după 28 de zile sau aveți dashboard-uri în timp real?