WordPress sin JavaScript pesado: INP móvil sin retrasos

INP WordPress móvil ya no es una rareza de laboratorio ni una manía de consultor con demasiadas pestañas abiertas. Es una forma bastante cruda de medir si una web responde cuando el usuario toca la pantalla, pulsa un botón, abre un menú, escribe en un buscador interno o intenta cerrar ese banner de cookies que aparece como un portero de discoteca. En términos prácticos: una página puede cargar rápido y, aun así, sentirse torpe. Como una puerta automática que se abre tarde.

Google considera que una página ofrece una buena experiencia de interacción cuando el Interaction to Next Paint se mantiene por debajo de 200 milisegundos en el percentil 75, separado por móvil y escritorio. Entre 200 y 500 milisegundos la cosa ya pide taller; por encima de 500, el usuario empieza a notar el atasco, aunque no sepa ponerle nombre. Desde marzo de 2024, INP sustituyó a FID como métrica estable de Core Web Vitals, precisamente porque FID miraba solo la primera interacción y dejaba fuera buena parte de la vida real de una página.

En WordPress, el problema suele tener menos glamour del que prometen algunos dashboards. No suele ser una conspiración del algoritmo, ni una tragedia inevitable del CMS más usado del planeta. Casi siempre hay una mezcla de tema demasiado cargado, constructor visual con hambre, plugins que meten scripts en todas las páginas, analítica duplicada, etiquetas de marketing con diarrea nerviosa, vídeos incrustados, sliders decorativos y menús móviles que parecen una pequeña aplicación dentro de otra aplicación. Todo eso cae sobre el mismo sitio: el hilo principal del navegador. Y en móvil, ese hilo no es una autopista alemana. Es una calle estrecha en agosto, con furgonetas descargando.

El punto importante para SEO y negocio es este: optimizar INP en WordPress móvil no consiste en perseguir un 100 en PageSpeed, sino en reducir el trabajo que bloquea la respuesta del navegador. La caché ayuda, el CDN ayuda, la compresión ayuda, claro. Pero cuando el dedo toca la pantalla y el navegador está ocupado interpretando JavaScript que nadie necesitaba en ese momento, la web tarda. El usuario no ve “JavaScript no crítico ejecutándose”. Ve una web que no obedece.

WordPress no es lento: lo vuelven lento

WordPress moderno no parte de cero ni está condenado. Las últimas versiones han ido incorporando mejoras de rendimiento reales, desde estrategias de carga de scripts hasta APIs más limpias para interactividad. WordPress 6.3 introdujo soporte nativo para cargar scripts con defer y async mediante sus APIs; WordPress 6.5 incorporó módulos JavaScript y la Interactivity API; WordPress 6.9 añadió mejoras de rendimiento en frontend, carga de estilos y scripts, y optimizaciones orientadas a LCP. A fecha de mayo de 2026, WordPress 7.0 está todavía en fase Release Candidate 4, por lo que no debe instalarse en producción salvo entornos de prueba.

La paradoja está servida: el núcleo mejora, pero muchas instalaciones empeoran. Es el viejo drama del piso recién reformado lleno de muebles heredados. WordPress puede servir una página razonablemente ligera, pero luego llegan el page builder, el popup, el carrusel, el comparador, el chat, el pixel, el tag manager con medio ecosistema dentro, el plugin de reseñas, el de redes sociales, el de consentimiento, el de formularios, el de A/B testing y el de “optimización” que carga otro panel propio. Al final, la portada parece un mercadillo de JavaScript.

En móvil se paga todo. Más. El informe Web Almanac de HTTP Archive muestra que las páginas móviles acumulan muchas más tareas largas que las de escritorio y que el tiempo dedicado a esas tareas largas es mucho mayor en móvil. La mediana móvil registraba 14 tareas largas por página frente a 3 en escritorio, y más de 2,3 segundos dedicados a long tasks, muy por encima del entorno desktop. No es un matiz técnico: es la explicación de por qué un sitio “va bien en mi ordenador” y se arrastra en un Android medio con cobertura mediocre.

WordPress, además, arrastra una cultura peligrosa: instalar antes de medir. Falta un botón, plugin. Falta un aviso, plugin. Falta un formulario, plugin. Falta una animación, plugin. Es cómodo, sí. También es la manera más rápida de convertir una web editorial o ecommerce en una mochila llena de piedras. Y luego se mira Search Console con cara de sorpresa, como quien encuentra agua en el sótano después de dejar el grifo abierto.

Qué mide INP cuando el usuario toca la pantalla

INP mide la latencia de las interacciones durante la visita: clics, toques y entradas de teclado. No se queda en el primer toque. Observa la sesión y reporta una interacción representativa de las peores, descartando determinados valores extremos en páginas con muchas interacciones. Por eso es más incómodo que FID. Porque no permite esconder la suciedad debajo de la primera carga.

La interacción tiene tres piezas: retraso de entrada, tiempo de procesamiento y retraso de presentación. Dicho en cristiano: cuánto tarda el navegador en empezar a atender el gesto, cuánto tarda el JavaScript en hacer su trabajo y cuánto tarda la pantalla en pintar el resultado. Si un menú hamburguesa tarda en abrirse, puede ser porque el navegador estaba ocupado con una tarea larga, porque el evento del menú ejecuta demasiado código, o porque después de ejecutarlo hay que recalcular estilos, layout y pintura como si se estuviera mudando una catedral.

Aquí aparece el sospechoso principal: el JavaScript pesado. No porque JavaScript sea malo. JavaScript es necesario. Sin él no habría buscadores internos vivos, filtros, carritos, validaciones, menús avanzados ni experiencias modernas. El problema es su abuso, su carga indiscriminada y su ejecución en páginas donde no pinta nada. Un plugin de checkout no debería cargar todo su arsenal en un artículo informativo. Un script de slider no debería aparecer en una plantilla sin slider. Un formulario de contacto no necesita respirar en cada URL del sitio como si fuera el Espíritu Santo.

En INP WordPress móvil, el diagnóstico debe mirar menos la foto del laboratorio y más los datos de campo. Lighthouse puede orientar, pero INP se entiende de verdad con datos reales: Search Console, CrUX, PageSpeed Insights con información de usuarios, medición propia con la biblioteca web-vitals, trazas en Chrome DevTools y pruebas manuales sobre interacciones concretas. Google recuerda que Search Console agrupa URLs por estado, métrica y grupos similares, usando datos reales de usuarios cuando hay volumen suficiente. Eso explica por qué un cambio tarda días en verse y por qué una URL puede aparecer castigada por el comportamiento de un conjunto, no por una captura puntual tomada con café y buena fibra.

El JavaScript que sobra casi siempre está a la vista

La mejora de INP rara vez empieza con una gran refactorización épica. Empieza abriendo la página como quien abre un armario lleno de trastos. Hay scripts que se cargan en todas partes y solo se usan en una. Hay bibliotecas enteras para resolver una interacción mínima. Hay animaciones de entrada que bloquean más de lo que decoran. Hay menús móviles construidos con más capas que una lasaña. Hay consentimiento de cookies que, en algunas webs, pesa como un ministerio.

El patrón se repite en sitios editoriales: portada cargada de bloques, anuncios, recomendaciones, embeds sociales, vídeos, newsletters, tracking y módulos de “última hora”. En ecommerce, la película cambia de decorado pero no de trama: filtros, variaciones de producto, carritos laterales, chat, reviews, pagos aplazados, píxeles de remarketing, sistemas antifraude, mapas de calor. Cada elemento tiene una justificación comercial. Todos juntos, a veces, fabrican una experiencia pegajosa. El dedo toca y la web tarda un suspiro largo. Ese suspiro es INP.

Conviene desconfiar de las soluciones mágicas. Minificar no elimina trabajo; solo lo empaqueta. Combinar scripts puede incluso empeorar la situación si genera un bloque enorme que el navegador debe descargar, parsear y ejecutar de golpe. Diferir todo sin criterio puede romper dependencias o retrasar funcionalidades necesarias. Cargar async a lo loco es como soltar ciclistas en una rotonda sin señales: alguno llegará, pero no necesariamente en orden ni sin susto.

WordPress ofrece herramientas mejores que hace unos años. La estrategia defer permite cargar scripts sin bloquear el parseo inicial del HTML y conservar el orden de ejecución; async puede ser útil para scripts independientes, aunque exige más cuidado. WordPress aplica lógica de elegibilidad porque no todos los scripts pueden diferirse si dependen de otros o tienen código inline asociado. Este detalle técnico evita una carnicería elegante: optimizar por atributo y romper la web por dependencia.

La limpieza útil suele ser más quirúrgica. Cargar scripts solo donde hacen falta. Sustituir sliders por HTML y CSS cuando no aportan nada. Evitar librerías completas para comportamientos sencillos. Reducir listeners globales de scroll y resize. Romper tareas largas. Pasar trabajo no urgente a momentos posteriores. Evitar que el primer toque del usuario coincida con una digestión pesada de scripts de marketing. Y revisar terceros. Ahí hay barro. Muchos sitios no fallan por su código, sino por la romería de terceros que han invitado a casa.

Medir antes de tocar: la diferencia entre cirugía y superstición

El error clásico en WordPress es empezar por el plugin de rendimiento de moda. Puede ayudar, pero no sustituye el diagnóstico. Para mejorar INP WordPress móvil, primero hay que saber qué interacción falla. No basta con ver “INP pobre”. Hay que descubrir si el problema está en el menú, el buscador, los filtros, el botón de añadir al carrito, el consentimiento de cookies, el acordeón de preguntas, el formulario, el login o una interacción dentro de un iframe publicitario. Google subraya que INP puede incluir interacciones lentas dentro de iframes y que cada contexto tiene su propio hilo principal, aunque en dispositivos limitados el impacto se contagia.

Search Console da la alarma. PageSpeed Insights ayuda a cruzar datos de campo y laboratorio. DevTools permite grabar una traza, tocar exactamente el elemento conflictivo y ver qué tareas bloquean la respuesta. En móvil real, mejor todavía. La emulación sirve, pero no huele igual. Hay Android de gama media que enseñan más sobre rendimiento que diez informes verdes en escritorio.

En un proyecto SEO serio, la medición debe separar plantillas. No tiene sentido mezclar portada, post, categoría, producto, checkout y landing de captación como si fueran el mismo animal. Un post informativo puede tener buen LCP y mal INP por un bloque de recomendados o por un banner invasivo. Una ficha de producto puede fallar por variaciones, reviews y scripts de pago. Una categoría puede sufrir por filtros en cliente, scroll infinito y tarjetas con imágenes mal planteadas. Cada plantilla tiene su propio crimen.

La decisión editorial también cuenta. En medios y blogs de marketing digital se ha normalizado meter demasiados módulos “para retener”. Relacionados, más leídos, newsletter, autor, bio expandida, tabla de contenidos, anuncios, vídeo, carruseles, recomendador, etiquetas, caja de herramientas, popup. Todo suma. Pero la experiencia no siempre mejora por acumulación. A veces una página convierte mejor cuando respira. Qué escándalo: menos cosas, más lectura.

Una arquitectura ligera también vende

Existe una confusión peligrosa: pensar que una web ligera es una web pobre. No. Una web ligera es una web que decide. Carga lo necesario, aplaza lo secundario y no convierte cada interacción en una mudanza del DOM. En WordPress, esto significa elegir temas sobrios, bloques bien hechos, plugins auditados y una arquitectura donde el contenido no dependa de un castillo de scripts para mostrarse.

Para un blog profesional como seoetico.com, la prioridad editorial debería ser clara: lectura rápida, navegación limpia, buscador interno si aporta valor, categorías bien resueltas, tablas o comparativas solo cuando tengan sentido, anuncios o captación sin secuestrar el primer toque. El usuario que llega desde Google Discover, desde una búsqueda técnica o desde redes no viene a admirar una coreografía de animaciones. Viene a resolver algo. Si la web responde tarde, el texto pierde autoridad antes de que el lector llegue al segundo párrafo.

En ecommerce, el equilibrio es más delicado. No se puede eliminar la interactividad porque la venta vive de ella. Pero sí se puede ordenar. Los filtros deben ser rápidos, el carrito debe responder, las variaciones no deberían bloquear media página, las reseñas pueden hidratarse cuando entran en viewport, el chat no tiene por qué competir con el primer renderizado, los métodos de pago no deben cargar todo su equipaje antes de que el usuario muestre intención. El rendimiento aquí no es estética técnica. Es caja registradora.

Google insiste en que Core Web Vitals forman parte de lo que sus sistemas buscan recompensar dentro de una buena experiencia de página, aunque también advierte de que obtener buenos resultados no garantiza posiciones por sí solo. Esto es importante para no vender humo: INP no sustituye al contenido, a la intención de búsqueda ni a la autoridad. Pero una web con buen contenido y mala respuesta móvil está regalando fricción. Y la fricción, en SEO, no siempre grita; a veces solo erosiona.

La parte menos vistosa es la gobernanza. Antes de instalar un plugin, debería existir una pregunta incómoda: qué script añade, dónde se carga, cuánto pesa, qué interacción toca y qué pasa si se desactiva. Antes de insertar un nuevo píxel, otra: aporta datos accionables o solo calma la ansiedad del dashboard. Antes de aprobar un diseño con tres animaciones en móvil, una tercera: mejora la comprensión o solo decora la espera. Parece sentido común. Lo es. Por eso se ignora tanto.

El móvil no perdona la fantasía

El futuro inmediato de WordPress va hacia más capacidades, más edición visual, más bloques, más colaboración, más APIs y más automatización. Bien usado, eso puede mejorar mucho la producción web. Mal usado, puede fabricar páginas cada vez más pesadas con una facilidad deliciosa. La técnica avanza; la tentación también.

La buena noticia es que INP WordPress móvil se puede mejorar sin convertir una web en una sábana blanca sin vida. No hay que renunciar a la analítica, ni al marketing, ni a la conversión, ni a una interfaz cuidada. Hay que quitar grasa. Cargar menos JavaScript al inicio, ejecutar menos trabajo en cada interacción, aislar plugins por plantilla, revisar terceros, medir con usuarios reales y entender que el móvil no es una versión pequeña del escritorio. Es otro campo de batalla, con menos CPU, menos paciencia y menos margen para el teatro.

Una web que responde bien transmite algo que el usuario no verbaliza pero siente: control. Toca y ocurre. Pulsa y cambia. Escribe y aparece. No hay gelatina bajo el dedo. Para Google, para SEO y para negocio, esa sensación importa porque está pegada a la experiencia real, no al escaparate técnico. Y para WordPress, el mensaje es bastante simple, casi antipático: el CMS puede correr; lo que no puede hacer es cargar con todos los caprichos de una instalación sin criterio.

El rendimiento móvil ya no se arregla maquillando el marcador. Se arregla quitando ruido. Menos JavaScript inútil, menos terceros desbocados, menos menús convertidos en aplicaciones, menos plugins con bula papal. Más HTML que llega pronto, más CSS sobrio, más interacción nativa, más medición de campo, más decisiones editoriales con consecuencias técnicas. Ahí, en esa austeridad inteligente, WordPress vuelve a moverse con dignidad. Y el INP deja de ser una luz roja para convertirse en lo que debería haber sido desde el principio: una comprobación de que la web responde cuando alguien, al otro lado, simplemente toca la pantalla.