import { onLCP, onINP, onCLS } from 'web-vitals';
function sendToAnalytics({ name, value, id, entries }) {
const body = JSON.stringify({
name,
value,
id,
element: entries[0]?.target?.className || 'unknown',
url: window.location.pathname
});
if (navigator.sendBeacon) {
navigator.sendBeacon('/api/vitals', body);
} else {
fetch('/api/vitals', { body, method: 'POST', keepalive: true });
}
}
onLCP(sendToAnalytics);
onINP(sendToAnalytics);
onCLS(sendToAnalytics);Dacă încă vă uitați doar în Lighthouse ca să măsurați LCP sau INP pentru clienții voștri, am o veste proastă: testați într-un acvariu steril. Utilizatorii reali au telefoane ieftine, conexiuni proaste și dau scroll înainte să se încarce scripturile voastre grele. Am pățit asta recent pe un proiect de e-commerce cu peste 80k useri activi, unde scorul mobil era verde în Lab, dar în Search Console eram pe roșu.
INP și LCP: De ce contează doar datele din producție
Interaction to Next Paint (INP) a devenit teroarea developerilor de frontend. Dacă LCP se mai rezolvă cu un tag de preloading pe imaginea de hero și un server rapid, INP-ul e un monstru complet diferit. Ține direct de thread-ul principal de JavaScript și de cât de repede răspunde pagina când userul dă un click.
Am avut cazul unde un script de tracking configurat prost bloca thread-ul principal exact când userul încerca să deschidă coșul de cumpărături. În Lighthouse totul arăta perfect, scor 95. În realitate, INP-ul real depășea 450ms pe dispozitivele mid-range. Utilizatorii dădeau click, nu se întâmpla nimic timp de jumătate de secundă, așa că dădeau click din nou. Rata de conversie s-a prăbușit înainte să ne prindem noi ce se întâmplă.
Vercel Analytics vs RUM custom: Trade-off-ul de care nu vorbește nimeni
Când folosești Next.js, e extrem de tentant să bifezi căsuța de "Speed Insights" din Vercel Dashboard. Dai un click, merge din prima, ai grafice frumoase. Dar vine cu un trade-off major: costul și limitarea datelor.
Vercel Analytics devine extrem de scump dacă depășești tier-ul gratuit. La proiectul nostru, am calculat că ne-ar fi costat în jur de 120 de dolari pe lună doar monitorizarea de performanță. În plus, datele sunt destul de agregate; nu poți să vezi exact ce element HTML a declanșat un layout shift masiv sau ce ID de buton a stricat INP-ul.
Așa că am trecut pe o soluție de RUM (Real User Monitoring) custom, construită în casă. Folosim librăria oficială web-vitals trimisă asincron și un endpoint simplu în Cloudflare Workers care salvează totul într-o bază de date. Am economisit 90% din costuri și, cel mai important, acum salvăm selectorul CSS exact care a provocat layout shift-ul. Știm precis: elementul .cart-drawer-item a mutat layout-ul cu 0.12 secunde.
Cum colectezi metricile fără să încetinești site-ul
Nu ai nevoie de un script imens care să ruleze în head. Vrei doar să prinzi metricile esențiale și să le trimiți fără să blochezi execuția paginii. Folosim navigator.sendBeacon pentru că rulează asincron, chiar și când utilizatorul închide tab-ul, fără să afecteze performanța percepută a paginii.
Până la urmă, optimizarea pentru Google nu mai e demult un joc de ghicite în PageSpeed Insights. RUM custom ne-a salvat bugetul și ne-a arătat exact unde lovește lag-ul în lumea reală.
Voi ce folosiți pentru monitorizarea asta în producție? Mergeți pe mâna celor de la Vercel sau v-ați scris propria soluție?