Dile adiós a Google Chrome lento: ahora la navegación en páginas web es mucho más rápida y fluida

Google ha resuelto uno de los problemas más frecuentes de la navegación en celulares: estás leyendo un artículo en el teléfono y la página de repente se congela o da saltos.

El fenómeno tiene nombre técnico scroll jank o desplazamientos bruscos y el equipo de Chrome para Android logró reducir su frecuencia en un 48% entre 2023 y 2026, según Petr Čermák, ingeniero de software del equipo de Chrome, en el blog oficial de Chromium.

El resultado se suma a otro hito reciente: Android se convirtió en la plataforma móvil más rápida para navegar por la web.

El scroll jank ocurre cuando el dispositivo no logra mostrar a tiempo un fotograma con el desplazamiento actualizado. En una pantalla de 60 Hz, Chrome dispone de apenas 16,7 milisegundos para entregar cada fotograma antes de que la pantalla se refresque.

Si ese plazo se incumple, la pantalla repite la posición anterior durante un ciclo completo y el usuario percibe un pequeño frenazo al mover el dedo. El problema no es de velocidad bruta, sino de consistencia: cada actualización de desplazamiento debe tardar exactamente el mismo tiempo en aparecer en pantalla.

La reducción del 48% en la frecuencia de desplazamientos bruscos no significa que las páginas carguen más rápido. La mejora afecta a la regularidad con la que Chrome entrega cada fotograma, algo que se percibe especialmente al leer artículos largos o navegar por páginas con mucho contenido.

Por qué Chrome es más vulnerable que otras aplicaciones

Una aplicación Android convencional recibe los eventos de entrada y las señales de sincronización en un único hilo y produce el fotograma. Chrome, en cambio, opera con procesos separados para el navegador, el renderizador y la GPU.

Este modelo mejora la estabilidad, la seguridad y el rendimiento, pero multiplica los puntos donde un retraso mínimo puede desencadenar un efecto dominó.

Cuando el usuario toca la pantalla, el evento de entrada no va a un solo hilo: primero llega al proceso del navegador para determinar qué elemento fue tocado, luego se reenvía al proceso del renderizador para calcular el nuevo desplazamiento. Las señales de sincronización siguen un camino distinto.

A esto se suma que Chrome consume eventos de entrada sin búfer directamente desde el hardware, lo que significa que llegan a intervalos irregulares, a veces varias veces por ciclo de refresco.

Los cinco cambios que redujeron el problema a la mitad

Google solucionó el error con cinco mecanismos:

• Input Vizard.

El problema era que Chrome procesaba las instrucciones del dedo del usuario por un canal interno que también gestionaba muchas otras tareas simultáneas, lo que generaba retrasos.

El equipo redirigió esas instrucciones a un canal dedicado exclusivamente al movimiento de la pantalla, de modo que una tarea pesada en segundo plano ya no interrumpe el desplazamiento.

• Input Framer.

A veces, cuando Chrome estaba listo para dibujar el siguiente fotograma, la información sobre dónde había movido el dedo el usuario aún no había llegado. El resultado era un fotograma vacío y, por tanto, un tirón visible.

La solución fue darle a Chrome una pequeña ventana de espera, equivalente a un tercio del tiempo entre refresco y refresco, para recibir esa información antes de proceder.

• Predicción de entrada.

Cubrió los casos donde ni esa espera era suficiente. Si la información del dedo no llegaba a tiempo, Chrome no se quedaba paralizado: estimaba la posición siguiente basándose en la trayectoria del movimiento ya registrado y generaba un fotograma provisional. En la práctica, el usuario no percibe la diferencia.

• Direct2Thread.

Simplificó la comunicación interna del navegador. Antes, una instrucción de desplazamiento debía pasar por hasta tres intermediarios internos antes de llegar a su destino. El equipo eliminó esos pasos innecesarios y estableció una línea directa.

• Browser controls in Viz.

Cuando el usuario desplaza una página hacia abajo, la barra de navegación de Chrome se oculta al mismo ritmo que el contenido.

Esa sincronización dependía de un canal interno muy ocupado, lo que generaba pequeños desajustes entre el movimiento de la barra y el de la página.

El equipo trasladó esa responsabilidad a la unidad gráfica del dispositivo, que ya controla directamente lo que aparece en pantalla.