Te voy a contar una situación que seguramente has vivido, ya sea como usuario o, lo que es peor, revisando tu propia tienda online.
Entras en una web desde el móvil. La página parece haber cargado perfectamente: ves la foto del producto, el precio y ese botón grande y colorido que dice «Añadir al Carrito». Tu cerebro dice «compra», tu dedo baja y toca el botón.
Y entonces… nada.
El botón no se hunde. No cambia de color. No aparece el icono de «cargando». Durante medio segundo (que en internet es una eternidad), tienes la sensación de que el móvil se ha bloqueado o la web está rota. Frustrado, le das al botón dos o tres veces más (lo que llamamos Rage Clicks). De repente, la web «despierta» y añade tres productos al carrito de golpe.
Ese «congelamiento» es el enemigo silencioso del comercio electrónico hoy en día. Tu web puede tener un 95 en los tests de velocidad porque la foto carga rápido, pero si la web no responde a tus dedos, para el usuario es una web lenta.
Desde marzo de 2024, Google le ha puesto nombre y apellido a este problema: INP (Interaction to Next Paint). Y si no lo estás midiendo, estás perdiendo dinero.
1. ¿Qué es el INP y por qué sustituye al FID?
Para entender esto, imaginemos un restaurante.
La métrica antigua de Google, el FID (First Input Delay), era como medir cuánto tardaba el camarero en llegar a tu mesa cuando levantabas la mano. Si llegaba rápido, Google decía «este restaurante es rápido». Pero el FID tenía una trampa: no medía cuánto tardaba el camarero en tomarte nota y traerte la comida. Solo medía el tiempo de reacción inicial.
El INP (Interaction to Next Paint) mide la experiencia completa. Mide desde que levantas la mano (clic/toque) hasta que el camarero te trae el primer plato (el navegador pinta el siguiente fotograma confirmando la acción).
Si el camarero llega rápido a tu mesa pero se queda 40 segundos mirando al techo «procesando» tu pedido antes de escribirlo, la experiencia es mala. Eso es un INP alto. Google ha dejado de preocuparse solo por la «reacción» y ha empezado a preocuparse por la «respuesta visual completa».
El semáforo del INP
- Buena respuesta: Menos de 200 milisegundos. El usuario siente que la web es fluida, casi como una app nativa.
- Necesita mejora: Entre 200ms y 500ms. Se nota un pequeño «lag» o retraso.
- Pobre: Más de 500ms. La web se siente rota. El usuario abandona.
2. El culpable técnico: El atasco en el «Hilo Principal»
Aquí es donde nos ponemos la bata de ingeniero, pero lo vamos a explicar para que se entienda fácil.
Los navegadores web (Chrome, Safari, Edge) tienen una limitación fundamental de diseño: funcionan con un Hilo Único (Single Thread).
Imagina que tu navegador es una autopista de un solo carril. Por ese carril único tienen que pasar todos los camiones:
- El camión que dibuja el HTML y CSS (la estructura y diseño).
- El camión que gestiona los clics del usuario.
- El camión del JavaScript (la lógica, los trackers, las animaciones).
El problema surge cuando tienes una Tarea Larga (Long Task). Esto ocurre cuando un camión de JavaScript gigante (por ejemplo, el código que carga todo el catálogo de productos o un script de analítica pesado) ocupa el carril durante 300 milisegundos.
Si en ese momento el usuario intenta hacer clic en un botón (un coche pequeño intentando entrar a la autopista), no puede. Tiene que esperar a que el camión gigante termine de pasar. Ese tiempo de espera en el arcén es lo que dispara tu métrica de INP y frustra a tu cliente.
3. ¿Cómo sé si mi web sufre de esto?
El error número uno es mirar tu web desde tu ordenador de oficina con fibra óptica y un procesador i7 de última generación. Ahí todo vuela.
El problema del INP se manifiesta en los dispositivos de tus clientes: móviles Android de gama media, iPhones de hace tres generaciones o conexiones 4G inestables. En esos dispositivos, procesar ese «camión de JavaScript» cuesta mucho más tiempo.
Para diagnosticarlo de verdad, necesitas dos herramientas:
- Google Search Console (Core Web Vitals): Aquí verás datos reales de usuarios (datos de campo). Si ves una línea roja en «INP», tienes trabajo que hacer.
- Chrome DevTools (Pestaña Rendimiento): Si haces una grabación de perfil mientras usas tu web, verás bloques rojos y amarillos en la línea de tiempo. Esas son las Tareas Largas. Al pinchar en ellas, el navegador te dirá: «Culpa a este script de Facebook» o «Culpa a esta función de tu menú».
4. Soluciones Reales: Ingeniería WPO (Web Performance Optimization)
En PonteClick no nos conformamos con instalar un plugin de caché. Eso es maquillaje. Para arreglar el INP, hay que hacer cirugía en el código. Aquí tienes tres estrategias que usamos en nuestros proyectos de Diseño Web técnico:
A. Trocear las Tareas (Yielding to the Main Thread)
Esta es la técnica más efectiva. Si tienes un script que tiene que procesar 5.000 datos, no lo hagas todo de golpe bloqueando el carril 5 segundos.
Obligamos al código a hacer «pausas». Le decimos al navegador: «Procesa 100 datos, para y mira si el usuario ha hecho clic en algo. Si ha hecho clic, atiéndelo. Si no, sigue con los siguientes 100». En términos técnicos, usamos setTimeout, requestIdleCallback o el moderno scheduler.yield(). Esto convierte un camión gigante en 50 motos pequeñas, permitiendo que el tráfico (los clics del usuario) fluya entre ellas.
B. El truco de la «Fachada» para los Widgets
¿Tienes un chat de soporte (Zendesk, WhatsApp, HubSpot) en tu web? Esos scripts son pesadísimos y suelen bloquear la carga inicial.
No cargues el chat real al principio. Carga una imagen falsa (una fachada) que parece el botón del chat. Es un simple dibujo, no pesa nada. Solo cuando el usuario pasa el ratón por encima o hace intención de clicar, entonces descargamos e iniciamos el código real del chat. Para el usuario la experiencia es idéntica, pero te has ahorrado 300ms de bloqueo en el momento crítico de la carga.
C. Web Workers: Abrir un segundo carril
Si la autopista principal está llena, ¿por qué no usamos la carretera secundaria? Los Web Workers permiten mover tareas pesadas (como encriptación, filtros complejos de bases de datos o procesamiento de imágenes) a un hilo secundario. El Hilo Principal se queda libre exclusivamente para pintar la pantalla y atender al usuario, mientras el «trabajo sucio» se hace en segundo plano. Es ingeniería web avanzada, pero es lo que diferencia a una web profesional de una plantilla básica.
5. El impacto en tu negocio (Por qué te debe importar)
Puede que pienses: «Bueno, medio segundo tampoco es para tanto».
En el entorno digital, la velocidad es confianza. Una web que responde al instante se percibe como robusta, segura y profesional. Una web que se traba al hacer clic se percibe (inconscientemente) como insegura o de baja calidad.
Google ha hecho estudios exhaustivos: mejorar el INP de «pobre» a «bueno» puede incrementar las tasas de conversión en un 20% o más. Estamos hablando de recuperar a uno de cada cinco clientes que se iban frustrados sin que tú lo supieras.
Además, al ser un factor de ranking oficial, tener un mal INP es como ir con el freno de mano echado en tu estrategia de Agencia SEO. Por mucho contenido que crees, Google priorizará a tu competencia si su web ofrece una experiencia técnica superior.
6. Conclusión: La nueva era de la responsividad
Hemos pasado de la era de la «Carga Rápida» a la era de la «Respuesta Inmediata». Ya no basta con que tu web se vea; se tiene que sentir viva.
El INP no es una métrica vanidosa para programadores; es un indicador directo de la salud de tu negocio online. Si tu equipo técnico te dice que «la web ya está optimizada» pero las gráficas de Search Console dicen lo contrario, es hora de abrir el capó y mirar cómo se está ejecutando el JavaScript.
En PonteClick, entendemos que la belleza del diseño no sirve de nada si la ingeniería que hay detrás no funciona como un reloj suizo. Optimizar el INP es una de las inversiones con mayor retorno directo que puedes hacer hoy en tu activo digital.
