Core Web Vitals 2026: por qué INP es el que más fallan y casi nadie te lo dijo

En marzo de 2024 Google cambió una de las tres métricas que decide si tu sitio es rápido a los ojos del buscador, y la mayoría de los negocios nunca se enteró. Retiró FID, la métrica de interactividad que casi todos pasaban, y la reemplazó por INP, mucho más estricta. Dos años después el dato es duro: el 43% de los sitios falla INP, lo que lo convierte en el Core Web Vital que más sitios reprueban en 2026. Y alrededor del 40% de los sitios que pasaban con FID dejaron de pasar con INP, sin tocar nada, solo porque la regla cambió debajo de ellos.

Hay un segundo detalle que casi ninguna agencia panameña explica, y que es el que más confunde a los dueños de negocio: tu informe de PageSpeed puede marcar 98 sobre 100 mientras tus usuarios reales viven en rojo. Google no mide tu laboratorio; mide a tus visitantes. Esta guía explica qué cambió, por qué falla justo el tipo de sitio que vende la competencia, y por qué un sitio construido con la arquitectura correcta pasa INP sin que nadie tenga que optimizar nada.

Los tres Core Web Vitals, en una frase cada uno

Google evalúa la experiencia técnica con tres métricas, y etiqueta cada página según datos de usuarios reales. LCP (Largest Contentful Paint) mide cuánto tarda en cargar el elemento principal visible; el umbral bueno es 2,5 segundos o menos. CLS (Cumulative Layout Shift) mide cuánto se mueve el contenido inesperadamente mientras carga —ese salto molesto cuando vas a tocar un enlace y una imagen lo empuja hacia abajo—; el umbral bueno es 0,1 o menos. INP (Interaction to Next Paint) mide cuánto tarda la página en responder visualmente a cada interacción; el umbral bueno es 200 milisegundos o menos. De los tres, INP es el que más cuesta y el que más sitios reprueban.

Qué cambió con INP y por qué dolió tanto

FID era una métrica indulgente. Solo medía el retraso de la primera interacción del usuario con la página: el tiempo entre el primer clic y el momento en que el navegador empezaba a procesarlo. Era una ventana estrecha y fácil de pasar, y por eso casi todos los sitios la aprobaban sin esfuerzo. INP es otra cosa: mide el recorrido completo —de la interacción al repintado visible— de todas las interacciones de la visita, no solo la primera, y se queda con la peor. Pasó de medir el saludo inicial a medir toda la conversación.

El cambio no fue cosmético. INP castiga lo que FID ignoraba: la lentitud que aparece cuando el usuario ya está usando el sitio, al desplegar un menú, abrir un acordeón, filtrar un catálogo o enviar un formulario. Por eso tantos sitios que vivían en verde con FID amanecieron en rojo con INP sin cambiar una línea de código. El umbral quedó en 200 ms para el percentil 75 de las visitas: si una de cada cuatro interacciones tarda más de 200 ms en responder, fallas.

La trampa de Lighthouse: laboratorio contra campo

Aquí está el malentendido que cuesta dinero. Cuando un proveedor te muestra un PageSpeed Insights de 98 o 100 como prueba de que tu sitio es rápido, te está mostrando un dato de laboratorio. Lighthouse corre en un entorno simulado: una máquina potente con conexión rápida, en condiciones ideales. Google no usa eso para rankear. Usa datos de campo del Chrome User Experience Report (CrUX): mediciones de tus usuarios reales, en sus teléfonos reales —muchos de gama media en Panamá—, con sus conexiones reales, tomadas en el percentil 75 sobre una ventana móvil de 28 días.

La brecha entre ambos mundos puede ser de un orden de magnitud. Un sitio puede marcar 98 en el portátil del desarrollador y fallar INP en el campo porque los usuarios móviles, con dispositivos más lentos, viven una experiencia peor. Por eso conviene dejar de optimizar para el marcador de Lighthouse y mirar el que de verdad cuenta: el informe de Core Web Vitals de Google Search Console, que muestra tus datos de campo agrupados y etiquetados. Lighthouse sirve para diagnosticar qué archivo bloquea; CrUX dice si de verdad estás pasando.

Por qué INP es, en el fondo, un problema de JavaScript

Casi todos los fallos de INP tienen la misma causa raíz: JavaScript que bloquea el hilo principal del navegador. El navegador usa un solo hilo principal para responder a las interacciones del usuario y, a la vez, para ejecutar el JavaScript de la página. Cuando una tarea de JavaScript ocupa ese hilo más de 50 ms, cualquier toque del usuario tiene que esperar a que termine, y esa espera es exactamente lo que INP mide y castiga.

Ahí es donde el tipo de sitio decide el resultado. Un WordPress con page builder y una docena de plugins carga típicamente entre 200 y 500 KB de JavaScript: el constructor visual, los widgets de chat, los píxeles de marketing, las librerías de analítica, los sliders, los popups. Todo ese código compite por el mismo hilo que debería responder a los toques. A diferencia de LCP, que mejoras comprimiendo una imagen, INP no se arregla con un truco: exige repensar cómo se carga y ejecuta el JavaScript, y en una instalación saturada de plugins eso es difícil de raíz porque el dueño no controla el código de cada extensión.

Por qué un sitio estático pasa INP sin optimizar

La conclusión incómoda para quien vende sitios pesados es simple: si INP falla por exceso de JavaScript, un sitio que apenas tiene JavaScript no tiene qué fallar. La arquitectura estática moderna —como Astro con el patrón de islas— envía al navegador HTML y CSS ya construidos y solo el JavaScript mínimo imprescindible, típicamente menos de 100 KB y a veces casi cero en páginas de contenido. El hilo principal queda libre para responder a las interacciones de inmediato.

No es optimización: es aritmética. El problema que hunde al 43% de los sitios simplemente no aparece cuando no cargas el código que lo causa. Este propio sitio es la prueba: está construido con una arquitectura estática de alto rendimiento, su presupuesto de JavaScript es de pocos KB por página, y por eso responde por debajo de los umbrales sin necesidad de trucos. Es la misma lógica que explicamos en la comparación de WordPress contra Astro: la elección de arquitectura, tomada al principio, decide la mayoría de los problemas de rendimiento antes de que existan. Optimizar un sitio pesado para que pase INP cuesta semanas; partir de uno liviano lo da gratis.

El detalle que descoloca a los equipos: cómo agrupa Search Console

Hay un comportamiento de Google que sorprende incluso a equipos técnicos. Search Console no evalúa cada URL por separado: agrupa páginas similares y le asigna a todo el grupo el estado de la peor métrica del grupo. Eso significa que una sola plantilla lenta —pongamos, la ficha de producto— puede arrastrar a rojo a decenas o cientos de páginas que comparten su estructura, aunque individualmente algunas funcionen bien. El modelo de agrupación importa más de lo que la mayoría espera, porque cambia dónde conviene invertir el esfuerzo.

La lectura práctica es que no se optimiza página por página, sino plantilla por plantilla. Arreglar el JavaScript de la plantilla de producto, o del artículo de blog, o de la página de servicio, mueve de golpe a todo el grupo que la usa. Por eso un sitio con pocas plantillas bien hechas pasa Core Web Vitals con menos trabajo que uno con muchas plantillas dispares, cada una con su propio cóctel de plugins. La consistencia de arquitectura vuelve a ser la palanca: menos plantillas, más limpias, rinden mejor que muchas plantillas parchadas.

Las tres fases de cada interacción, para entender dónde se pierde el tiempo

INP no mide una sola cosa, sino el recorrido completo de una interacción dividido en tres fases, y entenderlas ayuda a saber qué arreglar. La primera es el retraso de entrada: el tiempo que el toque del usuario espera porque el hilo principal está ocupado ejecutando otra tarea de JavaScript. La segunda es el tiempo de procesamiento: lo que tardan en ejecutarse los manejadores de eventos que responden a esa interacción. La tercera es el retraso de presentación: lo que tarda el navegador en pintar en pantalla el resultado visible del cambio.

La mayoría de los fallos de INP nacen en la primera fase, el retraso de entrada, y casi siempre por la misma razón: el hilo principal estaba bloqueado ejecutando JavaScript de terceros cuando el usuario tocó. Por eso diferir los scripts no esenciales rinde tanto: libera el hilo para que la interacción se atienda al instante en vez de hacer cola detrás de la analítica o del widget de chat. Saber en qué fase se pierde el tiempo es lo que separa una optimización quirúrgica de un mes de prueba y error a ciegas.

Qué hacer si tu sitio falla INP hoy

Si tu sitio actual está en rojo y rehacerlo no es opción inmediata, hay arreglos reales, aunque parchen en vez de resolver. Difiere el JavaScript no crítico: los widgets de chat, la analítica y los píxeles de marketing son de los mayores asesinos de INP; cárgalos después de la interacción, no al inicio. Parte las tareas largas: cualquier tarea que bloquee el hilo principal más de 50 ms empuja el INP a rojo, así que conviene dividirlas en trozos pequeños. Reduce el TTFB con edge computing para servir el contenido desde el punto más cercano al usuario. Audita plugin por plugin en WordPress: muchas veces dos o tres extensiones cargan la mayor parte del JavaScript que sobra.

Pero conviene ser honesto sobre el techo de esa vía: en un sitio construido sobre una base pesada, esos arreglos llevan el INP de "pobre" a "necesita mejorar" más a menudo que a "bueno". Llega un punto en que seguir parchando cuesta más que reconstruir sobre una base liviana, y ese cálculo es justo lo que medimos en una auditoría web: cuánto costaría llevar tu sitio actual a verde frente a cuánto costaría partir de cero con la arquitectura correcta. A veces el parche es lo sensato; a veces es tirar dinero bueno sobre malo.

Lo que viene: la métrica no se detiene

Vale la pena mirar adelante. En 2026 Google confirmó en su blog de Search Central, el 18 de marzo, que INP dejó de ser una métrica suplementaria para convertirse en señal de ranking equivalente a LCP y CLS, y los sitios con INP en el rango "necesita mejorar" registraron caídas de posición medibles, en promedio cercanas a un lugar. Google también empezó a hablar de métricas nuevas, todavía no de ranking, como un índice de estabilidad visual que observa toda la visita y no solo la carga inicial. La dirección es clara: la vara de lo que Google considera "rápido y estable" sube cada año, y el costo de arrastrar un sitio pesado se acumula.

Para un negocio panameño que compite por palabras clave donde el contenido de todos es parecido, INP es a menudo el desempate: ante dos páginas equivalentes, la que responde rápido gana la posición. Y en la era del zero-click, donde cada visita que sí llega vale más, perderla porque el sitio responde lento es un lujo que ningún negocio se puede permitir. El primer paso no cuesta nada: abre Google Search Console, entra al informe de Core Web Vitals y mira cuántas de tus páginas están en rojo por INP. Ese número es el tamaño real del problema.

Hay un agravante específico del mercado panameño que vuelve esto más urgente. INP se mide en dispositivos reales, y en Panamá una parte grande del tráfico llega desde teléfonos Android de gama media, con procesadores menos potentes que el iPhone del desarrollador o el portátil de la agencia. Un sitio pesado que apenas pasa INP en un equipo de gama alta puede fallar de forma clara en el teléfono típico del cliente panameño, justo el dispositivo desde el que se hace la mayoría de las búsquedas locales. El mismo código que se ve aceptable en el laboratorio del desarrollador castiga al negocio en el bolsillo de su cliente. Por eso medir en campo, y no en el portátil de quien construyó el sitio, no es un tecnicismo: es ver la realidad que vive quien te va a comprar.