Core Web Vitals en WordPress: optimizar INP, LCP y CLS

#Qué son los Core Web Vitals en 2026

#Valores buenos y malos de LCP, INP y CLS

#Por qué INP es más difícil de corregir que LCP y CLS

LCP depende sobre todo de la velocidad del servidor y de la optimización de imágenes: problemas bien entendidos con soluciones claras. CLS consiste en reservar espacio para el contenido dinámico, una disciplina de CSS y HTML. INP trata de la eficiencia de ejecución de JavaScript, un problema bastante más difícil porque exige entender el hilo principal del navegador, la planificación de tareas y el manejo de eventos.

Los sitios WordPress son especialmente vulnerables a un mal INP porque:

1. Sobrecarga de plugins: cada plugin puede añadir JavaScript que bloquea el hilo principal
2. Constructores de páginas: Elementor, Divi y WPBakery añaden frameworks frontend pesados
3. Scripts de terceros: analítica, anuncios, widgets de chat y embeds sociales compiten por el tiempo del hilo principal
4. Dependencia de jQuery: muchos temas y plugins WordPress todavía dependen de jQuery, que suma más de 85 KB de JavaScript bloqueante
5. Sin code splitting: los temas WordPress tradicionales cargan todo el JavaScript en cada página

#Cómo funciona INP

#Cuáles son las tres fases de una interacción

Cuando un usuario hace clic en un botón, toca un enlace o pulsa una tecla, el navegador procesa la interacción en tres fases:

1. Retraso de entrada (input delay): tiempo entre la interacción física y el momento en que el navegador empieza a ejecutar el manejador de eventos. Lo causa un hilo principal ocupado con otras tareas
2. Tiempo de procesamiento (processing time): tiempo necesario para ejecutar todos los manejadores de eventos de esa interacción
3. Retraso de presentación (presentation delay): tiempo para pintar la actualización visual en pantalla una vez terminados los manejadores

La fórmula es sencilla:

INP = Retraso de entrada + Tiempo de procesamiento + Retraso de presentación

La métrica informa de la interacción más lenta de la visita. En páginas con mucha actividad la regla se suaviza un poco: según web.dev, se descarta la interacción más alta por cada 50 interacciones. La mayoría de las páginas recibe menos de 50 interacciones por visita, así que en la práctica se informa de la peor. Después Google evalúa la página en el percentil 75 de todas las visitas registradas en campo. Esto significa que una sola interacción lenta puede hundir tu puntuación INP, incluso si todas las demás son rápidas. En un sitio WordPress típico, con formularios, menús, filtros y carruseles, hay decenas de interacciones posibles y basta con que una vaya mal.

INP pasó a ser Core Web Vital y sustituyó a FID el 12 de marzo de 2024, según el anuncio publicado en web.dev. FID quedó obsoleto en esa misma transición y desapareció del informe de Search Console.

#Qué cuenta como interacción

No todas las acciones del usuario cuentan como interacción a efectos de INP:

• Clics en botones, enlaces, toggles y menús: cuentan
• Toques en móvil (eventos touch): cuentan
• Pulsaciones de teclas en campos de texto, cajas de búsqueda y atajos de teclado: cuentan
• Scroll: no cuenta (el navegador lo mide por separado)
• Hover: no cuenta (pasar el cursor por encima de un elemento no activa INP)

La distinción importa: si el sitio tiene un scroll lento, eso no se refleja en INP. Pero si el usuario pulsa un botón de filtro y la pantalla tarda 400 ms en actualizarse, eso es un problema grave de INP.

#Cómo medir INP en sitios WordPress

#Google Search Console (datos de campo)

La fuente de datos más importante. Ve a Core Web Vitals y elige Móvil o Escritorio. Search Console muestra datos INP de usuarios reales agregados durante 28 días. Las páginas se agrupan por patrón de URL y se califican como Buenas, Necesitan mejora o Pobres.

Empieza siempre aquí. Los datos de campo reflejan la experiencia real de los usuarios, con dispositivos lentos, conexiones débiles e interacciones que las pruebas de laboratorio nunca simulan. Si Search Console marca un INP pobre, Google está viendo ese problema y puede afectar a los rankings.

#PageSpeed Insights (laboratorio y campo)

Introduce cualquier URL y obtendrás dos tipos de datos:

• Datos de campo: mediciones de usuarios reales del Chrome UX Report (CrUX). Son los datos que Google usa para su evaluación
• Datos de laboratorio: mediciones simuladas de Lighthouse, ejecutadas en un entorno controlado

Para INP, los datos de campo importan mucho más, porque las pruebas de laboratorio pueden no activar las mismas interacciones que realizan los usuarios reales. Un sitio puede tener un informe de laboratorio impecable y un INP de campo pobre, porque los usuarios abren menús complejos, filtros de búsqueda y formularios que Lighthouse no prueba.

#Chrome DevTools (depuración)

Para diagnosticar un problema concreto de INP, Chrome DevTools es imprescindible. El proceso:

1. Abre DevTools, ve al panel Rendimiento y pulsa Grabar
2. Interactúa con la página: pulsa botones, abre menús, rellena formularios
3. Detén la grabación y analiza el resultado

Busca en concreto:

• Tareas largas: tareas de más de 50 ms, marcadas con un triángulo rojo en la esquina. Cualquier tarea por encima de ese umbral bloquea el hilo principal
• Manejadores de eventos: cuánto tarda en procesarse cada clic o toque. Si un clic dispara varios manejadores, el tiempo se acumula
• Layout thrashing: layouts síncronos forzados durante las interacciones. Ocurre cuando JavaScript lee y escribe propiedades de layout de forma alterna y obliga al navegador a recalcular una y otra vez

#Cómo mejorar INP en WordPress

#1. Diferir JavaScript no crítico

La corrección de mayor impacto. La mayoría de los plugins WordPress cargan JavaScript en el <head>, bloqueando el hilo principal antes incluso de que la página se renderice:

<!-- Antes: bloqueante -->
<script src="plugin-slider.js"></script>

<!-- Después: diferido -->
<script src="plugin-slider.js" defer></script>

El atributo defer indica al navegador que descargue el archivo en paralelo pero lo ejecute solo cuando el HTML esté completamente analizado. Eso libera el hilo principal durante la carga inicial y reduce el retraso de entrada de las primeras interacciones.

Plugins que más se benefician de diferir:

• Analítica (GA4, GTM): añadir defer o cargar con requestIdleCallback
• Widgets de chat (Intercom, Tawk.to): cargar después del primer scroll del usuario o a los 5 segundos
• Embeds sociales (Facebook, Twitter/X): cargar solo cuando sean visibles (Intersection Observer)
• Sliders y carruseles: diferir la inicialización hasta que entren en el viewport

#2. Eliminar JavaScript de plugins no usados

Muchos plugins cargan sus scripts en todas las páginas del sitio, se necesiten o no. Audita qué plugins necesitan de verdad JavaScript en el frontend:

# Listar los scripts encolados en el frontend
wp eval 'do_action("wp_enqueue_scripts"); global $wp_scripts; foreach ($wp_scripts->queue as $s) echo $s . "\n";'

wp eval se ejecuta fuera de una petición de página, así que hay que disparar a mano el hook wp_enqueue_scripts; si no, la cola sale vacía. Los scripts que un plugin encola solo para una plantilla o consulta concreta no aparecerán así. Para verlo página por página, el plugin Query Monitor lista los scripts encolados de la página que estás viendo. A partir de esa lista, marca los que esa página no necesita.

Casos más comunes:

• Contact Form 7: carga CSS y JavaScript en todas las páginas, pero los formularios suelen estar en una o dos. Solución: cargarlo de forma condicional solo donde hay formulario
• WooCommerce cart fragments: el AJAX de fragmentos del carrito se ejecuta en todas las páginas, incluso fuera de la tienda. Solución: desactivarlo en páginas que no son de la tienda
• Estilos de bloques de Gutenberg: WordPress carga CSS y JavaScript para todos los bloques registrados, incluso los que no se usan en la página. Solución: quitar los estilos de los bloques no usados

La carga condicional se puede hacer en el functions.php del tema o con un plugin de gestión de assets como Asset CleanUp o Perfmatters.

#3. Dividir tareas largas

Cualquier tarea de JavaScript de más de 50 ms bloquea el hilo principal. Mientras se ejecuta, el navegador no puede responder al usuario, lo que eleva directamente el retraso de entrada de INP. La solución es partir las tareas largas en trozos más pequeños y devolver el control al navegador entre uno y otro.

scheduler.yield() es la API moderna. Todavía no está en todos los navegadores (la guía de tareas largas de web.dev indica Chrome y Edge 129 y Firefox 142, sin soporte en Safari), así que conviene envolverla con un fallback de setTimeout y ceder el control por plazo de tiempo:

// Ceder al navegador, con fallback para navegadores sin scheduler.yield()
function yieldToMain() {
  if (globalThis.scheduler?.yield) {
    return scheduler.yield();
  }
  return new Promise(resolve => setTimeout(resolve, 0));
}

// Romper un bucle largo en trozos, cediendo cada 50 ms aproximadamente
async function processItems(items, deadline = 50) {
  let lastYield = performance.now();
  for (const item of items) {
    processItem(item);
    if (performance.now() - lastYield > deadline) {
      await yieldToMain();
      lastYield = performance.now();
    }
  }
}

Guías anteriores condicionaban la cesión a navigator.scheduling.isInputPending(). web.dev ya no recomienda esa API: puede devolver false aunque el usuario haya interactuado, y la entrada no es el único motivo para ceder, porque las animaciones y otras actualizaciones de la interfaz también necesitan el hilo principal. Ceder por presupuesto de tiempo, haya entrada pendiente o no, mantiene la página receptiva sin depender de ella.

#4. Usar event listeners pasivos

Los listeners de scroll y touch pueden bloquear al navegador, porque tiene que esperar a saber si el manejador llamará a preventDefault() para cancelar el scroll. Marcar el listener como pasivo le dice al navegador que el scroll no se cancelará, así que puede desplazarse de inmediato:

// Antes: bloqueante
element.addEventListener('touchstart', handler);

// Después: pasivo (indica al navegador que el scroll no se cancelará)
element.addEventListener('touchstart', handler, { passive: true });

// Aplicarlo también a los listeners de scroll
window.addEventListener('scroll', onScroll, { passive: true });

Este cambio importa sobre todo en móvil, donde los eventos touch son constantes. Muchos plugins WordPress añaden listeners de scroll sin la opción passive, lo que provoca tirones y retrasos en las interacciones.

#5. Optimizar el tamaño del DOM

Los árboles DOM grandes ralentizan cada interacción porque el navegador debe recalcular estilos y layout para más elementos. El artículo de web.dev sobre tamaño del DOM e interactividad indica que Lighthouse considera excesivo un DOM de más de 1.400 nodos y empieza a avisar a partir de 800. En sitios WordPress hechos con constructores de páginas es habitual superar con creces esa cifra, y así un buen INP se vuelve muy difícil.

Formas de reducir el DOM:

• Eliminar divs envoltorio innecesarios: constructores como Elementor añaden varios envoltorios por cada sección y columna. web.dev señala reducir la profundidad del DOM como la palanca principal
• Carga diferida del contenido bajo el pliegue: añadir elementos al DOM solo cuando hacen falta o se vuelven visibles
• Virtual scrolling para listas largas: en lugar de pintar cientos de elementos, pintar solo los visibles
• Simplificar los layouts del constructor: menos secciones, columnas y widgets anidados

#6. Eliminar jQuery donde sea posible

jQuery añade unos 85 KB de JavaScript minificado y bloquea el hilo principal durante la inicialización. Muchos temas y plugins lo usan solo para operaciones sencillas que JavaScript moderno resuelve de forma nativa:

// jQuery: document.ready
$(function() { /* ... */ });

// Moderno: DOMContentLoaded
document.addEventListener('DOMContentLoaded', () => { /* ... */ });

// jQuery: selector
$('.my-class');

// Moderno: querySelectorAll
document.querySelectorAll('.my-class');

// jQuery: añadir una clase
$('.element').addClass('active');

// Moderno: classList
document.querySelector('.element').classList.add('active');

// jQuery: AJAX
$.ajax({ url: '/api/data', success: callback });

// Moderno: fetch
fetch('/api/data').then(res => res.json()).then(callback);

Eliminar jQuery por completo no siempre es posible, sobre todo si hay plugins esenciales que dependen de él. En ese caso la prioridad es cargar jQuery con defer y asegurarse de que el código propio del tema usa las alternativas modernas.

#Web Workers, content-visibility y requestIdleCallback para INP

#Web Workers para cálculos pesados

Las operaciones intensivas de CPU, como procesar datos, manipular imágenes o hacer cálculos complejos, deben salir del hilo principal y ejecutarse en un Web Worker. Así el hilo principal queda libre para responder al usuario:

// main.js: delegar el procesamiento al worker
const worker = new Worker('heavy-task.js');
worker.postMessage(data);
worker.onmessage = (e) => updateUI(e.data);

// heavy-task.js: se ejecuta en un hilo separado
self.onmessage = (event) => {
  const result = heavyComputation(event.data);
  self.postMessage(result);
};

El worker se ejecuta en su propio hilo, aislado del principal. Mientras dura el cálculo, el usuario puede seguir interactuando con la página sin retrasos. La técnica es especialmente útil en tiendas WooCommerce con filtros de producto complejos o búsqueda en vivo.

#Content-visibility para contenido fuera de pantalla

La propiedad CSS content-visibility le dice al navegador que no renderice las secciones que no están en el viewport. Eso reduce el trabajo de renderizado durante las interacciones, porque el navegador no recalcula estilos ni layout del contenido que el usuario aún no ve:

/* Omitir el renderizado de las secciones bajo el pliegue */
.below-fold-section {
  content-visibility: auto;
  contain-intrinsic-size: 0 500px;
}

contain-intrinsic-size fija un tamaño estimado para la sección y evita saltos en la barra de scroll. La técnica rinde más en páginas largas con muchas secciones, como las landing pages hechas con constructores.

#requestIdleCallback para trabajo no urgente

El trabajo que no tiene que ejecutarse al momento, como cargar analítica, precargar recursos o enviar telemetría, puede esperar a que el navegador esté inactivo:

// Cargar analítica en tiempo inactivo
requestIdleCallback(() => {
  loadGoogleAnalytics();
}, { timeout: 3000 }); // fallback: cargar en 3 segundos como máximo

// Precargar la página siguiente en tiempo inactivo
requestIdleCallback(() => {
  const link = document.createElement('link');
  link.rel = 'prefetch';
  link.href = '/next-page/';
  document.head.appendChild(link);
});

La opción timeout garantiza que la tarea se ejecute dentro de un plazo máximo aunque el navegador nunca quede del todo inactivo. Es un equilibrio entre capacidad de respuesta (no bloquear interacciones) y función (que la analítica acabe cargando).

#INP en WordPress headless con Astro y Next.js

Para sitios donde INP es crítico y optimizar el WordPress clásico no basta, la arquitectura headless es la opción más radical.

#INP en sitios con Astro

Astro envía cero JavaScript por defecto. En páginas sin islas interactivas, INP no se ve afectado por scripts porque no hay nada bloqueando el hilo principal. El navegador recibe HTML y CSS, así que las interacciones nativas responden al instante.

Incluso en páginas con componentes interactivos, Astro usa el patrón de islas: solo los componentes que necesitan interactividad cargan JavaScript. Un botón de añadir al carrito carga su propio script, mientras la cabecera, el texto, las imágenes y el pie siguen siendo HTML estático.

#INP con Next.js y React Server Components

Next.js con React Server Components renderiza la interfaz en el servidor y envía al cliente solo el JavaScript necesario. Junto con el code splitting automático, cada página carga solo el JavaScript que necesita, no el bundle completo de la aplicación.

En el App Router de Next.js los componentes son Server Components por defecto. Solo los marcados explícitamente con 'use client' envían JavaScript al navegador. Esa inversión del modelo tradicional da lugar a bundles de JavaScript mucho más pequeños.

#INP típico según la arquitectura del sitio

#Checklist para optimizar INP en WordPress

• Verificar Search Console Core Web Vitals para puntuaciones INP actuales
• Identificar páginas con peor INP usando PageSpeed Insights
• Diferir todo JavaScript no crítico (defer o async)
• Cargar condicionalmente scripts de plugins solo en páginas que los necesiten
• Eliminar o reemplazar código dependiente de jQuery donde sea posible
• Agregar { passive: true } a listeners de eventos de scroll/touch
• Romper tareas largas con scheduler.yield() o setTimeout
• Lazy-load contenido debajo del fold y embeds de terceros
• Reducir el tamaño del DOM por debajo del umbral de Lighthouse de 1.400 elementos
• Considerar migración a Astro o Next.js para la mejora más dramática
• Monitorear INP de campo en Search Console durante 28 días después de los cambios

#Conclusión

INP es el Core Web Vital que separa los sitios que se sienten rápidos de los lentos. Mientras que LCP mide la carga y CLS mide la estabilidad, INP mide cómo se siente el sitio cuando interactúas con él. Es la métrica más cercana a la percepción real de velocidad: una página que carga rápido pero tarda medio segundo en responder a un clic sigue pareciendo lenta.

Para sitios WordPress, el camino hacia un buen INP requiere una gestión disciplinada de JavaScript. Cada plugin añadido, cada script de terceros y cada manejador de eventos sin optimizar suma bloqueo del hilo principal. Las correcciones de esta guía (diferir scripts, carga condicional, dividir tareas largas, listeners pasivos y un DOM más pequeño) son el camino para pasar de un INP pobre (más de 500 ms) a uno bueno (200 ms o menos).

Para los sitios donde estas optimizaciones no bastan, un cambio de arquitectura a WordPress headless con Astro o Next.js ofrece una salida más estable. Con poco o ningún JavaScript en el cliente, INP deja de ser un problema.

La inversión se paga directamente en rankings de búsqueda, engagement del usuario y tasas de conversión. Cada milisegundo de mejora de INP hace que tu sitio se sienta más responsivo, y Google recompensa eso con mejor visibilidad.

¿Necesitas ayuda optimizando tus Core Web Vitals? Explora nuestros servicios de optimización de velocidad WordPress o contáctanos para una evaluación de rendimiento gratuita.