Encuentra y corrige problemas de Interaction to Next Paint (INP): guía paso a paso
Aprende a identificar y corregir problemas de Interaction to Next Paint usando datos RUM, Chrome DevTools y la API LoAF
Encuentra y corrige problemas de Interaction to Next Paint (INP)
Esta página forma parte de nuestra serie sobre Interaction to Next Paint (INP). INP mide la capacidad de respuesta de tu sitio web rastreando el tiempo entre una interacción del usuario y la siguiente actualización visual. Una buena puntuación de INP es inferior a 200 milisegundos, mientras que las puntuaciones superiores a 500 milisegundos se consideran deficientes. Si eres nuevo en INP, comienza con la página principal de INP para obtener una visión completa.
Según el Web Almanac 2025, el 23% de los orígenes móviles aún no pasan el INP. Si tu sitio es uno de ellos, este es el proceso: confirma el problema en Search Console, diagnostica las causas raíz con datos de Real User Monitoring (RUM), replica localmente y aplica correcciones específicas a cada fase del INP.
CONSEJO INP: la mayoría de las veces el INP será mucho peor
cuando un usuario interactúa con la página durante la fase de inicio de la
carga de la página. Por eso, al depurar el INP,
tiene sentido registrar todas las interacciones así como el estado de carga de la página.
Table of Contents!
Paso 1: Comprueba el INP en Search Console
El primer paso es confirmar que realmente tienes un problema de INP. Antes de hacer cualquier cambio en el código, verifica el problema en Google Search Console para trabajar con datos reales de campo en lugar de suposiciones.
Inicia sesión en tu Google Search Console. En el menú izquierdo haz clic en Core Web Vitals y selecciona Móvil o Escritorio (consejo: la mayoría de las veces los problemas de INP aparecen primero en móvil, así que empieza por móvil).
Aquí verás un resumen de todos los problemas relacionados con Core Web Vitals que hay actualmente en tu sitio. Si uno de estos problemas está relacionado con INP, has confirmado que hay un problema.
Paso 2: Identifica los problemas de Interaction to Next Paint
Google Search Console no te proporciona más información aparte de grupos de URL para descubrir qué está causando los problemas con Interaction to Next Paint. Por eso, la mayoría de las veces los desarrolladores van a ciegas. Empiezan eliminando JavaScript no utilizado (siempre una gran idea) y dividiendo el hilo principal (también una gran idea), pero eso rara vez corrige el INP por completo.
Por eso, al mejorar el INP, necesitamos saber exactamente qué está pasando. Necesitamos respuestas a cuatro preguntas críticas:
¿Qué elementos, al interactuar con ellos, causan una mala puntuación de INP?
Normalmente una mala puntuación de INP no se debe a un solo elemento sino a una combinación de problemas. Necesitamos
abordarlos uno por uno, empezando por los peores y avanzando hacia
arriba.
¿Cuándo ocurren estas interacciones? ¿Ocurren
durante la fase de inicio de
la carga de la página, o ocurren incluso cuando la página principal se ha cargado completamente?
¿Dónde ocurren
estas interacciones? ¿Ocurren en todas las páginas, o solo
en unas pocas páginas seleccionadas?
¿Cómo podemos replicar
estas interacciones? Puede que ya hayas descubierto que es
difícil replicar problemas de INP. Por eso necesitamos prepararnos para el éxito
imitando las características del dispositivo con una mala puntuación de INP.
Configura el seguimiento RUM
Para responder a todas estas preguntas necesitamos empezar a rastrear usuarios reales y registrar cualquiera de los problemas que
puedan ocurrir con Interaction to Next Paint. Hay varias formas de habilitar el seguimiento RUM. La
primera es usando la biblioteca Web Vitals y enviando los resultados a tu propio backend de analítica.
La ventaja de este método es que es económico y flexible. La desventaja es que puede suponer mucho
trabajo extra.
Una buena alternativa a enviar tus datos de Core Web Vitals a tu propio backend es usar una de las muchas herramientas RUM disponibles. Hemos desarrollado CoreDash precisamente para estos casos de uso. CoreDash es una herramienta RUM de bajo coste, rápida y eficaz que hace el trabajo. Por supuesto hay muchas soluciones RUM disponibles y también harán el trabajo (aunque a un precio más alto).
Encuentra interacciones lentas por elemento que causan un INP alto
Comienza encontrando las interacciones más lentas que causan las peores puntuaciones de INP. Ordena tus páginas por "INP metric by Elements" en CoreDash y obtendrás tus interacciones más lentas. Haz clic en la primera línea para filtrar tus métricas por estas interacciones.
Encuentra cuándo ocurren las interacciones con mal INP
A continuación, ordena las URLs filtradas por estado de carga. Esto te dará más información sobre la causa raíz del INP. En este caso el INP alto ocurre cuando el contenido DOM se ha cargado. Esto significa que los scripts se han analizado pero los scripts asíncronos y los sub-recursos de la página aún no se han cargado. En este caso el INP es causado por clics tempranos cuando la carga de la página no ha terminado completamente.
Continúa haciendo clic en el estado de carga con mayor impacto para crear otro filtro.
Encuentra las URLs responsables de puntuaciones de INP altas
Finalmente, cuando hayamos filtrado por los elementos con la interacción más lenta y el estado de carga correcto, vamos a examinar las URLs donde el INP está en su peor momento. En este caso esto ocurre claramente en un conjunto específico de páginas.
Encuentra las características del dispositivo
Cuando hayamos identificado las interacciones lentas, el estado de carga y las URLs que causan un alto Interaction to Next Paint, vamos a examinar qué tipos de visitantes causan las peores puntuaciones de INP. Examinaríamos la memoria del dispositivo, el ancho de banda, el tamaño de pantalla y otras características de hardware. Una vez que hayamos identificado estas características podemos pasar a replicar y registrar el problema.
Uso de la API Long Animation Frames (LoAF) para diagnósticos de INP
La API Long Animation Frames (LoAF) te indica exactamente qué scripts y funciones causan interacciones lentas. A diferencia de la antigua API Long Tasks, LoAF te proporciona URLs de scripts, nombres de funciones y desgloses de tiempo por frame. Es especialmente útil cuando se combina con datos RUM de una herramienta como CoreDash.
Este observer recopila entradas LoAF para frames de más de 50ms, capturando la atribución del script, la duración y el tiempo de bloqueo:
// Observe Long Animation Frames for INP attribution
const observer = new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
// Only log frames longer than 50ms
if (entry.duration > 50) {
console.log('Long Animation Frame:', {
duration: entry.duration,
blockingDuration: entry.blockingDuration,
renderStart: entry.renderStart,
styleAndLayoutStart: entry.styleAndLayoutStart,
scripts: entry.scripts.map(script => ({
sourceURL: script.sourceURL,
sourceFunctionName: script.sourceFunctionName,
invokerType: script.invokerType,
invoker: script.invoker,
duration: script.duration
}))
});
}
}
});
observer.observe({ type: 'long-animation-frame', buffered: true });
La API LoAF revela qué scripts contribuyen a cada fase del INP. El array scripts te indica el archivo fuente exacto y el nombre de la función, mientras que renderStart y styleAndLayoutStart te ayudan a separar el tiempo de procesamiento del presentation delay. LoAF actualmente solo funciona en Chromium (Chrome 123+), por lo que para depuración en Firefox y Safari, confía en el panel de rendimiento y los datos RUM. Para más información sobre cómo la carga de JavaScript async vs defer afecta estos tiempos, consulta nuestra guía dedicada.
Paso 3: Replica y depura las interacciones que causan una puntuación de INP alta
Con estos datos en mano, podemos empezar a corregir las causas raíz.
Prepárate para el éxito: replica las circunstancias donde falla el INP
Lo siguiente que debemos hacer es intentar recrear el INP fallido. Lo hacemos imitando las circunstancias donde el INP podría estar fallando.
Usa el panel de rendimiento de Chrome: Abre las herramientas de desarrollador de Chrome (Ctrl+Shift+I) y selecciona el
panel de rendimiento. En la barra superior puedes seleccionar la limitación de CPU (limítala a 4x de ralentización para
emular un dispositivo móvil normal), la limitación de red (selecciona el preset de 3G rápido para imitar tu
dispositivo móvil promedio), y establece la concurrencia de hardware en 4 u 8 para imitar tu dispositivo móvil promedio.
Para cargar Chrome con menos memoria disponible (aunque reducir la configuración de red y CPU a menudo será suficiente) inicia Chrome en un contenedor Docker y asigna menos memoria.
Recarga la página, interactúa y comprueba el INP con el visualizador de Core Web Vitals
Ahora simula las condiciones y confirma que las puntuaciones de INP coinciden con lo que reportaron tus datos RUM.
Recarga la página y haz clic en el elemento correcto en el momento correcto
Depura el INP con un trace de rendimiento
Este es el momento para el que te has estado preparando en los pasos anteriores. Es hora de descubrir por qué una determinada interacción está causando la mala puntuación de Interaction to Next Paint.
Abre la Consola de Desarrollador de Chrome (Ctrl+Shift+I), navega al panel de Rendimiento y esta vez haz clic en el icono de la Flecha Circular para recargar la página y empezar a grabar (o usa el atajo Ctrl+Shift+E). Mientras la grabación está en curso, interactúa con el elemento que causa el mal INP. Después de unos segundos, detén la grabación y examina la línea de tiempo. Busca el evento de interacción en la pista "Interactions", luego inspecciona las tareas correspondientes en la pista "Main" para ver exactamente qué código se está ejecutando durante cada fase.
Lectura del trace de rendimiento
En el panel de Rendimiento de Chrome, la interacción aparecerá como una barra de color en la pista "Interactions". Haz clic en ella para ver la duración total del INP y su desglose. Debajo, en la pista "Main", puedes ver las tareas individuales que se ejecutaron durante la interacción. Presta atención a:
- Tareas antes del manejador de eventos: estas contribuyen al input delay
- El propio manejador de eventos: este es el tiempo de procesamiento
- Trabajo de renderizado después de que el manejador termina: este es el presentation delay
Compara estos hallazgos con tus datos LoAF para confirmar que los scripts identificados en el trace coinciden con los datos de atribución de tu herramienta RUM. Este también es un buen momento para comprobar si algún manejador de scroll en JavaScript está contribuyendo al problema.
Paso 4: Corrige los problemas de INP
Sabes qué interacción es lenta y por qué. Es hora de corregirla. Interaction to Next Paint se puede desglosar en 3 fases: input delay, tiempo de procesamiento y presentation delay.
Cada fase necesita un enfoque diferente. Aquí tienes un resumen. Sigue los enlaces para las guías de optimización completas.
Minimiza el Input Delay:
El input delay es el tiempo entre la interacción con la página y cuando el callback del evento comienza a ejecutarse. Aunque algo de input delay es inevitable (los navegadores necesitan tiempo para programar los callbacks), puedes minimizarlo:
- Evita las tareas largas. Cada vez que se ejecuta una tarea, bloquea el hilo principal y deja los callbacks de eventos esperando. Esto es especialmente importante al optimizar los clics tempranos (ya que la mayoría de los scripts se estarán ejecutando en ese momento). Para estrategias para reducir el bloqueo de JavaScript, consulta nuestra guía sobre JavaScript async vs defer.
- Ten cuidado al crear nuevas tareas. Por ejemplo, tareas recurrentes mediante
setTimeout()o tareas que probablemente ocurrirán antes del evento INP como callbacks en el eventomouseover. - Mide y evalúa la interacción temprana. Cuando un elemento interactivo se presenta temprano (por ejemplo un elemento de búsqueda del sitio) y está controlado por JavaScript que se carga después, cualquier interacción con el elemento no activará una actualización de diseño inmediata. O prioriza la funcionalidad o oculta/deshabilita el elemento antes de que funcione correctamente.
- Usa web workers para ejecutar JavaScript fuera del hilo principal del navegador. Los web workers permiten que los scripts se ejecuten fuera del hilo principal. Esto evitará que el hilo principal se bloquee y cause problemas de input delay en el INP.
- Carga scripts de terceros no esenciales durante el tiempo de inactividad del navegador. Algunos scripts son más críticos que otros. Tiene sentido priorizar estos scripts y cargar los menos importantes durante el tiempo de inactividad del navegador. Por ejemplo, un script de chat. Consulta nuestra guía sobre 14 métodos para diferir JavaScript para técnicas prácticas.
Minimiza el tiempo de procesamiento
- Elimina código innecesario. El código innecesario es código antiguo que aún se ejecuta o código nuevo que no se necesita en esta página específica pero aún consume tiempo de CPU. Esta es, con diferencia, la forma más fácil de mejorar inmediatamente el INP.
- Difiere el código que no necesita ejecutarse antes del siguiente paint. Separa el código en código crítico que debe ejecutarse antes del INP y código no crítico (por ejemplo enviar analíticas) y prográmalo después del evento de paint con el método
requestIdleCallback(). - Optimiza el código que debe ejecutarse antes del paint. Revisa tu código y reescribe las partes lentas o ineficientes.
- Proporciona retroalimentación inmediata. En tareas complicadas o potencialmente lentas, proporciona retroalimentación inmediata antes de ejecutar el código principal.
Minimiza el Presentation Delay
- Mantén el DOM pequeño y simple. Será mucho más fácil para un navegador renderizar una página con pocos y simples elementos DOM no anidados (nodos HTML) que renderizar una página con muchos nodos DOM anidados. Lee más sobre corregir el tamaño excesivo del DOM.
- Usa content-visibility para renderizar de forma diferida el contenido fuera de pantalla. Content-visibility acelerará el renderizado de las partes visibles de la página al retrasar el renderizado del contenido fuera de pantalla y renderizarlo justo a tiempo.
Solución rápida: yield al hilo principal con scheduler.yield()
Hacer yield al hilo principal entre trabajo crítico y no crítico mejora las tres fases del INP a la vez. La API scheduler.yield() proporciona una forma limpia de hacerlo. Aquí tienes una función auxiliar reutilizable con un fallback para navegadores que aún no soportan la API:
async function yieldToMain() {
if ('scheduler' in window && 'yield' in window.scheduler) {
return await window.scheduler.yield();
}
return new Promise((resolve) => {
setTimeout(resolve, 0);
});
}
// Usage in an event handler
async function handleButtonClick() {
// Critical work: update the UI
updateVisualFeedback();
// Yield to let the browser paint
await yieldToMain();
// Non-critical work: analytics, logging
sendAnalyticsEvent('button_click');
logInteraction();
}
Cada fase del INP en detalle
Cada fase tiene sus propias estrategias de optimización:
- Input Delay: Aprende cómo minimizar el tiempo entre la interacción del usuario y el inicio del procesamiento del evento. El input delay suele ser la más pequeña de las tres fases, pero aumenta drásticamente durante el inicio de la página cuando el hilo principal está ocupado con la ejecución de scripts.
- </b>Tiempo de procesamiento: Optimiza el código del manejador de eventos que se ejecuta durante la interacción. En la mayoría de las páginas, aquí es donde la mayor parte de tu esfuerzo de optimización da resultados.
- Presentation Delay: Reduce el trabajo de renderizado y pintado que sigue al procesamiento del evento. En páginas complejas con DOMs grandes, esta suele ser la fase más larga.
Para estrategias adicionales que abarcan las tres fases, consulta nuestras guías sobre mejorar el INP eliminando el scroll con JavaScript y elegir async vs defer para tu JavaScript.
Performance degrades unless you guard it.
I do not just fix the metrics. I set up the monitoring, the budgets, and the processes so your team keeps them green after I leave.
Start the Engagement
