import { onINP, onLCP, onCLS, Metric } from 'web-vitals';
function sendToAnalytics(metric: Metric) {
const body = JSON.stringify({
name: metric.name,
value: metric.value,
rating: metric.rating, // 'good' | 'needs-improvement' | 'poor'
delta: metric.delta,
id: metric.id,
page: window.location.pathname,
// Context util pentru debugging
connection: (navigator as any).connection?.effectiveType || 'unknown',
target: metric.entries[0]?.target?.nodeName || null,
});
if (navigator.sendBeacon) {
navigator.sendBeacon('/api/rum-collector', body);
} else {
fetch('/api/rum-collector', { body, method: 'POST', keepalive: true });
}
}
// Monitorizăm metricile principale
onINP(sendToAnalytics);
onLCP(sendToAnalytics);
onCLS(sendToAnalytics);Nu mai stau să explic ce înseamnă LCP, INP sau CLS — le știm deja cu toții din documentația Google. Ce mă interesează pe mine și probabil și pe voi este cum le măsurăm eficient pe traficul real fără să spargem bugetul pe abonamente SaaS inutile.
Anul trecut am trecut un e-commerce de la un setup clasic la Next.js 14, găzduit pe Vercel. Aveam în jur de 45k de utilizatori unici pe lună. Prima reacție a fost să bifăm Vercel Speed Insights că e la un click distanță. Arăta superb în dashboard: totul verde, scoruri de 95+. Problema a apărut când am verificat Google Search Console după o lună: INP-ul era în zona galbenă, iar LCP-ul pe mobil fluctua agresiv.
Unde suferă Vercel Speed Insights
Vercel Analytics e excelent pentru setup rapid, dar are două mari bube când vrei să faci debug serios.
În primul rând, e vorba de eșantionare (sampling) și cost. Când crește traficul, costul pentru Speed Insights sare destul de repede. În al doilea rând, dashboard-ul îți arată medii și percentile (p75), dar nu îți oferă contextul complet al sesiunii.
Când un utilizator de pe un Samsung A12 ieftin are un INP de 450ms pe pagina de checkout, Vercel îți zice doar că ai o problemă de INP acolo. Nu știi ce script terț rula în fundal, ce element a fost apăsat sau dacă omul avea 15 tab-uri deschise.
Soluția RUM custom: web-vitals + Beacon API
M-am enervat și am scos Vercel Speed Insights de pe proiect. Am pus în schimb librăria oficială web-vitals de la Google și am trimis metricile către un mic Cloudflare Worker care scrie direct într-o instanță de ClickHouse.
Beneficiul uriaș? Am putut atașa metadata la fiecare metrică trimisă:
- Tipul de conexiune (4g, 3g, slow-2g)
- Dacă utilizatorul era autentificat sau nu
- Scripturile terțe încărcate pe pagina respectivă
- Target-ul exact din DOM care a declanșat INP-ul (ex:
#add-to-cart-button)
Măsurând așa, am descoperit că un widget de chat bloca thread-ul principal timp de 300ms la prima interacțiune, fix când userul încerca să deschidă meniul. Fără contextul ăsta extras prin RUM, băteam pasul pe loc și optimizam componente de React degeaba.
Cum arată diferența de costuri și efort
La un proiect cu ~50k utilizatori lunari, Vercel ne cerea undeva la 20-30$ suplimentar doar pentru Speed Insights/Analytics la nivelul lor de pachet. Soluția custom cu Worker și ClickHouse ne costă sub 2$ pe lună în resurse de compute, iar datele ne aparțin 100%.
Totuși, există un trade-off clar. Cu Vercel ai zero mentenanță. Cu RUM custom trebuie să-ți faci singur dashboard-ul în Grafana sau Metabase și să gestionezi tu volumul de date dacă sari de 1-2 milioane de evenimente pe lună.
Pentru proiecte mici, rămâneți pe Vercel sau folosiți utilitarul gratuit din Google PageSpeed / Chrome UX Report (CrUX). Dar dacă depindeți de conversii și SEO pe cuvinte cheie competitive, un RUM propriu bazat pe web-vitals e singura cale prin care înțelegeți cu adevărat ce se întâmplă în browserul clientului.
Voi ce folosiți pentru monitorizare în prod? V-ați lovit și voi de decalaje între ce zice Vercel și ce raporta Search Console?