import { onINP, onCLS } from 'web-vitals/attribution';
function sendToAnalytics({ name, value, id, attribution }) {
const body = JSON.stringify({
name,
value,
id,
element: name === 'INP' ? attribution.interactionTarget : attribution.largestShiftTarget,
loadState: attribution.loadState
});
if (navigator.sendBeacon) {
navigator.sendBeacon('/api/vitals', body);
} else {
fetch('/api/vitals', { body, method: 'POST', keepalive: true });
}
}
onINP(sendToAnalytics);
onCLS(sendToAnalytics);Ne batem capul cu Core Web Vitals și în 2026, iar INP (Interaction to Next Paint) a devenit noul coșmar pentru SEO și UX. Dacă te bazezi doar pe Lighthouse sau pe datele sintetice din CI/CD, pierzi complet din vedere ce experimentează utilizatorii tăi reali. Am trecut recent prin procesul ăsta la un proiect cu 25k vizitatori unici pe lună și vreau să îți arăt de ce uneltele "out-of-the-box" s-ar putea să te mintă frumos.
Vercel Analytics: Bun, dar scump și chior
Să fim sinceri. Vercel Analytics e mișto pentru că îl activezi cu un singur click din consolă. N-ai nevoie de setup, n-ai cod de scris. Dar are două mari probleme cu care m-am lovit direct.
În primul rând, costul devine nesimțit destul de repede dacă ai trafic mediu spre mare. În al doilea rând, și cel mai important, îți oferă doar date agregate (P75 sau P90). Vezi că ai un INP de 350ms pe paginile de produs, dar habar n-ai care element sau ce script blochează thread-ul principal. E un buton de adaugă în coș? E widget-ul de chat? Vercel nu-ți spune asta. Pentru noi, asta a însemnat ore întregi de ghicit și teste inutile în tab-ul de Performance din Chrome DevTools.
RUM custom: Cum prinzi vinovatul din spatele CLS și INP
Ca să rezolvăm problema, am renunțat la soluțiile predefinite și am trecut la un RUM (Real User Monitoring) custom, folosind librăria oficială web-vitals de la Google. Avantajul e uriaș: poți colecta "attribution data". Adică poți trimite la server selectorul exact al elementului HTML care s-a deplasat (pentru CLS) sau pe care s-a dat click (pentru INP).
Am ales să trimitem aceste date printr-un simplu endpoint de Cloudflare Workers direct într-o bază de date ClickHouse (poți folosi și Tinybird sau Supabase). Cost total? Sub 5 dolari pe lună, față de sutele de dolari pe care le cereau platformele de RUM dedicate sau add-on-ul de la Vercel. Plus că deținem 100% din date și am economisit cam 30% la timpul de debugging.
Ce am descoperit după o săptămână de monitorizare reală
Surpriza a fost uriașă. În timp ce testele sintetice arătau un CLS impecabil de 0.02, utilizatorii reali de pe telefoane Android ieftine aveau un CLS de 0.28 pe pagina de checkout. Vinovatul? Un banner de cookie-uri care se încărca asincron și împingea tot conținutul în jos cu 80 de pixeli, dar doar pe ecrane mai înguste de 360px.
La fel și cu INP. Am descoperit că scriptul de tracking de la Facebook Pixel bloca interacțiunea cu meniul de navigare timp de 450ms pe ecranele mobile, lucru pe care Lighthouse nu îl detecta deloc pentru că el nu face click efectiv pe elemente în timpul rulării.
Cum facem monitorizarea eficientă în 2026?
Trade-off-ul e clar. Setup-ul custom îți cere timp de implementare și mentenanță pentru infrastructura de colectare a logurilor. Dacă ai un site de prezentare cu 500 de vizite pe lună, rămâi pe Vercel Analytics sau chiar pe PageSpeed Insights (CrUX). Dar dacă business-ul tău depinde de conversii și SEO, merită să investești două zile să îți pui la punct propriul sistem RUM.
Voi cum monitorizați performanța în producție acum? Mergeți pe chestii integrate sau v-ați construit propriul pipeline de date?