import { onLCP, onINP, onCLS, Metric } from 'web-vitals';
function sendToAnalytics(metric: Metric) {
const body = JSON.stringify({
name: metric.name,
value: metric.value,
rating: metric.rating,
id: metric.id,
page: window.location.pathname,
effectiveType: (navigator as any).connection?.effectiveType || 'unknown'
});
if (navigator.sendBeacon) {
navigator.sendBeacon('/api/vitals', body);
} else {
fetch('/api/vitals', { body, method: 'POST', keepalive: true });
}
}
export function initWebVitals() {
onLCP(sendToAnalytics);
onINP(sendToAnalytics);
onCLS(sendToAnalytics);
}Am refăcut recent monitorizarea de performanță pe un magazin online cu 90k vizitatori lunari pentru că Lighthouse ne arăta doar scoruri verzi de 95+, în timp ce în Google Search Console aveam alerte constante. În producție, pe telefoane ieftine și conexiuni 4G slabe, INP-ul o lua razna complet. Dacă te bazezi doar pe teste sintetice, pierzi lejer traficul organic fără să înțelegi de ce pici în SERP.
De ce te păcălește Lighthouse și ce e de făcut cu INP
Lighthouse rulează într-un mediu steril. N-are extensii de adblocker care consumă RAM, n-are 20 de tab-uri deschise în fundal și nici nu simulează un utilizator real care dă click furios pe un buton în timp ce se hidratează React-ul.
LCP (Largest Contentful Paint) și CLS (Cumulative Layout Shift) le-am stabilizat destul de repede. Un CDN bine configurat, priority pe imaginea hero și dimensiuni explicite pe div-uri rezolvă 90% din cazuri.
Problema dureroasă rămâne INP (Interaction to Next Paint). Am avut un buton de "Adaugă în coș" care în dev răspundea în 15ms. În prod, la p75 pe Android mid-range, ajungea la 340ms. Motivele? Re-renderings inutile în fundal, handler-e de event neoptimizate și un script de analytics care bloca main thread-ul exact când userul făcea prima interacțiune.
Vercel Analytics vs Custom RUM (Real User Monitoring)
Când vrei date reale de la utilizatori (RUM), prima tentație e să activezi Vercel Speed Insights sau Vercel Analytics.
Am folosit soluția lor pe mai multe proiecte de Next.js și este extrem de convenabilă. O pui în două minute în layout.tsx, ai grafice curate, iar datele vin automat agregate pe rute. Totuși, există două trade-off-uri mari:
- Costul la volum: Dacă ai trafic serios, costurile cresc rapid când depășești planul Pro. Pentru un proiect cu un milion de event-uri pe lună, plătești substanțial doar ca să vezi niște medii.
- Lipsa de context la debug: Vercel îți arată că ai p75 prost pe ruta
/products/[slug], dar nu poți filtra ușor după versiunea de aplicație, User Agent exact, viewport sau starea rețelei (navigator.connection). Te uiți la grafic și știi că ai o problemă, dar nu știi pe ce dispozitive crapă.
Varianta pe care am trecut acum la proiectele mai mari e un pipeline custom minimalist. Folosim librăria oficială web-vitals direct în client și trimitem metricile către un endpoint propriu sau un instanță de PostHog/ClickHouse.
Cum arată un setup minimalist de RUM
Cea mai mare ironie este să adaugi o librărie grea de monitoring care strică exact performanța site-ului. Pachetul web-vitals are sub 2KB gzipped și nu blochează nimic dacă folosești sendBeacon pentru trimiterea datelor.
Prin metoda asta scăpăm de overhead-ul de rețea. Trimiterea se face când browserul are timp liber sau la descărcarea paginii. În plus, atașăm app_version și device_memory pe payload. Așa am descoperit că INP-ul nostru uriaș apărea exclusiv pe dispozitive cu mai puțin de 4GB RAM din cauza unui modal neresetat în memorie.
După două săptămâni de profilare și refactoring pe bază de date RUM reale, am coborât INP-ul mediu de la 280ms la 85ms. Conversiile pe mobile au crescut cu ~12% în luna următoare.
Voi ce folosiți pentru monitorizare în prod? Ați lăsat Vercel să se ocupe de tot sau v-ați construit un pipeline custom când au crescut volumul și costurile?