INP en WordPress: el dato web que enfada a tus usuarios

Mejorar INP en WordPress se ha convertido en una de esas tareas incómodas que ya no se pueden dejar para “cuando haya tiempo”, ese trastero digital donde acaban las auditorías técnicas, los plugins dudosos y los rediseños que alguien prometió revisar después del verano. INP, siglas de Interaction to Next Paint, mide cuánto tarda una página en reaccionar visualmente después de una interacción real del usuario: un clic, un toque en móvil, una pulsación de teclado. No mide solo si la web carga. Mide si responde. Y ahí WordPress, con sus temas hinchados, constructores visuales, pop-ups, sliders, formularios, píxeles publicitarios y scripts de terceros, suele enseñar las costuras.

Desde que INP sustituyó a FID como métrica de capacidad de respuesta dentro de Core Web Vitals, el asunto dejó de ser una rareza para obsesos del rendimiento. Google ya no se conforma con saber si el primer clic tuvo suerte. Observa el comportamiento de la página durante la visita y toma como referencia las interacciones más lentas, con el percentil 75 como vara de medir. La lectura práctica es bastante menos elegante: si el usuario toca un menú, intenta abrir un acordeón, pulsa un botón de compra o escribe en un buscador interno y la web se queda pensando como una impresora de oficina, el problema no es “sensación”. Es rendimiento. Y tiene nombre.

El nuevo termómetro de la paciencia digital

INP es una métrica cruel porque se parece mucho más a la experiencia real que a la comodidad del informe. Antes, con FID, muchas webs podían salir bien paradas porque se medía la demora del primer input, pero no todo lo que ocurría después. Era como juzgar un restaurante por la rapidez con la que te dan la carta, aunque luego el camarero desaparezca cuarenta minutos y el segundo plato llegue frío. INP mira el servicio completo. Especialmente ese momento en el que el usuario ya está dentro, ya confía, ya quiere hacer algo… y la interfaz se le queda pegada a los dedos.

En WordPress esto ocurre con una frecuencia casi grosera. El CMS no es el villano, conviene decirlo cuanto antes, porque WordPress bien trabajado puede ser rápido, estable y muy competitivo. El problema es el ecosistema que lo rodea cuando se usa como un cajón de sastre. Un tema multipropósito con veinte animaciones, un constructor visual cargando bibliotecas enteras para pintar tres bloques, un plugin de cookies que bloquea medio árbol de scripts, otro de formularios con validaciones pesadas, cuatro píxeles de medición, un chat flotante y un carrusel que nadie mira. Todo eso no pesa solo al cargar; también ocupa el hilo principal del navegador, que es donde se decide si la página responde o se queda tiesa.

Para Google, una experiencia buena en INP suele situarse en 200 milisegundos o menos. Entre 200 y 500 milisegundos entra en zona de mejora. Por encima de 500, mala señal. En el papel parecen cifras de laboratorio, números diminutos como polvo bajo una lámpara. En la práctica, medio segundo de retraso tras un toque en móvil ya se nota. El dedo espera, el botón no cambia, el usuario duda. Vuelve a pulsar. La web procesa dos veces. Aparece el clásico pequeño caos: menús que se abren tarde, filtros que reaccionan a trompicones, formularios que parecen no haber recibido la orden, botones de compra que transmiten menos confianza que un cajero automático con la pantalla congelada.

Por qué WordPress tropieza tanto con el INP

La mayor parte de los problemas de INP en WordPress nacen en el navegador, no necesariamente en el servidor. El hosting importa, claro; un TTFB alto puede arrastrar la experiencia inicial y condicionar otras métricas. Pero INP vive sobre todo en el territorio del JavaScript, del CSS, del DOM y de cómo el navegador reparte su atención cuando el usuario intenta interactuar. El matiz importa porque todavía hay demasiadas auditorías de rendimiento que prometen arreglarlo todo con caché, compresión y CDN. Eso ayuda. No siempre cura.

El hilo principal del navegador tiene que ejecutar scripts, calcular estilos, ordenar el diseño, pintar la pantalla y atender eventos. Si un script largo está trabajando cuando el usuario toca un botón, la interacción espera. Esa espera es parte del INP. Después llega el tiempo de procesamiento del propio evento: lo que hace el JavaScript asociado al clic, al teclado o al toque. Por último aparece el retraso de presentación, el tramo hasta que el cambio se ve en pantalla. Input delay, processing duration y presentation delay, dicho en jerga; en castellano de batalla, espera, trabajo y pintura.

WordPress añade capas. Muchas. Un sitio sencillo con un tema moderno, pocas dependencias y bloques bien montados puede tener un INP decente sin heroicidades. Un ecommerce en WooCommerce con filtros AJAX, mini carrito dinámico, banners, recomendaciones, pop-ups, valoraciones, pasarela de pago, seguimiento publicitario y personalización en tiempo real entra en otro barro. Cada interacción puede despertar una pequeña orquesta de scripts. El usuario toca “añadir al carrito” y, por debajo, se mueve más gente que en una mudanza.

Los constructores visuales son un capítulo propio. Elementor, Divi, WPBakery, Oxygen, Bricks y compañía pueden usarse con criterio, pero cuando una página depende de widgets anidados, animaciones, contenedores profundos y bibliotecas que cargan aunque no hagan falta, el navegador empieza a caminar con una mochila de piedras. No es una cuestión moral. Es física. Más nodos en el DOM, más estilos, más scripts, más listeners, más posibilidades de que una interacción caiga justo cuando la página está digiriendo otra cosa.

El problema no siempre está donde parece

Hay webs que miran el servidor con lupa mientras el verdadero atasco está en el navegador. Ocurre mucho. Se cambia de hosting, se activa una CDN, se comprimen imágenes, se instala caché, se celebra una subida en PageSpeed y, aun así, el usuario sigue notando la página pastosa. La velocidad inicial mejora, pero la interfaz continúa respondiendo tarde. El escaparate abre antes; el dependiente sigue dormido.

En WordPress, la frontera entre lo técnico y lo editorial se ha vuelto borrosa. Un bloque de vídeo incrustado puede deteriorar la interacción. Un módulo de contenidos relacionados puede cargar más JavaScript del que parece. Un banner de newsletter puede enganchar eventos, pintar elementos tardíos y bloquear la respuesta. Una tabla comparativa con demasiados scripts puede ser útil para el lector y, a la vez, torpe para el navegador. El rendimiento no vive en un sótano separado del contenido. Vive dentro de cada decisión de plantilla.

Medir bien antes de tocar medio sitio

La tentación habitual es instalar otro plugin para arreglar los plugins anteriores. Un clásico. Pero para mejorar INP en WordPress conviene empezar con una medición que distinga laboratorio y campo. PageSpeed Insights, Search Console y los datos de experiencia real muestran comportamiento de usuarios reales cuando hay suficiente tráfico. Lighthouse y Chrome DevTools permiten reproducir problemas en laboratorio. No son lo mismo, no hablan con el mismo acento y no siempre coinciden.

Los datos de campo tienen una virtud esencial: enseñan lo que pasa fuera del ordenador del desarrollador, en móviles normales, redes imperfectas, pestañas abiertas, baterías cansadas y navegadores con vida propia. El usuario real no navega dentro de una demo recién instalada ni con una conexión de fibra simétrica y silencio absoluto. Lleva prisa, tiene WhatsApp vibrando, abre la web desde Google, desde Discover, desde una newsletter o desde un anuncio. Y toca. Ahí aparece el INP que importa.

El laboratorio, en cambio, sirve para operar. Chrome DevTools permite grabar una interacción lenta y ver qué estaba bloqueando el hilo principal. Puede aparecer un script de un plugin, una función de tracking, una animación, una recalculación de estilos, una actualización masiva del DOM o una cadena de tareas largas. Las tareas largas, normalmente superiores a 50 milisegundos, son sospechosas habituales porque impiden al navegador atender trabajos críticos justo cuando el usuario pide respuesta. No siempre son culpables únicas, pero huelen fuerte.

En WordPress hay que medir páginas concretas, no solo la home. La portada suele estar más cuidada que una mesa puesta para invitados; los problemas reales viven en plantillas de artículo, categorías, fichas de producto, checkout, páginas con formularios y buscadores internos. Un blog puede tener buen INP en la home y fatal en artículos con vídeos incrustados, bloques sociales, anuncios programáticos y módulos de recomendación. Un ecommerce puede pasar en categorías ligeras y hundirse en filtros, carrito lateral o variaciones de producto. La plantilla manda.

Los sospechosos habituales: JavaScript, anuncios y temas obesos

El primer sospechoso casi siempre es JavaScript excesivo. No todo JavaScript es malo, faltaría más. Sin él no tendríamos interacciones modernas, validaciones, componentes reactivos, analítica avanzada ni muchas funciones necesarias. El problema aparece cuando se ejecuta demasiado, demasiado pronto o sin relación con lo que el usuario está haciendo. Un script de carrusel en una página sin carrusel, un slider inicializado antes de entrar en pantalla, una biblioteca entera para abrir un desplegable, un chat cargado desde el primer milisegundo aunque nadie lo use. Pequeñas extravagancias. Todas con factura.

Los anuncios añaden su propio circo. En medios, blogs monetizados y webs con display, los scripts publicitarios pueden afectar a INP porque introducen tareas, subastas, medición, renderizado de creatividades y cambios de layout. No basta con decir “los anuncios ralentizan”, que es una frase perezosa. Lo relevante es cuándo se cargan, cuántos proveedores intervienen, cómo se priorizan y si bloquean la interacción. Una web editorial puede sobrevivir con publicidad bien gobernada. Con una cascada de terceros descontrolada, el móvil de gama media empieza a sonar a ventilador imaginario.

Los plugins de consentimiento también merecen atención. Algunos CMP y banners de cookies son sorprendentemente pesados para hacer algo tan humilde como preguntar permiso. Cargan dependencias, gestionan categorías, bloquean scripts, disparan eventos y modifican el DOM. Si el usuario intenta cerrar el banner y la página responde tarde, el primer contacto con la marca ya viene con una mueca. Privacidad sí, torpeza no.

Luego están los temas. Hay temas de WordPress que nacieron para hacerlo todo: restaurante, academia, inmobiliaria, tienda, portfolio, revista, clínica dental y, si se insiste, quizá cohete espacial. Esa ambición suele venir con CSS inmenso, JavaScript genérico y opciones que nadie activa pero todos pagan en rendimiento. Un tema ligero, compatible con bloques nativos, con CSS ajustado y menos dependencias suele dar mejor base. No hace magia. Simplemente no empieza la carrera con una nevera atada a la espalda.

WooCommerce, filtros y formularios: donde más se nota

En WooCommerce, el INP puede resentirse en zonas muy concretas: fichas con muchas variaciones, filtros de categoría, carrito, checkout y módulos de upselling. Aquí conviene evitar plugins que duplican funcionalidades, revisar fragmentos AJAX del carrito, reducir scripts por plantilla y probar el flujo completo en móvil. Comprar en una web lenta produce una desconfianza casi animal. El botón tarda, el pago tarda, el campo no responde. El cliente no piensa “qué interesante problema de main thread”. Piensa otra cosa. Peor.

Los formularios también delatan muchas instalaciones de WordPress. Validaciones pesadas, campos condicionales, reCAPTCHA, integraciones con CRM, eventos de analítica, envíos AJAX y mensajes dinámicos pueden convertir un simple “Enviar” en una pequeña ceremonia burocrática. En captación de leads, ese retraso duele. No porque Google lo mida, sino porque el usuario acaba de levantar la mano y la web parece mirar hacia otro lado.

Los buscadores internos y los filtros merecen una prueba aparte. Cuando se activan en cada pulsación de teclado o recalculan demasiados elementos sin pausa, el navegador se atraganta. En móvil se nota todavía más. Un filtro lento no parece sofisticado; parece roto. Y pocas cosas dañan más la confianza que una interfaz que obliga al usuario a adivinar si ha hecho clic, si no, si falta cargar algo o si el sitio simplemente se ha rendido.

Cómo mejorar INP en WordPress sin romper la web

La mejora real empieza quitando trabajo innecesario al navegador. En WordPress, eso significa revisar qué scripts se cargan, dónde se cargan y cuándo se ejecutan. No todo debe aparecer en todas las páginas. Un formulario de contacto no necesita vivir en cada artículo. Un script de reseñas de producto no pinta nada en una categoría informativa. Una biblioteca de mapas no debería cargar en una página que no muestra mapas. Cargar solo lo necesario parece una obviedad, pero media web moderna funciona como si preparara una boda para servir un café.

La descarga diferida ayuda, pero con cuidado. Aplazar JavaScript puede mejorar métricas de carga y reducir bloqueo inicial, aunque si se hace mal puede retrasar interacciones importantes. El objetivo no es mandar todo al final como quien esconde trastos en un armario antes de una visita. El objetivo es priorizar. Lo esencial para la interfaz debe estar disponible cuando el usuario lo necesita; lo decorativo puede esperar; lo invisible, más aún. Diferir scripts no consiste en apagar luces a ciegas.

Dividir tareas largas es otra medida relevante. Cuando una función hace demasiado trabajo de golpe, el navegador no puede respirar. En desarrollos a medida, se puede trocear el procesamiento, ceder el control al hilo principal y permitir que las interacciones entren antes. En un WordPress típico, el editor no siempre toca ese nivel de código, pero sí puede elegir plugins mejor construidos, eliminar widgets pesados, reducir animaciones y pedir a desarrollo que revise los scripts que aparecen como causantes de retrasos en DevTools. No todo se arregla desde el panel de administración, aunque el panel venda esa fantasía con mucho entusiasmo.

Las interacciones críticas merecen trato preferente. Menús móviles, botones de compra, buscadores internos, filtros, acordeones, pestañas de producto, formularios y banners de consentimiento deben responder con rapidez visible. Si una animación pesa demasiado, se simplifica. Si un filtro recalcula medio universo en cada toque, se revisa. Si el mini carrito lanza varias peticiones y bloquea la interfaz, se optimiza. El usuario no premia que el botón sea precioso si parece no funcionar.

Optimizar CSS también importa. Un CSS gigantesco obliga al navegador a calcular más, aplicar más reglas y resolver más conflictos. En temas muy cargados, eliminar estilos no usados, reducir hojas globales y simplificar selectores puede ayudar a que la presentación llegue antes después de una interacción. Menos decoración inútil no significa una web pobre. Significa una web que no convierte cada gesto en una mudanza.

Las imágenes, por su parte, no son el centro de INP, pero pueden empeorar el contexto si fuerzan cambios, consumen recursos o conviven con scripts pesados. Una imagen enorme, un slider heroico, un vídeo de fondo y una animación al hacer scroll no son necesariamente “branding”. A veces son una excavadora entrando en un salón. El rendimiento también tiene gusto. Y el buen gusto, en web, suele pesar poco.

Caché, hosting y CDN ayudan, pero no absuelven

La caché sigue siendo necesaria. Un buen sistema de caché de página, object cache cuando procede, compresión, HTTP/2 o HTTP/3, imágenes optimizadas y CDN pueden mejorar mucho la experiencia general. Reducen carga del servidor, aceleran entrega y ayudan a que la página llegue antes al navegador. Pero INP no es solo velocidad de carga. Una página puede cargar rápido y responder mal. Como un camarero que llega corriendo a la mesa y luego olvida el pedido.

El hosting influye de manera indirecta y a veces directa. Un servidor lento puede retrasar respuestas dinámicas, llamadas AJAX o procesos de checkout, y eso se nota en interacciones concretas. En WordPress con WooCommerce, membresías, buscadores internos o filtros que consultan la base de datos, el backend no desaparece de la película. Conviene revisar PHP actualizado, base de datos limpia, consultas pesadas, object cache persistente y recursos suficientes. No por postureo técnico, sino porque un sitio editorial o comercial con tráfico móvil no puede depender de un servidor que respira como un acordeón viejo.

El CDN tampoco es una varita. Sirve para acercar archivos, cachear recursos, reducir latencia y absorber tráfico. Pero si el problema principal es un plugin que ejecuta 300 milisegundos de JavaScript en cada clic, el CDN entregará ese problema con gran eficiencia. Rápido, sí. Malo, también.

WordPress 6.8 incorporó mejoras de rendimiento relevantes, incluida la carga especulativa, pensada para que ciertas navegaciones parezcan casi instantáneas al anticipar páginas que el usuario podría visitar. También se han ido introduciendo mejoras orientadas a reducir bloqueos y mejorar el comportamiento del frontend. Bienvenido sea. Pero ninguna actualización del core puede limpiar por sí sola una instalación llena de dependencias redundantes, scripts de terceros y decisiones acumuladas durante años. El core mejora; el sitio decide.

El error de mirar solo la puntuación de PageSpeed

PageSpeed Insights es útil, pero se ha convertido en una tragaperras emocional: se mete una URL, se espera el número, se celebra o se sufre. Mal asunto cuando el debate queda reducido a verde, ámbar o rojo. Para mejorar INP en WordPress, la puntuación global importa menos que encontrar qué interacción concreta está fallando y por qué. Una nota de 89 puede ocultar una mala experiencia en un botón clave. Una nota más baja puede convivir con una interacción razonable si el problema está en otra métrica.

Search Console agrupa URLs con comportamientos similares y ayuda a detectar patrones. Si una familia de páginas falla, suele haber una plantilla detrás. Si los artículos con vídeo empeoran, el problema puede estar en los embeds. Si las categorías de WooCommerce sufren, quizá los filtros, el grid de productos o los scripts de variación están empujando demasiado. Si solo falla móvil, que suele ser lo habitual, hay que probar en condiciones móviles. No vale abrir Chrome en un monitor enorme y declarar absuelto al acusado.

Una auditoría seria cruza datos de campo, pruebas de laboratorio y lectura técnica de la plantilla. Primero se localizan las páginas afectadas. Después se reproducen interacciones lentas. Luego se identifican scripts, tareas largas, recalculaciones y bloqueos. Finalmente se decide qué se elimina, qué se retrasa, qué se reescribe y qué se acepta porque aporta valor. Optimizar no es adelgazar por adelgazar. Una web también necesita negocio, medición, publicidad, diseño y conversión. La cuestión es que todo eso no convierta cada clic en una espera con cara de disculpa.

La métrica tiene otra virtud incómoda: obliga a mirar la web como la usa la gente, no como la imagina el equipo. Un usuario no separa rendimiento, diseño, contenido, SEO y conversión. Para él todo es una sola cosa. La página va o no va. Responde o no responde. Le permite avanzar o le hace perder paciencia. INP traduce esa fricción a un número, con todas las limitaciones de cualquier métrica, pero también con una claridad bastante útil para cortar debates eternos.

La parte SEO: no es magia, pero tampoco decorado

Core Web Vitals forma parte de las señales de experiencia de página de Google, aunque no funciona como una palanca mágica que sube posiciones por sí sola. Un contenido malo no se vuelve bueno por tener INP verde. Un sitio sin autoridad no conquista una SERP competida solo por responder rápido. Pero cuando dos resultados compiten en calidad, intención de búsqueda y confianza, la experiencia pesa. Y fuera del ranking puro, la respuesta rápida afecta a métricas de usuario, conversión, navegación interna, recurrencia y dinero. Sí, dinero. Esa métrica tan poco romántica.

En SEO, mejorar INP en WordPress tiene una lectura doble. Por un lado, reduce fricción en el usuario orgánico que llega desde Google, especialmente en móvil. Por otro, obliga a ordenar el sitio: menos plugins inútiles, plantillas más limpias, anuncios mejor gestionados, temas menos obesos, decisiones técnicas menos caprichosas. El rendimiento acaba siendo una forma de higiene editorial y comercial. Lo que sobra se nota. Lo que bloquea, también.

Hay una ironía deliciosa en muchas webs obsesionadas con publicar más y más contenido mientras su interfaz se comporta como una puerta atascada. Se invierte en keyword research, clusters, EEAT, autoridad temática, enlazado interno y titulares brillantes, pero luego el menú móvil tarda en abrir, el buscador se queda congelado y el formulario de lead responde cuando el usuario ya se ha ido. El SEO moderno no vive solo en el texto. Vive en la fricción completa.

También hay una lectura de marca. Una web lenta no parece solo lenta. Parece descuidada. En ecommerce, parece menos segura. En medios, parece menos fiable. En servicios profesionales, parece menos solvente. El usuario no hace un diagnóstico técnico; hace un juicio. A veces injusto, sí. Pero rapidísimo. Si WordPress tarda en obedecer cada clic, la percepción de calidad baja aunque el artículo sea bueno, el producto sea competitivo o la propuesta comercial tenga sentido. La experiencia manda antes de que el argumento pueda defenderse.

Cuando el clic manda, la web obedece

INP ha puesto sobre la mesa algo bastante simple: una web debe reaccionar cuando alguien la toca. No dentro de un rato. No después de ejecutar media docena de scripts decorativos. No cuando el plugin de turno termine su ceremonia privada. WordPress puede cumplir perfectamente, pero necesita menos acumulación y más criterio. Menos “instala este plugin” y más mirar qué ocurre de verdad en el navegador. Menos obsesión por la puntuación final y más atención al gesto humano: tocar, esperar, confiar o irse.

El dato enfada a los usuarios porque no se ve como dato. Se siente como torpeza. Un retraso pequeño parece una duda. Uno grande parece abandono. Y en la web, cuando la interfaz duda, el usuario también. Ahí está la importancia real de INP: no en la sigla, ni en el gráfico, ni en el informe para enseñar en una reunión, sino en ese instante mínimo donde una página demuestra si está viva o solo cargada. El clic manda. WordPress, si quiere competir, tiene que obedecer.