Cómo mejorar el INP de tu web WordPress

Por qué INP se convirtió en el dolor de cabeza de WordPress

En marzo de 2024 Google hizo el cambio que muchos veníamos esperando y otros tantos preferíamos ignorar. INP, Interaction to Next Paint, reemplazó oficialmente a FID dentro de Core Web Vitals. Y de las tres métricas principales, esta es la que más sitios WordPress están fallando ahora mismo. No es exageración, es lo que veo cada semana cuando reviso reportes de PageSpeed Insights y Search Console de clientes nuevos.

La diferencia con FID es brutal. FID solo medía el primer clic, esa primera interacción del usuario con la página. Era una métrica generosa, casi indulgente. INP mide todas las interacciones a lo largo de la sesión y reporta básicamente la peor. Es decir, ya no basta con que el primer clic sea rápido. Cada vez que alguien toca un menú, abre un acordeón, escribe en un buscador o hace scroll con un sticky, esa interacción se está midiendo. Si una sola fue lenta, INP la cuenta.

El umbral bueno está por debajo de 200 milisegundos. Entre 200 y 500 es mejorable. Más de 500 es pobre y prácticamente garantiza que Google te lo va a marcar en rojo en Search Console. Cuando empecé a auditar sitios con esta métrica nueva, me encontré con instalaciones de WordPress que en FID iban perfectas y en INP se iban a 800 o 1200 milisegundos. Sitios bien rankeados, bien optimizados a la vieja usanza, fallando por algo que antes ni se medía.

Cómo medir INP de verdad y no engañarte

Acá viene el primer error que veo todo el tiempo. La gente abre PageSpeed Insights, ve un INP simulado verde y se va tranquila. Mal. Lo que vale es el dato de campo, lo que Google llama Field Data o CrUX. Eso es lo que de verdad usa el algoritmo para evaluar tu sitio.

Yo uso tres fuentes en paralelo cuando estoy diagnosticando un problema de INP en WordPress. Primero Search Console, en la sección de Core Web Vitals. Ahí me muestra cuántas URLs están en cada estado y agrupadas por causa. Segundo PageSpeed Insights con la URL específica, mirando el Origin Summary que viene del CrUX. Y tercero, para cuando necesito mucho detalle, la extensión Web Vitals de Chrome que me deja interactuar con la página y ver el INP de cada acción en tiempo real.

Esta extensión es la que me cambió el trabajo. Hago clic en el menú y veo cuántos milisegundos tardó. Abro un acordeón y veo el número. Escribo en un campo de búsqueda y veo si está bloqueando el main thread. Es la única forma honesta de saber dónde están los problemas reales de tu sitio, porque las herramientas sintéticas no simulan bien la interacción.

Las causas reales del INP alto en sitios WordPress

Después de meses peleando con esta métrica, ya identifico patrones casi de memoria. El JavaScript pesado es el culpable número uno. WordPress por sí solo no carga tanto JS, pero la combinación de plugins de elementos, builders visuales, sliders, popups y formularios convierte cualquier sitio en una bomba de scripts.

Lo segundo son los third-party scripts. Google Analytics 4, Google Tag Manager, Meta Pixel, Hotjar, Clarity, chats como Tawk o Crisp, herramientas de A/B testing, retargeting de Ads. Cada uno suma main thread, cada uno se ejecuta cuando el usuario menos lo necesita. He visto sitios con ocho herramientas de tracking corriendo a la vez. Ninguna sirve si la página no responde cuando el usuario hace clic.

El main thread bloqueado es la consecuencia técnica de todo lo anterior. El navegador tiene un solo hilo principal para responder a interacciones. Si ese hilo está ocupado procesando JavaScript, no puede atender al clic del usuario. Y mientras espera, el contador de INP sigue corriendo. Por eso una página con mucho JavaScript ejecutándose en paralelo siempre va a tener problemas, aunque tenga un servidor rápido y un buen hosting.

Las soluciones que sí funcionan en WordPress

Voy a ser directo con lo que funciona y lo que no, porque he probado mucho. Lo primero es aplicar defer o async a todos los scripts que se pueda. Defer significa que el script se descarga en paralelo pero se ejecuta después de que el HTML esté parseado. Async se descarga y ejecuta cuando pueda, sin orden garantizado. Para tracking y analytics, async va bien. Para scripts que dependen de otros, defer es más seguro.

En WordPress hay plugins como WP Rocket, FlyingPress, Perfmatters o el propio Autoptimize que permiten aplicar defer a todos los scripts con un par de checks. Es la mejor inversión de tiempo que puedes hacer. Yo recomiendo Perfmatters cuando el cliente ya tiene un plugin de cache decente, y FlyingPress cuando quiere todo en uno.

El code splitting es otra técnica clave, aunque más avanzada. Consiste en partir el JavaScript en bloques chiquitos que se cargan solo cuando se necesitan. Si tienes un formulario que solo aparece en contacto, no tiene sentido cargar ese JS en la home. En WordPress puro esto es complicado de implementar, pero plugins como Perfmatters tienen una función llamada Script Manager que permite desactivar scripts página por página. Una maravilla cuando se usa bien.

Reducir plugins es la solución más impopular y la que más resultados da. Cada plugin añade su propio JavaScript, sus propias requests, su propia carga al main thread. Cuando audito un sitio y encuentro 45 plugins activos, sé que ahí está la mitad del problema. Hago una limpieza honesta, dejo los esenciales y desactivo los que duplican funciones. El INP suele bajar 200 o 300 milisegundos solo con eso.

Third-party scripts, el enemigo silencioso

Aprovecho para hablar de este punto en serio porque es donde más sitios se hunden. Cada script de terceros se carga desde un dominio externo y ejecuta código que tú no controlas. Google Analytics 4, por ejemplo, ejecuta unos 90 kilobytes de JavaScript que bloquean el main thread mientras se procesan. Multiplica eso por Tag Manager, Pixel y dos o tres herramientas más, y ya tienes 300 o 400 milisegundos perdidos solo en tracking.

Lo que hago en estos casos es priorizar. Pregunto al cliente qué herramientas usa de verdad para tomar decisiones. Casi siempre la respuesta es Google Analytics y nada más. El resto está ahí porque alguien lo instaló y nunca lo quitó. Limpiar esa basura digital es un alivio para el INP y para el bolsillo.

Para los scripts que sí son necesarios, uso una técnica que llamo delayed loading. Consiste en cargar el script no cuando se abre la página, sino cuando el usuario hace su primera interacción real, como un scroll o un movimiento del mouse. WP Rocket y FlyingPress lo traen integrado. El analytics se carga 200 milisegundos después de que el usuario llegue, no antes. El INP mejora muchísimo y los datos siguen llegando porque la sesión continúa.

Web workers, la técnica avanzada que pocos usan

Los web workers son hilos separados del main thread donde puedes ejecutar JavaScript pesado sin bloquear al navegador. Es decir, el código corre en paralelo y no interfiere con las interacciones del usuario. Suena ideal y lo es, pero no todos los scripts pueden moverse a un worker porque algunos necesitan acceso al DOM.

Partytown es una librería open source que mueve scripts de terceros como Google Analytics a un web worker. Hay un plugin de WordPress que lo integra y es relativamente fácil de configurar. He visto casos donde mover GA4 y Tag Manager a Partytown bajó el INP de 700 milisegundos a 250. Es una de esas técnicas que parecen magia pero tienen base sólida.

Eso sí, no es para todo el mundo. Si tu sitio depende mucho de scripts de terceros que interactúan con el DOM, como chats o formularios embebidos, los workers van a romper cosas. Yo lo recomiendo para sitios donde el tracking es la principal carga de terceros y donde el INP es crítico para el negocio.

Cloudflare y el truco del edge computing

Cloudflare tiene una función llamada Rocket Loader que reescribe los scripts al vuelo para que carguen de forma diferida. En teoría es perfecto. En la práctica, a veces rompe sliders, popups y formularios complejos. Lo activo siempre como prueba y monitoreo si algo deja de funcionar.

Más interesante todavía es Cloudflare Workers, que permite ejecutar código en el edge, en los servidores de Cloudflare más cercanos al usuario. Para tracking se puede usar Zaraz, que reemplaza Tag Manager y ejecuta los scripts en el servidor antes de enviar al navegador. El usuario recibe el HTML ya procesado, sin los kilobytes de tracking. INP se beneficia mucho.

Para sitios pequeños o medianos esto puede ser overkill, pero para ecommerce y proyectos donde cada milisegundo cuenta, vale la inversión. El plan gratuito de Cloudflare ya incluye varias de estas funciones, así que se puede probar sin gastar.

Plugins y temas, decisiones que arrastras durante años

La elección del tema y los plugins principales determina el techo de tu rendimiento. Un tema mal optimizado, con miles de líneas de CSS y JavaScript innecesario, te va a dar problemas de INP por siempre. Hay temas pesados que cargan 500 kilobytes de JS solo para mostrar la home.

Recomiendo siempre temas livianos como GeneratePress, Kadence, Blocksy o Astra en sus versiones premium. Son temas modulares, donde solo se carga el código de las funciones que usas. Eso ya marca una diferencia gigante respecto a temas masivos como Avada o Divi, que cargan todo aunque no lo uses.

Con los builders visuales pasa lo mismo. Elementor en su versión actual ha mejorado, pero sigue siendo pesado. Si puedo, recomiendo el editor de bloques nativo de WordPress con un buen tema basado en bloques. Es más limpio, más rápido y el INP se beneficia. Si el cliente ya tiene Elementor, lo dejo y optimizo todo lo demás, porque migrar un sitio entero es un proyecto serio.

Mi flujo de trabajo para bajar el INP

Cuando me llega un sitio con problemas de INP, sigo un orden que me ha funcionado bien. Primero mido el estado actual con datos de campo, sin tocar nada. Documento el INP actual, las URLs problemáticas y las interacciones específicas que están fallando. Esto es importante para tener un punto de comparación honesto.

Después limpio plugins innecesarios. Reviso uno por uno, pregunto al cliente cuáles usa y desactivo los que sobran. Suelo encontrar entre 10 y 20 plugins prescindibles en sitios maduros.

El tercer paso es atacar third-party scripts. Reviso qué herramientas hay corriendo, decido cuáles quedarse y aplico delayed loading o las muevo a web workers según el caso. Aquí suelo ganar entre 200 y 400 milisegundos de INP.

Después configuro un buen plugin de optimización con defer y async para todos los scripts. WP Rocket o FlyingPress me sirven en la mayoría de proyectos. Activo lazy load de imágenes y videos, minifico CSS y JS, y en algunos casos uso critical CSS para acelerar el primer pintado.

Finalmente vuelvo a medir y comparo. Si el INP sigue alto, voy a Script Manager y desactivo scripts página por página. A veces es la única forma de bajar de 250 a 180 milisegundos en páginas concretas.

Errores que cometí y aprendí a evitar

Hace dos años, cuando recién empezaba con INP, instalé Partytown en un ecommerce sin probar bien y rompí el checkout. El cliente perdió ventas durante seis horas hasta que detectamos el problema. Aprendí que cualquier cambio agresivo se prueba primero en un staging idéntico al de producción.

También aprendí a no confiar en las herramientas sintéticas. PageSpeed Insights es útil pero su INP simulado no refleja la realidad. Los datos de campo siempre mandan. Si Search Console te dice que el INP de tus URLs está mal, hazle caso aunque PageSpeed te muestre 100 puntos.

Otro error clásico es optimizar la home y olvidar las páginas internas. Google evalúa cada URL por separado. Si la home va perfecta pero las páginas de producto van mal, vas a tener problemas. Hay que medir y optimizar URL por URL, no solo la portada.

Lo que viene con INP en los próximos meses

Google está afinando cómo mide INP. La tendencia clara es que las métricas de campo van a tener cada vez más peso en el ranking. Ya no basta con optimizar para Lighthouse, hay que optimizar para usuarios reales. Eso significa pensar en cómo la gente usa de verdad tu sitio, no en cómo lo simula un bot.

También se viene más presión sobre los plugins de WordPress. Los desarrolladores están empezando a tomar en serio el rendimiento porque saben que un plugin pesado pierde cuota de mercado. Es un buen momento para revisar tu stack y quedarte solo con lo que funciona bien.

Mi consejo final es simple. Trata el INP como una métrica de negocio, no técnica. Un sitio que responde rápido convierte más, retiene mejor a los usuarios y ranquea mejor. Cada milisegundo que bajas de INP es dinero que vuelve. Ese es el verdadero motivo para tomarse el trabajo en serio.

Preguntas frecuentes sobre cómo mejorar el INP en WordPress

Cuál es el INP bueno para mi sitio WordPress

El umbral bueno está por debajo de 200 milisegundos. Entre 200 y 500 se considera mejorable y Google te lo va a marcar como necesita atención en Search Console. Por encima de 500 es pobre y afecta el ranking. La meta realista para un sitio WordPress bien optimizado debería ser quedarse cómodamente por debajo de 150 milisegundos.

Por qué mi INP empeoró si antes tenía FID en verde

Porque son métricas distintas. FID solo medía el primer clic, mientras que INP mide todas las interacciones durante la sesión y reporta la peor. Es totalmente normal pasar de un FID excelente a un INP regular, porque ahora se evalúan cosas que antes ni se medían, como abrir menús, acordeones o usar buscadores internos.

Qué plugins de WordPress ayudan más a mejorar INP

WP Rocket y FlyingPress son los más completos para optimización general. Perfmatters tiene un Script Manager que permite desactivar scripts por página, ideal para INP. Autoptimize es una opción gratuita decente. Para third-party scripts, el plugin de Partytown puede ayudar mucho si tu carga de tracking es alta.

Cuánto tarda en actualizarse el INP en Search Console

Los datos de campo se actualizan con un retraso de 28 días, porque Google usa una ventana rodante de los últimos 28 días de datos reales. Eso significa que si haces cambios hoy, vas a ver resultados completos en Search Console recién dentro de un mes. Para medir progreso más rápido conviene usar la extensión Web Vitals de Chrome y testear en sesiones reales.

Es mejor desactivar Google Analytics para bajar el INP

No hace falta desactivarlo, hace falta cargarlo bien. Si lo pones con delayed loading, async o lo mueves a un web worker con Partytown, su impacto en INP se reduce a casi nada. El problema no es Analytics en sí, es cómo se carga junto a otros cinco scripts de tracking al mismo tiempo.

Cómo afecta el hosting al INP

El hosting afecta más a métricas como LCP o TTFB que a INP directamente, porque INP mide la respuesta del navegador a interacciones, no la velocidad del servidor. Sin embargo, un buen hosting con HTTP/3, caché en servidor y recursos suficientes te ayuda indirectamente, porque libera al navegador para responder mejor a las interacciones.

Sirve usar AMP para mejorar el INP

AMP ya no es la solución que era hace años. Google dejó de priorizarlo en resultados y muchos sitios lo están abandonando. Es preferible optimizar tu WordPress normal con buenas prácticas que migrar a AMP, porque AMP impone restricciones que limitan mucho lo que puedes hacer y no garantiza un INP mejor que un sitio bien optimizado.

Cómo identifico qué scripts están dañando mi INP

Usa la pestaña Performance de Chrome DevTools y graba una sesión interactuando con tu sitio. Vas a ver claramente qué scripts están bloqueando el main thread. La extensión Web Vitals también te muestra el INP de cada interacción y qué función JavaScript lo causó. Con esas dos herramientas tienes diagnóstico preciso.

Conviene quitar Elementor para mejorar el INP

Si puedes migrar a otro builder más liviano o al editor de bloques nativo, sí ayuda mucho. Pero migrar un sitio entero es un proyecto serio. Si Elementor ya está en producción, la alternativa es optimizarlo bien con Elementor Pro, desactivar las funciones que no usas, y aplicar buenas prácticas de caché y delayed loading sobre todo lo demás.

Cuánto cuesta optimizar el INP de un sitio WordPress

Depende del estado inicial y del nivel de optimización buscado. Una optimización básica con plugins como WP Rocket y limpieza de scripts puede tardar entre 4 y 8 horas de trabajo. Una optimización profunda con code splitting, web workers y reescritura de tema puede tardar entre 20 y 40 horas. La inversión casi siempre se justifica porque mejora conversión y ranking.