Una puntuación INP roja no representa un problema de rendimiento hasta que se identifica cuál de las tres fases está consumiendo el tiempo. La mayoría de los equipos omiten este paso, compran un complemento de almacenamiento en caché o posponen la ejecución de un script, y observan cómo el percentil 75 se mantiene sin cambios. Esta guía es el árbol de decisiones que utilizamos: siete ramas que conducen desde un número de error en el Informe de UX de Chrome hasta el controlador, script o etiqueta de terceros específico responsable, con un umbral establecido en cada bifurcación. Está dirigida a líderes de front-end y equipos de crecimiento que gestionan tanto el número de conversiones como la puntuación de Lighthouse.
La brecha es real. En el Web Almanac 2025, El 77% de los orígenes móviles tenían un buen INP. frente al 97% en escritorio, y solo El 48% de los orígenes móviles superaron las tres métricas de Core Web Vitals. (Archivo HTTP). Lo que aún falla en los dispositivos móviles es principalmente la latencia de interacción, y en su mayoría es diagnosticable.
Qué mide INP y qué ignora discretamente
Interaction to Next Paint informa una latencia de interacción por visita de página, en el Percentil 75 a través de tu origen. Bueno es 200 ms o menos, necesita mejorar es superior a 200 ms y hasta 500 ms, deficiente es superior a 500 ms (web.dev). Tres aspectos de esa definición cambian la forma de depurarla:
- Solo cuentan los clics, toques y pulsaciones de teclas. Pasar el ratón por encima, hacer zoom y El desplazamiento no se mide, por lo que un desplazamiento irregular puede hacer que una página parezca rota mientras que INP permanece en verde.
- En páginas con muchas interacciones, INP ignora una interacción más alta por cada 50Por lo tanto, una interacción catastrófica poco frecuente puede ocultarse en una página con mucha interacción y salir a la luz en una con poca interacción.
- Cada interacción se divide en retraso de entrada (antes de que tus cuidadores corran), duración del procesamiento (tus manejadores corriendo) y retraso en la presentación (después de sus manipuladores, antes de que se pinten los cuadros). Estos tres no tienen casi nada en común como problemas de ingeniería (web.dev).
Ese último punto resume todo el método. No estás depurando "INP". Estás depurando una de las tres fases, y cada una tiene una solución diferente.
Rama 0: confirme que el número es real antes de tocar el código.
Abre PageSpeed Insights y lee la sección de campos, no la puntuación de laboratorio. Las herramientas de laboratorio no pueden medir el INP, ya que este requiere que un usuario real pulse algo. Si el origen no tiene datos de campo, tienes un problema de tráfico, no de rendimiento, y ninguna de las siguientes opciones aplica todavía. Luego, analiza los datos de dispositivos móviles y de escritorio por separado; a nivel mundial, la diferencia fue de 20 puntos porcentuales en 2025. Si la versión móvil está en rojo y la de escritorio en verde, deja de realizar pruebas en tu portátil.
Rama 1: ¿La interacción lenta ocurre durante la carga o después de ella?
Instrumentar el campo con el web-vitals Creación de atribución. Cuatro líneas te dan los datos:
import {onINP} from 'web-vitals/attribution';
onINP(({value, rating, attribution}) => {
navigator.sendBeacon('/rum', JSON.stringify({value, rating, attribution}));
});
Leer attribution.loadState primero. Si la mayoría de las malas interacciones conllevan un estado de carga de carga or dom-interactivoLos usuarios están tocando mientras tus scripts aún se están evaluando: un problema de entrega, solucionado en el paquete y el administrador de etiquetas, no en el controlador. Si las interacciones erróneas se extienden a páginas completamente cargadas, ve a la Rama 2.
Rama 2: ¿a qué subparte le corresponde el tiempo?
Log inputDelay, processingDuration y presentationDelay para cada muestra. Nuestra regla de trabajo: una subparte posee la interacción cuando da cuenta de más del 50% del total de INP. Si ninguno logra superar el 50%, considérelo primero como un caso de retardo de entrada; la congestión difusa del hilo principal suele ser lo que empeora los otros dos.
| Subparte dominante | Investiga primero | Causa típica | Primera solución |
|---|---|---|---|
| Retardo de entrada > 50% | longAnimationFrameEntries tipo de invocador | Evaluación del script durante la carga; temporizadores; una interacción previa aún en ejecución | Aplazar o eliminar scripts de terceros; dividir paquetes; mover el trabajo periódico a un hilo aparte. |
| Duración del procesamiento > 50% | longestScript y totalScriptDuration | Un controlador de eventos costoso; una actualización de estado que desencadena una renderización completa. | Ceder el control dentro del manejador; mover el trabajo no visual después del siguiente pintado. |
| Retraso en la presentación > 50% | totalStyleAndLayoutDuration | DOM grande; diseño desordenado; pesado requestAnimationFrame Trabaja | Reducir el tamaño del DOM; aplicar content-visibility; lecturas y escrituras por lotes |
| Ninguna subparte > 50% | todo lo anterior | Congestión general del hilo principal | Tratar como retardo de entrada, volver a medir y luego volver a ramificar. |
Rama 3: nombre el script
La compilación de atribución incluye entradas de fotogramas de animación larga junto a cada muestra INP. attribution.longestScript te proporciona el invocador, la función y el archivo fuente del peor script en la interacción; totalScriptDuration Agrega todo lo que supera los 5 ms. Aquí es donde un vago "React es lento" se convierte en una ruta de archivo. Comprueba el tipo de invocador: classic-script or module-script señala la evaluación del tiempo de carga, mientras que user-callback or event-listener apunta a algo que se ejecuta después de la carga: un observador, un temporizador, un oyente de análisis (web.dev).
Rama 4: ¿Es suya o de un tercero?
Ordena la atribución de tu script por origen. Los gestores de etiquetas, las plataformas de consentimiento, las herramientas de grabación de sesiones y los widgets de chat instalan detectores globales que se ejecutan antes que el tuyo con cada clic. Si un origen de terceros aparece en más de una cuarta parte de tus peores muestras, la solución es comercial antes que técnica: reduce el alcance de la etiqueta, cárgala al interactuar o muévela al servidor. No modifiques tu controlador para recuperar los 40 ms que consume un widget de chat de todos modos.
Rama 5: reprodúzcalo en el laboratorio y luego corrija el marco.
Toma el selector de attribution.interactionTarget, abre las herramientas para desarrolladores de Chrome con la limitación de CPU ajustada a tu combinación de dispositivos de campo y graba la interacción. Busca una tarea sobre 50 ms, el umbral de tarea larga (web.dev), y dividirlo cediendo.
Enviar scheduler.yield() con una alternativa. Chrome y Edge lo admiten desde la versión 129 y Firefox desde la 142, pero Safari no lo hace, ni en ordenadores de escritorio ni en iOS.y MDN lo marca como disponibilidad limitada en lugar de Baseline (DND, Puedo usar). Para una audiencia turca o del Golfo con una gran cuota de mercado de iOS, una setTimeout La opción de reserva no es opcional.
Rama 6: mide el mercado al que realmente vendes.
Los promedios globales de CrUX ocultan el mercado que te paga. El conjunto de datos de CrUX BigQuery publica tablas de países: chrome-ux-report.country_tr.YYYYMM Para Turquía, el mismo patrón para cualquier código de país de dos letras: se actualiza mensualmente, con el factor de forma del dispositivo y el tipo de conexión efectiva como dimensiones (Chrome para desarrolladores). La API pública de CrUX no expone el país, por lo que esta sección solo está disponible en BigQuery.
Compara tu origen con la tabla de países para cada mercado en el que vendes. Un minorista que opera en Turquía, Alemania y los países del Golfo suele encontrar tres distribuciones INP diferentes a partir de un mismo código base, debido a las diferencias en la combinación de dispositivos y las condiciones de la red. Adapta tu código al mercado que genera ingresos, no al que tiene tu oficina.
Rama 7: demuestra que movió algo.
Considera esta solución como un experimento, no como una implementación definitiva. Trendyol, un mercado turco, rastreó un INP móvil de 963 ms a una tarea de 700–900 ms de duración causada por una devolución de llamada de IntersectionObserver dentro de un componente React, aplazó la actualización del estado con scheduler.yield()y redujo el INP del percentil 75 de aproximadamente 1,400 ms a aproximadamente 650 ms durante seis meses. Su prueba A/B mostró un Incremento del 1 % en los clics desde los listados a los detalles del producto por sesión. (web.dev). autobús rojo redujo las interacciones de carga diferida de 870–900 ms a 350–370 ms, mejoró una interacción de entrada de texto en un 72% y reportó una Aumento del 7% en las ventas totales (web.dev).
Nótese la escala correcta: 1%, no 40%. Lo cual nos lleva a una cifra que conviene corregir.
La cifra del 8.4% merece una salvedad.
La cifra más citada en este campo es que una mejora de 0.1 s en la velocidad móvil aumenta la conversión minorista en un 8.4 % y la de viajes en un 10.1 %. Proviene de un estudio real: 55 y Deloitte, encargado por Google, 37 marcas, más de 30 millones de sesiones (web.dev). Pero medía métricas de carga como el tiempo de carga de la página y la latencia del servidor, no INPLos datos abarcan 30 días a finales de 2019; y no hubo grupo de control, por lo que se trata de una correlación observada, no de un efecto causal. Úselo para iniciar una conversación sobre el presupuesto, no para pronosticar el retorno de la inversión de una solución para la latencia de interacción.
[DATOS INTERNOS NECESARIOS: Datos de Switas antes y después de la p75 INP y delta de conversión de un proyecto con un cliente, para reemplazar los estudios de caso públicos con evidencia de primera mano.]
Dónde falla este árbol de decisiones
- Orígenes con poco tráfico. Con datos de campo limitados, el percentil 75 es ruido. Por debajo de aproximadamente 1,000 interacciones por plantilla por semana, realice un análisis en el laboratorio y acepte que no podrá verificar la victoria en CrUX.
- Los usuarios de Safari y Firefox son invisibles. CrUX solo está disponible para Chrome. Si una parte significativa de tus ingresos proviene de iOS Safari, tus datos INP describen una población que no estás midiendo completamente.
- El problema del desplazamiento brusco queda fuera del alcance de este análisis. INP ignora el desplazamiento, por lo que este árbol nunca encontrará el problema en una lista de desplazamiento infinito que se ve fatal pero que da positivo en las pruebas.
- Detecta latencia, no problemas de diseño. Una interacción de 180 ms en un panel de filtros confuso es un problema de UX que este árbol no puede ver.
Preguntas Frecuentes
¿Es INP lo mismo que el retardo de la primera entrada?
No. FID solo medía el retraso antes de que se ejecutaran los manejadores de la primera interacción. INP abarca la latencia total de una interacción representativa a lo largo de la visita, incluyendo la ejecución del manejador y el dibujo posterior.
¿Por qué mi puntuación de Lighthouse parece correcta mientras que la de INP está en rojo?
Lighthouse es una herramienta de laboratorio y no puede medir el INP: no hay ningún usuario real pulsando ningún botón. Indicadores como el Tiempo Total de Bloqueo tienen una correlación débil. Consulta la sección de campos de PageSpeed Insights.
¿Cuánto tardará en aparecer una solución en Crux?
CrUX informa datos en una ventana móvil de 28 días, y las tablas de BigQuery se publican mensualmente. Se espera una señal parcial después de aproximadamente cuatro semanas y una lectura completa después de dos actualizaciones mensuales.
¿Puedo solucionar el problema de INP sin tocar el framework?
A menudo sí. La solución de Trendyol consistió en añadir un yield dentro de una función de devolución de llamada en React 16.9, sin necesidad de actualizar. Aplazar las etiquetas de terceros también es independiente del framework.
¿Afecta un banner de consentimiento a INP?
Puede ocurrir de dos maneras: el propio script del banner compite por el hilo principal durante la carga, y la decisión de consentimiento suele desencadenar una ráfaga de carga de etiquetas inmediatamente después. Mida la primera interacción tras el consentimiento por separado.
¿Necesito un proveedor de RUM o me basta con la biblioteca web-vitals?
La configuración de atribución, junto con un punto final de baliza, es suficiente para ejecutar este árbol. Un proveedor compra retención, segmentación y paneles de control, no mejores datos de atribución.
¿Debo optimizar INP para SEO o para conversión?
Decide apostar por la conversión. Las Core Web Vitals son un indicador de posicionamiento, pero los casos de negocio documentados (1 % en Trendyol, 7 % en redBus) son efectos en la calidad de la interacción que justifican el trabajo por sí solos.
Ejecuta esto en tu propia página de listado.
Toma tu plantilla con mayor tráfico, instrumentala con la compilación de atribución y recorre las ramas 0 a 7 en orden. Si prefieres que el árbol se ejecute con tus propios datos de campo, incluyendo la segmentación por país y el diseño del experimento, nuestra equipo de rendimiento web hace exactamente este compromiso.
Fuentes
- Interacción con el siguiente dibujo (INP) — web.dev
- Optimizar la interacción para el siguiente dibujo — web.dev
- Encuentra interacciones lentas en el campo — web.dev
- Optimizar tareas largas — web.dev
- Rendimiento — Web Almanac 2025, HTTP Archive
- Cómo Trendyol redujo el INP en un 50% — web.dev
- Cómo redBus mejoró el INP y aumentó las ventas en un 7 % — web.dev
- Los milisegundos hacen millones — web.dev / 55 / Deloitte
- CrUX en BigQuery: Chrome para desarrolladores
- Planificador: yield() — MDN
- API del programador: rendimiento - caniuse
- Biblioteca JavaScript web-vitals — GoogleChrome/web-vitals
