Tiempo de procesamiento del INP: causas, optimización y ejemplos de código

Problemas de Interaction to Next Paint (INP) causados por el tiempo de procesamiento

Esta página forma parte de nuestra serie sobre Interaction to Next Paint (INP). INP mide el tiempo total desde la interacción del usuario hasta la siguiente actualización visual. El tiempo de procesamiento es la segunda de las tres fases que componen el INP, precedida por el retardo de entrada y seguida por el retardo de presentación. Si eres nuevo en INP, lee primero nuestra guía sobre cómo identificar y corregir problemas de INP.

En este artículo nos enfocamos en el tiempo de procesamiento: cómo afecta al Interaction to Next Paint y cómo minimizar el tiempo de procesamiento para mejorar el INP.

En resumen: Interaction to Next Paint (INP) mide cuánto tiempo tarda un usuario en ver un cambio visual en una página después de interactuar con ella. El INP se puede descomponer en 3 componentes: "retardo de entrada", "tiempo de procesamiento" y "retardo de presentación".

El tiempo de procesamiento es un factor importante del INP total, representando aproximadamente el 40% del retraso en promedio. Esto significa que optimizar tu código JavaScript, particularmente los event handlers, puede impactar significativamente la puntuación de INP de tu sitio web.

CONSEJO INP: el tiempo de procesamiento se puede optimizar ejecutando inmediatamente el código importante que precede la actualización del layout y programando el resto del código para que se ejecute después.

¿Qué es el tiempo de procesamiento?

Interaction to Next Paint (INP) se puede descomponer en 3 subpartes: "retardo de entrada", "tiempo de procesamiento" y "retardo de presentación".

El tiempo de procesamiento se refiere al tiempo que tarda el navegador en ejecutar todos los callbacks de eventos asociados 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 hay algo de tiempo de procesamiento, los problemas de INP ocurren cuando los callbacks de eventos consumen demasiado tiempo de procesamiento.

En términos simples: el tiempo de procesamiento es la duración del "trabajo" que ocurre en respuesta a tu interacción. Cuando haces clic en un botón de búsqueda, el tiempo de procesamiento incluye todo, desde validar tu consulta, preparar la solicitud a la API, actualizar el estado local, activar eventos de analítica, y cualquier otro código asociado a ese evento de clic. Cada línea de JavaScript en esos event handlers contribuye al tiempo de procesamiento.

El tiempo de procesamiento y el INP

El tiempo de procesamiento podría ser lo primero que te viene a la mente cuando piensas en optimizar el Interaction to Next Paint. Es el "trabajo que necesita realizarse" antes de que el navegador pueda actualizar el layout.

Muchos desarrolladores piensan en mejorar el INP en términos de optimizar las funciones de callback (optimizar el tiempo de procesamiento), y tienen razón. Pero en términos de importancia, el tiempo de procesamiento ni siquiera es la parte más importante a mejorar. Aun así, en promedio, representa aproximadamente el 40% del tiempo total del INP.

En CoreDash recopilamos millones de datos de Core Web Vitals cada hora. Según esos datos, el tiempo de procesamiento representa el 40% del Interaction to Next Paint. Aunque es una porción significativa, optimizar solo el tiempo de procesamiento probablemente no será suficiente para corregir los problemas de INP. También deberías analizar el retardo de entrada (18%) y el retardo de presentación (42%).

Ejemplo de tiempo de procesamiento: cuando un usuario hace clic en un botón para enviar un formulario, el código que valida los datos del formulario, los envía al servidor y gestiona la respuesta, todo contribuye al tiempo de procesamiento. Cuanto más tarden estas operaciones, mayor será el tiempo de procesamiento y, potencialmente, peor la puntuación de INP.

¿Qué causa un tiempo de procesamiento alto?

Para empezar a corregir los problemas de INP causados por un tiempo de procesamiento alto, necesitamos entender cuáles son las posibles causas. Un tiempo de procesamiento alto, el tiempo que tardan los callbacks de eventos en completarse, puede ser causado por código innecesario, código no optimizado, callbacks agrupados y layout thrashing. Examinemos cada una de estas cuatro áreas.

1. Código innecesario. El código antiguo, sin usar o sin relevancia inmediata para la interacción del usuario puede prolongar el tiempo de ejecución de los callbacks. Esto incluye llamadas de analítica, registro de logs y sincronización de estado que no necesitan completarse antes del siguiente pintado.
   
2. Código no optimizado. El código ineficiente (generalmente bucles o consultas ineficientes al DOM) puede hacer que los callbacks de eventos se ejecuten más lento de lo necesario. Un ejemplo común es consultar el DOM dentro de un bucle con document.querySelectorAll() en lugar de almacenar en caché el resultado antes del bucle.
   
3. Callbacks agrupados. Múltiples callbacks de eventos programados de forma consecutiva crean una cola. Si un callback activado por la interacción del usuario se queda atrapado en esta cola, la respuesta parece retrasada. Por ejemplo, un handler de pointerdown, un handler de mousedown y un handler de click pueden ejecutarse secuencialmente para un solo clic.
   
4. Layout thrashing. Las manipulaciones frecuentes del DOM que provocan recálculos del layout pueden sobrecargar el navegador y causar regresiones de rendimiento. Esto ocurre cuando tu código alterna entre leer y escribir propiedades del layout dentro de un bucle, forzando al navegador a recalcular el layout múltiples veces.

Minimizar el tiempo de procesamiento

La estrategia es doble: optimizar el código existente (eliminar código innecesario y optimizar el código actual) y distinguir entre el código que necesita ejecutarse antes y después de la actualización del layout. El código crítico para la actualización del layout debe ejecutarse primero, y todo el demás código puede ejecutarse después de la actualización del layout.

1. Eliminar código sin usar. Aunque eliminar código sin usar pueda parecer algo obvio, en la mayoría de los sitios hay al menos algo de código antiguo sin usar que simplemente se ejecuta sin aportar nada a la página ni al UX. Lo primero que hay que hacer es asegurarse de que no se esté ejecutando código innecesario. Esto se puede lograr mediante tree shaking, code splitting, inspeccionando la cobertura de código en Chrome, y usando un buen IDE que señale el código sin usar. (Consejo pro: también examina críticamente los recursos cargados por tu Tag Manager.) Para más estrategias, consulta nuestra guía sobre 14 métodos para diferir JavaScript.
2. Minimizar el tiempo de ejecución de callbacks. Usa un perfilador de JavaScript para identificar cuellos de botella en tu código y enfócate en esas áreas para optimizar. Considera técnicas como la memoización, el precálculo y el almacenamiento en caché para evitar cálculos redundantes. (Consejo: puedes usar el panel de rendimiento de Chrome para encontrar scripts con tiempos de ejecución largos.)
   
3. Priorizar el código crítico y programar el resto. Una vez optimizado el código de los callbacks, divide el código en lo que necesita ejecutarse inmediatamente y lo que puede diferirse. Observa este ejemplo real:
   
   En este ejemplo, los callbacks de eventos de Google Tag Manager y Facebook se ejecutan antes del código (React) que precede la actualización del layout. La solución es programar los callbacks de GTM y Facebook para que se ejecuten cuando el navegador esté inactivo.
4. Evitar layout thrashing o reflow. El layout thrashing ocurre cuando las actualizaciones de estilos y las lecturas de estilos se mezclan en un bucle, causando que el navegador recalcule el layout numerosas veces. Para evitar el layout thrashing, realiza todos los cambios de estilo (los "sets") antes de solicitar los valores de estilo (los "gets"). Este enfoque minimiza la frecuencia de las actualizaciones del layout, logrando una página más rápida. Por ejemplo, en un bucle que establece el ancho de cada párrafo para que coincida con el ancho de un elemento, lee el ancho del elemento una vez antes del bucle y usa ese valor para actualizar el ancho de los párrafos dentro del bucle.

Dividir event handlers con setTimeout(0)

Cuando no puedes eliminar o diferir código de un event handler, la siguiente mejor opción es dividir el handler en fragmentos más pequeños. El patrón setTimeout(callback, 0) te permite dividir el trabajo en múltiples tareas, dándole al navegador la oportunidad de gestionar la actualización del layout entre ellas. Aquí tienes un ejemplo práctico:

// Before: one long event handler blocks the next paint
button.addEventListener('click', () => {
  updateUI();           // Critical: must run before paint
  validateForm();       // Important but can wait
  sendAnalytics();      // Non-critical
  syncLocalStorage();   // Non-critical
});

// After: break into critical and deferred work
button.addEventListener('click', () => {
  updateUI();  // Critical: runs immediately before paint

  setTimeout(() => {
    validateForm();
  }, 0);

  setTimeout(() => {
    sendAnalytics();
    syncLocalStorage();
  }, 0);
});

La desventaja de setTimeout(0) es que coloca la continuación al final de la cola de tareas. Si ya hay otras tareas en la cola, el código diferido puede no ejecutarse inmediatamente. Para un comportamiento más predecible, usa scheduler.yield() en su lugar (consulta la sección siguiente). Para patrones específicos de manejo de scroll en JavaScript, consulta nuestra guía dedicada.

Usar requestAnimationFrame para actualizaciones visuales

Cuando tu event handler necesita activar una actualización visual, requestAnimationFrame() asegura que tu código se ejecute en el momento óptimo: justo antes de que el navegador realice su siguiente repintado. Esto es especialmente útil cuando necesitas agrupar las lecturas y escrituras del DOM para evitar layout thrashing.

// Use requestAnimationFrame to batch visual updates
button.addEventListener('click', () => {
  // Read layout properties first (outside rAF)
  const containerWidth = container.offsetWidth;

  requestAnimationFrame(() => {
    // Write layout properties inside rAF
    items.forEach(item => {
      item.style.width = containerWidth + 'px';
    });
  });

  // Schedule non-visual work for idle time
  requestIdleCallback(() => {
    trackButtonClick();
    updateSessionState();
  });
});

Este patrón separa las lecturas del DOM de las escrituras del DOM, previniendo el layout síncrono forzado. La actualización visual se ejecuta en el momento ideal dentro del pipeline de renderizado del navegador, y el trabajo no visual se ejecuta durante el tiempo inactivo.

Cómo priorizar el código crítico

El concepto de "priorizar el código crítico y programar el resto" puede resultar algo abstracto. Podemos priorizar el código crítico usando requestIdleCallback() y cediendo el control al hilo principal.

Usamos requestIdleCallback para tareas menos importantes que no necesitan ejecutarse inmediatamente. Aquí tienes un ejemplo de antes y después de programar un evento de GTM:

/* before: immediately run code */
gtag('event', '<event_name>', {
   'event_category': '<event_category>',
 });

/* after: run the same code during browser idle */
requestIdleCallback(() => {
  gtag('event', '<event_name>', {
    'event_category': '<event_category>',
  });
}, { timeout: 1000 });

La desventaja de requestIdleCallback es que el código podría no ejecutarse tan pronto como desearías. En ese caso, puedes "ceder el control al hilo principal" después de que se haya ejecutado el código más importante, dándole al navegador un momento para realizar la actualización del layout. Aquí tienes un ejemplo de cómo dividir tareas cediendo el control al hilo principal:

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

async function handleClick() {
  // Do the most important layout updates here
  await yieldToMain();
  // Do other tasks that need to run as soon as possible after the layout update
}

Programación detallada con scheduler.postTask()

La función scheduler.postTask() proporciona una programación de tareas más detallada mediante la asignación de prioridades, lo que ayuda al navegador a priorizar el trabajo para que las tareas de baja prioridad cedan el control al hilo principal. Consulta la tabla de compatibilidad de navegadores antes de usar esta API en producción.

La función postTask() acepta tres configuraciones de prioridad: "background" para las tareas de menor prioridad, "user-visible" para tareas de prioridad media, y "user-blocking" para tareas críticas que requieren alta prioridad.

Al asignar la prioridad correcta a cada parte del trabajo dentro de tu event handler, puedes asegurar que el navegador gestione las interacciones del usuario de forma responsiva mientras completa todas las tareas necesarias:

// Schedule critical UI work at high priority
scheduler.postTask(() => {
  updateCartBadge();
  showConfirmation();
}, { priority: 'user-blocking' });

// Schedule data sync at medium priority
scheduler.postTask(() => {
  syncCartWithServer();
}, { priority: 'user-visible' });

// Schedule analytics at low priority
scheduler.postTask(() => {
  gtag('event', 'add_to_cart', { item: productId });
  fbq('track', 'AddToCart');
}, { priority: 'background' });

Implicaciones prácticas

Abordemos la pregunta más importante: "¿Qué significa todo esto para mi sitio?" Así es como abordar la optimización del tiempo de procesamiento para WordPress y React/Next.js.

WordPress

WordPress ofrece un control limitado en lo que respecta a scripts de terceros. Muchos scripts se añaden a través de plugins. La mayoría de las veces, esos scripts añadirán event listeners a la página que no hacen nada excepto retrasar el Interaction to Next Paint (INP). Si tu sitio WordPress tiene problemas con el INP causados por un tiempo de procesamiento largo, sigue estos pasos:

• Revisa la configuración del tema. Desmarca las opciones innecesarias como "smooth scroll" o "animated menu". Configuraciones como estas tienden a causar problemas de INP.
• Identifica qué scripts son responsables del tiempo de procesamiento largo (consejo: usa el panel de rendimiento de Chrome). Si esos scripts están relacionados con plugins, considera buscar otro plugin que haga aproximadamente lo mismo con menos JavaScript.
• A menudo hay scripts personalizados ejecutándose en la página. Revisa esos scripts y asegúrate de que cedan el control al hilo principal con frecuencia y envuelvan los callbacks menos importantes en una función requestIdleCallback.
• Descarga los scripts no utilizados por página (consejo: usa wp_deregister_script). Algunos plugins tienden a inyectar scripts en todas las páginas incluso cuando la funcionalidad no es necesaria.
• Revisa tu Tag Manager y elimina las etiquetas sin usar o innecesarias.
• Usa temas ligeros y limpios. Los temas multipropósito que "hacen de todo" tienden a tener más scripts y event handlers más pesados.
• Evita los page builders ya que a menudo dependen en gran medida de JavaScript para presentar las páginas al usuario final.

React / Next.js

Los hooks y las funcionalidades de concurrencia de React permiten reducir significativamente el tiempo de procesamiento del INP. Estas son las técnicas clave:

Prioriza la interacción del usuario con las funcionalidades de concurrencia de React:

Las funcionalidades de concurrencia de React introducidas en las versiones 16 y 18 proporcionan hooks y mecanismos para optimizar el renderizado y lograr una experiencia de usuario más fluida, especialmente durante la entrada de datos.

• useTransition y startTransition: marcan las actualizaciones no críticas para renderizarlas después. Esto evita que las actualizaciones grandes bloqueen la interacción del usuario. Por ejemplo, envuelve la actualización de resultados de búsqueda en startTransition para que escribir en el campo de búsqueda siga siendo responsivo.
• useDeferredValue: divide tu UI en secciones esenciales y menos críticas. React puede interrumpir el renderizado de las partes menos críticas para una experiencia más responsiva. Esto es ideal para renderizar listas filtradas o resultados de búsqueda.
• useOptimistic: muestra un estado temporal y optimista mientras las operaciones asíncronas (como solicitudes de red) están en curso. Esto mantiene la UI responsiva incluso durante la obtención de datos.

Suspense para obtención de datos (React 18+)

Suspense en React 18 puede usarse para mejorar el INP al permitir que el navegador priorice las interacciones del usuario y optimice el renderizado. Aunque React 16 introdujo Suspense para code splitting, React 18 extiende esta funcionalidad para abarcar la obtención de datos.

• Un componente fallback, como un indicador de carga, se muestra mientras los datos se cargan.
• Una vez que llegan los datos, React reanuda el renderizado del componente suspendido.
• Suspense, combinado con el renderizado interrumpible en Concurrent React, prioriza las interacciones del usuario. Si un usuario interactúa con un componente suspendido, React prioriza el renderizado de ese componente, manteniendo la capacidad de respuesta.

En conjunto, estas funcionalidades trabajan juntas para asegurar que React priorice las interacciones del usuario y evite bloquear la UI durante las actualizaciones o la obtención de datos.

Explora las otras fases del INP

El tiempo de procesamiento es solo una parte del Interaction to Next Paint. Para optimizar completamente tus puntuaciones de INP, también deberías abordar las otras dos fases:

• Retardo de entrada: minimiza el tiempo de espera antes de que los event handlers comiencen a ejecutarse. El retardo de entrada representa aproximadamente el 18% del tiempo total del INP.
• Retardo de presentación: reduce el trabajo de renderizado y pintado que representa aproximadamente el 42% del tiempo total del INP.

Para un flujo de diagnóstico completo, consulta nuestra guía sobre cómo encontrar y corregir problemas de INP, y regresa a la página principal de INP para la descripción general completa.