Los Core Web Vitals de Google ya no son opcionales para SEO. En 2026, estas metricas influyen directamente en los rankings de búsqueda, e INP (Interaction to Next Paint) se ha convertido en la más desafiante para los sitios WordPress. Mientras que LCP y CLS se pueden corregir con optimización de imágenes y reservaciones de layout, INP requiere repensar fundamentalmente como se ejecuta JavaScript en tus páginas.
INP reemplazo a FID (First Input Delay) como Core Web Vital en marzo de 2024. La diferencia es significativa: FID solo media la primera interacción, mientras que INP mide cada interacción a lo largo de toda la visita a la página. Un sitio podria puntuar bien en FID pero terriblemente en INP, y muchos sitios WordPress lo hacen.
Entendiendo Core Web Vitals en 2026
Las Tres Metricas que Importan
| Metrica | Que Mide | Bueno | Necesita Mejora | Pobre |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Velocidad de carga | < 2.5s | 2.5-4s | > 4s |
| INP (Interaction to Next Paint) | Capacidad de respuesta | < 200ms | 200-500ms | > 500ms |
| CLS (Cumulative Layout Shift) | Estabilidad visual | < 0.1 | 0.1-0.25 | > 0.25 |
Por Que INP es el Mas Dificil de Corregir
LCP se trata principalmente de velocidad del servidor y optimización de imágenes: problemas bien entendidos con soluciones claras. CLS se trata de reservar espacio para contenido dinámico: una disciplina de CSS y HTML. INP se trata de eficiencia de ejecucion de JavaScript: un problema fundamentalmente más dificil porque requiere entender el hilo principal del navegador, la programacion de tareas y el manejo de eventos.
Los sitios WordPress son particularmente vulnerables a mal INP porque:
- Sobrecarga de plugins — cada plugin puede agregar JavaScript que bloquea el hilo principal
- Constructores de páginas — Elementor, Divi, WPBakery agregan frameworks frontend pesados
- Scripts de terceros — analíticas, anuncios, widgets de chat, embeds sociales compiten por tiempo del hilo principal
- Dependencia de jQuery — muchos temas y plugins WordPress todavia dependen de jQuery, agregando 85KB+ de JavaScript bloqueante
- Sin code splitting — los temas WordPress tradicionales cargan todo el JavaScript en cada página
Como Funciona INP
El Ciclo de Vida de la Interacción
Cuando un usuario hace clic en un boton, toca un enlace o presiona una tecla, el navegador lo procesa en tres fases:
- Retraso de entrada — tiempo entre la interacción fisica y el navegador comenzando a procesar el manejador de eventos (causado por el hilo principal ocupado con otras tareas)
- Tiempo de procesamiento — tiempo para ejecutar todos los manejadores de eventos para esta interacción
- Retraso de presentacion — tiempo para renderizar la actualización visual despues de que los manejadores de eventos completen
INP = Retraso de entrada + Tiempo de procesamiento + Retraso de presentacion
La metrica captura la peor interacción (realmente el percentil 98) durante toda la visita a la página. Esto significa que una sola interacción lenta puede hundir tu puntuacion INP, incluso si todas las demás interacciones son rápidas.
Que Cuenta como Interacción
- Clics en botones, enlaces, toggles, menús
- Toques en móvil (eventos touch)
- Pulsaciones de teclas en campos de entrada, cajas de búsqueda
- NO scroll (el scroll se mide por separado)
- NO hover (el hover solo no activa INP)
Midiendo INP en Sitios WordPress
Google Search Console (Datos de Campo)
La fuente de datos más importante. Navega a Core Web Vitals -> Movil/Escritorio. Search Console muestra datos INP de usuarios reales agregados durante 28 dias. Las páginas se agrupan por patron de URL y se califican como Bueno, Necesita Mejora o Pobre.
PageSpeed Insights (Lab + Campo)
Ingresa cualquier URL y obtiene ambos:
- Datos de campo — mediciones de usuarios reales del Chrome UX Report
- Datos de laboratorio — mediciones simuladas de Lighthouse
Para INP, los datos de campo importan más porque las pruebas de laboratorio pueden no activar las mismás interacciones que los usuarios reales realizan.
Chrome DevTools (Depuracion)
Abre DevTools -> panel Rendimiento -> Grabar -> Interactua con la página -> Detener grabacion. Busca:
- Tareas Largas (barras amarillas/rojas) — cualquier tarea mayor a 50ms bloquea el hilo principal
- Manejadores de eventos — cuanto tiempo toma cada clic/toque en procesarse
- Layout thrashing — layouts sincronos forzados durante interacciones
Correcciones INP Específicas de WordPress
1. Diferir JavaScript No Crítico
La correccion de mayor impacto. La mayoria de los plugins WordPress cargan JavaScript en el <head>, bloqueando el hilo principal antes de que la página siquiera renderice:
<!-- Antes: bloqueante -->
<script src="plugin-slider.js"></script>
<!-- Despues: diferido -->
<script src="plugin-slider.js" defer></script>
Plugins que más se benefician de diferir:
- Analiticas (GA4, GTM) — agregar
defero cargar viarequestIdleCallback - Widgets de chat (Intercom, Tawk.to) — cargar despues del scroll del usuario o despues de 5 segundos
- Embeds sociales (Facebook, Twitter) — cargar solo cuando sean visibles (Intersection Observer)
- Sliders y carruseles — diferir inicializacion hasta que sean visibles
2. Eliminar JavaScript de Plugins No Usados
Audita que plugins realmente necesitan JavaScript frontend:
# Listar todos los scripts encolados en una página
wp eval 'global $wp_scripts; foreach($wp_scripts->queue as $s) echo $s . "\n";'
Infractores comunes:
- Contact Form 7 carga en cada página, pero los formularios existen en solo una página -> cargar condicionalmente
- WooCommerce cart fragments AJAX se ejecuta en cada página -> deshabilitar en páginas no-tienda
- CSS/JS de bloques Gutenberg carga para todos los bloques, incluso los no usados -> eliminar estilos de bloques no usados
3. Romper Tareas Largas
Cualquier tarea de JavaScript mayor a 50ms bloquea el hilo principal. Usa scheduler.yield() (moderno) o setTimeout (fallback) para romper tareas largas:
// Romper un bucle largo en trozos más pequenos
async function processItems(items) {
for (const item of items) {
processItem(item);
// Ceder al navegador entre items
if (navigator.scheduling?.isInputPending?.()) {
await scheduler.yield();
}
}
}
4. Usar Event Listeners Pasivos
Los listeners de eventos de scroll y touch bloquean al navegador de hacer scroll suavemente:
// Antes: bloqueante
element.addEventListener('touchstart', handler);
// Despues: pasivo (le dice al navegador que no se prevendran scrolls)
element.addEventListener('touchstart', handler, { passive: true });
5. Optimizar Tamaño del DOM
Arboles DOM grandes (más de 1,500 elementos) ralentizan cada interacción porque el navegador debe recalcular estilos y layout para más elementos:
- Eliminar divs wrapper innecesarios
- Lazy-load contenido debajo del fold
- Usar virtual scrolling para listas largas
- Simplificar layouts de constructores de páginas
6. Eliminar jQuery Donde Sea Posible
jQuery agrega 85KB de JavaScript y bloquea el hilo principal durante la inicializacion. Alternativas modernas:
// jQuery: document.ready
$(function() { /* ... */ });
// Moderno: DOMContentLoaded
document.addEventListener('DOMContentLoaded', () => { /* ... */ });
// jQuery: selector
$('.my-class');
// Moderno: querySelectorAll
document.querySelectorAll('.my-class');
Optimización INP Avanzada
Web Workers para Computacion Pesada
Mover operaciones intensivas de CPU fuera del hilo principal:
// main.js -- descargar procesamiento al worker
const worker = new Worker('heavy-task.js');
worker.postMessage(data);
worker.onmessage = (e) => updateUI(e.data);
Content Visibility para Contenido Fuera de Pantalla
Decirle al navegador que omita el renderizado de contenido aun no visible:
/* Omitir renderizado para secciones debajo del fold */
.below-fold-section {
content-visibility: auto;
contain-intrinsic-size: 0 500px;
}
requestIdleCallback para Trabajo No Urgente
Diferir trabajo no esencial a periodos de inactividad del navegador:
// Cargar analíticas durante tiempo inactivo
requestIdleCallback(() => {
loadGoogleAnalytics();
}, { timeout: 3000 }); // fallback: cargar dentro de 3 segundos
La Ventaja Headless para INP
Astro: INP Esencialmente Cero
Astro envia cero JavaScript por defecto. En páginas sin islas interactivas, INP no aplica porque no hay nada bloqueando el hilo principal. Incluso con islas, solo los componentes interactivos específicos cargan JavaScript: el resto es HTML estatico.
Next.js: React Server Components
Next.js con React Server Components renderiza UI en el servidor y envia solo el JavaScript del clientes necesario. Combinado con code splitting automático, cada página carga solo el JavaScript que necesita.
Comparación de Rendimiento
| Enfoque | INP Tipico | JavaScript Cargado |
|---|---|---|
| WordPress tradicional + plugins | 300-800ms | 500KB-2MB |
| WordPress optimizado (scripts diferidos) | 150-300ms | 200-500KB |
| Next.js (App Router + RSC) | 50-150ms | 50-200KB |
| Astro (estatico + islas) | 0-50ms | 0-50KB |
Lista de Verificación de Optimización INP
- 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 (
deferoasync) - 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()osetTimeout - Lazy-load contenido debajo del fold y embeds de terceros
- Reducir tamaño del DOM a menos de 1,500 elementos
- Considerar migración a Astro o Next.js para la mejora más dramatica
- Monitorear INP de campo en Search Console durante 28 dias despues de los cambios
Conclusion
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 como se siente el sitio cuando interactuas con el. Para sitios WordPress, el camino hacia un buen INP requiere gestión disciplinada de JavaScript o un cambio fundamental de arquitectura a Headless.
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 contactanos para una evaluación de rendimiento gratuita.


