El manejador de clic se ejecuta hasta el final como una única tarea. Después se vacían todas las microtareas que haya encolado, incluidas las callbacks de promesas resueltas, antes de que ocurra nada más. Solo entonces, si toca un fotograma, el navegador ejecuta las callbacks de requestAnimationFrame y pasa por estilo, layout, pintado y composición. Una tarea larga o una cadena infinita de microtareas retrasa ese fotograma, y los usuarios leen ese retraso como tirones.
Por qué lo preguntan los entrevistadores
Casi todo el trabajo de rendimiento en frontend se reduce a saber qué bloquea el fotograma. El entrevistador quiere oír que scripting, estilo, layout y pintado comparten un único hilo principal, que las microtareas no son una forma de ceder el control al navegador y que requestAnimationFrame existe para el trabajo que debe aterrizar antes del pintado. También predice si sabes depurar una queja de respuesta o si vas a esparcir llamadas a setTimeout hasta que el síntoma se mueva.
Cómo estructurar tu respuesta
- Nombra las tres fases en orden: tarea, vaciado de microtareas y oportunidad de renderizado.
- Señala que las microtareas dejan sin aire al renderizador mientras que un timeout cede el control.
- Di dónde encaja requestAnimationFrame respecto a estilo y layout.
- Conéctalo con una métrica como la latencia de interacción.
Ejemplo de respuesta
El manejador en sí es una tarea del hilo principal, así que se ejecuta de principio a fin sin que nada lo interrumpa. En cuanto retorna, el navegador vacía la cola de microtareas, así que cualquier continuación de un await o callback de then se ejecuta ahí mismo, y si esas siguen encolando más microtareas el navegador nunca tiene ocasión de pintar. Cuando esa cola está vacía, y solo si de verdad toca un fotograma, el navegador ejecuta las callbacks de requestAnimationFrame, recalcula estilos, hace layout, pinta y compone. Por eso trato las tareas largas como el enemigo real. En un panel en el que trabajé, un cambio de filtro hacía una ordenación síncrona de unas cuarenta mil filas dentro del manejador, y el clic se sentía muerto durante unos doscientos milisegundos. Partirlo para que el manejador solo actualizara el input y luego ceder con scheduler.yield antes del paso caro mantuvo intacto el presupuesto de fotograma, y la interacción empezó a responder de inmediato aunque el trabajo total fuera idéntico.
¿Tienes esta entrevista a la vuelta de la esquina? GhostPilot escucha tu llamada en vivo, detecta la pregunta en cuanto la hacen y pone una respuesta estructurada en tu pantalla en tiempo real. Pruébalo en tu próxima entrevista de práctica, o coge un Session Pass de $29, sin suscripción, para la de verdad.
Mira cómo funcionaPreguntas de seguimiento que puedes esperar
- ¿Por qué esperar una promesa ya resuelta no le da al navegador ocasión de pintar?
- ¿Cuándo recurrirías a requestAnimationFrame en vez de a un timeout?
- ¿Cómo trocearías una tarea larga sin cambiar el resultado?
Más preguntas para Desarrollador frontend
Tu entrevistador hará su propia versión de esta. Pega la descripción real del puesto en el Question Predictor gratuito y obtén las 20 preguntas que ese puesto tiene más probabilidades de hacerte, con lo que cada una busca en realidad.
Predecir mis preguntas