Dimensione CoreDash: Browser

Dimensione: Pagina e Navigazione: URL (u)

La dimensione Browser raggruppa i dati di performance in base alla stringa User Agent inviata dal client. Questo ti permette di analizzare le performance dei Core Web Vitals attraverso la lente dello specifico software che esegue il rendering della tua applicazione (ad esempio, Chrome, Firefox, Safari, Edge, Samsung Internet).

La dimensione Browser isola i vincoli software, le differenze tra i motori di rendering (Blink, Gecko, WebKit) e la compatibilità degli script di terze parti.

RUM vs. CrUX

Comprendere la fonte dei tuoi dati è fondamentale per un'analisi tecnica accurata.

• CrUX (Chrome User Experience Report): Questo dataset raccoglie dati esclusivamente da utenti che hanno fornito il consenso su Chrome (e alcuni derivati di Chromium). Esclude indiscriminatamente il traffico da Firefox (motore Gecko) e Safari (motore WebKit).
• CoreDash RUM: Raccoglie dati da ogni browser che esegue lo snippet JavaScript.

Per molti siti web, i browser non-Chrome rappresentano il 30-50% del traffico. Affidarsi esclusivamente a CrUX crea un punto cieco: stai ottimizzando per il motore V8 di Google trascurando i motori SpiderMonkey (Firefox) e JavaScriptCore (Safari) utilizzati da un segmento massiccio del tuo pubblico.

Diagnostica specifica per metrica

Diversi motori di browser gestiscono le risorse, compilano JavaScript e calcolano la geometria del layout in modo differente. Usa questa dimensione per individuare i problemi specifici di ogni motore.

Interaction to Next Paint (INP)

I problemi di INP sono direttamente correlati all'efficienza del motore JavaScript del browser e alla pianificazione del main-thread.

• Firefox (SpiderMonkey): Firefox gestisce la priorità dei task in modo diverso da Chrome. Un event listener pesante che non crea problemi in Chrome potrebbe causare un ritardo di input evidente in Firefox a causa delle differenze nel modo in cui il main thread effettua lo yield.
• Safari (JavaScriptCore): mostra spesso comportamenti distinti riguardanti la latenza del "tap" su mobile. La logica di hydration che sembra istantanea su Android (Chrome) può innescare ritardi su iOS a causa di modelli di propagazione degli eventi differenti.

Largest Contentful Paint (LCP)

Le discrepanze di LCP segnalano solitamente una mancanza di parità di funzionalità o di supporto per le moderne API di ottimizzazione.

• Negoziazione del formato: Se Chrome riporta un LCP veloce ma Firefox è lento, verifica la tua strategia per i formati immagine. Potresti servire AVIF a Chrome utilizzando un fallback con JPEG più pesanti per le versioni browser più vecchie che non lo supportano.
• Priority Hints: Chrome rispetta rigorosamente fetchpriority="high". I browser che ignorano questo attributo trattano la risorsa LCP con priorità standard, gonfiando artificialmente il Load Delay.
• Protocolli di connessione: Edge e Firefox possono negoziare le connessioni HTTP/3 (QUIC) in modo diverso in ambienti di rete aziendali o limitati, impattando sulla componente TTFB di LCP.

Cumulative Layout Shift (CLS)

I motori di rendering calcolano la geometria dei pixel utilizzando diverse logiche di sub-pixel.

• Rendering dei font (Gecko vs. Blink): Firefox (Gecko) e Chrome (Blink) renderizzano le baseline e la crenatura dei font in modo leggermente diverso. Se non fai corrispondere perfettamente le metriche del font di fallback, il blocco di testo si ridimensionerà al caricamento del web font, causando uno shift in un browser ma non nell'altro.
• Riserva della barra di scorrimento: I browser Windows (Edge/Firefox/Chrome) riservano spazio fisico per le barre di scorrimento, mentre i browser macOS le sovrappongono. Questa disparità causa spesso layout shift basati sulla larghezza che sono invisibili durante lo sviluppo su un Mac ma evidenti per gli utenti Windows.

Workflow: Isolare le regressioni specifiche del motore

Il caso d'uso principale per questa dimensione è la "Validazione del Motore".

• Identifica l'anomalia: Ordina la tua tabella Browser per Impatto o Volume. Cerca un browser specifico (es. Firefox Mobile) che abbia un punteggio significativamente peggiore rispetto al baseline (Chrome Mobile).
• Verifica l'ambiente: Controlla se il problema è strettamente correlato al browser o a una combinazione di browser e sistema operativo (es. Edge su Android vs. Edge su Windows).
• Debug: Se Edge è lento ma Chrome è veloce (entrambi usano Blink), indaga su estensioni di terze parti o software di sicurezza aziendale comuni tra gli utenti Edge che iniettano script nel DOM. Se Firefox è lento, analizza il tuo CSS alla ricerca di proprietà non standard o layout thrashing che Gecko penalizza più pesantemente rispetto a Blink.

Browser Legacy ed Embedded

Usa la dimensione Browser per identificare i cali di performance della "Long Tail".

Browser In-App: Il traffico da Instagram, LinkedIn o Facebook spesso avviene in WebView limitate che si comportano diversamente dal browser mobile nativo.

Versioni Legacy: Potresti riscontrare traffico da versioni di browser datate. Se queste generano un INP elevato, configura i tuoi strumenti di build (Babel/PostCSS) per servire i polyfill necessari oppure, se il volume è trascurabile, prendi la decisione strategica di interrompere il supporto per ridurre la dimensione del bundle per gli utenti moderni.