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,
delta: metric.delta,
id: metric.id,
element: 'attribution' in metric ? (metric.attribution as any)?.element : null,
page: window.location.pathname,
});
if (navigator.sendBeacon) {
navigator.sendBeacon('/api/rum-metrics', body);
} else {
fetch('/api/rum-metrics', { body, method: 'POST', keepalive: true });
}
}
onCLS(sendToAnalytics);
onINP(sendToAnalytics);
onLCP(sendToAnalytics);Dacă te bazezi doar pe Lighthouse rulat din Chrome DevTools sau din CI, optimizezi pentru un laborator imaginar. În realitate, pe un telefon mid-range cu 4G fluctuant prin provincie, cifrele tale de LCP și INP arată complet diferit. Dacă nu culegi metrici direct de la useri reali (Real User Monitoring - RUM), afli că ai probleme abia după 28 de zile, când Google Search Console îți taie din traficul organic.
De unde vine ruptura dintre Lab și Producție
Am pățit-o la un magazin online cu vreo 40k de vizite zilnice. În pipeline aveam Lighthouse cu scor 94 pe mobil. Toată lumea fericită, PR-uri merguite cu mândrie. După trei săptămâni, Search Console a început să arunce zeci de URL-uri în Needs Improvement exclusiv din cauza INP (Interaction to Next Paint) și CLS.
De ce? În laborator nu rulează scripturi de cookie consent care injectează bannere asincron după 1.5 secunde (bye bye CLS). Nici nu ai utilizatori care apasă nervos pe filtre în timp ce un bundle de 400kB de JavaScript încă face re-render în fundal. INP măsoară cea mai proastă latență la interacțiune din întreaga sesiune a utilizatorului, nu doar primul click.
Vercel Speed Insights: comoditate cu preț piperat
Dacă ești deja găzduit pe Vercel, Speed Insights e la un simplu click distanță. Îl activezi din dashboard, pui pachetul de @vercel/speed-insights, iar UI-ul lor arată curat. Îți sortează automat rutele problematice și separă scorurile pe percentile (p75, unde se uită și Google).
Trade-off-ul e cel clasic: vendor lock-in și costuri absurde când crești. Pe un proiect mic e neglijabil, dar când sari de 250k de pageviews pe lună, adaugi costuri fixe lunare doar pentru câteva grafice. Mai rău: ești legat de ecosistemul lor. Dacă mâine muți aplicația pe un cluster de Kubernetes pe Hetzner sau AWS, pierzi tot istoricul de performanță și trebuie să o iei de la zero.
Soluția pe barba ta: pachetul web-vitals + Beacon API
Biblioteca oficială web-vitals de la Google are sub 2kB gzip. Poți să trimiți metricile în propriul backend fără să blochezi vreodată firul principal de execuție, folosind navigator.sendBeacon. Trimitem datele către un endpoint serverless foarte subțire (sau un Cloudflare Worker) care varsă log-urile direct într-un ClickHouse sau într-o bază de date Timescale.
Avantajul uriaș față de Vercel e că prin funcțiile de atribuire (onINP, onLCP) poți trimite exact selectorul CSS al elementului care a declanșat problema. Nu mai ghicești care componentă a întârziat rendering-ul: primești în baza de date direct #add-to-cart-btn sau .promo-slider.
Ce alegi în final?
Dacă ai o echipă mică de 2-3 oameni și arde să livrați funcționalități de business, plătește Vercel sau DebugBear și nu-ți bate capul. Își scot banii prin timpul economisit.
Dacă ai însă trafic de la sute de mii de utilizatori în sus și un om capabil să ridice un dashboard în Grafana, un worker propriu cu web-vitals te costă sub 5 euro pe lună și îți dă granularitate totală asupra datelor.
Voi cum monitorizați Web Vitals în producție acum? Vă bazați doar pe Search Console când e deja prea târziu sau aveți alerte live?