Dimensione Core/Dash: Browser

Dimensione: Browser (browser)

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

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

RUM vs. CrUX

Comprendere l'origine dei tuoi dati è importante per un'analisi ingegneristica accurata.

• CrUX (Chrome User Experience Report): Questo set di dati raccoglie dati esclusivamente dagli utenti opt-in su Chrome (e alcuni derivati di Chromium). Esclude ciecamente il traffico da Firefox (motore Gecko) e Safari (motore WebKit).
• CoreDash RUM: Raccoglie i 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 mentre trascuri i motori SpiderMonkey (Firefox) e JavaScriptCore (Safari) utilizzati da un enorme segmento del tuo pubblico.

Diagnostica specifica per metrica

Diversi motori dei browser gestiscono le risorse, compilano JavaScript e calcolano la geometria del layout in modo diverso. Usa questa dimensione per individuare gli errori specifici del 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 prioritizzazione delle attività in modo diverso rispetto a Chrome. Un listener di eventi pesante che passa in Chrome potrebbe causare un ritardo di input evidente in Firefox a causa delle differenze nel modo in cui il main thread cede il controllo (yielding).
• Safari (JavaScriptCore): esibisce spesso comportamenti distinti per quanto riguarda la latenza di "tap" su mobile. La logica di idratazione che sembra istantanea su Android (Chrome) potrebbe innescare ritardi su iOS a causa di modelli di propagazione degli eventi distinti.

Largest Contentful Paint (LCP)

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

• Negoziazione del formato: Se Chrome riporta un LCP veloce ma Firefox arranca, verifica la tua strategia per i formati delle immagini. Potresti servire AVIF a Chrome ricadendo (fallback) su JPEG più pesanti per le versioni precedenti dei browser che non hanno supporto.
• Priority Hints: Chrome rispetta aggressivamente fetchpriority="high". I browser che ignorano questo attributo trattano la risorsa dell'LCP con priorità standard, gonfiando artificialmente il Load Delay.
• Protocolli di connessione: Edge e Firefox potrebbero negoziare le connessioni HTTP/3 (QUIC) in modo diverso negli ambienti di rete aziendali o limitati, impattando la componente TTFB dell'LCP.

Cumulative Layout Shift (CLS)

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

• Rendering dei font (Gecko vs. Blink): Firefox (Gecko) e Chrome (Blink) renderizzano le linee di base e il tracking dei font in modo leggermente diverso. Se non fai combaciare 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.
• Prenotazione della barra di scorrimento: I browser su Windows (Edge/Firefox/Chrome) riservano spazio fisico per le barre di scorrimento, mentre i browser su macOS le sovrappongono. Questa disparità causa spesso layout shift basati sulla larghezza che sono invisibili durante lo sviluppo su Mac ma prominenti per gli utenti Windows.

Flusso di lavoro: Isolare le regressioni specifiche del motore

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

• Identifica il valore anomalo (Outlier): Ordina la tabella Browser per Impatto o Volume. Cerca un browser specifico (ad es. Firefox Mobile) che ha un punteggio significativamente peggiore rispetto alla linea di base (Chrome Mobile).
• Verifica l'ambiente: Controlla se il problema è strettamente correlato 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), investiga su estensioni di terze parti o software di sicurezza aziendale comuni tra gli utenti Edge che iniettano script nel DOM.Se Firefox è lento, revisiona il tuo CSS per proprietà non standard o layout thrashing che Gecko penalizza più pesantemente rispetto a Blink.

Browser legacy e integrati (Embedded)

Usa la dimensione Browser per identificare i cali di performance della "Coda lunga".

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

Versioni legacy: Potresti trovare traffico da versioni di browser obsolete. Se queste generano 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 abbandonare il supporto per ridurre le dimensioni del bundle per gli utenti moderni.