Planteamiento y contexto
La página se ve bien en Lighthouse; sin embargo, los usuarios reales reportan que los clics se sienten trabados. El RUM existente solo reporta un valor de INP y no puede determinar si los manejadores de eventos, requestAnimationFrame, el estilo y la disposición (layout), o los scripts de terceros causaron el retraso. Diseña el ciclo de observación, correlación, muestreo, agregación y corrección con LoAF.
Qué está evaluando el entrevistador
- Si comprendes el retraso de entrada (input delay), la duración del procesamiento y el retraso de presentación de INP.
- Si sabes que LoAF mide cuadros que superan los 50 milisegundos y expone la atribución de scripts y los tiempos de renderizado.
- Si correlacionas interacciones, LoAF, la versión de la página y el contexto del dispositivo en lugar de subir cada evento sin procesar.
- Si manejas el soporte del navegador, los búferes, los scripts de origen cruzado (cross-origin) y el riesgo de privacidad.
- Si conectas los datos con correcciones de código, comprobaciones de regresión y alertas.
Preguntas para aclarar primero
- ¿El objetivo es el diagnóstico de INP, la fluidez de las animaciones, el monitoreo de tareas largas o los tres?
- ¿Cuáles son la tasa de muestreo, los usuarios diarios, el presupuesto de reporte y el período de retención?
- ¿Se permite registrar URLs, fuentes de scripts, tipos de interacción y versiones de página?
- ¿Qué navegadores deben ser compatibles y cuál es el respaldo cuando LoAF no está disponible?
- ¿Qué equipo es responsable de las alertas y correcciones, y los umbrales deben usar p75, p95 o cohortes de dispositivos?
Una respuesta de 30 segundos
“Pondría el desglose de fases de INP y la observación de LoAF en una sola ruta de correlación de RUM. Usaría PerformanceObserver para long-animation-frame, conservando únicamente los cuadros que se intersecten con ventanas de interacción de alto INP, y retendría duration, blockingDuration, renderStart, styleAndLayoutStart y la atribución de scripts. Detectaría el soporte, anonimizaría campos, muestrearía dinámicamente y agruparía reportes en lotes con la versión de la página, la cohorte de dispositivos y una clave de sesión anónima. Agregaría por interacción y lanzamiento, y luego vincularía las alertas con sourceURL y la función. Validaría cada corrección con las mismas cohortes y muestreo.”
Análisis detallado paso a paso
1. Dividir las fases de INP
El retraso de entrada es el tiempo desde que se encola hasta el inicio del manejador, la duración del procesamiento es la ejecución del manejador y el retraso de presentación es el tiempo desde que termina el procesamiento hasta el siguiente cuadro pintado. LoAF no reemplaza al INP; agrega contexto de cuadros para localizar la fase lenta.
2. Observar entradas de LoAF
Observa long-animation-frame con PerformanceObserver en lugar de leer repetidamente la línea de tiempo de rendimiento. El umbral es de 50 milisegundos y las entradas incluyen duration, blockingDuration, renderStart, styleAndLayoutStart, firstUIEventTimestamp y scripts.
if (PerformanceObserver.supportedEntryTypes.includes("long-animation-frame")) {
const observer = new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
queueFrameForCorrelation(entry);
}
});
observer.observe({ type: "long-animation-frame", buffered: true });
}3. Correlacionar interacciones y versiones
Mantén un resumen de interacción de INP de corta duración y un búfer circular de entradas de LoAF. Cuando finalice una interacción, usa firstUIEventTimestamp, startTime y duration para encontrar los cuadros que se intersectan y retén solo los pocos más explicativos. Adjunta la versión de la página, la cohorte del experimento, la clase de dispositivo y una clave de sesión anónima, nunca la entrada completa del usuario.
4. Explicar el costo de scripts y renderizado
blockingDuration estima el tiempo que bloquea la entrada o el trabajo de alta prioridad; renderStart y styleAndLayoutStart ayudan a separar el pre-renderizado, estilo/layout y otras fases. scripts puede identificar la URL del hilo principal, la función y el tipo de invocador, pero los iframes de origen cruzado, los workers y las extensiones pueden tener una atribución incompleta.
5. Diseñar controles de muestreo y privacidad
Reporta por defecto interacciones con alto INP, cuadros largos anómalos o una pequeña muestra aleatoria; limita la tasa por cada sesión anónima. Aplica listas de permitidos o hash a dominios de scripts, elimina parámetros de consulta, entradas de usuario y texto del DOM, y deshabilita la atribución detallada en páginas sensibles. Aplica en el servidor políticas de retención, acceso, eliminación y una política de muestreo versionada.
6. Cerrar el ciclo de agregación y corrección
Agrega p75/p95 por interacción, versión (release), dispositivo, red y fuente de script en lugar de un único promedio del sitio. Las alertas muestran las fases de entrada, procesamiento y presentación, además de la atribución común. Compara el antes y el después usando el mismo muestreo y cohortes para asegurar que el problema no se haya trasladado a otro dispositivo o interacción.
Ejemplo de una respuesta sólida
“Primero usaría el desglose de fases de INP para decidir si predomina la entrada, el procesamiento o la presentación, y luego agregaría evidencia de LoAF. El cliente detecta características y observa long-animation-frame, reteniendo únicamente las entradas que intersectan interacciones de alto INP con duration, blockingDuration, tiempos de renderizado y la atribución de scripts disponible. La correlación utiliza la versión, la cohorte del experimento, el dispositivo y una clave de sesión anónima, no la entrada del usuario. La atribución detallada se muestrea y se anonimiza con un límite de retención; los navegadores no compatibles aún reportan el INP básico. El servidor agrega por interacción, versión y dispositivo, alerta sobre el código fuente probable y valida las correcciones con comprobaciones de regresión a nivel de cohorte.”
Errores comunes
- Reportar solo un número de INP → sin diagnóstico de fase o código → correlacionar las fases de INP con los cuadros de LoAF.
- Subir cada cuadro largo sin procesar → alto costo y contexto expuesto → muestrear, anonimizar y conservar cuadros que intersecten con alto INP.
- Tratar 50 milisegundos como una línea de aprobación de INP → se confunde el umbral de cuadros con una métrica de producto → explicar los umbrales y los objetivos de percentiles por separado.
- Asumir que cada script tiene atribución → los cuadros de origen cruzado y los workers están incompletos → marcar brechas y analizar con cohortes de versiones y dispositivos.
- Mirar solo el promedio del sitio → desaparecen problemas graves específicos de dispositivos → segmentar por interacción, dispositivo, red y versión.
Preguntas de seguimiento y respuestas
¿Reemplazará LoAF a la Long Tasks API?
No directamente. LoAF mide cuadros y proporciona un contexto más rico, mientras que Long Tasks sigue siendo útil para el monitoreo existente y navegadores compatibles. Compara ambos durante la migración en lugar de eliminar la señal antigua de forma abrupta.
¿Por qué no subir la URL de cada script?
Las URLs pueden contener identificadores, parámetros de consulta o rutas internas, y aumentan el volumen. Elimina parámetros, restringe dominios, aplica funciones hash a los valores o conserva solo mapeos de fuentes versionados según la sensibilidad de la página.
¿Cómo diferencias el costo de layout de la ejecución de scripts?
Compara renderStart, styleAndLayoutStart, duration y las entradas de scripts. Si el tiempo de scripts es pequeño pero el intervalo de estilo/layout es grande, inspecciona el tamaño del DOM, los selectores y el layout sincrónico; confirma con un trace de laboratorio.
¿Qué pasa con los navegadores sin LoAF?
Detecta la característica y recurre a INP básico, Event Timing o Long Tasks, etiquetando la versión de observación en el lado del servidor. No excluyas a esos usuarios de las métricas de experiencia general; expón la diferencia de capacidad de diagnóstico en reportes segmentados.