Consigna y contexto
Los usuarios reportan una página entrecortada tras hacer clic en un botón de filtro. Explica cómo localizar las long tasks en el hilo principal, evaluar su efecto en Interaction to Next Paint (INP) y verificar una solución.
Distingue entre el retraso de entrada (input delay), el trabajo del controlador de eventos (event-handler work) y el siguiente renderizado (next paint). Decir "agrega debounce" o "usa un worker" no es un diagnóstico. Cubre evidencia de usuarios reales, trazas de laboratorio, métricas de regresión y límites de fallback.
Qué evalúa el entrevistador
Modelo de rendimiento
Una respuesta sólida descompone una interacción en espera de entrada, procesamiento de eventos, renderizado y pintado, y luego explica por qué un hilo principal ocupado retrasa la respuesta del navegador.
Diagnóstico basado en evidencia
Usa PerformanceObserver, trazas de Performance del navegador y el contexto de la interacción para identificar el script, el componente y el tamaño de los datos en lugar de adivinar.
Compensaciones al reparar
Analiza la división de tareas, la reducción del trabajo sincrónico, la virtualización, el aplazamiento de actualizaciones no críticas y los workers, teniendo en cuenta la serialización y la consistencia del estado.
Validación con usuarios reales
Compara el p75 de INP, la cantidad de long tasks, los percentiles de interacción y la conversión del negocio. Separa las muestras de laboratorio de los dispositivos, redes y CPUs de gama baja del mundo real.
Preguntas aclaratorias para hacer
- ¿La falta de fluidez afecta a todas las interacciones o a una sola condición de filtro?
- ¿Qué dispositivos, navegadores y tamaños de datos están dentro del alcance?
- ¿El problema ocurre en la carga inicial, en el procesamiento de eventos o en el layout y pintado posteriores al evento?
- ¿Existen muestras de INP, duración de eventos y long tasks de usuarios reales?
- ¿Los resultados deben actualizarse sincrónicamente o la UI puede responder antes de que termine el cómputo?
- ¿Pueden cambiar el ordenamiento, la paginación o la precisión de los resultados?
Estructura de respuesta de 30 segundos
“Usaría muestras de INP e interacción de usuarios reales para encontrar la página afectada y luego grabaría una traza de Performance con el mismo dispositivo y tamaño de datos. PerformanceObserver puede recopilar long tasks de más de 50ms; la traza localiza la pila de llamadas y la fase de pintado. Si el trabajo sincrónico del evento es demasiado grande, dividiría el trabajo, reduciría los rerenders y virtualizaría la lista. Consideraría un worker solo para trabajo de CPU puro y rentable, contemplando el costo de mensajes y serialización. Después compararía el p75 de INP, las long tasks de interacción y la conversión.”
Análisis paso a paso en profundidad
Paso 1: Establecer una línea base
Segmenta el p75 de INP, la duración del evento, el retraso del siguiente pintado, la cantidad de long tasks y los errores por página, interacción, dispositivo y versión. Una máquina local rápida no es una línea base de la población.
Paso 2: Reproducir y localizar
Graba la interacción con el filtro en el panel Performance del navegador. Inspecciona el gráfico de llamas del hilo principal, las long tasks, el layout y el pintado. Un PerformanceObserver puede recopilar entradas de long tasks en tiempo de ejecución y adjuntar el contexto de página, interacción y versión.
Paso 3: Separar cuellos de botella
Una larga espera de entrada apunta a una tarea sincrónica previa; un trabajo de eventos prolongado apunta a parsing, filtrado o actualizaciones de estado; un pintado largo apunta a layout, estilos o un DOM grande. INP es el recorrido completo de entrada a siguiente pintado, no la duración de una sola función.
Paso 4: Reducir el trabajo sincrónico
Reduce el cómputo y los rerenders con paginación, virtualización, filtrado incremental y almacenamiento en caché. Mueve el registro de logs, el prefetching y la analítica fuera de la ruta crítica de interacción. Usa programación por chunks o tiempos de inactividad solo si cuentas con un plan para cuando el tiempo de inactividad sea insuficiente.
Paso 5: Evaluar un worker
Un worker se adapta a trabajo de CPU puro con datos transferibles o manejables. Las copias grandes, los mensajes frecuentes y el acceso al DOM pueden anular los beneficios. Versiona los resultados, cancela el trabajo obsoleto y evita que un filtro antiguo sobrescriba un estado más nuevo.
Paso 6: Verificar y prevenir regresiones
Reproduce la prueba en dispositivos y conjuntos de datos representativos de gama baja y luego despliega gradualmente. Compara el p75/p95 de INP, la cantidad de long tasks, la finalización de interacciones, las cancelaciones y la conversión. Establece un presupuesto de rendimiento que alerte o bloquee regresiones.
Respuesta modelo de alta calidad
“Primero usaría datos de usuarios reales para identificar la interacción, el dispositivo y la versión donde se concentra el problema, y luego grabaría el filtro con el mismo tamaño de datos. La traza muestra el filtrado de arreglos, actualizaciones de estado y el layout de la lista en un solo manejador, por lo que cachearía el filtrado, virtualizaría la lista y pospondría el trabajo no crítico.
Recopilaría long tasks de más de 50ms con PerformanceObserver y las correlacionaría con la página y la interacción. Si el filtrado sigue siendo un cuello de botella de CPU puro, lo movería a un worker, limitaría el tamaño de los mensajes y descartaría resultados obsoletos. Probaría la solución en modo canary en dispositivos de gama baja y compararía el p75 de INP, la cantidad de long tasks, las cancelaciones y la finalización de filtros antes de expandir el despliegue.”
Errores comunes
- Mirar solo la latencia promedio → los usuarios de la cola desaparecen → segmenta el p75/p95 de INP por dispositivo.
- Tratar una long task como INP → se omiten la entrada y el pintado → traza la línea de tiempo completa de la interacción.
- Agregar debounce a cualquier falta de fluidez → la respuesta necesaria puede retrasarse → localiza primero los cuellos de botella de cómputo, renderizado y red.
- Mover todo el trabajo a un worker → el costo de copiado y mensajería crece → migra solo el trabajo de CPU puro que sea rentable.
- Probar solo en una laptop de desarrollo → los dispositivos de gama baja siguen sufriendo tirones → reproduce en dispositivos, datos y cohortes de despliegue representativos.
- Dividir en chunks sin cancelación → los resultados obsoletos sobrescriben el nuevo estado → agrega comprobaciones de versión, cancelación y commit.
- Usar solo Lighthouse de laboratorio → se pierden las interacciones reales → muestrea INP y long tasks de usuarios reales.
- No tener un presupuesto de rendimiento después de la solución → las regresiones pasan desapercibidas → establece umbrales y monitoreo continuo.
Preguntas de seguimiento y respuestas
Pregunta de seguimiento 1: Una long task dura solo 60ms. ¿Por qué el INP sigue siendo deficiente?
Inspecciona la espera de entrada, el layout y el pintado después del manejador, así como las tareas vecinas. El INP es la ruta de respuesta completa; una sola tarea de 60ms no explica todo el escenario.
Pregunta de seguimiento 2: ¿Qué pasa si un worker hace que el resultado sea más lento?
Mide la serialización, la transferencia y la programación. Mantén una ruta rápida en el hilo principal para datos pequeños, agrupa mensajes más grandes o transfiere buffers, y cancela solicitudes obsoletas.
Pregunta de seguimiento 3: ¿Cómo observas el origen de las long tasks?
Registra la hora de inicio, la duración, la página y la versión con PerformanceObserver, y luego usa la traza de Performance para ver la pila de llamadas. Nunca registres información confidencial del usuario.
Pregunta de seguimiento 4: ¿Qué ocurre si el filtrado debe sentirse inmediato?
Reconoce la entrada y muestra el progreso de forma sincrónica, luego calcula incrementalmente. Mantén las versiones de los resultados alineadas con el estado del filtro y expón un estado temporal frente al completado.
Pregunta de seguimiento 5: ¿Cómo demuestras que no se perjudicó la conversión?
Aplica un despliegue tipo canary para el cambio y compara el p75 de INP, la finalización, la cancelación, los errores y la conversión principal por dispositivo y red, con condiciones de parada explícitas.
Fuente 1: Datos de rendimiento de MDN
MDN define los registros de long tasks como tareas que duran 50ms o más, proporcionando evidencia en tiempo de ejecución del bloqueo del hilo principal.
Fuente 2: PerformanceObserver
MDN documenta la observación de entradas de rendimiento con PerformanceObserver, lo que permite la recopilación en tiempo de ejecución de long tasks y contexto de versiones.
Fuente 3: Long Tasks e INP en web.dev
web.dev explica que las long tasks bloquean el hilo principal y retrasan la respuesta, y recomienda dividir el trabajo, reducir el trabajo sincrónico y evaluar el uso de workers; INP captura la capacidad de respuesta desde la interacción hasta el siguiente pintado.