01
Tareas largas en el hilo principal
Las tareas largas de JavaScript impiden que el navegador inicie o termine una interacción con rapidez. Pueden venir de bundles propios, plugins o terceros.
Home / Optimización INP en WordPress
Interaction to Next Paint · WordPress
Optimización INP en WordPress para la interacción que el usuario realmente percibe.
Un INP deficiente significa que la página tarda demasiado en responder visualmente después de una interacción. En WordPress la causa suele ser trabajo del main thread: JavaScript de plugins, widgets de page builders, tags de terceros, actualizaciones costosas del DOM o varios handlers pequeños apilados sobre el mismo clic. Trazo la interacción y reduzco el trabajo que la rodea.
Guía técnica + servicio de implementación · Revisado el 16 de agosto de 2026
01 · Lo que suele fallar
El clic es rápido. El trabajo asociado no lo es.
INP observa la latencia de interacción durante una visita. Eso lo hace especialmente sensible al trabajo JavaScript que se acumula después de la carga: tags de marketing, sliders, builders, filtros, validación y grandes actualizaciones del DOM.
02
Manejadores de eventos pesados
Un manejador de clic que lee/escribe el layout, recorre un DOM grande o inicializa componentes de forma síncrona puede generar retraso de procesamiento.
03
Contención por terceros
Analítica, consentimiento, chat, anuncios y scripts de experimentación pueden ocupar el mismo main thread justo cuando el usuario intenta interactuar.
04
Actualizaciones costosas del DOM
Mega menús, filtros, popups y widgets de builders pueden disparar trabajo costoso de style/layout/paint cuando añaden, eliminan o modifican muchos nodos.
05
Inicialización en la primera interacción
Algunos plugins inicializan widgets complejos en el primer uso. Diferir trabajo solo sirve si el primer clic del usuario no tiene que pagar todo el coste de inicialización.
06
Interacciones que dependen del servidor
La búsqueda AJAX, los filtros y el checkout mezclan latencia del navegador con latencia de red/servidor, por lo que una mala respuesta puede requerir perfilar frontend y backend juntos.
02 · Diagnosticar antes de cambiar
Registra la interacción y después inspecciona qué ocupó el hilo principal.
Reproduzco la acción lenta —menú, filtro, formulario, búsqueda o checkout— en DevTools y con datos de campo/RUM cuando están disponibles. Así se evita perder tiempo en scripts que no tienen relación con la interacción que realmente experimentan los usuarios.
Traza de interacción a pintado
Divido el evento en input delay, tiempo de procesamiento del handler y presentation delay, en lugar de tratar el valor final de INP como un único número opaco.
Tareas largas alrededor del evento
Identifico los scripts que se ejecutan antes y durante la interacción y los relaciono con código del tema, plugins o terceros.
Coste de los manejadores
Inspecciona los listeners y el código de componentes buscando trabajo síncrono, layout forzado y operaciones repetidas sobre el DOM.
Presión sobre DOM y layout
Las estructuras grandes o muy anidadas encarecen las actualizaciones de estilos/layout, especialmente en constructores, mega menús y filtros facetados.
Programación de terceros
Mide la ejecución de consentimiento, analítica y chat, y aparta el trabajo no crítico de los momentos sensibles a la interacción cuando sea posible.
Separación de AJAX
En filtros, búsqueda y checkout, separo el tiempo del handler del navegador del tiempo de solicitud/servidor y del renderizado de la respuesta para corregir la capa adecuada.
03 · Implementation
Reduce el trabajo antes del siguiente renderizado.
El objetivo no es retrasar indiscriminadamente todos los scripts. Es mantener rápidas las interacciones críticas sin romper analítica, consentimiento ni funcionalidad de la aplicación.
Elegir interacciones representativas
Uso señales de campo y flujos críticos de negocio —menú, filtro de producto, añadir al carrito, checkout, búsqueda, formulario— en lugar de probar clics aleatorios.
Quitar JavaScript innecesario
Descargo scripts de páginas donde no se necesitan y elimino bibliotecas o código de widgets duplicado o heredado cuando es seguro.
Dividir tareas pesadas
Refactorizo trabajo síncrono largo, reduzco cambios innecesarios del DOM y programo trabajo no urgente para que el navegador pueda pintar feedback antes.
Optimizar la estructura de componentes
Simplifica menús, filtros, popups y widgets del constructor que provocan layouts costosos o inicializaciones repetidas.
Controlar a terceros
Carga el código de marketing, chat y experimentación con prioridades y comportamiento de consentimiento deliberados; después confirma que la medición sigue funcionando.
Verificar tiempos en producción
Vuelve a probar tras aplicar minificación, caché y CDN en producción, porque el orden y timing de los scripts pueden diferir de staging.
04 · Lo que realmente recibes
Interacciones rápidas, no solo un número mejor en laboratorio.
El handover relaciona un INP deficiente con scripts/componentes concretos para que futuros cambios puedan revisarse contra las mismas rutas de interacción.
01
Traza de interacción
El evento concreto y el trabajo del main thread responsables de la respuesta lenta.
02
Mapa de responsables de cada script
Fuentes de tema, plugins y terceros vinculadas a tareas largas durante la interacción.
03
Correcciones de código y recursos
Descarga selectiva, refactorización, programación o cambios de componentes.
04
Plan para terceros
Decisión clara sobre qué carga inmediatamente, después del consentimiento, cuando el navegador está idle o solo en páginas que lo necesitan.
05
QA funcional
Menús, filtros, formularios, añadir al carrito y checkout validados después de cambios en JavaScript.
06
Notas de medición
Cómo reproducir la traza y qué monitorizar mientras se acumulan los datos de campo.
Si el sitio carga rápido pero se siente pesado al hacer clic, INP es la métrica que hay que investigar.
Para fallos combinados de LCP, INP y CLS, usa el servicio completo de Core Web Vitals para WordPress.
FAQ
Preguntas que recibo antes de tocar producción.
¿Cuál es una buena puntuación INP?
Para Core Web Vitals, un buen Interaction to Next Paint es de 200 milisegundos o menos en el percentil 75. El objetivo son los datos de campo; las trazas de interacción en laboratorio identifican por qué una acción es lenta.
¿Un plugin de caché puede corregir el INP?
La caché de página puede mejorar la respuesta del servidor y la carga inicial, pero la mayoría de problemas de INP son trabajo de interacción en el main thread después de cargar. JavaScript, DOM/layout y scripts de terceros requieren atención separada.
¿Por qué el INP es malo solo en móvil?
Las CPU móviles más lentas hacen más visibles las tareas largas de JavaScript y el trabajo de DOM. Una interacción que parece fluida en un ordenador de escritorio puede superar el umbral en teléfonos de gama media.
¿Qué plugins de WordPress provocan un INP malo?
No existe una lista universal fiable. Builders, sliders, popups, chat, consentimiento, analítica, filtros y formularios pueden contribuir según su configuración. Traza la interacción real y relaciona el script que se ejecuta con su origen.
¿Retrasar JavaScript mejora siempre el INP?
No. Mover una inicialización costosa al primer clic puede empeorar INP. Las estrategias de diferido deben mantener el trabajo no crítico lejos de los momentos sensibles a la interacción.
¿La latencia del servidor puede afectar al INP?
En interacciones que esperan solicitudes de red —filtros, búsqueda, checkout— la respuesta percibida por el usuario incluye trabajo del navegador y del servidor. La traza debe separar esas capas antes de optimizar.