INP Input Delay: Causas, diagnóstico y soluciones

Problemas de Interaction to Next Paint (INP) causados por el input delay

Esta página forma parte de nuestra serie sobre Interaction to Next Paint (INP). El INP mide el tiempo total desde una interacción del usuario hasta la siguiente actualización visual. El input delay es la primera de las tres fases que componen el INP, seguida por el processing time y el presentation delay. Si es nuevo en el INP, lea primero nuestra guía sobre cómo identificar y corregir problemas de INP.

CONSEJO INP: la mayoría de las veces el input delay ocurrirá durante las primeras etapas de carga de la página web. Es cuando el navegador está más ocupado analizando y ejecutando scripts.

¿Qué es el input delay?

El input delay se refiere al tiempo que tarda el navegador en comenzar a procesar una callback de evento después de que un usuario interactúa con una página web (por ejemplo, al hacer clic en un botón o presionar una tecla). Aunque siempre existe algo de input delay (incluso los navegadores necesitan tiempo para programar las callbacks), el input delay excesivo ocurre cuando el navegador está ocupado realizando otras tareas programadas y no puede programar inmediatamente las callbacks solicitadas por la interacción.

Durante el input delay, el usuario ya ha realizado su acción (clic, toque o pulsación de tecla), pero el navegador aún no ha comenzado a ejecutar el controlador de eventos asociado. El usuario no ve ninguna respuesta en absoluto. Esto es diferente del processing time, donde el controlador de eventos se está ejecutando activamente, y del presentation delay, donde el navegador está renderizando la actualización visual. El input delay es puro tiempo de espera causado por un main thread congestionado.

Input delay y el INP

El Interaction to Next Paint (INP) se puede desglosar en 3 subpartes: "Input Delay", "Processing Time" y "Presentation Delay".

Puede notar que hay similitudes de nombre entre el Input Delay y el antiguo Core Web Vital "First Input Delay" (FID). El Interaction to Next Paint reemplazó al FID como Core Web Vital en marzo de 2024. El First Input Delay medía solo el tiempo entre la primera interacción y la callback del evento. Aunque el FID se haya retirado, el input delay sigue siendo importante porque está en la base de cada medición de Interaction to Next Paint.

La importancia del input delay

Dado que muchos desarrolladores piensan en mejorar el INP en términos de optimizar las funciones de callback (optimizando el processing time), el input delay a menudo se pasa por alto. Es cierto que el input delay no suele ser la parte más grande del INP, pero si optimizamos el input delay, a menudo optimizaremos todas las interacciones INP a la vez. Reducir el input delay mejora cada interacción en la página, no solo la peor.

En CoreDash recopilamos millones de puntos de datos de Core Web Vitals cada hora. Según esos datos, el input delay representa aproximadamente el 18% del Interaction to Next Paint. Eso es menos que el processing time o el presentation delay, pero el input delay suele ser la fase más fácil de reducir porque la causa raíz es casi siempre "demasiado JavaScript ejecutándose en el momento equivocado".

Causas del input delay

El input delay ocurre cuando el main thread está ocupado ejecutando otras tareas. Estas tareas pueden originarse en:

1. Tareas tempranas. Los scripts normales, diferidos y asíncronos que se ponen en cola al principio crearán tareas tempranas. Estas son la fuente más común de input delay porque se ejecutan durante la ventana crítica de inicio, cuando es más probable que los usuarios interactúen con la página.
2. Tareas programadas. Algunas tareas no se ejecutan al inicio de la carga de la página, sino que pueden programarse para después de que la página se haya cargado. Estas tareas también pueden interferir con el INP y causar un input delay. Por ejemplo, scripts que se ejecutan después del evento window.onload o scripts que se retrasan por los llamados plugins de optimización. Obtenga más información sobre cuándo usar async vs defer para JavaScript.
3. Tareas repetitivas. Tareas recurrentes a través de setInterval() que tardan un tiempo relativamente largo en ejecutarse y coinciden con el INP.
4. Callbacks superpuestas. Las callbacks superpuestas son una causa común de input delay. Múltiples callbacks programadas muy juntas pueden crear una cola, retrasando el procesamiento de la siguiente interacción. Por ejemplo, un controlador de mouseover que se dispara justo antes que un controlador de click puede retrasar el procesamiento del clic durante la duración de la tarea de mouseover.

Minimizar el input delay

1. Dividir las tareas tempranas largas en múltiples tareas más pequeñas. Durante las tareas largas el navegador no puede responder a la entrada del usuario, mientras que después de cada tarea corta el navegador sí puede responder. Divida las tareas largas con scheduler.yield() o envolviendo cada función en un timeout de 0 con setTimeout(callback, 0).
2. Gestionar los elementos interactivos. Considere no presentar elementos interactivos (como una barra de búsqueda) antes de que el código JavaScript que los controla esté completamente cargado. Esto evitará clics tempranos en elementos que no están listos para recibirlos. Para optimizar la UX en este patrón, podría priorizar la carga del JavaScript necesario o ocultar/desactivar temporalmente el elemento hasta que sea funcional.
3. Ejecución de scripts en tiempo de inactividad (idle time). Programe scripts no críticos para que se ejecuten durante los períodos de inactividad del navegador con requestIdleCallback(). Esta función se ejecuta cuando el navegador está inactivo y no necesita procesar la entrada del usuario.
4. Usar web workers para ejecutar JavaScript fuera del main thread del navegador. Los web workers permiten que los scripts se ejecuten fuera del main thread. Esto evitará que el main thread se bloquee y cause problemas de input delay en el INP.
5. Comprobar si hay entrada pendiente durante las tareas repetitivas. Antes de ejecutar un conjunto de tareas programadas, compruebe si hay entrada pendiente antes de iniciar las tareas. Si hay alguna entrada pendiente, realice primero un yield al main thread.
6. Eliminar código innecesario. Audite regularmente sus scripts y elimine cualquier código innecesario o incluso scripts completos, porque cada línea de código puede causar potencialmente un input delay que afecte al Interaction to Next Paint. Consulte nuestra guía sobre 14 métodos para diferir JavaScript para conocer técnicas prácticas.

Dividir tareas con scheduler.yield()

La API scheduler.yield() es la forma recomendada de dividir tareas largas. A diferencia de setTimeout(callback, 0), que coloca la continuación al final de la cola de tareas, scheduler.yield() preserva la prioridad de la tarea. Esto significa que el navegador reanudará su código lo antes posible después de manejar cualquier entrada de usuario pendiente. Aquí tiene una función de ayuda reutilizable:

async function yieldToMain() {
  if ('scheduler' in window && 'yield' in window.scheduler) {
    return await window.scheduler.yield();
  }
  // Fallback para navegadores sin scheduler.yield()
  return new Promise((resolve) => {
    setTimeout(resolve, 0);
  });
}

// Ejemplo: dividir una secuencia de inicio larga
async function initializeApp() {
  loadCriticalFeatures();
  await yieldToMain();  // Dejar que el navegador maneje cualquier entrada pendiente

  loadSecondaryFeatures();
  await yieldToMain();

  loadAnalytics();
  await yieldToMain();

  loadNonEssentialWidgets();
}

Para obtener más información sobre cómo funciona scheduler.yield() internamente, consulte el blog de Chrome Developers.

Priorizar tareas con scheduler.postTask()

Mientras que scheduler.yield() divide las tareas, scheduler.postTask() le ofrece un control detallado sobre la prioridad de las tareas. La API acepta tres niveles de prioridad: "user-blocking" para tareas críticas que requieren la máxima prioridad, "user-visible" para tareas de prioridad media, y "background" para las tareas de menor prioridad que deben ejecutarse durante el tiempo de inactividad.

Usando postTask() puede asegurarse de que el trabajo no esencial no bloquee las interacciones del usuario. Aquí tiene un ejemplo práctico que programa el trabajo de analítica con prioridad background mientras mantiene las actualizaciones de la UI en la prioridad más alta:

// Prioridad alta: el feedback de la UI se ejecuta primero
scheduler.postTask(() => {
  showLoadingSpinner();
}, { priority: 'user-blocking' });

// Prioridad media: obtener datos
scheduler.postTask(async () => {
  const data = await fetchSearchResults(query);
  renderResults(data);
}, { priority: 'user-visible' });

// Prioridad baja: la analítica puede esperar
scheduler.postTask(() => {
  trackSearchEvent(query);
  sendToAnalytics('search', { query });
}, { priority: 'background' });

Consulte la tabla de soporte del navegador para scheduler.postTask() antes de usarla en producción. Para los navegadores que no admiten la API, recurra a requestIdleCallback() para tareas en segundo plano y a queueMicrotask() para tareas de alta prioridad.

Implicaciones prácticas

¿Qué significa esto para su sitio? Aquí tiene recomendaciones específicas para WordPress y React/Next.js.

WordPress

WordPress, debido a su arquitectura basada en plugins, a menudo viene con un tema y un gran número de plugins. Tanto los plugins como los temas suelen depender de JavaScript para su funcionalidad. Dado que estos plugins y temas son mantenidos por desarrolladores externos, usted no tiene control sobre los contenidos. Esto significa que no puede cambiar los archivos y optimizar el "código defectuoso". Incluso si los scripts se comportan bien hoy, no hay garantía de que lo hagan después de la próxima actualización.

Para minimizar el input delay y optimizar el Interaction to Next Paint (INP) en WordPress, siga estos pasos:

• Evite usar plugins siempre que sea posible. Aunque los plugins son una forma fácil de añadir funcionalidad, a menudo añaden scripts a la página. Esos scripts causarán un input delay que impactará en el INP. Para cada plugin, pregúntese: ¿puedo lograr la misma funcionalidad con código personalizado o una solución del lado del servidor?
• Elija temas ligeros. Muchos temas de WordPress "lo ofrecen todo". Aunque eso parece una gran idea, significa que probablemente estén llenos de funcionalidades que no se utilizan pero que sí consumen un tiempo valioso de CPU.
• Evite los constructores de páginas (page builders). Los constructores de páginas como Elementor o WPBakery le ofrecen una interfaz visual y fácil de usar para crear diseños. Desafortunadamente, a menudo dependen de scripts pesados para presentar ese diseño a los visitantes.
• Solo cargue los scripts cuando sean necesarios. WordPress tiende a cargar todos los scripts en todas las páginas. Para solucionar esto, cree un tema hijo y anule el registro de los scripts innecesarios por tipo de página:

function my_deregister_scripts() {
  if ( ! is_page( 'contact' ) ) {
    // Anular el registro del script del formulario de contacto en páginas que no sean de contacto
    wp_dequeue_script( 'contact-form-script' );
  }
}
add_action( 'wp_enqueue_scripts', 'my_deregister_scripts' );

• Audite su Tag Manager. Los contenedores de Google Tag Manager a menudo acumulan etiquetas con el tiempo. Cada etiqueta que se dispara durante la carga de la página añade una tarea al main thread. Elimine las etiquetas no utilizadas, establezca activadores adecuados (por ejemplo, dispare las etiquetas de marketing solo en las páginas de conversión) y utilice los informes de tiempo integrados del Tag Manager para identificar las etiquetas lentas.
• Retrase los scripts de terceros no esenciales. Los widgets de chat, las herramientas de feedback y las incrustaciones de redes sociales no necesitan cargarse inmediatamente. Use requestIdleCallback() o un activador basado en el scroll para cargarlos solo cuando sea probable que el usuario los necesite. Para estrategias detalladas, lea nuestra guía sobre 14 métodos para diferir JavaScript.

React / Next.js

Los sitios de React y Next.js funcionan principalmente con JavaScript. La ejecución de los scripts de inicio, la hidratación de los componentes y el procesamiento del DOM virtual llevan tiempo y pueden causar un input delay para el Interaction to Next Paint (INP). La buena noticia es que tanto React como Next.js proporcionan herramientas para gestionar esto de forma eficaz.

• Use componentes de servidor (React Server Components en el App Router de Next.js). Los componentes de servidor se renderizan en el servidor y envían cero JavaScript al cliente, lo que reduce directamente la cantidad de código que compite por el tiempo del main thread.
• Cargue los scripts de terceros con la estrategia correcta. En Next.js, use el componente next/script con strategy="afterInteractive" para los scripts necesarios después de la hidratación, o strategy="lazyOnload" para los scripts que pueden cargarse durante el tiempo de inactividad del navegador. Consulte nuestra guía sobre async vs defer JavaScript para conocer los principios subyacentes.
• Implemente un patrón de inactividad hasta urgencia (idle-until-urgent). Este patrón prioriza las interacciones del usuario sobre las tareas en segundo plano mediante el uso de requestIdleCallback() para la inicialización no crítica, manteniendo al mismo tiempo un fallback síncrono que se activa cuando el componente es realmente necesario.
• Carga diferida (lazy load) de componentes. Cargue de forma diferida los componentes que no se necesiten inmediatamente usando React.lazy() o el dynamic() de Next.js con { ssr: false } para componentes exclusivos del cliente.
• Use Suspense para componentes interactivos. Envuelva los componentes interactivos en límites <Suspense> para que el resto de la página pueda renderizarse y volverse interactiva mientras los componentes pesados se cargan en segundo plano. Esto evita que un solo componente lento bloquee el procesamiento de la entrada en toda la página.
• Use las transiciones de React para actualizaciones no urgentes. Envuelva las actualizaciones de estado no críticas en startTransition() para que React pueda interrumpirlas si el usuario realiza una nueva interacción. Esto mantiene la interfaz de usuario receptiva incluso cuando hay grandes re-renderizados en curso.

Explore las otras fases del INP

Para tener su INP bajo control, aborde también las otras dos fases:

• Processing Time: Optimice el código del controlador de eventos que se ejecuta durante la interacción. En la mayoría de las páginas, aquí es donde rinde frutos la mayor parte de su esfuerzo de optimización.
• Presentation Delay: Reduzca el trabajo de renderizado y pintura que sigue al procesamiento del evento. En páginas complejas con DOMs grandes, esta suele ser la fase más extensa.

Para un flujo de trabajo de diagnóstico completo, consulte nuestra guía sobre cómo encontrar y corregir problemas de INP, y regrese a la página principal del INP para obtener una visión general completa.