En el desarrollo frontend, la optimización suele centrarse en reducir peticiones, adelgazar el bundle o aprovechar la caché. Sin embargo, en interfaces muy interactivas —con datos en streaming, animaciones y entrada del usuario simultáneas—, el cuello de botella pasa a ser otro: el hilo principal del navegador. Este artículo explica por qué ese hilo es un recurso caro y cómo gestionarlo.
El hilo principal concentra casi todo lo que el código puede tocar: ejecución de JavaScript, manejo de eventos, respuestas de red, internals del framework y, además, gran parte del proceso de pintado (cálculo de estilos, layout y paint). El compositor solo recibe la fase final. Para mantener 60 fps en una pantalla de 60 Hz, cada cuadro dispone de unos 16,6 ms; tras descontar el trabajo interno del navegador, el presupuesto real ronda de 10 ms, y se reduce a la mitad en dispositivos de 120 Hz. Como JavaScript sigue un modelo de bucle de eventos single-threaded, una sola tarea que ocupe 200 ms bloquea repintados e interacciones: cualquier tarea superior a 50 ms se considera problemática.
Esa misma idea subyace tras métricas clave como INP (Interaction to Next Paint) y TBT (Total Blocking Time): ambas miden, en esencia, cuánto tiempo estuvo bloqueado el hilo principal. Optimizar el rendimiento consiste, por tanto, en gastar con cuidado ese único hilo. El artículo distingue dos familias de estrategias: gestionar mejor el tiempo dentro del propio hilo principal o derivar trabajo fuera de él. Dentro de la primera familia, propone cuatro movimientos básicos —dividir (splitting), agrupar (batching), priorizar (prioritizing) y diferir (deferring)— y se detiene en la técnica de dividir tareas largas en fragmentos pequeños que liberan el hilo entre medias, ilustrándolo con el caso de un chat de livestream que recibe ráfagas de cientos de mensajes por segundo.