Chrome per Android è diventato molto più fluido negli ultimi anni, e i numeri lo dimostrano. Google ha spiegato nel dettaglio come sia riuscita a ridurre del 48% lo scroll jank tra il 2023 e il 2026, quel fastidioso effetto per cui la pagina sembra saltare o incepparsi mentre si scorre col dito. Un problema piccolo in apparenza, ma che rovina l’esperienza di navigazione più di quanto si pensi.
Il termine scroll jank indica proprio questi micro scatti improvvisi. Tecnicamente succede quando il dispositivo non riesce a mostrare in tempo un fotogramma con la nuova posizione di scorrimento. Google ha definito questo fenomeno uno dei principali nemici di una buona esperienza web da mobile, e ha cominciato a lavorarci seriamente proprio nel 2023.
Perché Chrome soffre più di altre app
Chrome deve consegnare ogni fotogramma prima che lo schermo si aggiorni, con una scadenza rigidissima. Se un ritardo spinge l’elaborazione oltre quel limite, lo schermo resta bloccato su una posizione di scorrimento vecchia per un intero ciclo di aggiornamento, circa 16,7 millisecondi su un display a 60 Hz. E l’occhio umano percepisce quel fotogramma saltato come uno scatto brusco, quasi a strappi.
Il punto è che Chrome non funziona come una normale app Android. Ha processi separati per browser, renderer e GPU. Questa architettura migliora stabilità, sicurezza e prestazioni, ma allo stesso tempo peggiora il problema dello scroll jank. Quando il dito tocca lo schermo, l’hardware genera un evento che non finisce in un unico thread. Prima arriva al processo browser per il cosiddetto hit testing, poi viene passato al renderer per calcolare la nuova posizione. I segnali VSync seguono un percorso ancora diverso, attraversando anch’essi più processi. Il risultato è una catena complicata, con tanti punti in cui qualcosa può andare storto. In più Chrome legge l’input direttamente dall’hardware, quindi gli eventi arrivano a intervalli irregolari, spesso più volte per ciclo.
Le mosse tecniche di Google
Per districare questa pipeline multiprocesso, l’azienda ha avviato diversi progetti che vanno dalle euristiche automatiche fino a veri cambiamenti architetturali. Il primo è la previsione dell’input. Quando un evento arriva così in ritardo che nemmeno il periodo di tolleranza basta, Chrome crea da solo un aggiornamento sintetico dello scorrimento e prevede la posizione futura basandosi sulla curva osservata fino a quel momento. Allungare ancora il margine di tolleranza non era un’opzione, perché avrebbe aumentato il rischio di non riuscire a produrre il fotogramma in tempo.
C’è poi il lavoro sui controlli del browser gestiti in Viz. Quando si scorre verso il basso su un sito da Android, la barra dei controlli scivola fuori dallo schermo insieme alla pagina. Prima questo movimento sincronizzato coinvolgeva il thread principale del browser a ogni singolo fotogramma, creando parecchie occasioni per gli scatti visivi. Con la nuova architettura il processo GPU applica la posizione di scorrimento direttamente allo screenshot dei controlli, senza dover parlare con il thread principale.
Infine c’è la questione della priorità dei thread di input Android. Una catena vale quanto il suo anello più debole, e a volte gli eventi impiegavano troppo tempo ad arrivare a Chrome perché i thread del sistema operativo venivano scavalcati da lavori a priorità più bassa. Google ha collaborato con Android per assicurarsi che tutti i thread incaricati di consegnare l’input hardware avessero una priorità abbastanza alta da non finire in fondo alla lista.