Si abriste PageSpeed Insights y viste tres luces rojas, este artículo es para ti. Los core web vitals wordpress son tres métricas que Google usa como señal de ranking, y fallan casi siempre por las mismas cuatro causas: theme pesado, plugins acumulados, imágenes sin optimizar y scripts de terceros bloqueantes. Esta guía da el diagnóstico por causa raíz, los umbrales actualizados a 2026 (con INP en lugar de FID) y un plan priorizado por impacto, no por complejidad técnica.
No es una guía plugin-céntrica. Si el problema es el hosting o el theme y ningún plugin lo va a resolver, también te lo digo.
¿Qué son los Core Web Vitals en 2026? (y qué cambió con INP)
Los Core Web Vitals son tres métricas de experiencia de usuario que Google publica como parte de sus señales de ranking: miden velocidad de carga, capacidad de respuesta a interacciones y estabilidad visual. En 2026 las tres métricas oficiales son LCP, INP y CLS — no FID. Si lees una guía que aún habla de FID, está desactualizada.
LCP, INP y CLS: tabla de umbrales y qué mide cada métrica
| Métrica | Qué mide | Umbral “bueno” | Causa más común en WordPress |
|---|---|---|---|
| LCP (Largest Contentful Paint) | Tiempo hasta que se renderiza el elemento visible más grande (normalmente la imagen hero o el <h1>) | ≤ 2,5 s | Imagen hero sin optimizar, TTFB alto del hosting, theme pesado |
| INP (Interaction to Next Paint) | Latencia desde la primera interacción del usuario (clic, tap, tecla) hasta que el navegador pinta la respuesta | ≤ 200 ms | JavaScript de plugins (page builders, chat widgets, analytics) |
| CLS (Cumulative Layout Shift) | Suma de los desplazamientos visuales inesperados durante la vida de la página | ≤ 0,1 | Imágenes sin width/height, anuncios o embeds que cargan tarde, fuentes que provocan FOUT |
Las definiciones canónicas y los umbrales viven en web.dev/articles/vitals. Cualquier número distinto que veas circulando en blogs viejos está obsoleto.
Por qué INP reemplazó a FID en marzo de 2024 — y qué implica para tu WordPress
En marzo de 2024 Google sustituyó First Input Delay (FID) por Interaction to Next Paint (INP) como métrica oficial. La razón: FID solo medía la primera interacción y solo el delay inicial, dando puntajes engañosamente buenos en sitios cuyo JavaScript se atascaba después del primer clic. INP mide todas las interacciones de la sesión y reporta el peor cuantil. La documentación oficial está en web.dev/articles/inp.
Para WordPress esto cambia las prioridades: muchos sitios pasaban FID porque el primer clic ocurría antes de que el JS pesado del page builder terminara de ejecutarse. Con INP, si el visitante interactúa con un menú o un formulario y el thread principal está ocupado parseando el JS de Elementor o de Tawk.to, la métrica falla. INP castiga lo que FID disimulaba.
¿Cómo medir tus Core Web Vitals en WordPress?
Antes de tocar nada, mide. El error más caro en optimización de WordPress es perseguir un score de Lighthouse de 100 que no se traduce en mejoras reales para Google. Lo que ranquea son los datos de campo, no los del laboratorio.
Datos de campo vs. datos de laboratorio: la diferencia que cambia el diagnóstico
Esta distinción separa a quien optimiza con criterio de quien optimiza por impulso. Hay dos tipos de datos:
- Datos de laboratorio (lab data): son simulaciones controladas. Lighthouse y la pestaña de “Diagnóstico” de PageSpeed Insights ejecutan tu página en un entorno virtual con CPU y red emuladas. Sirven para diagnóstico técnico y para validar el efecto inmediato de un cambio. No son la señal de ranking de Google.
- Datos de campo (field data): son métricas reales de usuarios reales medidas por el Chrome UX Report (CrUX) sobre los últimos 28 días. PageSpeed Insights los muestra en el bloque superior (“Descubre lo que tus usuarios reales están experimentando”). Estos son los que Google usa para ranking — y los únicos que aparecen en Google Search Console.
Implicación práctica: puedes tener Lighthouse en verde y CrUX en rojo (porque tu hosting tiene picos de TTFB que el lab no captura), o al revés. Si Search Console te marca URLs con problemas de CWV, son los datos de campo los que fallan, y tus cambios no se reflejarán hasta que pasen 28 días de tráfico real bajo la versión optimizada. Fuente oficial: Google Search Central.
PageSpeed Insights, Search Console y Web Vitals Extension: cuándo usar cada uno
- PageSpeed Insights (pagespeed.web.dev) — punto de partida obligado. Muestra campo y laboratorio en la misma vista. Úsalo para auditar URLs específicas.
- Google Search Console → Experiencia de página → Core Web Vitals — la fuente de verdad sobre qué URLs fallan en producción. Solo datos de campo. Úsalo para priorizar.
- Web Vitals Extension de Chrome — gratuita, mide CWV en vivo mientras navegas. Útil para depurar INP en flujos reales (menús, formularios, modales).
- Lighthouse en DevTools — diagnóstico técnico profundo. No mires el score; mira “Oportunidades” y “Diagnóstico”.
Las 4 causas más comunes de fallar core web vitals wordpress
En un diagnóstico típico, las causas raíz se reparten entre cuatro frentes. Identificar cuál pesa más en tu sitio evita que gastes tiempo optimizando lo que no mueve la aguja.
Causa 1 — Theme pesado o page builder. Elementor, Divi y WPBakery añaden entre 15 y 30 recursos bloqueantes por página incluso cuando solo se usan un par de bloques. Castiga LCP (CSS bloqueante en el head) e INP (JS pesado del builder ocupando el thread principal).
Causa 2 — Plugins acumulados. Cada plugin que registra un script en wp_enqueue_scripts lo carga en todas las páginas por defecto, aunque solo se use en una. Un sitio con 40 plugins puede inyectar 25 scripts y 15 hojas de estilo en el home aunque solo necesite cinco.
Causa 3 — Imágenes sin optimizar. Sin WebP/AVIF, sin lazy loading, sin atributos width/height, sin srcset. Causa número uno de LCP malo (hero de 1,8 MB) y muy común en CLS (la imagen aparece de golpe y empuja el contenido).
Causa 4 — Scripts de terceros bloqueantes. Chat widgets (Tawk, Crisp, Intercom), pixels de marketing, AdSense. Cargan síncronos en <head> y consumen el thread principal antes de que el usuario pueda interactuar. Atacan INP.
Plan de acción priorizado: qué arreglar primero y qué esperar
El orden importa. Optimizar imágenes en un sitio con TTFB de 1,8 s es pintar paredes de una casa con goteras. Hazlo así:
- Hosting y TTFB primero. Mide TTFB en PageSpeed Insights. Si está sobre 600 ms en mediciones repetidas, el problema es el servidor — ningún plugin lo arregla. El monitoreo de CWV es parte de un plan de mantenimiento serio: revisa la guía de mantenimiento WordPress para empresas.
- Imágenes después. WebP o AVIF, lazy loading nativo (
loading="lazy"excepto en la imagen LCP), atributoswidth/heightsiempre,srcsetresponsive. Plugins: ShortPixel, Imagify, EWWW. Suele bajar LCP entre 30 y 60 % en una sola intervención. - Caché y minificación. WP Rocket si tienes presupuesto (USD 59/año), LiteSpeed Cache si tu hosting es LiteSpeed (gratis), W3 Total Cache o Cache Enabler como alternativas. La caché ataca TTFB en visitas posteriores; la minificación reduce CSS/JS.
- Scripts de terceros al final. Carga diferida de chat widgets (tras 5 s o tras scroll), pixels en GTM con triggers retrasados, AdSense con
requestIdleCallback. Esto ataca INP directo.
Rangos de inversión 2026
Para que sepas qué esperar antes de pedir presupuestos:
- Auditoría técnica con informe accionable: USD 100–300. Te dice cuáles son las causas raíz y en qué orden atacarlas. Sin ejecutar cambios.
- Optimización completa (imágenes, caché, minificación, scripts diferidos): USD 500–2.000. Cubre la mayoría de sitios PyME sin customizaciones pesadas. Resultado típico: las tres métricas en verde en lab, mejora en field a las 4–8 semanas.
- Refactor de tema o cambio de page builder: USD 2.000–5.000+. Cuando el theme (Avada, Divi, WPBakery sobre un sitio grande) es la causa raíz y la única salida es reconstruir plantillas en un theme ligero o Gutenberg nativo.
Cuándo el problema es el theme (y no los plugins ni el hosting)
Si ya optimizaste imágenes, instalaste caché, diferiste scripts y migraste a un hosting decente, y aun así LCP e INP siguen en rojo, el sospechoso es el theme. Tres señales: (a) PageSpeed Insights reporta más de 200 KB de JavaScript no usado del theme o del builder; (b) “Reduce el trabajo del hilo principal” de Lighthouse atribuye más de 2 s a scripts del builder; (c) el home carga más de 15 CSS distintos del theme.
En 2026 los themes que cumplen CWV sin acrobacias son Astra, GeneratePress, Blocksy y Kadence: ligeros, basados en Gutenberg o con builder propio optimizado, con menos de 50 KB de CSS/JS críticos por página. Cambiar de theme implica reconstruir plantillas; no es operación de 30 minutos, pero en sitios grandes paga la diferencia en semanas.
Hay un escenario donde el theme deja de ser la palanca: cuando el sitio crece más allá de lo que WordPress sostiene bajo presión. Si WooCommerce con 5.000+ SKUs te da TTFB de 2 s en horario pico aunque el hosting sea managed, el problema ya no es el theme — es el stack.
¿Vale la pena migrar a un stack más rápido? Cuándo sí y cuándo no
La pregunta honesta de cierre. Migrar fuera de WordPress (a Astro, Next.js o un headless con WordPress como CMS y frontend estático) puede llevar LCP a sub-1 s y dejar INP en 50 ms sin esfuerzo. La contrapartida: costo, complejidad y la pérdida de la edición visual en vivo que conoce tu equipo.
Tres señales de que la optimización llegó al techo en tu instalación: (1) llevas más de USD 3.000 invertidos y los datos de campo siguen en ámbar; (2) el TTFB en horario pico no baja de 800 ms ni cambiando de hosting; (3) cada plugin nuevo regresa una métrica al rojo. En esos casos, la migración se paga en 12–18 meses entre ahorro de hosting, conversión recuperada y SEO técnico.
En Overnatic primero diagnosticamos antes de proponer cualquier acción: una auditoría de 2–3 horas aclara si tu sitio necesita optimización, refactor de tema o migración de stack — y rara vez es lo que el cliente esperaba. Si quieres revisar opciones, revisa nuestros servicios y cuéntanos el caso.