import { onINP, onLCP, onCLS, Metric } from 'web-vitals/attribution';
function sendToAnalytics(metric: Metric) {
const body = JSON.stringify({
name: metric.name,
value: metric.value,
rating: metric.rating,
delta: metric.delta,
id: metric.id,
attribution: (metric as any).attribution
});
// sendBeacon nu blocheaza navigarea sau inchiderea tab-ului
if (navigator.sendBeacon) {
navigator.sendBeacon('/api/rum-metrics', body);
} else {
fetch('/api/rum-metrics', { body, method: 'POST', keepalive: true });
}
}
export function registerWebVitals() {
onCLS(sendToAnalytics);
onLCP(sendToAnalytics);
onINP(sendToAnalytics);
}Dacă încă te bazezi pe scorul Lighthouse rulat pe laptopul tău M-series ca să raportezi performanța către client, te minți singur. În producție, pe telefoane de 800 de lei și rețele 4G gâfâite din provincie, scorurile alea verzi devin roșii instant.
Am pățit-o acum câteva luni pe un magazin online cu ~50k vizitatori unici pe lună. Pe local scoteam 98 pe linie. În Search Console, după două săptămâni de la lansare, Google ne-a trântit un avertisment galben pe INP (Interaction to Next Paint) și CLS. Acolo am realizat că fără Real User Monitoring (RUM) navighezi cu ochii închiși.
INP a schimbat complet ecuația
De când INP a înlocuit vechiul FID, optimizările superficiale nu mai țin. FID măsura doar prima reacție a browserului la un click, în timp ce INP măsoară cea mai proastă latență pe toată durata sesiunii utilizatorului.
La proiectul menționat, aveam un filtru lateral cu vreo 140 de checkbox-uri într-un React nememorizat corespunzător. Când userul bifa o categorie, thread-ul principal îngheța 380ms pe un ecran mobil mediu. Google vrea sub 200ms. Pe desktopul meu de dev dura 18ms, motiv pentru care nici nu observasem problema până n-au venit datele din teren.
Vercel Speed Insights vs RUM pe infrastructura ta
Prima tentativă a fost să activez Vercel Analytics / Speed Insights. Are două mari avantaje: îl configurezi în 3 minute cu un pachet de npm și interfața e impecabilă pentru management, care vrea să vadă grafice colorate fără să întrebe prea multe.
Dar vine cu un compromis major: costul per volum și granularitatea datelor. Dacă depășești tier-ul inclus (care la proiecte active se evaporă repede), plătești simțitor pentru fiecare mie de puncte de date. În plus, Vercel îți dă agregări frumoase, dar când vrei să vezi exact pe ce element de DOM a făcut userul click când a bubuit INP-ul, ești limitat.
Alternativa pe care am mers până la urmă a fost librăria oficială web-vitals de la Google legată la un endpoint propriu via navigator.sendBeacon. Trimitem metricele brute într-un ClickHouse (sau chiar un PostgreSQL simplu dacă volumul e mic) și le afișăm în Grafana.
Trade-off-uri fără ocolișuri
Soluția custom cu web-vitals e gratis din punct de vedere licențe și ai acces la proprietatea attribution. Asta înseamnă că la INP afli selectorul CSS exact care a blocat interfața, iar la LCP știi dacă a fost de vină imaginea de hero sau un font extern.
Partea nasolă? Mentenanța. Trebuie să deduplici datele, să ignori sesiunile scriptate și să ai grijă să nu-ți transformi endpoint-ul de colectare într-un punct unic de cădere dacă ai un spike de trafic.
Vercel Analytics merită dacă ai echipă mică, zero timp de devops și bugetul nu e o problemă. Dacă vrei însă debug real pe bucățile de cod care distrug scorul SEO, o colectare custom îți arată adevărul gol-goluț.
Voi cum raportați datele din teren către echipa de SEO?