Data di pubblicazione: 4 aprile 2025
Risolvere i problemi di prestazioni nel mondo reale significa colmare il divario tra il tuo ambiente di sviluppo e le diverse esperienze di prestazioni dei tuoi utenti. In questo post esamineremo le nuove funzionalità di DevTools di Chrome che ti aiutano a basare maggiormente le tue decisioni di debug delle prestazioni su dati reali anziché su supposizioni.
Calibrare le aspettative
A partire da Chrome 134, DevTools include la calibrazione del throttling della CPU, un nuovo strumento per rimuovere l'incertezza legata alla scelta del livello di throttling della CPU corretto. Esegui la calibrazione una volta e DevTools genererà le preimpostazioni di limitazione "Dispositivo mobile di livello basso" e "Dispositivo mobile di livello intermedio" specifiche per la tua macchina di sviluppo.
Un problema comune nel lavoro sul rendimento del web è che, in qualità di sviluppatori, spesso creiamo siti su computer desktop veloci, mentre molti dei nostri utenti utilizzano dispositivi mobili meno potenti. Individuare un problema di prestazioni può essere complicato se si verifica solo su un dispositivo con una CPU molto più lenta.
Lo standard di riferimento è il debug remoto su un dispositivo mobile reale, ma da quasi un decennio Chrome supporta anche il throttling della CPU per cicli di iterazione rapidi e leggeri durante lo sviluppo.
Ma quale livello di throttling della CPU dovresti scegliere? 4 volte? 20x? Come fai a sapere quale corrisponde meglio al tipo di dispositivi che visitano il tuo sito? E in che modo la velocità del tuo computer cambia questa decisione, che tu stia utilizzando una workstation di fascia alta o un Chromebook di 8 anni in viaggio?
La procedura di calibrazione della limitazione
Quando viene aperto il riquadro Rendimento, le impostazioni dell'ambiente includono un menu a discesa per impostare il livello di throttling della CPU. Se non hai mai eseguito la calibrazione, vedrai due opzioni disattivate in "Preimpostazioni calibrate" nel menu a discesa e un'opzione Calibra… in fondo.
Se selezioni questa opzione, verranno visualizzate le preimpostazioni di throttling della CPU in Impostazioni (puoi anche accedervi direttamente).
- Fai clic sul pulsante Calibra.
- Fai clic su Continua quando viene visualizzato l'avviso che ti informa che uscirai brevemente dalla pagina corrente
- Verrà eseguito un rapido benchmark per misurare la velocità della tua attuale macchina e la calibrazione sarà completata
Le opzioni di limitazione verranno ora compilate con le preimpostazioni calibrate per i dispositivi di livello basso e medio.
Questi due preset dovrebbero essere sufficienti per la maggior parte dei casi d'uso di sviluppo e, in genere, consigliamo il preset "di fascia media" in quanto corrisponde a un dispositivo mobile "tipico" visualizzato sul web. Se sai che molti dei tuoi utenti hanno dispositivi ancora più lenti o che un problema di prestazioni si verifica in genere solo per questi utenti, l'opzione "livello basso" dovrebbe essere abbastanza lenta da acquisire anche la coda lunga dei dispositivi di fascia bassa.
Infine, se ritieni che si sia verificato un problema con la calibrazione o che il tuo computer locale sia cambiato in qualche modo, puoi sempre eseguire nuovamente la calibrazione tramite il menu a discesa di throttling o nelle impostazioni, in modo da eseguire nuovamente il benchmark e aggiornare le preimpostazioni.
Come funziona il throttling della CPU in DevTools
Se ti è mai capitato di chiederti come funziona il throttling della CPU in DevTools, la risposta è relativamente semplice. Quando attivi la limitazione per una scheda, Chrome avvia un thread di limitazione separato che interrompe e sospende il thread principale della scheda per brevi picchi frequenti. L'obiettivo è sospendere il thread principale per un tempo sufficientemente lungo in modo che la durata di una determinata attività aumenti in base al fattore di throttling.
Ad esempio, con una limitazione della CPU pari a 4 volte, il thread principale verrà sospeso per circa il 75% del tempo, il che rende il completamento di qualsiasi operazione del thread principale quattro volte più lungo.
Il vantaggio di questo approccio è che è per lo più trasparente per il resto di Chrome; non è necessario alcun codice specializzato per rallentare JavaScript, il layout o ciascuno dei molti altri tipi di attività che un browser deve svolgere. Tutte le attività sul thread principale richiedono più tempo perché il thread stesso può essere eseguito solo per una frazione di tempo.
Quando la limitazione della CPU si comporta come un vero dispositivo mobile
Di conseguenza, molti tipi di attività legate alla CPU mobile vengono simulate bene dal throttling della CPU. Ad esempio, se un'interazione attiva JavaScript e il layout, è molto probabile che venga eseguita in modo molto simile a come sarebbe stata eseguita su un dispositivo mobile.
Prendi in considerazione un'attività attivata dal clic su un pulsante, che esegue JavaScript per aggiungere nuovi elementi al DOM, il che richiede al browser di eseguire calcoli di stile e layout per posizionare i nuovi contenuti:
Con il preset di throttling della CPU "dispositivo mobile di fascia media" calibrato (3,7 volte su questa macchina di sviluppo), l'interazione sembra molto simile, ma la durata aumenta in modo significativo, diventando un'attività lunga:
Il test della stessa interazione su un dispositivo di livello intermedio reale utilizzando il debug remoto produce un risultato notevolmente simile, sia nella forma che nella durata della traccia dell'interazione. Poiché questa attività è in gran parte legata alla CPU nel thread principale (esegue il codice JavaScript della pagina e il codice di stile e layout di Chrome), la limitazione calibrata ricrea con precisione le prestazioni reali dei dispositivi mobili:
Quando potresti comunque voler eseguire il test su un dispositivo mobile reale
Sebbene molto utile, il throttling della CPU non può simulare tutti gli aspetti dell'hardware mobile. Su uno smartphone, la velocità del disco è inferiore, la larghezza di banda della memoria è più limitata e il throttling termico può attivarsi in qualsiasi momento per ridurre la velocità di esecuzione.
Una limitazione comune del throttling riguarda il lavoro che richiede un'intensa attività della GPU. Le GPU mobile e desktop sono diverse dal punto di vista dell'architettura e Chrome esegue le operazioni della GPU in un processo separato dal thread principale della pagina. Di conseguenza, il throttling della CPU di DevTools non influisce sul processo GPU (il che è un bene, perché influirebbe sulla reattività di DevTools stesso e del resto del browser).
La pittura, il compositing e gli stili con molti effetti complicati sono problemi di prestazioni comuni che possono sembrare accettabili su una macchina di sviluppo, ma inaspettatamente lenti sui dispositivi mobili. Inoltre, può essere complicato capire se esiste un problema quando si tenta di ricrearlo sulla macchina di sviluppo.
Considera la stessa interazione di prima (fai clic e aggiungi molti elementi al DOM), solo che questa volta i nuovi elementi sono stilizzati con un numero eccessivo di ombreggi e filtri di sfocatura che richiedono molta GPU.
La forma iniziale e la durata dell'interazione sono simili, ma alla fine è presente un nuovo lungo tratto di pittura nel thread principale per gli effetti aggiunti:
Su uno smartphone di fascia media reale, la parte del thread principale dell'interazione è molto simile a quella simulata, inclusa la pittura extra, ma un processo GPU apparentemente esegue un'enorme quantità di lavoro prima che il risultato dell'interazione possa essere visualizzato sullo schermo:
Il lavoro della GPU prolunga l'interazione di altri 300 millisecondi ed è un lavoro che non esiste quasi per la GPU del laptop, anche con il throttling della CPU (thread principale) abilitato.
Esistono anche altri casi che presentano svantaggi significativi dell'emulazione, come i caricamenti di pagine con dipendenze profonde, in cui è presente un'interazione tra il throttling della rete simulato, le comunicazioni interprocessuali e l'accesso alle cache di disco e memoria.
Assicurati sempre di eseguire il test su dispositivi mobili reali. Inoltre, se non riesci a ricreare in laboratorio un problema sul tuo computer che i dati sul campo indicano essere presente per gli utenti di dispositivi mobili, prova a eseguire il debug remoto con un dispositivo reale per verificare se manca una differenza.
Ulteriori miglioramenti al debug basato sui dati
Di recente sono state introdotte altre nuove funzionalità per semplificare la definizione delle impostazioni e delle decisioni di debug in base ai tuoi utenti reali.
Se hai attivato i dati sul campo, il riquadro Rendimento fornirà suggerimenti sul throttling in base agli utenti del 75° percentile misurati dal Report sull'esperienza utente di Chrome (CrUX) e la visualizzazione delle metriche in tempo reale ti avviserà se le metriche misurate localmente differiscono dai dati sul campo. Questo argomento è stato trattato in dettaglio in un post precedente sull'importazione di dati di Core Web Vitals reali in DevTools.
Una novità è che ora gli approfondimenti del riquadro Rendimento nella barra laterale ti avvisano anche se le metriche misurate in una traccia non corrispondono a quelle che gli utenti stanno riscontrando nella realtà.
Se attivi i dati sul campo, potrai anche utilizzare il 75° percentile di Core Web Vitals per stabilire l'ordine in cui vengono visualizzati gli approfondimenti nella barra laterale. Ad esempio, se in genere i tuoi utenti hanno un ottimo Largest Contentful Paint (LCP), ma un pessimo Interaction to Next Paint (INP), i suggerimenti utili per migliorare l'INP tenderanno a trovarsi in cima all'elenco.
Infine, se hai mai passato da una traccia all'altra o caricato tracce dal disco, può essere difficile ricordare esattamente quali impostazioni di emulazione e throttling mobile hai utilizzato in ogni traccia. Il menu a discesa per la selezione della traccia nella parte superiore del riquadro Rendimento ora mostra le informazioni di emulazione per ogni traccia.
Interrompi, calibra e ascolta
In definitiva, dobbiamo basare le nostre decisioni di debug sul mondo reale: iniziando con i dati sul campo provenienti da report di analisi e utenti per trovare i problemi, poi ricreando queste esperienze utente in laboratorio per la diagnosi. Queste nuove aggiunte a DevTools dovrebbero contribuire a semplificare un po' la procedura.
La calibrazione del throttling della CPU e gli avvisi sulle esperienze di campo e di laboratorio divergenti contribuiscono a ridurre l'incertezza sul fatto che tu stia o meno seguendo la strada giusta e consentono un'approssimazione più coerente del rendimento reale. Eliminando le supposizioni dalla configurazione ed evidenziando potenziali discrepanze, DevTools ha lo scopo di aiutarti a dedicare più tempo alla risoluzione dei problemi di prestazioni effettivi che interessano i tuoi utenti.
Hai idee per ulteriori miglioramenti o suggerimenti per nuove funzionalità? Facci sapere.