INP en móviles: el segundo que separa visita y abandono

El INP en móviles mide algo bastante menos abstracto que una puntuación bonita en PageSpeed: mide cuánto tarda una página en reaccionar después de que una persona toca, pulsa, escribe o intenta hacer algo. No cuánto carga. No cuánto pesa. No si el logo aparece rápido. Eso ya lo miran otras métricas. INP se fija en la respuesta real de la interfaz, en ese instante incómodo en el que el usuario toca un botón y la web se queda pensando, como un camarero que ha oído el pedido pero decide mirar al techo. Google considera que una página ofrece buena experiencia cuando su INP está en 200 milisegundos o menos; entre más de 200 y 500 milisegundos necesita mejorar; por encima de 500 milisegundos entra en terreno malo.

La métrica importa más en móvil porque ahí el margen de paciencia se evapora. La conexión puede bailar, el procesador del dispositivo no siempre es generoso, la pantalla es pequeña, el dedo tapa parte de la interfaz y cada script añadido —anuncios, consent mode, píxeles, chats, mapas, vídeos, pop-ups con alma de plaga bíblica— compite por el mismo hilo principal del navegador. Desde el 12 de marzo de 2024, Interaction to Next Paint sustituyó a First Input Delay como Core Web Vital estable, de modo que la interactividad dejó de medirse solo por el primer toque y empezó a evaluarse de forma más exigente durante toda la vida de la página.

El nuevo termómetro de la paciencia móvil

Durante años, muchos responsables de SEO técnico se acostumbraron a mirar la velocidad web como quien mira el velocímetro de un coche parado. LCP, peso de imágenes, caché, compresión, servidor, CDN. Todo correcto, todo necesario. Pero el usuario no vive la web como una auditoría. Vive la web con el pulgar. Entra, acepta o rechaza cookies, abre el menú, filtra un producto, despliega un acordeón, toca una pestaña, intenta cerrar un interstitial, escribe en el buscador interno. Ahí aparece INP.

La diferencia con FID parece pequeña hasta que se entiende. First Input Delay medía el retraso del primer gesto. INP observa las interacciones de la página y toma como referencia una de las más lentas, con criterio estadístico, para representar la capacidad real de respuesta. Es una métrica menos complaciente, menos de escaparate. Una web podía aprobar FID porque el primer toque respondía razonablemente bien, aunque después el menú se arrastrara como una persiana oxidada. Con INP, esa coartada se estrecha.

Para Google, los Core Web Vitals miden experiencia real de usuario en carga, interactividad y estabilidad visual. En el trío actual, LCP vigila cuándo aparece el contenido principal, CLS controla los saltos visuales e INP se ocupa de la respuesta a la interacción. No son métricas decorativas ni una obsesión de consultor con demasiadas pestañas abiertas: Google recomienda alcanzar buenos Core Web Vitals porque forman parte de lo que sus sistemas buscan premiar en experiencia de página, aunque deja claro que obtener buenos resultados no garantiza por sí solo mejores rankings.

Ahí conviene bajar el tono mesiánico. INP no es una palanca mágica para subir diez posiciones. Tampoco un adorno. Es una señal técnica, una señal de uso y, sobre todo, una alerta de negocio. Si una landing convierte peor en móvil, si un ecommerce pierde pasos en el checkout, si un medio ve caer páginas por sesión cuando despliega módulos de recomendación y publicidad, mirar solo el SEO es mirar el humo y no el fuego.

Por qué el móvil castiga más cada milisegundo

En escritorio, una mala interacción molesta. En móvil, interrumpe. La diferencia es física. El usuario tiene una mano ocupada, camina, viaja, espera el metro, compara precios en una tienda, lee entre notificaciones. La web no ocupa un entorno limpio; pelea contra el mundo. Y cuando una pulsación tarda demasiado en pintar la respuesta, el cerebro no lo interpreta como “hay una tarea JavaScript larga bloqueando el hilo principal”. Lo interpreta como “esto no va”.

La trampa clásica es pensar que una web rápida de carga es automáticamente una web rápida de uso. No siempre. Una página puede mostrar el primer contenido con elegancia y luego bloquearse cuando el usuario intenta interactuar. O puede cargar aparentemente ligera, pero ejecutar una procesión de scripts tras el consentimiento de cookies. Primero todo parece seda. Luego entra la maquinaria: etiquetas de analítica, pruebas A/B, personalización, afiliación, publicidad programática, widgets sociales, recomendaciones, formularios con validaciones pesadas. Pequeños cuchillos. Ninguno parece mortal por separado.

El móvil lo acusa porque dispone de menos capacidad que un portátil moderno, especialmente en gamas medias y bajas. Y el SEO, aunque se analice desde pantallas grandes, ocurre en bolsillos bastante más humildes. Esta es una de las grandes distorsiones del sector: se audita en fibra, Mac caro, Chrome actualizado y café de especialidad; se navega en 4G irregular, Android cansado y batería al 18 %. La realidad siempre tiene menos glamour.

PageSpeed Insights ayuda a ver esa brecha porque informa de la experiencia de página tanto en móvil como en escritorio y combina datos de campo, cuando existen, con diagnósticos de laboratorio. No es un juez absoluto, pero sí una radiografía útil: enseña síntomas, no opera al paciente. Search Console, por su parte, agrupa URL según datos reales de uso en el informe de Core Web Vitals, lo que permite detectar patrones por plantillas, secciones o tipos de página.

El punto delicado está en no confundir la puntuación global de rendimiento con INP. Lighthouse puede dar pistas con Total Blocking Time, tareas largas y coste de JavaScript, pero INP es una métrica de campo: depende de lo que usuarios reales hagan en condiciones reales. Una página puede salir airosa en una prueba puntual y fallar donde duele, en las interacciones cotidianas que la herramienta no ha reproducido.

El segundo invisible que rompe la confianza

Aunque los umbrales de INP se expresan en milisegundos, el daño se percibe de forma humana. Un botón que no responde durante medio segundo no parece “medio segundo”; parece duda. Un menú que se abre tarde no parece “latencia”; parece torpeza. Un campo de formulario que se queda congelado al escribir no parece un problema técnico; parece una web poco fiable.

En contenidos editoriales, el impacto puede ser más silencioso. El lector toca el menú y tarda. Intenta cerrar un módulo intrusivo y tarda. Abre una galería y tarda. La página no se rompe, no da error, no se cae con dramatismo. Simplemente se vuelve pegajosa. Como caminar por un suelo recién fregado. El usuario quizá no formule una queja, pero se va antes, lee menos, vuelve menos. Las métricas de engagement lo cuentan luego con cara de funeral.

En ecommerce, el asunto es todavía más directo. Filtros lentos, variaciones de producto que no reaccionan, carritos con botones remolones, checkouts donde cada toque parece pedir permiso al servidor del Vaticano. Ahí INP deja de ser una métrica técnica y se convierte en fricción comercial. El usuario no abandona porque odie la marca. Abandona porque el camino cruje.

En generación de leads, pasa lo mismo. Formularios con validación excesiva, campos que recalculan demasiado, calendarios de reserva pesados, selectores con librerías enormes para hacer algo que un HTML nativo resolvía con menos teatro. El marketing pide datos; el frontend responde con un laberinto. Luego se culpa al tráfico. A veces el tráfico no era malo. La página era lenta al tacto.

Qué mide INP exactamente y dónde se rompe

INP observa el tiempo que transcurre desde que el usuario inicia una interacción hasta que el navegador puede pintar la siguiente respuesta visual. En esa distancia caben tres tramos principales: el retraso de entrada, el tiempo de procesamiento y el retraso de presentación. Chrome incorporó una lectura más desglosada de estos componentes para ayudar a entender si el problema está antes de ejecutar el código, durante la ejecución o en la pintura final.

El retraso de entrada aparece cuando el navegador está ocupado antes incluso de atender el gesto. El usuario toca, pero el hilo principal sigue atrapado en una tarea anterior: evaluando JavaScript, calculando estilos, ejecutando un script de terceros, digiriendo una hidratación pesada en una aplicación renderizada en cliente. La interacción llama a la puerta; nadie abre.

El tiempo de procesamiento es lo que ocurre cuando la página ya atiende el gesto, pero el código asociado tarda demasiado. Un clic que lanza demasiada lógica, un cambio de pestaña que reconstruye medio DOM, un filtro que recalcula una lista enorme sin pausa, una búsqueda interna que dispara estados, eventos y renderizados como si estuviera quemando confeti. Aquí el problema suele oler a JavaScript. Mucho JavaScript. JavaScript con hambre.

El retraso de presentación llega después: el navegador ha hecho trabajo, pero todavía necesita recalcular estilos, layout o pintura antes de que el usuario vea la respuesta. Es la parte visual del atasco. DOM grande, CSS complejo, cambios de diseño costosos, animaciones mal planteadas, componentes que fuerzan recalculados de layout. La web ya sabe qué debe mostrar, pero tarda en enseñarlo.

Google recomienda reducir tareas largas y evitar que el hilo principal quede bloqueado durante demasiado tiempo, dividiendo trabajos grandes en partes más pequeñas para permitir que el navegador responda antes a las interacciones. Dicho en cristiano: no convertir cada toque en una mudanza.

La culpa rara vez es una sola línea de código

El INP malo suele ser coral. No aparece porque un desarrollador se levantó con ganas de arruinar la mañana. Aparece por acumulación. Una librería “por comodidad”. Un plugin “por si acaso”. Un tag “imprescindible para atribución”. Un script de chat “solo para leads calientes”. Un consentimiento de cookies que carga media feria. Un framework moderno usado como excavadora para plantar una maceta.

En WordPress, el patrón se repite con claridad casi didáctica. Tema pesado, constructor visual, plugins que inyectan recursos en todas las páginas, sliders, formularios, píxeles, embeds, anuncios. El sitio puede seguir funcionando, claro. También un coche con el maletero lleno de ladrillos avanza. La cuestión es cómo acelera cuando le pides respuesta.

En React, Vue, Angular o Next.js, el problema cambia de traje. Hidratación excesiva, bundles grandes, componentes que renderizan más de lo necesario, estados globales mal gobernados, listas sin virtualización, eventos caros. Las aplicaciones modernas pueden ser brillantes, pero también tienen esa tendencia tan de nuestra época: usar una grúa para mover una silla.

Chrome ya había señalado, al analizar INP en frameworks modernos, que el exceso de JavaScript, el mal code-splitting, las tareas largas y los scripts de terceros pueden empeorar de forma notable la respuesta de las páginas. La solución no pasa por odiar los frameworks, sino por usarlos con sentido: dividir código, cargar progresivamente, retrasar lo no esencial y cortar tareas largas antes de que conviertan el hilo principal en una rotonda sin salida.

Cómo diagnosticar INP sin perseguir fantasmas

La primera regla para trabajar el INP en móviles es separar datos de laboratorio y datos de campo. Los datos de laboratorio sirven para reproducir, aislar y arreglar. Los datos de campo sirven para priorizar. Sin datos reales, el equipo puede optimizar la interacción equivocada con una precisión admirable y una utilidad discutible. Muy de la casa.

Search Console ofrece una vista agrupada del problema. No dice “este botón concreto te está matando”, pero sí indica si un conjunto de URL tiene mala experiencia en móvil o escritorio según datos reales. Es el mapa general. Después conviene ir a PageSpeed Insights, CrUX, herramientas RUM propias o librerías como web-vitals para capturar interacciones concretas en producción. Ahí aparece la verdad menos cómoda: no todas las páginas fallan igual y no todos los usuarios sufren lo mismo.

Un análisis serio debe mirar plantillas. Home, categoría, ficha de producto, artículo, checkout, landing de campaña, buscador interno, página con vídeo, página con comparador, página con mapa. Muchas webs tienen un INP aceptable en artículos simples y desastroso en páginas monetizadas. O al revés: una ficha de producto limpia y una home convertida en mercadillo de módulos dinámicos. La media, en estos casos, es un sedante.

Chrome DevTools permite grabar una interacción en el panel Performance y observar tareas largas, eventos, renderizados, recálculos de estilo y bloqueos del hilo principal. No hace falta mirar la traza como si fuera el electrocardiograma de un astronauta; basta con encontrar los bloques enormes, identificar qué los dispara y preguntarse qué parte puede dividirse, posponerse o eliminarse.

La documentación técnica insiste en localizar interacciones lentas en campo y luego reproducirlas manualmente en laboratorio. Es el camino sensato: primero saber dónde sangra la web; luego abrir.

Señales habituales de una web con INP tocado

Una web con mal INP suele delatarse en gestos muy concretos. El menú hamburguesa que abre tarde. El buscador que se atasca al escribir. El filtro que bloquea la pantalla en cada cambio. El botón de añadir al carrito que no confirma nada durante un instante demasiado largo. La pestaña de contenido que tarda en mostrar el panel. El banner de cookies que parece ligero hasta que se pulsa una opción y despierta a todos los proveedores.

En medios digitales, la publicidad programática merece capítulo propio. No porque sea el villano único, que sería demasiado cómodo, sino porque añade complejidad real: subastas, scripts, iframes, medición, consentimientos, refrescos, visibilidad, formatos ricos. La página editorial moderna no es una página; es un pequeño aeropuerto. Y cada pasajero quiere embarcar primero.

La analítica tampoco sale limpia. Se instalan etiquetas con buena intención y mala dieta. Un sitio con Google Tag Manager puede terminar ejecutando código heredado, píxeles duplicados, eventos redundantes y scripts que nadie recuerda haber aprobado. La web va cargando pasado. Como una redacción con archivadores hasta el techo.

En ecommerce, el enemigo acostumbra a esconderse en capas de personalización, reseñas externas, recomendaciones, motores de búsqueda, promociones dinámicas y scripts de afiliación. Todo suma. O más exactamente: todo compite.

Arreglar INP sin convertir la web en un laboratorio triste

Optimizar INP no significa vaciar la web hasta dejarla con la alegría visual de una factura de gas. Significa decidir qué debe responder primero. La prioridad es que el gesto del usuario tenga una reacción visible rápida. Puede ser abrir el menú, mostrar un estado de carga, confirmar una acción, pintar el primer cambio. La interfaz debe decir “te he oído”. Esa frase, aunque sea visual, salva sesiones.

La mejora suele empezar por el JavaScript no esencial. Lo que no hace falta para responder al primer gesto no debería bloquearlo. Scripts de terceros cargados demasiado pronto, funcionalidades que solo se usan más abajo, módulos que podrían esperar a una interacción real, widgets que pesan como una mudanza. Cargar menos al inicio no es una derrota del marketing; es dejar respirar a la web.

Después vienen las tareas largas. Si una operación tarda demasiado, hay que partirla. El navegador necesita pequeñas ventanas para atender al usuario. Técnicas como dividir trabajo, usar carga progresiva, mover cálculos pesados a web workers cuando tenga sentido o evitar renderizados masivos ayudan a reducir la latencia percibida. La idea no es hacer magia: es impedir que una tarea monopolice el hilo principal.

También conviene mirar el DOM. Un árbol enorme, con demasiados nodos, estilos complejos y componentes anidados, puede convertir cualquier cambio visual en una operación lenta. Hay webs que no tienen una página: tienen una selva tropical. Bonita, quizá. Densa, seguro.

En interfaces móviles, muchas veces la solución es más sencilla de lo que parece: usar componentes nativos cuando bastan, evitar animaciones que fuerzan layout, no recalcular listas enteras por cada pulsación, limitar validaciones agresivas en formularios, reservar espacio para elementos dinámicos y reducir dependencias. Menos teatro. Más respuesta.

SEO, conversión y UX: tres nombres para la misma fricción

El sector ha separado durante años SEO, conversión y experiencia de usuario como si fueran departamentos sin parentesco. INP los junta en la misma mesa. Una página lenta al tacto afecta a la percepción de calidad, a la navegación, al engagement, al checkout, a la captación de leads y, de forma indirecta o directa según el caso, al rendimiento orgánico.

Google no premia una página solo por ir rápida, igual que un periódico no gana lectores solo por tener una portada limpia. El contenido sigue importando. La autoridad importa. La intención de búsqueda importa. La arquitectura importa. Pero cuando dos páginas compiten con contenido comparable, una experiencia móvil torpe es lastre. No siempre visible. Lastre al fin.

La frase incómoda es esta: muchos problemas de INP no se arreglan en SEO, se arreglan en producto. Hay que hablar con desarrollo, diseño, analítica, monetización y negocio. El consultor puede detectar el atasco, pero si cada departamento defiende su script como si fuera un órgano vital, la web seguirá lenta. No hay auditoría que sobreviva a un comité de etiquetas sin dueño.

Para priorizar, lo razonable es empezar por las plantillas con más tráfico móvil y mayor impacto económico. No todas las URL merecen el mismo esfuerzo. Una página informativa con pocas visitas puede esperar. Una ficha de producto que recibe tráfico orgánico cualificado no. Una landing SEM con coste por clic alto tampoco. Un checkout móvil, menos aún. El INP se mejora donde el usuario toca y donde el negocio sangra.

Un buen INP se nota aunque nadie lo nombre

La paradoja de INP es que, cuando se mejora, el usuario no lo celebra. Nadie entra en una web y dice: “Qué magnífica reducción del tiempo de procesamiento”. Simplemente navega. Toca y ocurre. Escribe y aparece. Filtra y responde. Compra y avanza. La buena interactividad es silenciosa, como una puerta bien engrasada.

Para seoetico.com, el asunto encaja además con una lectura más amplia del SEO actual. La optimización técnica ya no puede limitarse a satisfacer herramientas. Debe responder a comportamientos reales. Un informe verde que no se traduce en una web usable en móvil sirve para una captura bonita, poco más. La métrica no es el objetivo; es el detector de humo.

El INP en móviles obliga a mirar la web desde el dedo del usuario, no desde el escritorio del equipo. Y ahí se caen bastantes discursos. El pixel que parecía imprescindible quizá no lo era tanto. El pop-up que prometía conversión quizá estaba cobrando peaje. La animación que daba “dinamismo” quizá era grasa. El plugin que ahorró dos horas hace tres años quizá lleva robando milisegundos cada día desde entonces.

No hace falta convertir cada proyecto en una cruzada ascética contra JavaScript. Hace falta criterio. Medir con datos de campo, reproducir con herramientas de laboratorio, identificar interacciones lentas, recortar lo que bloquea, dividir tareas grandes, posponer terceros, simplificar interfaces y proteger las páginas que más importan. Suena menos glamuroso que hablar de IA generativa, GEO y automatizaciones brillantes. También suele dar más dinero.

El pulgar no espera eternamente

El INP ha puesto nombre técnico a una sensación muy vieja: la web que no contesta pierde autoridad. En móvil, esa pérdida ocurre rápido, casi sin ruido. Un segundo no parece gran cosa en una reunión, pero en una pantalla pequeña puede ser la frontera entre seguir navegando y cerrar la pestaña. Entre comprar y marcharse. Entre leer otro artículo y volver a Google.

La buena noticia es que INP no exige adivinación. Hay umbrales claros, herramientas conocidas y causas bastante repetidas. La mala es que obliga a tomar decisiones. Quitar peso. Ordenar etiquetas. Discutir con plugins. Revisar frameworks. Decir que no a ciertos adornos. Hacer limpieza donde antes se acumulaba “por si acaso”.

Una web móvil decente no debe parecer rápida solo cuando carga. Debe sentirse rápida cuando se usa. Esa es la diferencia. Y en esa diferencia, pequeña como un parpadeo, se juega una parte cada vez más seria del SEO técnico moderno.