Core/Dash Dimension: Browser

Dimensione: Browser (browser)

La dimensione Browser raggruppa i dati sulle prestazioni in base alla stringa User Agent inviata dal client. Questo ti consente di verificare le prestazioni Core Web Vitals attraverso la lente del software specifico che renderizza la tua applicazione (ad es. Chrome, Firefox, Safari, Edge, Samsung Internet).

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

RUM vs. CrUX

Comprendere la fonte dei tuoi dati è importante per un'analisi ingegneristica accurata.

• CrUX (Chrome User Experience Report): Questo dataset raccoglie dati esclusivamente dagli utenti che hanno aderito su Chrome (e alcuni derivati Chromium). Esclude completamente 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 una parte massiccia del tuo pubblico.

Diagnostica specifica per metrica

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

Interaction to Next Paint (INP)

I problemi di INP sono direttamente correlati all'efficienza del motore JavaScript del browser e alla schedulazione del thread principale.

• Firefox (SpiderMonkey): Firefox gestisce la prioritizzazione delle attività in modo diverso da Chrome. Un event listener pesante che funziona bene in Chrome potrebbe causare un ritardo di input evidente in Firefox a causa delle differenze nel modo in cui il thread principale esegue il yield.
• Safari (JavaScriptCore): spesso presenta comportamenti distinti riguardo alla latenza del "tap" su mobile. La logica di hydration che sembra istantanea su Android (Chrome) può causare ritardi su iOS a causa di modelli di propagazione degli eventi distinti.

Largest Contentful Paint (LCP)

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

• Negoziazione del formato: Se Chrome riporta un LCP veloce ma Firefox è in ritardo, verifica la tua strategia dei formati immagine. Potresti servire AVIF a Chrome mentre usi un fallback con JPEG più grandi per versioni di browser più vecchie che non supportano il formato.
• Priority Hints: Chrome rispetta aggressivamente 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 aziendali o di rete limitati, impattando la componente TTFB di LCP.

Cumulative Layout Shift (CLS)

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

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

Flusso di lavoro: Isolare le regressioni specifiche del motore

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

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

Browser legacy e integrati

Usa la dimensione Browser per identificare i rallentamenti della "coda lunga" delle prestazioni.

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

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