Core Web Vitals en WordPress: cómo poner LCP, INP y CLS en verde sin morir en el intento

Los Core Web Vitals dejaron de ser una métrica técnica curiosa para convertirse en un factor de ranking real desde 2021. En 2026, con INP sustituyendo a FID como métrica oficial y la AI Overview de Google penalizando webs lentas, una pyme que ignora estas métricas pierde tráfico orgánico de forma medible. Lo paradójico es que el 70 % de las webs WordPress que llegan a auditoría tienen sus Core Web Vitals en rojo y nadie en la empresa lo sabe.

La buena noticia: poner los Core Web Vitals en verde en WordPress no requiere reescribir la web ni migrar de tema. Requiere disciplina técnica, herramientas correctas y aplicar el orden adecuado. Las webs que pasan de rojo a verde lo hacen normalmente en 4-8 semanas de trabajo metódico, sin tocar el contenido editorial ni cambiar el branding.

Este artículo es la guía operativa que aplicamos en VEXEO para poner LCP, INP y CLS en verde en webs WordPress reales. No son trucos genéricos: son los ajustes concretos, por orden, que mueven la aguja. Si tu PageSpeed Insights sale en naranja o rojo en móvil, esta guía te dice exactamente qué tocar y en qué secuencia.

Por qué importan los Core Web Vitals y cómo medirlos bien

Los Core Web Vitals son tres métricas que Google utiliza para evaluar la experiencia de usuario en una web. Desde marzo de 2024, la métrica INP sustituyó oficialmente a FID. Los umbrales actuales para considerar una web «en verde»:

• LCP (Largest Contentful Paint): menos de 2,5 segundos. Mide cuánto tarda en aparecer el elemento principal de la página (suele ser la imagen del hero o el bloque de texto principal).
• INP (Interaction to Next Paint): menos de 200 ms. Mide la latencia de la respuesta a la interacción del usuario (click, tap, tecla pulsada).
• CLS (Cumulative Layout Shift): menos de 0,1. Mide cuánto se mueve el diseño durante la carga (imágenes que aparecen tarde, banners que empujan contenido).

Para medirlos correctamente hay dos fuentes:

1. Datos de campo (CrUX). Son los datos reales de usuarios de Chrome agregados durante 28 días. Aparecen en PageSpeed Insights bajo «Origin Summary» y son los que Google usa para rankear. Solo están disponibles si la web tiene tráfico suficiente.
2. Datos de laboratorio (Lighthouse). Son simulaciones controladas. Son útiles para diagnóstico pero NO son los que cuentan para ranking. Una web puede tener Lighthouse 95 y CrUX en rojo si los usuarios reales tienen conexiones malas o dispositivos antiguos.

La regla práctica: optimiza siempre pensando en los datos de campo, no en los de laboratorio. Lighthouse es la brújula; CrUX es el mapa.

Infraestructura: prioriza un servidor con TTFB bajo y caché inteligente

Antes de tocar nada en WordPress, hay que asegurar que la infraestructura no es el cuello de botella. Si el servidor responde lento, cualquier optimización de frontend solo arregla el segundo problema sin tocar el primero.

El indicador clave aquí es el TTFB (Time to First Byte). Para una web WordPress razonable, el TTFB debe estar por debajo de 600 ms en condiciones normales, idealmente bajo 400 ms. Si tu TTFB supera 1 segundo de forma sistemática, el problema es el servidor, no WordPress.

Tres niveles de intervención en infraestructura:

• Hosting compartido barato (5-10 €/mes): insuficiente para una web WordPress profesional con tráfico. Cambia a managed WordPress (SiteGround GoGeek, WP Engine, Kinsta) por 25-50 €/mes.
• Hosting managed WordPress: incluye caché de servidor, CDN y optimizaciones nativas. Es el sweet spot para la mayoría de pymes.
• VPS o cloud dedicado: necesario solo si tienes tráfico alto (10.000+ sesiones diarias) o requisitos técnicos específicos. Cloudways, Hetzner o DigitalOcean con LiteSpeed son opciones razonables.

Además del hosting, hay tres elementos de infraestructura que afectan directamente a los Core Web Vitals:

1. CDN (Cloudflare, BunnyCDN). Sirve archivos estáticos desde servidores cercanos al usuario. Reduce LCP entre 200 y 800 ms según geografía.
2. Caché de página completa. WP Rocket, FlyingPress, LiteSpeed Cache o el caché nativo del hosting managed. Sin caché, cada visita ejecuta PHP y consulta base de datos.
3. HTTP/2 o HTTP/3. Protocolos modernos que permiten cargas paralelas más eficientes. La mayoría de hostings serios ya lo incluyen, pero conviene verificar.

LCP en verde: carga lo importante antes que nada

El LCP suele ser la métrica más fácil de optimizar y la que más rápido mejora el ranking. Las acciones concretas para bajar LCP en WordPress, por orden de impacto:

1. Convierte imágenes a WebP o AVIF. WebP reduce el peso entre un 25 y un 50 % sobre JPEG sin pérdida visible. AVIF es aún mejor pero todavía no es soportado en algunos navegadores antiguos. Plugins: ShortPixel, Imagify, Smush Pro.
2. Declara dimensiones explícitas en imágenes. Cada <img> debe tener width y height en el HTML. Sin ellos, el navegador no reserva espacio y el LCP se calcula mal.
3. Preload del LCP. Identifica qué elemento es el LCP de tu home (PageSpeed Insights te lo dice) y añade <link rel="preload" as="image" href="..." fetchpriority="high"> en el head.
4. Critical CSS inline. El CSS necesario para renderizar el contenido above-the-fold debe estar inline en el HTML. WP Rocket, Autoptimize y FlyingPress lo generan automáticamente.
5. Lazy loading solo para below-the-fold. Las imágenes del primer pantallazo NO deben tener loading=»lazy» porque retrasa su carga. WordPress añade lazy loading por defecto desde la versión 5.5, hay que excluir las imágenes hero manualmente.
6. Fuentes web optimizadas. Sirve las fuentes desde tu propio servidor en formato WOFF2 con font-display: swap. Cargar Google Fonts directamente desde Google añade latencia DNS y bloqueo de render.

Tras estas seis acciones, el LCP suele bajar entre 1 y 3 segundos en webs WordPress no optimizadas. Esto solo ya puede mover una web de rojo a verde en LCP.

INP bajo: interacción fluida sin tareas largas

El INP es la métrica más nueva y la que más se ignora. Mide cuánto tarda la web en responder cuando el usuario hace algo (click, tap, tecla). En WordPress, los problemas de INP suelen venir de JavaScript pesado bloqueando el hilo principal.

Acciones para mejorar INP en WordPress:

• Difiere o elimina scripts no críticos. Google Tag Manager, chats en vivo, widgets de redes sociales, scripts de marketing. Carga solo lo que se usa en la página específica, no todo en todas.
• Divide tareas largas (long tasks). Si tienes un script propio que tarda más de 50 ms en ejecutarse, divídelo en chunks con requestIdleCallback o setTimeout para no bloquear el hilo principal.
• Reduce el peso de JavaScript total. WordPress con muchos plugins acumula cientos de KB de JS innecesario. Usa Asset CleanUp, Perfmatters o Plugin Organizer para desactivar plugins por URL.
• Sirve JavaScript moderno. ES2017+ sin transpilación innecesaria a ES5. El JS moderno es entre un 15 y un 30 % más ligero.
• Evita constructores de página pesados (Elementor, Divi, WPBakery). Los page builders cargan cientos de KB de JS por página. Si tu web es nueva, usa Gutenberg con bloques nativos. Si ya usas constructor, optimízalo con plugins específicos (ej. Asset CleanUp para Elementor).

El INP es la métrica que más diferencia hace entre una web profesional y una «WordPress amateur». Tras optimizar INP, los usuarios perciben la web «más rápida» aunque el LCP no haya cambiado.

CLS estable: cero saltos de diseño en pantalla

El CLS mide cuánto se mueve el diseño durante la carga. Los saltos visuales son la principal queja de los usuarios sobre webs lentas: empiezan a leer y de repente el texto se desplaza porque un anuncio o una imagen tarda en aparecer.

Acciones para mantener CLS bajo en WordPress:

• Dimensiones explícitas en TODAS las imágenes e iframes. width y height en HTML o aspect-ratio en CSS. WordPress lo añade por defecto en imágenes subidas a la biblioteca, pero hay que revisar manualmente embebidos de YouTube, mapas y vídeos.
• Reserva espacio para banners, anuncios y embeds. Si un anuncio mide 728×90 px, define ese espacio antes de que cargue el script. Sin reserva, cuando carga empuja todo el contenido hacia abajo.
• No inyectes contenido dinámicamente arriba del fold. Avisos de cookies, banners de oferta o popups que aparecen tras la carga inicial generan CLS si desplazan contenido. Mejor que aparezcan superpuestos (overlay) sin afectar al layout.
• font-display: swap correctamente configurado. Si las fuentes web cargan tarde y el navegador sustituye la fuente por la del sistema durante un segundo, el cambio puede generar CLS si las métricas tipográficas son muy distintas. Usa Font Size Adjust o precarga las fuentes críticas.
• Evita animaciones que afecten al layout. Animaciones con transform y opacity no generan CLS; animaciones con top, left, width o height sí. Usa siempre transform para movimientos.

El CLS suele ser la métrica más fácil de poner en verde una vez identificadas las causas. Pocas correcciones pueden bajar el CLS de 0,3 a 0,05 sin afectar al diseño visual.

Ajustes específicos en WordPress: qué tocar y dónde

Más allá de los principios generales, hay ajustes específicos de WordPress que tienen impacto directo en Core Web Vitals:

1. Plugin de caché bien configurado. WP Rocket es el más completo (~50 €/año). Alternativas gratuitas: LiteSpeed Cache (si tu hosting es LiteSpeed), W3 Total Cache, Cache Enabler. Activa: page cache, browser cache, GZIP, lazy load, defer JS.
2. Optimización de base de datos. WP-Optimize o el built-in del plugin de caché. Limpia revisiones, transients, comentarios spam y tablas huérfanas. Mejora indirectamente TTFB.
3. OPcache activado. Caché de bytecode PHP en el servidor. Reduce el tiempo de ejecución de PHP entre un 30 y un 70 %. La mayoría de hostings managed lo activan por defecto.
4. Desactiva plugins por página. No todos los plugins se necesitan en todas las URLs. Perfmatters o Asset CleanUp permiten desactivar JS y CSS de plugins en páginas donde no se usan.
5. Limita el tamaño del DOM. Webs con miles de elementos HTML (típico de page builders sin optimizar) tienen LCP e INP peores. Por debajo de 1.500 elementos por página es el rango sano.
6. Compresión Brotli o GZIP a nivel servidor. Brotli es ~20 % más eficiente que GZIP. La mayoría de hostings modernos lo soportan; activarlo es un cambio en .htaccess o vía panel.

El proceso paso a paso: orden y foco

El orden importa. Optimizar los Core Web Vitals sin método produce mejoras parciales y a veces empeora otras métricas. El proceso que funciona:

1. Día 1: Medición base. PageSpeed Insights de las 5 URLs más importantes (home, servicios, productos, blog, contacto). Documenta LCP, INP, CLS y TTFB iniciales. Sin esta base, no sabrás si mejoras.
2. Días 2-3: Infraestructura. Revisa hosting, activa CDN, configura caché de página completa. Mide otra vez. Suele haber mejora notable solo con esto.
3. Días 4-7: LCP. Convierte imágenes a WebP, preload del LCP, dimensiones explícitas, critical CSS. Mide.
4. Días 8-12: INP. Difiere scripts, reduce JS por URL, optimiza page builder si aplica. Mide.
5. Días 13-15: CLS. Dimensiona iframes y embeds, reserva espacio para anuncios, ajusta animaciones. Mide.
6. Día 16: Espera datos CrUX. Los datos de campo tardan 28 días en actualizarse. No esperes resultados oficiales en SERP el día siguiente.

Tras este ciclo de 2-3 semanas, una web WordPress con problemas serios suele pasar a verde en al menos dos de las tres métricas. La tercera puede requerir intervención técnica más profunda.

Resultados realistas y metodología de medición

¿Qué esperar realistamente tras optimizar Core Web Vitals?

• LCP: de 4-6 segundos a 1,8-2,3 segundos en webs WordPress estándar.
• INP: de 400-700 ms a 80-180 ms tras eliminar scripts pesados.
• CLS: de 0,3-0,6 a 0,02-0,08 tras dimensionar correctamente.
• PageSpeed Score móvil: de 30-45 a 75-95.
• Posicionamiento orgánico: mejora visible en 4-8 semanas tras consolidar datos CrUX en verde.
• Bounce rate: reducción del 15-30 % en webs que pasaban de rojo a verde.

La metodología profesional siempre mide antes y después con la misma herramienta, el mismo dispositivo simulado y desde la misma ubicación geográfica. Sin metodología consistente, las cifras no son comparables.

Preguntas frecuentes sobre Core Web Vitals en WordPress

¿Cuánto tiempo tarda en notarse la mejora SEO tras optimizar Core Web Vitals? Entre 4 y 8 semanas. Los datos CrUX se actualizan cada 28 días, así que Google necesita al menos un ciclo completo para considerar los nuevos valores. Después, el efecto en ranking aparece progresivamente, no de un día para otro.

¿Es mejor WP Rocket, LiteSpeed Cache o FlyingPress? Para hostings LiteSpeed (SiteGround, Hostinger), LiteSpeed Cache es gratis y completo. Para otros hostings, WP Rocket es la opción más fácil de configurar. FlyingPress es más técnico pero rinde excelentemente.

¿Por qué Lighthouse me da 90 y CrUX me da rojo? Lighthouse simula condiciones controladas. CrUX mide usuarios reales con dispositivos y conexiones distintos. Las grandes diferencias suelen indicar problema en dispositivos antiguos o conexiones móviles lentas.

¿Tengo que cambiar de tema si quiero buenos Core Web Vitals? No necesariamente. Hay temas pesados (Avada, BeTheme) que se optimizan bien y temas ligeros (GeneratePress, Astra, Kadence) que parten con ventaja. El tema importa pero menos que la configuración técnica.

¿Elementor o Divi destruyen los Core Web Vitals automáticamente? Los hacen más difíciles, no imposibles. Con optimización agresiva (Asset CleanUp, exclusión de JS no usado, critical CSS) se pueden poner en verde. Con tema más ligero o Gutenberg, el camino es más corto.

¿Cuánto cuesta optimizar Core Web Vitals profesionalmente? Para una web WordPress estándar de 20-50 páginas, entre 600 € y 2.500 € de servicio puntual según complejidad. Mantenimiento continuo: 50-150 €/mes dentro de un plan de soporte WordPress.

Conclusiones: el SEO técnico empieza por los Core Web Vitals

En 2026 los Core Web Vitals no son una métrica opcional para webs profesionales. Son condición necesaria para ranking competitivo, especialmente en sectores donde la competencia tiene webs bien optimizadas. Una pyme que ignora estos indicadores está pagando con tráfico orgánico perdido sin saberlo.

La buena noticia: poner LCP, INP y CLS en verde es alcanzable con método. No requiere reescribir la web ni cambiar de tecnología. Requiere disciplina técnica aplicada en orden: infraestructura, LCP, INP, CLS. Cualquier web WordPress profesional puede llegar a verde en 4-8 semanas si se trabaja con criterio.

En VEXEO trabajamos los Core Web Vitals como parte indivisible del diseño web y el SEO/GEO, dentro del Escalón 2 de la Escalera de Madurez Digital. No es un servicio aparte: es parte del estándar de calidad. Si quieres revisar el estado actual de los Core Web Vitals de tu web o plantear una optimización completa, puedes solicitar una test de salud digital gratuito sin compromiso.

La velocidad es uno de los cinco pasos de una revisión completa: tienes el resto en cómo hacer una auditoría SEO básica en una tarde.