import { onCLS, onINP, onLCP, MetricWithAttribution } from 'web-vitals/attribution';
function sendToAnalytics(metric: MetricWithAttribution) {
const body = JSON.stringify({
name: metric.name,
value: metric.value,
rating: metric.rating, // 'good' | 'needs-improvement' | 'poor'
delta: metric.delta,
id: metric.id,
attribution: metric.attribution,
url: window.location.pathname,
});
// Folosim sendBeacon pentru a nu bloca navigarea utilizatorului
if (navigator.sendBeacon) {
navigator.sendBeacon('/api/rum-metrics', body);
} else {
fetch('/api/rum-metrics', { body, method: 'POST', keepalive: true });
}
}
export function initWebVitals() {
onCLS(sendToAnalytics);
onINP(sendToAnalytics);
onLCP(sendToAnalytics);
}Dacă testezi performanța doar cu Lighthouse pe laptopul tău M-series conectat la fibră, te minți singur. Utilizatorii reali vin de pe telefoane mid-range de acum trei ani, prin conexiuni 4G instabile din metrou, iar acolo metricile Core Web Vitals arată complet diferit.
Am pățit-o pe un proiect recent de e-commerce cu aproximativ 40k de vizitatori unici pe lună. În panoul Vercel totul părea verde, dar în Google Search Console primeam avertismente constante pe INP (Interaction to Next Paint) și LCP la paginile de categorie.
Iluzia synthetic tests și de ce contează RUM
Testele sintetice rulează într-un mediu steril, cu cache curat și fără extensii de browser care injectează 15 scripturi în DOM. RUM (Real User Monitoring) măsoară exact milisecundele trăite de Gigel când apasă pe butonul de adăugare în coș.
De când Google a înlocuit definitiv FID cu INP, optimizarea a devenit mult mai complicată. INP nu măsoară doar prima interacțiune, ci monitorizează cel mai prost răspuns al interfeței pe toată durata sesiunii. Dacă ai un dropdown de filtrare care blochează main thread-ul 300ms la al cincilea click, pagina ta a picat testul.
Vercel Analytics vs RUM Custom
Vercel Speed Insights e comod. Pui un pachet npm, activezi un toggle în dashboard și ai grafice frumoase fără să configurezi baze de date.
Dar vine cu limitări mari când vrei să faci debug serios:
- Nu ai date de atribuire granulare (care element DOM anume a declanșat layout shift-ul sau ce event handler a ținut procesorul blocat).
- Costurile sar rapid dacă ai volum mare de trafic.
- Datele sunt agregate rigid și nu le poți corela ușor cu ID-ul de sesiune sau erorile din Sentry.
La proiectul menționat am renunțat la panoul default și am implementat biblioteca oficială web-vitals cu modulul de attribution build, trimițând datele direct într-un endpoint intern conectat la ClickHouse.
Trade-off-uri pe bune
Să-ți construiești propriul pipeline de RUM înseamnă mentenanță în plus. Trebuie să gestionezi rate limiting, să filtrezi botii care trimit valori aberante și să construiești dashboard-uri în Grafana.
Pe de altă parte, câștigi vizibilitate chirurgicală. Am descoperit că 70% din problemele noastre de LCP nu veneau din optimizarea imaginilor (care erau servite impecabil prin CDN), ci dintr-un banner de cookie consent care întârzia randarea fonturilor cu 450ms pe dispozitivele mobile.
Dacă ai un site de prezentare sau un blog, Vercel Analytics e mai mult decât suficient. Dar dacă trăiești din conversii și SEO organic pe un magazin mare sau SaaS, colectarea manuală a metricilor cu tot cu target element e singura cale prin care nu orbecăi când repari performanța.
Voi cum monitorizați CWV în prod: mergeți pe soluții all-in-one plătite sau vă trimiteți metricele în propriul stack?