RUM in casa, senza servizi: cosa serve davvero

Un RUM in casa si costruisce con due API del browser, PerformanceObserver e navigator.sendBeacon, e un endpoint che riceve JSON. Il costo di rete non è il problema: un campione pesa 239 byte e venti campioni in un lotto compresso stanno in 273 byte.

Cosa raccogliere, e quando

Il collector minimo

const q = [];
const push = (kind, value) => q.push({ kind, value, path: location.pathname });
new PerformanceObserver((l) => {
  for (const e of l.getEntries()) push("lcp", Math.round(e.startTime));
}).observe({ type: "largest-contentful-paint", buffered: true });
new PerformanceObserver((l) => {
  for (const e of l.getEntries()) if (!e.hadRecentInput) push("cls", +e.value.toFixed(4));
}).observe({ type: "layout-shift", buffered: true });
addEventListener("pagehide", () => {
  const nav = performance.getEntriesByType("navigation")[0];
  push("ttfb", Math.round(nav.responseStart));
  navigator.sendBeacon("/rum", new Blob([JSON.stringify(q)], { type: "application/json" }));
});

Il codice richiede un endpoint /rum che accetti POST JSON e un browser con sendBeacon. Il vantaggio di sendBeacon è che la richiesta sopravvive alla chiusura della pagina, dove fetch verrebbe annullata. L'evento pagehide copre anche il passaggio in bfcache, dove unload non arriva.

Quanto pesa davvero

node -e "const z=require('zlib');const b=JSON.stringify(Array.from({length:20},(_,i)=>({kind:'lcp',value:1200+i*20})));console.log(Buffer.byteLength(b),z.gzipSync(b).length)"

Il comando richiede Node e nessuna dipendenza. Su un lotto reale i valori cambiano con il numero di campioni, ma l'ordine di grandezza resta: pochi kilobyte per visita, ridotti a poche centinaia di byte quando il server comprime la richiesta. Se il tuo endpoint non comprime, aggiungi Content-Encoding: gzip e accetta il corpo compresso: il risparmio è di un fattore 17.

Dal campione al numero pubblicabile

Un RUM che pubblica la media mente: la media nasconde la coda lenta. Si ordina il campione per metrica e si prende il valore al 75° percentile, che è il numero usato da CrUX e da Search Console. Con venti campioni il 75° percentile è il quindicesimo valore in ordine crescente, un dato troppo rumoroso per una decisione: serve un volume di visite sufficiente, altrimenti si legge il dato come indicazione e non come verdetto.

Il limite da dichiarare

Chi blocca gli script non invia nulla, quindi il campione è distorto verso chi ha un browser pulito e una connessione decente. Le metriche perse per crash o chiusura brusca non arrivano. E un beacon che contiene il path è un dato personale: serve una base giuridica, la minimizzazione dei campi e una retention breve, non un foglio di calcolo eterno.

Dove continuare

Il catalogo EneUI indicizza 111.985 componenti, il blocco banner 01 e l'icona chart bar, quella che finisce nel pannello. Per la meccanica degli osservatori leggi PerformanceObserver in pratica, per il confronto tra laboratorio e campo misurare l'LCP, per le soglie cosa sono i Core Web Vitals, e per il confronto tra architetture framework frontend a confronto.