Test Frame Rate

Un test del frame rate misura quante immagini un dispositivo consegna ogni secondo e quanto uniformemente arrivano. Questo test campiona il timestamp che il browser associa a ogni frame di animazione e converte l'intervallo tra frame consecutivi in un frame rate espresso in FPS. Da quei campioni riporta sei valori: il contatore live, la media, il minimo, l'1% Low, la deviazione standard degli intervalli tra frame e un conteggio degli stutter. La media descrive la capacità di elaborazione, mentre gli altri cinque descrivono la costanza, ed è per questo che vengono riportati separatamente. Un solo numero medio non può dirti se una sessione è stata fluida o piena di intoppi.

Assicurati che questa scheda sia la finestra attiva, perché i browser limitano i frame di animazione nelle schede in background e la lettura crollerebbe a un valore irrisorio. Chiudi le applicazioni pesanti, clicca Avvia Test e lascia il contatore attivo per almeno dieci secondi: a quel punto la sessione si completa da sola e il pannello diagnostico la valuta. Guarda prima stabilizzarsi la media, poi confrontala con l'1% Low subito sotto, e leggi per ultimi il jitter dei tempi di frame e il conteggio degli stutter. Per un confronto equo, esegui il test tre volte in condizioni identiche e confronta la dispersione invece di fidarti di una sola lettura, perché una singola sessione viene facilmente alterata da un aggiornamento in background.

L'1% Low prende l'uno percento di frame più lenti di una sessione, ne fa la media dei tempi di frame e la riconverte in un frame rate. Risponde alla domanda a cui la media non può rispondere: quanto sono brutti i momenti brutti? Se la media è 120 FPS ma l'1% Low è 45 FPS, allora circa un frame su cento impiega più del triplo del tempo che dovrebbe, e sono proprio quegli stalli che i giocatori percepiscono come scatti e input persi. Come regola pratica, un sistema sano mantiene l'1% Low entro circa il 10-20 percento della sua media, e un divario più ampio indica un problema di pacing dei frame, non di velocità pura.

Per lavoro da scrivania, video e navigazione, 60 FPS sono comodamente fluidi perché corrispondono alla frequenza di aggiornamento della maggior parte dei display. Nel gaming, 60 FPS sono giocabili, 120 FPS migliorano nettamente la nitidezza del movimento e la risposta agli input, e 240 FPS avvantaggiano soprattutto i giocatori competitivi con un pannello ad alta frequenza corrispondente. Oltre la frequenza del pannello i frame in più vengono in gran parte scartati, quindi 90 FPS su uno schermo a 60Hz aggiungono fluidità soprattutto riducendo il tearing, non mostrando frame visibili in più. La costanza conta più del picco, e 60 bloccati con un 1% Low di 55 si sentono meglio di una media di 90 con un 1% Low di 30.

Gli stutter derivano quasi sempre da tempi di frame irregolari, non da una media insufficiente. La causa più comune è il carico in background: un secondo monitor con video, una scheda che decodifica una pagina pesante, un client di sincronizzazione cloud o un aggiornamento di sistema rubano tempo di CPU e GPU a ondate. La seconda è la gestione termica o energetica: i portatili a batteria e gli chassis sottili riducono le frequenze sotto carico, ed è per questo che una sessione spesso parte veloce e peggiora entro un minuto. La terza è un limite di frame rate con una frequenza di aggiornamento non corrispondente: VSync e un limite di 60 FPS su un pannello a 60Hz si ostacolano e producono judder visibile.

È accurato per ciò che misura, cioè il frame rate che la pipeline di rendering del browser consegna davvero allo schermo, ed è lo strumento corretto per un'applicazione web, un gioco nel browser o una scena canvas e WebGL. Ogni frame riceve il timestamp dal browser stesso, quindi gli intervalli sono reali e non stimati. I limiti riguardano la portata, non la precisione: il browser non può leggere il contatore FPS interno di un gioco nativo in un'altra finestra, non può riportare l'utilizzo della GPU o la frequenza di clock e non può misurare la latenza click-to-photon. Non può nemmeno essere un benchmark bare-metal, perché il sistema operativo e il browser aggiungono entrambi un proprio carico.

Misurano due cose diverse che è facile confondere. Un test della frequenza di aggiornamento misura il tetto del pannello: quante volte al secondo il display può ridisegnarsi fisicamente, in genere 60, 120, 144 o 240 volte, e controlla anche ghosting e salti di frame. Un test del frame rate misura ciò che viene effettivamente consegnato dentro quel tetto. La relazione conta: se il tuo pannello è a 144Hz ma il frame rate consegnato è 60, il display non è affatto il collo di bottiglia e sostituirlo non cambierebbe nulla. Esegui il test della frequenza di aggiornamento per stabilire il tetto, poi il test del frame rate per vedere quanto di quel tetto stai davvero usando.

Affronta le cause in ordine di probabilità. Primo, chiudi le altre schede, le videochiamate e i launcher, poi ripeti il test per capire quanta parte del calo fosse carico in background. Secondo, controlla l'utilizzo di CPU e GPU durante la sessione, perché un singolo core saturo o una coda grafica intasata spiegano di norma un 1% Low basso. Terzo, passa il profilo di alimentazione del sistema operativo da risparmio energetico a bilanciato o prestazioni elevate, cosa che conta soprattutto sui portatili a batteria. Quarto, aggiorna il driver grafico e verifica che un portatile con grafica ibrida stia usando la GPU dedicata. Infine, riduci il carico di rendering della pagina che stai misurando.

Puoi testare qualsiasi gioco che gira dentro la scheda del browser, compresi i titoli HTML5, canvas, WebGL e WebGPU, perché vengono disegnati attraverso la stessa pipeline di frame di animazione che questo test campiona. Non puoi testare un gioco nativo in esecuzione in un'altra finestra o in modalità fullscreen esclusiva, perché una pagina web non ha accesso all'interno di un'altra applicazione. Per i giochi nativi usa l'overlay FPS integrato del gioco o del driver grafico, per esempio l'overlay prestazioni di NVIDIA GeForce Experience o di AMD Adrenalin. Usa questo test per i giochi nel browser e le applicazioni web, e quegli overlay quando ti serve la telemetria in-game.

Il tempo di frame è quanto tempo impiega un singolo frame, misurato in millisecondi, mentre gli FPS contano quanti frame entrano in un secondo. I due valori sono inversi dal punto di vista matematico: 60 FPS equivalgono a 16.7 ms per frame, 120 FPS a 8.3 ms e 144 FPS a 6.9 ms. Il tempo di frame è il dato più rivelatore quando cerchi stutter, perché descrive ogni frame singolarmente invece di fare la media di un intero secondo di frame. Una sessione con una media di 60 FPS può contenere comunque singoli frame da 40 ms o peggio, ed esattamente quei frame lunghi sono ciò che l'occhio legge come un intoppo. Questo test riporta direttamente il tempo di frame, così gli outlier che un contatore semplice nasconderebbe diventano visibili.

Una media alta con tempi di frame instabili si sente peggio di una più bassa ma costante, perché l'occhio è molto più sensibile ai cambi di pacing che alla velocità assoluta. Se una sessione ha una media di 144 FPS ma ogni decimo frame impiega 30 ms, il movimento presenterà visibilmente dei jerk nonostante la media sana. Le cause tipiche sono un singolo thread della CPU saturo, uno stallo della compilazione degli shader, un intoppo nello streaming delle texture o un processo in background in gara per la GPU. Il controllo pratico è guardare l'1% low e il conteggio degli stutter invece della media: un 1% low entro il 10-20 percento della media significa pacing sane, un divario maggiore indica un collo di bottiglia fatto di picchi, non di prestazioni grezze.

Un limite di frame rate limita quanti frame l'applicazione può produrre, di solito per mantenere l'uscita allineata con il display. Limitare leggermente sotto la frequenza di aggiornamento del pannello, per esempio 141 FPS su uno schermo a 144Hz con VSync attivo, è il metodo standard per ridurre la latenza di input evitando il tearing. Su un display a frequenza variabile come G-Sync o FreeSync, un limite sotto la massima frequenza mantiene il pannello dentro il suo intervallo variabile ed evita che ricada in un comportamento con frequenza fissa. Un limite diventa dannoso solo quando viene impostato sotto ciò che il sistema potrebbe altrimenti erogare senza una valida ragione, perché in quel caso lascia inutilizzata una parte reale delle prestazioni.