Chrome su Android scattava, Google ha risolto il problema. 3 anni dopo

Scorrere una pagina web su Android e sentire quella fastidiosa saccade improvvisa, quel micro-salto che interrompe la fluidità: si chiama scroll jank, ed è uno dei problemi più odiosi dell’esperienza mobile. Google ha appena pubblicato un resoconto dettagliato di come, tra il 2023 e il 2026, sia riuscita a ridurre del 48% la frequenza di questi scatti su Chrome per Android. Non è un aggiornamento singolo, ma il risultato di tre anni di lavoro ingegneristico su più fronti.

Vale la pena capire cosa hanno fatto, perché il problema era più complicato di quanto sembri e le soluzioni adottate sono tutt’altro che banali.

Vuoi ascoltare il riassunto dell’articolo?

Un’app Android tradizionale riceve gli eventi di input (il dito sullo schermo) e il segnale VSync (il metronomo del display, una volta ogni 16,7 millisecondi su un pannello a 60 Hz) sullo stesso thread, e produce un frame. Semplice, lineare, prevedibile. Chrome invece ha tre processi separati: browser, renderer e GPU.

Quando tocchiamo lo schermo, l’evento di input passa prima dal processo browser per l’hit testing, poi al renderer per calcolare il nuovo offset di scorrimento, mentre il VSync segue un percorso completamente diverso. Il risultato è una pipeline con decine di punti in cui un ritardo di pochi microsecondi può propagarsi a cascata e far perdere un frame intero.

A complicare ulteriormente le cose, Chrome consuma gli input direttamente dall’hardware senza buffer, il che significa che gli eventi arrivano a intervalli irregolari, spesso più volte per ogni ciclo di refresh. La velocità grezza non basta: serve coerenza assoluta nella consegna di ogni frame.

Il team ha prima strumentato ogni fase della pipeline con eventi di traccia Perfetto, poi ha costruito una libreria di query SQL per analizzare automaticamente migliaia di tracce e taggare i frame problematici con le cause probabili. Senza questa automazione, trovare pattern sarebbe stato impossibile.

Una volta identificati i colli di bottiglia, hanno iterato con esperimenti A/B fino al lancio definitivo.

I progetti che hanno contribuito di più alla riduzione del 48% sono stati:

• Input Vizard: in collaborazione con Android, Chrome ora riceve gli input sul thread compositor Viz nel processo GPU, invece che sul browser main thread (uno dei thread più occupati). Questo avvicina Chrome al modello a thread singolo delle app tradizionali.
• Input Framer: quando un evento di input arriva in ritardo rispetto al segnale VSync, il renderer ora aspetta fino a un terzo del ciclo di refresh prima di produrre un frame vuoto, riducendo i frame inutili.
• Input prediction: se l’OS non consegna alcun input entro la scadenza, Chrome genera un aggiornamento sintetico basato sulla curva di scorrimento osservata, evitando jank da ritardi di consegna.
• Direct2Thread: la comunicazione tra processi passava storicamente per thread IO intermedi, con fino a tre salti di thread invece di uno. Rimosso questo requisito sul percorso critico dello scroll.
• Browser controls in Viz: la barra degli indirizzi che scivola via quando scorriamo verso il basso coinvolgeva il browser main thread a ogni singolo frame. Ora è il processo GPU a gestire direttamente l’offset, senza passare dal main thread.
• Priorità dei thread Android: i thread OS responsabili della consegna degli input hardware a Chrome avevano priorità troppo bassa e venivano preemptati da altri processi. Google ha lavorato con Android per alzarla.

Vale la pena notare che la maggior parte degli interventi riguarda il lato input, non il rendering.

La logica è semplice: Chrome non può iniziare a preparare un frame se non sa ancora quale offset applicare.

Il risultato è visibile, e il post ufficiale del team Chromium promette che il lavoro continuerà. Per chi usa Chrome su Android, questi miglioramenti sono già attivi, anche se difficilmente li noterete in modo consapevole: la fluidità è una di quelle cose che si percepisce solo quando manca.