En 2026, la definición de un sitio web "rápido" ya no depende solo de lo pronto que aparece la primera imagen. Hoy la velocidad también se define por la capacidad de respuesta.
Cuando un usuario hace clic en un botón de tu sitio WordPress, ¿reacciona al instante o se nota un pequeño tirón? Ese intervalo, el tiempo entre la acción del usuario y la respuesta visual del navegador, es lo que mide Interaction to Next Paint (INP). INP es una de las tres Core Web Vitals, y Google Search afirma que sus sistemas de clasificación utilizan las Core Web Vitals. La misma documentación añade que no existe una única señal de experiencia de página y que la relevancia va primero, así que INP sirve para desempatar entre páginas útiles, no como atajo para adelantarlas. La razón de más peso para corregirlo es el visitante: un menú lento o un botón “Añadir al carrito” congelado se nota en cada visita a la página.
Esta guía, complemento de nuestra guía de Core Web Vitals 2026, explica cómo se calcula INP, qué ralentiza cada fase de una interacción en un sitio WordPress típico, cómo encontrar el script responsable con Long Animation Frames y qué APIs de WordPress ayudan.
Qué es INP y cuándo sustituyó a FID
INP pasó a ser una Core Web Vital estable el 12 de marzo de 2024, en sustitución de First Input Delay (FID). El artículo de lanzamiento en web.dev dio a los desarrolladores de plazo hasta el 9 de septiembre de 2024 para migrar cualquier código que leyera FID de las APIs de CrUX o PageSpeed Insights; después de esa fecha, la disponibilidad de FID dejó de estar garantizada. PageSpeed Insights evalúa ahora INP en lugar de FID en su valoración de Core Web Vitals.
La diferencia entre ambas métricas es el alcance. FID medía solo el retraso de entrada de la primera interacción en una página. INP observa la latencia completa (retraso de entrada, procesamiento y presentación) de cada clic, toque y pulsación de tecla durante toda la visita, de modo que una página que carga bien pero se atasca en su tercera interacción ya no aprueba.
Cómo se calcula INP
La definición de INP en web.dev establece tres franjas, evaluadas en el percentil 75 de las cargas de página y separadas entre móvil y escritorio:
| Valor de INP | Calificación |
|---|---|
| 200 ms o menos | Bueno |
| Más de 200 ms y hasta 500 ms | Necesita mejorar |
| Más de 500 ms | Deficiente |
En cada visita a una página, el navegador registra la latencia de todas las interacciones observadas. El INP que se informa es la más larga, con una regla para páginas con mucha actividad: se ignora la interacción más alta por cada 50 interacciones. La mayoría de las visitas tienen menos de 50 interacciones, así que en la práctica la peor interacción suele convertirse en el INP de esa visita. Si recoges INP tú mismo con JavaScript, web.dev sugiere tomar el percentil 98 de las interacciones al descargar la página, lo que se aproxima a la misma regla.
Solo cuentan los clics de ratón, los toques en pantallas táctiles y las pulsaciones de teclas. Pasar el cursor por encima, desplazarse y hacer zoom no se observan, aunque un clic o una pulsación de tecla dentro de esos gestos sí puede contar. Eso tiene una consecuencia práctica: una página puede no tener ningún valor de INP. Ocurre cuando el visitante nunca hace clic, toca ni escribe, cuando solo se desplaza, o cuando la visita procede de un bot, como un rastreador de buscador que no estaba programado para interactuar. Una entrada de blog en la que la mayoría de lectores solo hace scroll suele tener datos de INP más escasos que una página de producto con selector de variantes.
Cuáles son las tres fases de INP
Cada interacción que mide INP es la suma de tres partes, tal como describe la guía de web.dev para optimizar INP:
- Retraso de entrada (input delay): desde que el usuario inicia la interacción hasta que empieza a ejecutarse el primer callback de un manejador de eventos. Crece cuando el hilo principal está ocupado con otra cosa, como el análisis de un script, un temporizador que se dispara o una interacción anterior que todavía se está procesando.
- Duración del procesamiento (processing duration): el tiempo que tardan en ejecutarse todos los callbacks de manejadores de eventos de esa interacción.
- Retraso de presentación (presentation delay): desde el final de los callbacks hasta que el navegador pinta el siguiente frame, lo que incluye el recálculo de estilos, el layout y el pintado.
Para obtener la calificación “Bueno”, cada interacción, desde un clic en el menú de navegación hasta una pulsación de tecla en un campo de búsqueda, tiene que completarse visualmente en 200 ms o menos. Corregir una interacción lenta suele dejar al descubierto la siguiente, así que plantea la optimización de INP como un ciclo iterativo y no como una tarea única.
Cómo reducir el retraso de entrada en WordPress
El retraso de entrada suele deberse a que el hilo principal está ocupado justo cuando el usuario intenta hacer clic. En sitios WordPress, las fuentes más habituales son la evaluación de scripts durante la carga (análisis, compilación y ejecución del JavaScript de plugins y del tema) y los scripts de terceros que ejecutan trabajo periódico sin tener en cuenta lo que hace el usuario.
Cómo ceder el hilo principal con scheduler.yield()
El artículo de web.dev sobre tareas largas define una tarea larga como cualquier tarea de más de 50 ms. La solución es dividir el trabajo largo de JavaScript en tareas más pequeñas para que el navegador pueda atender una interacción entre ellas. scheduler.yield() devuelve una promesa que se resuelve en una nueva tarea, y su continuación tiene prioridad: el resto de tu trabajo se reanuda antes que otras tareas del mismo tipo en cola, de modo que un script de terceros no puede colarse entre tus fragmentos.
El soporte importa aquí. scheduler.yield() está disponible en Chrome 129, Edge 129 y Firefox 142, y Safari no lo admite. web.dev recomienda un fallback a setTimeout(), que también cede el control, solo que sin la continuación priorizada:
function yieldToMain() {
if (globalThis.scheduler?.yield) {
return scheduler.yield();
}
return new Promise((resolve) => setTimeout(resolve, 0));
}
async function processLargeList(items) {
for (const item of items) {
expensiveOperation(item);
await yieldToMain();
}
}Los tutoriales antiguos condicionan la cesión a navigator.scheduling.isInputPending(). web.dev ya no recomienda esa API: puede devolver false justo después de una interacción del usuario, y la entrada no es el único motivo para ceder, porque las animaciones y otras actualizaciones de renderizado también necesitan el hilo principal. Cede el control haya o no entrada pendiente.
Cómo eliminar el JavaScript que no se usa en WordPress
Solo debería cargarse el JavaScript necesario para la vista actual. Si un usuario está en una entrada del blog, no hay motivo para que haya una librería de checkout en la página. La carga condicional de recursos, por plantilla o por bloque, es lo primero que revisamos en una auditoría de INP de WordPress, porque el código que nunca se carga nunca puede bloquear una interacción. Encontrarás más sobre esto en nuestra guía de optimización de la velocidad de WordPress.
Cómo diferir scripts con la estrategia de carga de WordPress 6.3
WordPress 6.3 añadió una estrategia de carga a wp_register_script() y wp_enqueue_script(), documentada en la nota de Make WordPress Core sobre async y defer. El quinto parámetro acepta ahora un array con dos claves, strategy (defer o async) e in_footer:
wp_enqueue_script(
'wppoland-filters',
get_theme_file_uri( 'assets/filters.js' ),
array(),
'1.4.2',
array(
'strategy' => 'defer',
'in_footer' => true,
)
);La estrategia es una petición, no una garantía. WordPress revisa el árbol de dependencias: un script diferido del que depende un script bloqueante pasa también a ser bloqueante, para mantener el orden de ejecución. Un script en línea añadido con la posición after también obliga a su script padre a volver a ser bloqueante, y ese cambio puede propagarse en cascada por el árbol. Por eso, después de cambiar un tema o un plugin a defer, mira el código fuente de la página y confirma que el atributo está realmente ahí. La misma nota recomienda sustituir los viejos apaños con el filtro script_loader_tag por esta API.
Cómo reducir el tiempo de procesamiento de INP
Aquí es donde se pone a prueba la eficiencia de tu propio código. El consejo general de web.dev es hacer el menor trabajo posible en los callbacks de eventos.
Cómo mantener ligeros los manejadores de eventos
Evita la lógica compleja dentro de los manejadores de clic. Actualiza la parte de la interfaz que el usuario está esperando, cede el control y ejecuta todo lo demás en una tarea posterior. El ejemplo de web.dev usa un cuadro de texto: el carácter escrito se muestra de inmediato, mientras que el recuento de palabras, la corrección ortográfica y el guardado se aplazan con requestAnimationFrame() y un setTimeout() dentro de él, de modo que se ejecutan después de pintar el siguiente frame.
button.addEventListener('click', () => {
const price = calculatePrice(product, variant);
priceElement.textContent = formatPrice(price);
requestAnimationFrame(() => {
setTimeout(() => {
sendAnalytics('price_calculated', price);
saveCartDraft(product, price);
}, 0);
});
});El cambio visible ocurre en el manejador, y la analítica y el almacenamiento esperan hasta que se ha pintado el frame con el nuevo precio.
Cómo evitar el layout thrashing
El layout thrashing, también llamado layout síncrono forzado, se produce cuando el código cambia estilos y después lee una propiedad de layout como offsetWidth en la misma tarea. El navegador tiene que calcular el layout en ese mismo momento en lugar de hacerlo una vez al final del frame, y en un bucle eso ocurre en cada iteración. Lee primero todos los valores y luego escribe:
// Fuerza el layout en cada iteración: evítalo
elements.forEach((el) => {
const width = el.offsetWidth;
el.style.width = width + 10 + 'px';
});
// Primero lee, después escribe
const widths = elements.map((el) => el.offsetWidth);
elements.forEach((el, i) => {
el.style.width = widths[i] + 10 + 'px';
});Cómo sacar los scripts de terceros del hilo principal
Los scripts de terceros no esenciales, como widgets de chat y etiquetas de analítica, pueden trasladarse a un Web Worker con una librería como Partytown, para que dejen de competir con los manejadores de eventos en el hilo principal. No sirve para todos los scripts, porque algunas etiquetas necesitan acceso síncrono al DOM. Analizamos los pros y contras, incluidas las etiquetas que fallan dentro de un worker, en nuestra guía para reducir el impacto de los scripts de terceros en WordPress.
Cómo gestionar listas largas
En páginas con listas largas, como archivos del blog, páginas de categoría de WooCommerce o tablas de datos, renderizar cientos de elementos de entrada hace que cada interacción posterior pague el coste de un DOM grande. La virtualización renderiza solo los elementos cercanos al viewport y crea y elimina elementos a medida que el usuario se desplaza. La paginación o los botones “cargar más” consiguen el mismo objetivo con menos JavaScript.
Cómo corregir el retraso de presentación
Aunque tu código termine rápido, al navegador todavía puede costarle pintar el resultado cuando el DOM es grande o los estilos son caros de recalcular.
Cómo afecta el tamaño del DOM a INP
web.dev señala que el trabajo de renderizado crece con el tamaño del DOM, aunque no de forma lineal, y que un DOM grande ralentiza tanto el primer renderizado como el renderizado tras cada interacción. Hay dos opciones: aplanar el DOM, que en WordPress suele significar menos elementos envolventes del tema o del maquetador, y añadir nodos solo cuando una interacción los necesita, en lugar de renderizar de entrada todas las pestañas, ventanas modales y megamenús.
Cómo usar content-visibility y contain
content-visibility: auto permite al navegador saltarse el layout y el pintado de un elemento hasta que se acerca al viewport. Según el artículo de web.dev sobre content-visibility, la demo del blog de viajes redujo su tiempo de renderizado inicial de 232 ms a 30 ms, y la propiedad es Baseline recién disponible desde el 15 de septiembre de 2025 (Chrome 85, Firefox 125, Safari 18). Combínala con contain-intrinsic-size para que las secciones omitidas conserven una altura de reserva; la palabra clave auto hace que el navegador recuerde el último tamaño renderizado:
.comments-section {
content-visibility: auto;
contain-intrinsic-size: auto 2000px;
}
.sidebar {
contain: layout style paint;
}La propiedad contain en secciones independientes, como una barra lateral o un bloque de comentarios, indica al navegador que un cambio dentro de ellas no afectará al resto de la página, lo que limita cuánta parte de la página hay que recalcular antes del siguiente pintado.
Por qué renderizar HTML en el cliente empeora el retraso de presentación
Cuando el HTML llega por streaming desde el servidor, el navegador lo analiza por fragmentos y cede el control entre ellos. Cuando un script construye grandes cantidades de HTML en el cliente, el navegador no cede hasta haber analizado y renderizado ese HTML, lo que puede retrasar el siguiente frame. En WordPress esto aparece en los filtros AJAX y en los botones “cargar más” que inyectan de golpe una cadena de HTML enorme. Insertar lotes más pequeños, con una cesión entre ellos, mantiene corto el frame posterior al clic.
Qué provoca un INP deficiente en WordPress
Estos son los culpables que encontramos con más frecuencia cuando un sitio WordPress suspende en INP. Ninguno es exclusivo de WordPress, pero los plugins hacen que sea fácil instalarlos sin darse cuenta.
Maquetadores pesados
Divi y Elementor suelen añadir un anidamiento profundo del DOM, con varios elementos envolventes alrededor de cada widget, lo que hace más lento el recálculo del layout tras una interacción. Comprueba la profundidad en el panel Elements de DevTools antes y después de sustituir una sección por bloques nativos.
Widgets de chat
La mayoría de los scripts de chat en vivo consumen mucho hilo principal: se cargan y empiezan a trabajar en todas las páginas. Un patrón de carga al hacer clic, en el que un botón ligero carga el widget real solo cuando el usuario pide ayuda, elimina ese trabajo de las páginas donde nadie chatea.
Sliders con rotación automática
Las transiciones que se disparan cada pocos segundos pueden coincidir con los clics del usuario. Si el navegador está a mitad de una transición del slider cuando el usuario toca un enlace del menú, la interacción tiene que esperar a que termine ese trabajo, y eso aparece como retraso de entrada.
Scripts de WooCommerce fuera de la tienda
Los fragmentos del carrito y otros scripts de la tienda pueden acabar cargándose en páginas sin ninguna función de tienda, como las entradas del blog. Comprueba qué scripts de WooCommerce encola cada plantilla y consulta nuestra guía de rendimiento de WooCommerce para soluciones específicas de tiendas.
Google Maps incrustado
Un mapa de Google Maps incrustado carga una cantidad considerable de JavaScript y mantiene activos sus event listeners. Una imagen estática que carga el mapa interactivo al hacer clic evita ese coste a los visitantes que nunca usan el mapa.
Mejores herramientas para medir INP en 2026
Para corregir INP necesitas datos de usuarios reales y una forma de reproducir la interacción lenta en laboratorio.
CrUX API y PageSpeed Insights
La documentación de la CrUX API describe los datos como una media móvil de 28 días, actualizada a diario hacia las 04:00 UTC y con unos dos días de retraso respecto a la fecha actual. Cada métrica incluye un histograma y un valor p75, y puedes filtrar por PHONE, DESKTOP o TABLET. Solo aportan datos los usuarios de Chrome en escritorio y Android que han dado su consentimiento, así que Chrome en iOS y otros navegadores Chromium como Edge no figuran en los datos. Las páginas con poco tráfico a menudo no tienen registro propio y recurren a los datos del origen. PageSpeed Insights y el informe de Core Web Vitals de Search Console muestran los mismos datos de campo.
Cómo encontrar el script lento con Long Animation Frames (LoAF)
La API Long Animation Frames llegó en Chrome 123. Informa de cualquier frame cuya actualización de renderizado se retrasa más de 50 ms y, a diferencia de la API Long Tasks, agrupa el trabajo por frame, que es como se percibe INP. Long Tasks no va a desaparecer: Chrome indica que no tiene previsto retirarla, pero LoAF ofrece una atribución mucho mejor. Cada entrada incluye duration, blockingDuration, renderStart, styleAndLayoutStart y un array scripts. Los scripts de más de 5 ms reciben atribución con sourceURL, sourceFunctionName, invokerType y forcedStyleAndLayoutDuration, lo que a menudo basta para identificar el plugin responsable.
const observer = new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
console.log('LoAF', entry.duration, entry.blockingDuration,
entry.scripts.map((s) => ({
sourceURL: s.sourceURL,
sourceFunctionName: s.sourceFunctionName,
duration: s.duration,
forcedLayout: s.forcedStyleAndLayoutDuration,
})));
}
});
observer.observe({ type: 'long-animation-frame', buffered: true });LoAF es compatible con Chrome y Edge. Firefox y Safari no lo exponen, así que los datos de atribución de la monitorización de campo solo llegarán de navegadores Chromium.
Datos de campo con la versión de atribución de web-vitals
La librería web-vitals tiene una versión de atribución que te dice por qué una interacción fue lenta. La guía de web.dev para encontrar interacciones lentas en el campo enumera los campos: interactionTarget (un selector CSS del elemento), interactionType, inputDelay, processingDuration, presentationDelay y, desde la versión 4, longAnimationFrameEntries. Envíalos a tu endpoint de analítica con sendBeacon:
import { onINP } from 'web-vitals/attribution';
onINP(({ value, rating, attribution }) => {
navigator.sendBeacon('/analytics', JSON.stringify({
value,
rating,
target: attribution.interactionTarget,
inputDelay: attribution.inputDelay,
processingDuration: attribution.processingDuration,
presentationDelay: attribution.presentationDelay,
}));
});El desglose por fases te dice dónde mirar: un retraso de entrada grande apunta al trabajo que se ejecuta antes del clic, una duración de procesamiento grande a tus manejadores, y un retraso de presentación grande al tamaño del DOM y al renderizado.
Extensión Web Vitals y DevTools
La extensión Web Vitals y el panel Performance de Chrome DevTools muestran el INP de cada interacción mientras la realizas. Haz clic en cada botón, enlace y campo de formulario de tus plantillas clave y observa los valores. Las pruebas de laboratorio en un portátil rápido subestiman la latencia en móvil, así que usa la limitación de CPU de DevTools cuando reproduzcas una interacción lenta detectada en el campo. Las limitaciones propias del móvil las tratamos en nuestra guía de estrategias de rendimiento mobile-first.
Cómo mejorar INP en WordPress paso a paso
Paso 1: auditoría de partida
Obtén los datos de CrUX de tu origen y de tus plantillas principales (inicio, entrada del blog, producto, categoría) y anota INP por separado para móviles y escritorio. Empieza por las plantillas con peor valor p75 y con tráfico suficiente para que importe.
Paso 2: localizar las interacciones lentas
Añade al sitio la versión de atribución de web-vitals, o usa el observador de LoAF de arriba, y recoge el interactionTarget y el desglose por fases de las interacciones lentas. Así, la queja “la web va lenta” se convierte en una lista de elementos concretos.
Paso 3: inventario de scripts
Haz una lista de todos los scripts que se cargan en cada plantilla. Para cada uno, anota si es necesario en esa plantilla, si puede usar la estrategia defer, si puede cargarse al interactuar y si puede trasladarse a un worker o eliminarse.
Paso 4: dividir las tareas largas
En los scripts a los que LoAF atribuye frames lentos, divide las tareas largas con scheduler.yield() y el fallback a setTimeout(), empezando por el trabajo que se ejecuta durante una interacción o justo después.
Paso 5: reducir el coste del DOM y del renderizado
Aplana las secciones más profundas, añade content-visibility: auto a las zonas largas por debajo del pliegue y valora sustituir secciones del maquetador por bloques nativos de Gutenberg allí donde el DOM es más profundo.
Paso 6: monitorización continua
Mantén la monitorización de campo activa después de las correcciones. CrUX necesita 28 días para reflejar un cambio por completo, así que compara tus propios datos de campo semana a semana y configura una alerta para cuando el INP p75 supere los 200 ms.
Servicios de optimización de INP de WPPoland
En WPPoland nos especializamos en la métrica de rendimiento que pone a las personas primero.
- Refactorización de JavaScript: reescribimos el código sobrecargado de los plugins en alternativas ligeras que mantienen la funcionalidad sin el peso.
- Diagnóstico con LoAF: usamos telemetría de campo con atribución LoAF para señalar el script y la función que causan el retardo.
- Diseño de la interactividad: nos aseguramos de que la respuesta visible a un clic ocurra primero y de que todo lo demás espere hasta después del pintado.
Conclusión sobre INP en WordPress
Las Core Web Vitals tratan de lo que siente un usuario al interactuar con tu marca. Interaction to Next Paint es la métrica de la confianza. Cuando tu sitio responde al instante, tus usuarios sienten que tienen el control. Cuando se retrasa, parece roto, y en móvil un menú que no reacciona suele darse por roto. Ningún estudio publicado vincula una franja de INP con un porcentaje fijo de rebote o de conversión, así que mide tus propios datos antes y después.
¿Tu sitio WordPress va lento? Contacta con WPPoland para diagnosticar tu INP y corregir las interacciones que lo frenan.
