Encontrar y corregir problemas de Interaction to Next Paint (INP): Una guía paso a paso
Aprenda a identificar y corregir problemas de Interaction to Next Paint utilizando datos RUM, Chrome DevTools y la API LoAF
Encontrar y corregir problemas de Interaction to Next Paint (INP)
Esta página es parte de nuestra serie sobre Interaction to Next Paint (INP). INP mide la capacidad de respuesta de su sitio web rastreando el retraso entre una interacción del usuario y la siguiente actualización visual. Una buena puntuación INP es inferior a 200 milisegundos, mientras que las puntuaciones superiores a 500 milisegundos se califican como deficientes. Si es nuevo en INP, comience con la página central de INP para obtener una visión general completa.
En este artículo explicaremos una metodología completa para identificar problemas de Interaction to Next Paint y luego explicaremos cómo corregirlos. El proceso implica confirmar el problema en Google Search Console, diagnosticar las causas raíz con datos de Real User Monitoring (RUM), replicar las condiciones localmente y aplicar correcciones específicas a cada fase de 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 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!
Table of Contents!
Paso 1: Comprobar el INP en Search Console
El primer paso es confirmar que realmente tiene un problema de INP. Antes de realizar cambios en el código, verifique el problema en Google Search Console para trabajar con datos de campo reales en lugar de suposiciones.
Inicie sesión en su Google Search Console. En el menú de la izquierda haga clic en Core Web Vitals y seleccione Móvil o Escritorio (consejo: la mayoría de las veces los problemas de INP surgen primero en el móvil, así que comience con el móvil).
Aquí verá una descripción general de todos los problemas relacionados con Core Web Vitals que existen actualmente en su sitio. Si uno de estos problemas está relacionado con INP, ha confirmado que hay un problema.
Paso 2: Identificar problemas de Interaction to Next Paint
Google Search Console no le da ninguna información aparte de grupos de URL para averiguar qué está causando los problemas con el Interaction to Next Paint. Así que la mayoría de las veces los desarrolladores simplemente van a ciegas. Empiezan eliminando JavaScript no utilizado (siempre una gran idea) y rompiendo el hilo principal (también una gran idea), pero eso casi nunca soluciona el INP por completo.
Es por eso que, al mejorar el INP, necesitamos saber exactamente qué está pasando. Necesitamos respuestas a cuatro preguntas críticas:
¿Con qué elementos, al interactuar, se causa una mala puntuación INP?
Generalmente, una mala puntuación INP no es causada por un solo elemento sino por una combinación de problemas. Necesitamos
abordarlos uno por uno, comenzando por los peores y avanzando.
¿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 cada página, o ocurren
solo en algunas páginas seleccionadas?
¿Cómo podemos replicar
estas interacciones? Es posible que ya haya descubierto que es
difícil replicar problemas de INP. Es por eso que necesitamos prepararnos para el éxito
imitando las características del dispositivo con una mala puntuación INP.
Configurar el seguimiento RUM
Para responder a todas estas preguntas necesitamos comenzar a rastrear usuarios reales y registrar cualquiera de los problemas que
puedan ocurrir con el Interaction to Next Paint. Hay varias formas de habilitar el seguimiento RUM. La
primera es aprovechando la biblioteca Web Vitals y enviando los resultados a su propio backend de análisis.
La ventaja de este método es que es barato y flexible. La desventaja es que podría suponer mucho
trabajo extra.
Una buena alternativa para enviar sus datos de Core Web Vitals a su propio backend es usar una de las muchas herramientas RUM que existen. Hemos desarrollado CoreDash solo para estos casos de uso. CoreDash es una herramienta RUM de bajo costo, rápida y efectiva que hace el trabajo. Por supuesto, hay muchas soluciones RUM y también harán el trabajo (aunque a un precio más alto).
Encontrar interacciones lentas por elemento que causan un alto INP
Lo primero que hay que hacer es encontrar las interacciones más lentas que causan las peores puntuaciones INP. Liste sus páginas por "Métrica INP por Elementos" en CoreDash y obtendrá sus interacciones más lentas. Haga clic en la primera línea para filtrar sus métricas por estas interacciones.
Encontrar cuándo ocurren las interacciones INP malas
A continuación, ordene las URL filtradas por estado de carga. Esto le 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 subrecursos 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úe haciendo clic en el estado de carga con el mayor impacto para crear otro filtro.
Encontrar URL responsables de puntuaciones INP altas
Finalmente, cuando hemos filtrado los elementos con la interacción más lenta y el estado de carga correcto, vamos a echar un vistazo a las URL donde el INP es peor. En este caso, esto sucede claramente en un conjunto específico de páginas.
Encontrar características del dispositivo
Cuando hemos identificado interacciones lentas, estado de carga y URL que causan un alto Interaction to Next Paint, vamos a echar un vistazo a qué tipos de visitantes causan las peores puntuaciones INP. Buscaríamos Memoria del Dispositivo, Ancho de Banda, Tamaño de pantalla y otras características de hardware. Una vez que hemos identificado estas características podemos pasar a replicar y registrar el problema.
Uso de la API Long Animation Frames (LoAF) para diagnósticos INP
La API Long Animation Frames (LoAF) proporciona datos de atribución granulares que le ayudan a identificar exactamente qué scripts y funciones son responsables de las interacciones lentas. A diferencia de la antigua API Long Tasks, LoAF le da URL de scripts, nombres de funciones y desgloses de tiempo por fotograma. Esto lo convierte en una herramienta invaluable para la depuración de INP, especialmente cuando se combina con datos RUM de una herramienta como CoreDash.
Utilice el siguiente código para recopilar entradas LoAF para interacciones que superen un umbral. Este observador captura la atribución del script, la duración y el tiempo de bloqueo para cada fotograma de animación largo:
// Observar Long Animation Frames para atribución INP
const observer = new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
// Solo registrar fotogramas de más de 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. La matriz scripts le dice el archivo fuente exacto y el nombre de la función, mientras que renderStart y styleAndLayoutStart le ayudan a separar el tiempo de procesamiento del retraso de presentación. Para una discusión más profunda sobre cómo la carga de JavaScript async vs defer afecta estos tiempos, consulte nuestra guía dedicada.
Paso 3: Replicar y depurar interacciones que causan una puntuación INP alta
Una vez que tenemos toda la información que necesitamos, podemos empezar a profundizar en los problemas subyacentes del Interaction to Next Paint.
Prepárese para el éxito: replique las circunstancias fallidas del INP
Lo siguiente que debemos hacer es intentar recrear el INP fallido. Hacemos esto imitando las circunstancias donde el INP podría estar fallando.
Use el Panel de Rendimiento de Chrome: Abra las herramientas de desarrollador de Chrome (Ctrl+Shift+I) y seleccione el
panel de rendimiento. En la barra superior puede seleccionar el Throttle de CPU (acelérelo a una desaceleración de 4x para
emular un dispositivo móvil normal), el Throttle de Red (seleccione el preajuste 3G rápido para imitar su
dispositivo móvil promedio) y configure la concurrencia de hardware a 4 u 8 para imitar su dispositivo móvil promedio.
Para cargar Chrome con menos memoria disponible (aunque bajar la configuración de red y CPU a menudo hará el trabajo) inicie Chrome en un contenedor Docker y asigne menos memoria.
Recargue la página, interactúe y compruebe el INP con el visualizador Core Web Vitals
El siguiente paso para encontrar la causa de las malas puntuaciones INP es simular las condiciones y confirmar
que las puntuaciones INP son realmente tan malas como se informó.
Recargue la página y haga clic en el elemento correcto en el momento correcto
Depurar el INP con una traza de rendimiento
Este es el momento para el que se ha estado preparando en los pasos anteriores. Es hora de averiguar por qué una cierta interacción está causando la mala puntuación de Interaction to Next Paint.
Abra la Consola de Desarrollador de Chrome (Ctrl+Shift+I), navegue al panel de Rendimiento y esta vez haga clic en el icono de Flecha Circular para recargar la página y comenzar a grabar (o use el atajo Ctrl+Shift+E). Mientras la grabación se está ejecutando, interactúe con el elemento que causa el mal INP. Después de unos segundos, detenga la grabación y examine la línea de tiempo. Busque el evento de interacción en la pista "Interactions", luego inspeccione las tareas correspondientes en la pista "Main" para ver exactamente qué código se está ejecutando durante cada fase.
Lectura de la traza de rendimiento
En el panel de Rendimiento de Chrome, la interacción aparecerá como una barra de color en la pista "Interactions". Haga clic en ella para ver la duración total de INP y su desglose. Abajo, en la pista "Main", puede ver las tareas individuales que se ejecutaron durante la interacción. Preste atención a:
- Tareas antes del controlador de eventos: estas contribuyen al retraso de entrada
- El propio controlador de eventos: este es el tiempo de procesamiento
- Trabajo de renderizado después de que se completa el controlador: este es el retraso de presentación
Compare estos hallazgos con sus datos LoAF para confirmar que los scripts identificados en la traza coinciden con los datos de atribución de su herramienta RUM. Este también es un buen momento para verificar si algún controlador de desplazamiento de JavaScript está contribuyendo al problema.
Paso 4: Corregir problemas de INP
Ahora estamos en un punto en el que sabemos qué interacción está causando nuestro mal INP y hemos analizado exactamente qué está pasando durante esta interacción lenta. Esto significa que es hora de empezar a corregir el Interaction to Next Paint. El Interaction to Next Paint se puede desglosar en 3 fases: retraso de entrada, tiempo de procesamiento y retraso de presentación.
Cada fase del Interaction to Next Paint debe tratarse de manera diferente. A continuación se presenta un resumen de las estrategias más impactantes para cada fase. Para obtener guías de optimización completas, siga los enlaces a las páginas dedicadas.
Minimizar el retraso de entrada:
El retraso de entrada es el tiempo entre la interacción con la página y cuando la devolución de llamada (callback) del evento comienza a ejecutarse. Si bien siempre hay algún retraso de entrada (incluso los navegadores necesitan tiempo para programar las devoluciones de llamada), hay varias cosas a considerar:
- Evite tareas largas. Siempre que se ejecuta una tarea, bloqueará el hilo principal y dejará las devoluciones de llamada de eventos esperando. Esto es especialmente importante al optimizar clics tempranos (ya que la mayoría de los scripts se ejecutarán en ese momento). Para estrategias para reducir el bloqueo de JavaScript, consulte nuestra guía sobre JavaScript async vs defer.
- Tenga cuidado al crear nuevas tareas. Por ejemplo, tareas recurrentes a través de
setTimeout()o tareas que probablemente ocurrirán antes del evento INP como devoluciones de llamada en el eventomouseover. - Mida y evalúe 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 más tarde, cualquier interacción con el elemento no activará una actualización de diseño inmediata. O bien priorice la funcionalidad o oculte/desactive el elemento antes de que funcione correctamente.
- Utilice 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 retraso de entrada INP.
- Cargue scripts de terceros "agradables de tener" durante el tiempo de inactividad del navegador. Algunos scripts son más críticos que otros. Tiene sentido priorizar estos scripts y cargar scripts menos importantes durante el tiempo de inactividad del navegador. Por ejemplo, un script de chat. Consulte nuestra guía sobre 14 métodos para diferir JavaScript para técnicas prácticas.
Minimizar el tiempo de procesamiento
- Elimine 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 que aún consume tiempo de CPU. Esta es, con mucho, la forma más fácil de mejorar inmediatamente el INP.
- Difiera el código que no necesita ejecutarse antes del siguiente "paint". Divida el código en código crítico que debe ejecutarse antes del INP y código no crítico (por ejemplo, envío de análisis) y prográmelo después del evento "paint" con el método
requestIdleCallback(). - Optimice el código que debe ejecutarse antes del "paint". Revise su código y reescriba las partes lentas o ineficaces.
- Proporcione retroalimentación inmediata. En tareas complicadas o posiblemente lentas, proporcione retroalimentación inmediata antes de ejecutar el código principal.
Minimizar el retraso de presentación
- Mantenga 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. Lea más sobre cómo solucionar el tamaño excesivo del DOM.
- Utilice content-visibility para renderizar perezosamente el contenido fuera de pantalla. Content-visibility acelerará el renderizado de partes visibles de la página retrasando el renderizado de contenido fuera de pantalla y renderizando ese contenido fuera de pantalla justo a tiempo.
Solución rápida: ceder al hilo principal con scheduler.yield()
Una de las técnicas más efectivas para mejorar INP en las tres fases es ceder al hilo principal entre trabajo crítico y no crítico. La API scheduler.yield() proporciona una forma limpia de hacer esto. Aquí hay una función auxiliar reutilizable con un respaldo para navegadores que aún no admiten 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);
});
}
// Uso en un controlador de eventos
async function handleButtonClick() {
// Trabajo crítico: actualizar la UI
updateVisualFeedback();
// Ceder para dejar que el navegador pinte
await yieldToMain();
// Trabajo no crítico: análisis, registro
sendAnalyticsEvent('button_click');
logInteraction();
}
Profundización en cada fase de INP
Ahora que sabe cómo identificar y corregir problemas de INP, explore cada fase en detalle:
- Retraso de entrada: Aprenda a minimizar el tiempo entre la interacción del usuario y el inicio del procesamiento del evento. El retraso de entrada representa aproximadamente el 18% del tiempo total de INP.
- Tiempo de procesamiento: Optimice la ejecución del controlador de eventos que representa aproximadamente el 40% del tiempo total de INP.
- Retraso de presentación: Reduzca el trabajo de renderizado y pintura que representa aproximadamente el 42% del tiempo total de INP.
Para estrategias adicionales que abarcan las tres fases, consulte nuestras guías sobre mejorar INP abandonando el desplazamiento de JavaScript y elegir async vs defer para su JavaScript.
The RUM tool I built for my own clients.
CoreDash is what I use to audit enterprise platforms. Under 1KB tracking script, EU hosted, no consent banner. AI with MCP support built in. The same tool, available to everyone.
Create Free Account
