Interaction to Next Paint (INP): Qué es, cómo medirlo y mejorarlo

Interaction to Next Paint (INP) es una Core Web Vital que mide la rapidez con la que una página web responde a las interacciones del usuario, como clics, toques y pulsaciones de teclas. El INP captura la latencia completa desde la entrada del usuario, pasando por el procesamiento de JavaScript, hasta la actualización visual final en la pantalla. Una buena puntuación de INP es de 200 milisegundos o menos en el percentil 75. El INP reemplazó a First Input Delay (FID) como Core Web Vital en marzo de 2024.

¿Qué es Interaction to Next Paint (INP)?

Interaction to Next Paint (INP) es una métrica Core Web Vital que mide la capacidad de respuesta de una página web a lo largo de toda la visita del usuario. A diferencia de su predecesor, First Input Delay (FID), que solo medía el retraso antes de que comenzara el manejador de eventos de la primera interacción, el INP evalúa cada interacción que un usuario realiza con la página y reporta un valor único que representa la capacidad de respuesta general de la página.

Cada vez que un usuario hace clic en un botón, toca un enlace, presiona una tecla en el teclado o interactúa con un control personalizado, el navegador mide el tiempo total desde el momento de la entrada hasta que se pinta el siguiente fotograma en la pantalla. El INP selecciona una de las interacciones más lentas como la puntuación de capacidad de respuesta de la página. Para páginas con menos de 50 interacciones totales, el INP reporta la peor interacción individual. Para páginas con muchas interacciones, el INP generalmente utiliza el percentil 98 para filtrar valores atípicos ocasionales.

Un INP bajo significa que la página responde de manera confiable a la entrada del usuario de manera oportuna. Un INP alto significa que la página se siente lenta, no responde o tiene "jank" porque el navegador no puede procesar las interacciones y actualizar la pantalla lo suficientemente rápido.

INP vs FID: Qué cambió y por qué

El INP reemplazó oficialmente a First Input Delay (FID) como Core Web Vital en marzo de 2024. Google retiró el FID porque tenía dos limitaciones fundamentales que lo convertían en una medida incompleta de la capacidad de respuesta de la página.

En primer lugar, el FID solo medía la primera interacción en una página. Si el primer clic de un usuario era rápido pero las interacciones posteriores eran lentas, el FID reportaba una puntuación aprobatoria a pesar de la mala experiencia. El INP mide todas las interacciones a lo largo de la sesión, proporcionando una imagen mucho más precisa de la capacidad de respuesta real.

En segundo lugar, el FID solo medía la fase de retardo de entrada (input delay), lo que significa que capturaba el tiempo que el navegador pasaba esperando antes de comenzar a procesar el evento. Ignoraba por completo el tiempo dedicado a ejecutar el código del manejador de eventos (tiempo de procesamiento) y el tiempo necesario para pintar el resultado visual en la pantalla (retardo de presentación). El INP captura las tres fases, brindando a los desarrolladores una visión completa de la latencia de interacción.

La transición de FID a INP causó una caída de aproximadamente 5 puntos porcentuales en las tasas de aprobación de Core Web Vitals en móviles, según el HTTP Archive Web Almanac 2024. Esto sucedió porque muchos sitios que parecían receptivos bajo FID tenían interacciones posteriores lentas que el INP ahora captura.

¿Qué interacciones mide el INP?

El INP solo mide las interacciones que implican una entrada discreta del usuario que el navegador puede observar a través de manejadores de eventos. Comprender qué interacciones cuentan es esencial para una depuración y optimización precisas.

Interacciones que cuentan para el INP

• Clics del mouse (incluyendo clics en botones, enlaces, casillas de verificación y controles personalizados)
• Toques en pantallas táctiles (equivalente a clics en dispositivos móviles)
• Pulsaciones de teclas en un teclado físico o en pantalla (incluyendo escribir en campos de formulario, presionar Enter, usar atajos de teclado)

Interacciones que NO cuentan para el INP

• Desplazamiento (Scrolling) no cuenta porque es manejado por el hilo compositor del navegador y típicamente no bloquea el hilo principal
• Hovering (pasar el mouse por encima) no cuenta porque es un estado continuo del puntero, no una interacción discreta del usuario
• Gestos de arrastre no cuentan, aunque el pointerdown inicial que comienza un arrastre puede activar una entrada de INP
• Transiciones y animaciones CSS que ocurren sin entrada del usuario no son interacciones

Un error común es pensar que el desplazamiento afecta al INP. No lo hace. Sin embargo, si tu página utiliza desplazamiento basado en JavaScript en lugar del desplazamiento nativo del navegador, esos manejadores de desplazamiento de JavaScript pueden activar callbacks de eventos que el navegador mide como interacciones. Esta es una razón por la cual el desplazamiento nativo CSS supera consistentemente al desplazamiento JavaScript en capacidad de respuesta.

Las tres fases de una interacción INP

Cada interacción medida por el INP consta de tres fases secuenciales. El valor total del INP es la suma de las tres. Comprender cada fase es crítico porque la estrategia de optimización difiere para cada una.

1. Retardo de Entrada (Input Delay)

El retardo de entrada es el tiempo entre el momento en que el usuario interactúa con la página y el momento en que el navegador comienza a ejecutar los manejadores de eventos asociados. Este retraso ocurre porque el hilo principal del navegador puede estar ocupado con otro trabajo, como analizar JavaScript, ejecutar tareas programadas previamente o procesar otros callbacks de eventos.

El retardo de entrada es especialmente problemático durante la fase de carga de la página, cuando muchos scripts se están analizando y ejecutando simultáneamente. Los datos de CoreDash muestran que las interacciones durante la fase de carga tienen un INP p75 de 132ms, en comparación con solo 50ms para las interacciones después de que la carga de la página está completa. Esa es una diferencia de 2.6x. Reducir la contención del hilo principal durante el inicio de la página es una de las formas más efectivas de mejorar el INP.

En la mediana, el retardo de entrada es la sub-parte más pequeña del INP. Pero en el percentil 90, el retardo de entrada se convierte en el contribuyente dominante porque las tareas largas en el hilo principal pueden retrasar el procesamiento de eventos por cientos de milisegundos. El HTTP Archive Web Almanac 2024 encontró que menos del 25% de los sitios web mantienen la duración de las tareas por debajo del umbral recomendado de 50ms.

2. Tiempo de Procesamiento (Processing Time)

El tiempo de procesamiento es el tiempo total que el navegador pasa ejecutando todos los callbacks de los manejadores de eventos asociados con la interacción. Esto incluye cualquier JavaScript que se ejecute en respuesta al evento, desde la validación de formularios hasta actualizaciones de estado y llamadas de seguimiento de análisis.

El tiempo de procesamiento representa una parte significativa del INP total. Si un manejador de eventos realiza operaciones DOM costosas, hace llamadas API síncronas o ejecuta bucles ineficientes, el tiempo de procesamiento se disparará. Un patrón común que infla el tiempo de procesamiento es ejecutar código no esencial (como eventos de análisis o callbacks de etiquetas de terceros) dentro del mismo manejador de eventos que la actualización visual crítica.

3. Retardo de Presentación (Presentation Delay)

El retardo de presentación es el tiempo entre que todos los manejadores de eventos han terminado de ejecutarse y cuando el navegador presenta el siguiente fotograma que contiene la actualización visual. Esta fase incluye el recálculo de estilo, computación de diseño (layout), pintura y composición.

En la mediana, el retardo de presentación es la sub-parte más grande del INP porque cada interacción requiere al menos un pase de renderizado. Las páginas con un DOM grande o profundamente anidado tardan más en recalcular estilos y realizar el diseño. Las Single Page Applications (SPA) que re-renderizan grandes árboles de componentes después de cambios de estado son particularmente susceptibles a un alto retardo de presentación.

¿Qué son puntuaciones INP buenas y malas?

Para aprobar la evaluación de Core Web Vitals para la métrica Interaction to Next Paint, el percentil 75 de todas las interacciones registradas en el campo debe permanecer por debajo de los 200 milisegundos:

• Un INP por debajo o igual a 200 milisegundos significa que tu página tiene buena capacidad de respuesta.
• Un INP entre 200 y 500 milisegundos significa que la capacidad de respuesta de tu página necesita mejorar.
• Un INP por encima de 500 milisegundos significa que tu página tiene una mala capacidad de respuesta.

Es importante entender que el INP utiliza el percentil 75, no el promedio. Esto significa que el 75% de tus usuarios reales deben experimentar interacciones más rápidas de 200ms. La metodología del percentil 75 asegura que la métrica refleje la experiencia de los usuarios en dispositivos y conexiones más lentas, no solo aquellos con hardware de alta gama.

Cómo medir Interaction to Next Paint (INP)

El Interaction to Next Paint solo se puede medir con herramientas de campo que capturan interacciones reales de usuarios. A diferencia de las métricas de laboratorio que simulan una sola carga de página, el INP requiere visitantes reales haciendo clic, tocando y escribiendo en tus páginas. No hay forma de obtener una puntuación INP significativa de una prueba sintética porque el INP depende del comportamiento humano real.

Obtén las métricas oficiales de INP

Puedes obtener las métricas oficiales de INP desde PageSpeed Insights o el panel de control CrUX y Google BigQuery. PageSpeed Insights reporta la puntuación del percentil 75 basada en los últimos 28 días de datos de usuarios de Chrome. Google BigQuery proporciona más contexto histórico y permite consultas personalizadas en todo el conjunto de datos de CrUX.

Google Search Console también reporta problemas de INP en la sección de Core Web Vitals, agrupando las URL afectadas y marcando las páginas que necesitan mejora o tienen mala capacidad de respuesta.

Rastrea el INP con Real User Monitoring

Si bien el conjunto de datos oficial de CrUX es la fuente definitiva para las puntuaciones de Core Web Vitals, es altamente anónimo y no admite monitoreo en tiempo real ni filtrado detallado. Es por eso que los profesionales del rendimiento web confían en herramientas de Real User Monitoring (RUM) como CoreDash para obtener datos de INP accionables y en tiempo real. Las herramientas RUM recopilan mediciones de INP de cada carga de página, las atribuyen a elementos específicos, estados de carga y tipos de dispositivos, y te permiten diagnosticar exactamente qué interacciones están causando problemas.

Mide el INP para la sesión actual

La forma más sencilla de depurar el INP durante el desarrollo es a través de Chrome DevTools. Abre el panel de Rendimiento y usa el modo "timespan" en Lighthouse para registrar interacciones y ver su latencia. También puedes usar la extensión Core Web Vitals Visualizer, que superpone las puntuaciones de INP en la página mientras interactúas con ella.

Para una depuración práctica, usa la Librería JavaScript de Web Vitals de Google para registrar interacciones individuales en la consola:

Registra el INP en la consola con la librería JavaScript de Web Vitals

<script type="module">
 import {onINP}
 from 'https://unpkg.com/web-vitals@4/dist/web-vitals.attribution.js?module';
 onINP(console.log);
</script>

Cómo mejorar Interaction to Next Paint

Mejorar el Interaction to Next Paint requiere optimizar las tres fases: retardo de entrada, tiempo de procesamiento y retardo de presentación. Tu página podría responder instantáneamente a la mayoría de las interacciones, pero si incluso una interacción es lenta, puede definir la puntuación total de INP. Es por eso que es necesario un enfoque sistemático.

CONSEJO PageSpeed: la mayoría de las veces el INP será mucho peor cuando un usuario interactúa con la página durante la etapa de inicio de la carga de la página. ¡Es por eso que, al depurar el INP, tiene sentido registrar todas las interacciones así como el estado de carga de la página!

1. Minimizar el Retardo de Entrada: Prevenir Tareas Largas en el Hilo Principal

Por lo general, cualquier página es menos receptiva durante la fase de inicio de la página, cuando ocurre la mayor parte del trabajo del hilo principal (análisis, decodificación, renderizado y scripting). Para mantener el hilo principal lo más libre posible:

• Elimina código no utilizado. Usa tree shaking para eliminar código muerto y code splitting para dividir tu bundle en fragmentos más pequeños que se carguen bajo demanda. Audita la cobertura de tu código usando Chrome DevTools para identificar scripts que se cargan pero nunca se ejecutan.
• Carga código no esencial durante el tiempo de inactividad del navegador. ¿Realmente necesitas un widget de chat durante los primeros 500ms de la carga de la página? Programa scripts no críticos con requestIdleCallback() para que se ejecuten solo cuando el navegador esté inactivo.
• Identifica y reescribe scripts lentos que consuman recursos excesivos de CPU. Usa el panel de Rendimiento de Chrome para encontrar scripts con largos tiempos de ejecución y enfócate en optimizarlos.
• Mantén tu página fácil de renderizar. Evita tamaños de DOM grandes, imágenes excesivas, demasiados videos y animaciones CSS intensivas en CPU.
• Usa async y defer en etiquetas de script para evitar que JavaScript bloquee el analizador HTML. Considera diferir JavaScript no crítico completamente hasta después de que la página se haya vuelto interactiva.

Romper Tareas Largas con scheduler.yield()

JavaScript se ejecuta en el hilo principal del navegador utilizando un modelo de "ejecutar hasta completar": una vez que comienza una tarea, bloquea el hilo principal hasta que termina. Las tareas largas (más de 50ms) impiden que el navegador responda a la entrada del usuario. La API scheduler.yield() te permite crear explícitamente puntos de rendimiento (yield points) dentro de código de larga ejecución, dando al navegador la oportunidad de procesar interacciones de usuario pendientes antes de continuar.

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);
  });
}

// Uso: romper una tarea larga en fragmentos más pequeños
async function processLargeDataSet(items) {
  for (let i = 0; i < items.length; i++) {
    processItem(items[i]);

    // Ceder (yield) cada 5 ítems para dejar que el navegador maneje la entrada del usuario
    if (i % 5 === 0) {
      await yieldToMain();
    }
  }
}

Diferir Trabajo No Crítico con requestIdleCallback

Usa requestIdleCallback() para programar tareas no esenciales (análisis, telemetría, precarga) para cuando el navegador esté inactivo. Esto mantiene el hilo principal despejado para las interacciones del usuario y reduce directamente el retardo de entrada.

// En lugar de ejecutar análisis síncronamente:
document.querySelector('.cta-button').addEventListener('click', (e) => {
  // Crítico: actualizar la UI inmediatamente
  showConfirmation();

  // No crítico: enviar análisis durante tiempo inactivo
  requestIdleCallback(() => {
    sendAnalyticsEvent('cta_clicked', { page: location.pathname });
  }, { timeout: 2000 });
});

Usa Listeners de Eventos Pasivos

Para eventos que no necesitan llamar a preventDefault(), marca tus listeners de eventos como pasivos. Esto le dice al navegador que no necesita esperar a que tu manejador decida si cancelar el comportamiento predeterminado, permitiendo un desplazamiento más suave y una respuesta táctil más rápida.

// Listener pasivo: el navegador no espera a preventDefault()
document.addEventListener('touchstart', handleTouch, { passive: true });
document.addEventListener('wheel', handleWheel, { passive: true });

2. Minimizar el Tiempo de Procesamiento: Proporcionar Retroalimentación Inmediata

Cuando un visitante realiza una acción como enviar un formulario o agregar un artículo a una cesta, no esperes la confirmación del servidor antes de actualizar la UI. Proporciona retroalimentación visual inmediata ("Enviando tu formulario...", "Agregando artículo a la cesta...") y luego completa la operación en segundo plano.

Además, cede al hilo principal tan pronto como sea posible después de la actualización visual crítica. Debido a que JavaScript sigue un modelo de "ejecutar hasta completar", bloquea el hilo principal hasta que todo el código en el callback se haya ejecutado. Puedes crear manualmente un punto de rendimiento donde el navegador pueda actualizar el diseño y luego continuar ejecutando el código no crítico restante.

const formfeedbackEl = document.getElementById("formfeedback");
const formEl = document.getElementById("form");

formEl.addEventListener("submit", (evt) => {
  evt.preventDefault();
  formfeedbackEl.innerText = "Enviando formulario ... por favor espera";

  let headers = new Headers({ Accept: "application/json" });
  let formData = new FormData(formEl);
  fetch("/form-endpoint", { method: "POST", headers, body: formData })
    .then(function (response) {
      return response.json();
    })
    .then(function (jsonData) {
      formEl.reset();
      formfeedbackEl.innerText = jsonData.message;
    });
   setTimeout(other_code_that_needs_to_run(), 0);
});

3. Minimizar el Retardo de Presentación: Mantener las Cosas Simples

Cuando la página necesita actualizarse después de una interacción, el navegador debe recalcular estilos, realizar el diseño (layout), pintar los píxeles cambiados y componer el resultado. La complejidad y el tamaño de tu DOM determinan directamente cuánto tiempo toma este trabajo de renderizado.

Algunos entornos SPA mal optimizados re-renderizan demasiado contenido después de cada interacción. Por ejemplo, al actualizar un contador, asegúrate de actualizar solo el elemento del contador, no todo el árbol de componentes.

Sigue estas dos reglas de oro para un renderizado más rápido:

1. Mantén el DOM pequeño y simple. Es mucho más fácil para un navegador renderizar una página con menos elementos DOM (nodos HTML) que una página con estructuras DOM profundamente anidadas y complicadas. Apunta a menos de 1,400 elementos DOM en total, y evita anidar a más de 32 niveles de profundidad.
2. Usa content-visibility para renderizado diferido (lazy-render) de contenido fuera de pantalla. La propiedad CSS content-visibility: auto acelera el renderizado inicial al diferir el renderizado del contenido fuera de pantalla hasta que el usuario se desplaza cerca de él.

/* Aplica content-visibility a secciones fuera de pantalla */
.below-the-fold {
  content-visibility: auto;
  contain-intrinsic-size: auto 500px;
}

Depurando INP con la API Long Animation Frames (LoAF)

La API Long Animation Frames (LoAF) es una herramienta poderosa para diagnosticar problemas de INP. Proporciona información detallada sobre los fotogramas que tardan más de 50ms en renderizarse, incluidos datos de atribución de scripts que te dicen exactamente qué scripts están contribuyendo a interacciones lentas.

A diferencia de la antigua API Long Tasks, LoAF captura el tiempo de renderizado así como el tiempo de ejecución de scripts, lo que la hace particularmente útil para diagnosticar problemas de retardo de presentación. Las entradas de LoAF incluyen la duración del fotograma, la duración del bloqueo y un array de entradas de script que muestran la URL de origen, el nombre de la función y el tiempo de ejecución de cada script que se ejecutó durante el fotograma.

// Observar Long Animation Frames para encontrar cuellos de botella de INP
const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    // Solo mirar fotogramas de más de 100ms
    if (entry.duration > 100) {
      console.log('Long frame:', entry.duration + 'ms');

      // Registrar cada script que contribuyó
      for (const script of entry.scripts) {
        console.log(
          'Script:', script.sourceURL,
          'Función:', script.sourceFunctionName,
          'Duración:', script.duration + 'ms'
        );
      }
    }
  }
});

observer.observe({ type: 'long-animation-frame', buffered: true });

Las herramientas RUM como CoreDash integran datos de LoAF automáticamente, correlacionando fotogramas de animación largos con interacciones de usuario específicas para que puedas identificar exactamente qué script, en qué página, para qué tipo de interacción, está causando tus peores puntuaciones de INP.

INP y LCP: La Conexión de Tareas Largas

Las tareas largas en el hilo principal afectan tanto al INP como al Largest Contentful Paint (LCP). Una tarea de JavaScript que bloquea el hilo principal durante 200ms retrasa el procesamiento de eventos (empeorando el INP) y también retrasa al navegador en el renderizado del elemento LCP (empeorando el LCP). Cuando optimizas tu hilo principal rompiendo tareas largas, difiriendo JavaScript no crítico y reduciendo el tiempo de ejecución de scripts, mejoras ambas métricas simultáneamente.

Casos de Estudio: Mejoras de INP en Producción

redBus: 80 a 100% de Mejora en Conversión Móvil

redBus, una de las plataformas de venta de billetes de autobús en línea más grandes del mundo, invirtió en la optimización de Core Web Vitals en sus mercados globales. Su enfoque en reducir el tiempo de ejecución de JavaScript y optimizar los manejadores de eventos contribuyó a una mejora del 80 al 100% en las tasas de conversión móvil en sus mercados globales. Las mejoras fueron impulsadas por una combinación de reducción del tiempo de bloqueo del hilo principal, optimización de la carga de scripts de terceros e implementación de code splitting para reducir la cantidad de JavaScript analizado durante el inicio de la página.

Preply: INP de 250ms a 185ms, $200K por Año en Ahorros Estimados de SEO

Preply, una plataforma de tutoría de idiomas en línea, mejoró su INP de la página de inicio de aproximadamente 250ms a 185ms y su INP de la página de búsqueda de aproximadamente 250ms a 175ms. El equipo logró estas ganancias perfilando su aplicación React, identificando y eliminando re-renderizados innecesarios y difiriendo callbacks de eventos no críticos. Las puntuaciones mejoradas de Core Web Vitals se correlacionaron con clasificaciones de búsqueda más altas, traduciéndose en un valor de búsqueda orgánica estimado de $200,000 por año.

Lo que muestran los datos del mundo real sobre el INP

La brecha de INP entre Móvil y Escritorio

Los datos de CoreDash revelan que el INP móvil (131ms en p75) es 2.8 veces peor que el INP de escritorio (48ms en p75). Esta es la brecha de dispositivos más grande de cualquier métrica Core Web Vital. Los dispositivos móviles tienen procesadores más lentos, menos memoria y mayor latencia de red, todo lo cual contribuye a tiempos de bloqueo del hilo principal más largos y un procesamiento de eventos más lento. En escritorio, el 95.6% de las interacciones logran una puntuación INP "buena", mientras que en móviles esa cifra cae al 88.0%. Los usuarios móviles también experimentan 5 veces más eventos INP "pobres" (9.6% vs 1.9%).

Interacciones de Teclado vs Puntero

Los datos de CoreDash muestran que las interacciones de teclado (75ms p75) son un 56% más lentas que las interacciones de puntero (49ms p75). Los eventos de teclado también tienen significativamente más experiencias pobres: el 7.4% de las interacciones de teclado resultan en un INP pobre, en comparación con solo el 1.4% para las interacciones de puntero. Es probable que esta brecha se deba a que los eventos de teclado, especialmente en campos de formulario, desencadenan un procesamiento más complejo como validación de entrada, sugerencias de autocompletado y actualizaciones de estado.

Interacciones Durante la Carga vs Post-Carga

Las interacciones que ocurren durante la carga de la página tienen un INP dramáticamente más alto que aquellas después de que la página se ha cargado completamente. Los datos de CoreDash muestran que las interacciones durante la fase de "carga" (loading) tienen un INP p75 de 132ms, en comparación con solo 50ms para las interacciones post-carga. Esa es una diferencia de 2.6 veces. Incluso las interacciones durante la fase "dom-content-loaded" (75ms) muestran un INP elevado porque los scripts asíncronos y los sub-recursos todavía se están procesando. Estos datos respaldan firmemente la recomendación de diferir JavaScript no crítico para reducir la contención del hilo principal durante el inicio de la página.

Tasas de Aprobación Globales de INP

Según el HTTP Archive Web Almanac 2024, el 74% de todas las páginas móviles logran una puntuación INP "buena" (frente al 55% en 2022). Sin embargo, solo el 53% de los 1,000 sitios web más visitados aprueban el INP. Los sitios web de alto tráfico tienden a tener JavaScript más complejo, más scripts de terceros y estructuras DOM más intrincadas, todo lo cual contribuye a una peor capacidad de respuesta. En escritorio, el 97% de las páginas logran buenas puntuaciones INP, destacando la enorme brecha de rendimiento entre móvil y escritorio. La mediana de Total Blocking Time en pruebas de laboratorio es de 67ms en escritorio pero 1,209ms en móvil.

Preguntas Frecuentes

Profundizaciones Relacionadas

Esta página central cubre los fundamentos de Interaction to Next Paint. Para obtener orientación detallada sobre aspectos específicos de la optimización de INP, explora estos artículos dedicados:

• <strong>Encontrar y Corregir Problemas de INP</strong>: Una metodología de diagnóstico paso a paso utilizando Search Console, datos RUM y Chrome DevTools para identificar exactamente qué interacciones están causando tus peores puntuaciones de INP.
• <strong>Retardo de Entrada (Input Delay) de INP</strong>: Profundización en la primera fase del INP. Aprende cómo las tareas largas en el hilo principal bloquean el procesamiento de eventos y cómo minimizar el retardo de entrada con programación de tareas, code splitting y web workers.
• <strong>Tiempo de Procesamiento de INP</strong>: Profundización en la segunda fase del INP. Aprende cómo optimizar los callbacks de los manejadores de eventos, priorizar código crítico, diferir trabajo no esencial y usar características de concurrencia de React para reducir el tiempo de procesamiento.
• <strong>Retardo de Presentación de INP</strong>: Profundización en la tercera fase del INP. Aprende cómo el tamaño del DOM, el layout thrashing y el renderizado del lado del cliente contribuyen a actualizaciones visuales lentas y cómo reducir el retardo de presentación.

También puedes encontrar útiles estas guías de optimización de PageSpeed para mejorar el INP:

• Mejorar INP: Abandona el Desplazamiento JavaScript
• Async vs Defer: Estrategias de Carga de JavaScript
• 14 Métodos para Diferir JavaScript
• Widget de Chat con Core Web Vitals Perfectas
• Corrección: Evita un Tamaño Excesivo del DOM