Core Web Vitals en WordPress: por qué los plugins de caché ya no son suficientes en 2026

Llevas meses intentando mejorar la velocidad de tu WordPress. Has probado WP Rocket. Después W3 Total Cache. Luego LiteSpeed Cache. Has cambiado de hosting "premium". Has comprimido imágenes. Has lazy-loadeado lo que se podía lazy-loadear. Y aun así, cada vez que entras en Search Console, ahí está el aviso: "LCP por encima del umbral aceptable".

No estás solo. Es uno de los problemas más frecuentes que veo en proyectos de cliente. Y la respuesta corta es esta: en 2026, los plugins de caché ya no resuelven el problema de fondo, porque el problema de fondo no es la caché.

Te explico exactamente por qué.

Refresco rápido: qué son los Core Web Vitals

Si ya los conoces, salta a la siguiente sección. Si no, esto en 30 segundos:

Google mide tres cosas concretas para decidir si una web es "rápida":

• LCP (Largest Contentful Paint): cuánto tarda en aparecer el elemento más grande de la página (normalmente la imagen del hero o un titular grande). Debe ser menor de 2,5 segundos.

• INP (Interaction to Next Paint): cuánto tarda la web en responder cuando pulsas algo. Debe ser menor de 200 ms. Sustituyó al antiguo FID en marzo de 2024.

• CLS (Cumulative Layout Shift): cuánto se mueve el contenido mientras carga (esa sensación de cuando vas a pulsar algo y el botón se desplaza). Debe ser menor de 0,1.

Si los tres están en verde, Google considera tu web "rápida" y eso se traduce en mejor posicionamiento, menos rebote y más conversión.

El que más le cuesta a WordPress es LCP. Vamos a por él.

Causa 1: PHP y base de datos en cada visita

Esta es la madre de todas las causas. Y es la que ningún plugin de caché resuelve del todo.

WordPress, por su arquitectura, ejecuta código PHP y consulta tu base de datos cada vez que un visitante entra. Sí, los plugins de caché capturan el HTML resultante y lo guardan, pero:

• La caché se invalida cada vez que actualizas un post o cambia algo (lo que pasa más a menudo de lo que crees, porque cualquier comentario, suscriptor o cambio de stock de WooCommerce lo dispara).

• Cuando la caché está fría (primer visitante en mucho tiempo, o tras una invalidación), el visitante "paga" la espera completa: PHP arranca, consulta MySQL, monta el HTML, lo entrega. Eso son fácilmente 800-2.000 ms de TTFB.

• La caché de servidor no soluciona la latencia geográfica: si tu servidor está en Madrid y el visitante en México, ya tienes 250 ms de retraso solo por la distancia, antes de que tu PHP haya empezado.

El problema de fondo: el modelo "PHP + base de datos en cada request" estaba bien en 2010. En 2026, con Google premiando latencias por debajo de 1,5 segundos, es estructuralmente inviable para webs con tráfico real.

Cómo lo arreglas con caché: parcialmente. Plugins como WP Rocket o LiteSpeed reducen el TTFB de 1.500 ms a 300-500 ms cuando la caché está caliente. Sigue siendo demasiado.

Cómo lo arreglas de verdad: sirviendo HTML estático prefabricado desde un CDN global, sin PHP ni base de datos en el camino. Eso es exactamente lo que hace WordPress headless con Astro o Next.js.

Causa 2: JavaScript bloqueante de plugins de terceros

Cada plugin que instalas suele inyectar uno o varios scripts en el header. Yoast SEO, plugins de cookies, plugins de chat, plugins de analítica avanzada, plugins de widgets de redes sociales, plugins de A/B testing… cada uno añade su carga.

El problema no es solo el peso. Es que muchos de esos scripts son bloqueantes: el navegador no puede pintar el contenido principal hasta que se han descargado y ejecutado. Resultado: el LCP se va al traste.

Test rápido: abre tu web, haz clic derecho → "Inspeccionar elemento" → pestaña "Network" → recarga. Mira cuántos scripts hay antes de que aparezca tu hero. Si son más de 5-6, ahí tienes parte del problema.

Cómo lo arreglas con plugins: con mucha disciplina y plugins tipo "Asset CleanUp" o "Perfmatters" que te permiten desactivar scripts página por página. Funciona, pero es muy frágil: cualquier actualización de WordPress o de un plugin puede romper la configuración.

Cómo lo arreglas de verdad: con un frontend desacoplado, donde tú decides exactamente qué JavaScript carga en cada página. Astro tiene la ventaja brutal de cargar cero JavaScript por defecto, lo que elimina el problema de raíz.

Causa 3: Imágenes mal servidas (y no es solo culpa tuya)

WordPress tiene un sistema de imágenes responsive bastante decente desde la versión 4.4 (con srcset y sizes). Pero en la práctica, casi nunca está bien configurado:

• Los temas premium suelen ignorar el srcset y servir siempre la imagen original.

• Los plugins de optimización (Smush, ShortPixel, Imagify) reducen el peso pero no siempre generan los formatos modernos (WebP, AVIF) ni los tamaños adecuados.

• El "lazy loading" nativo a veces no se aplica a la imagen del hero, que es justo la que cuenta para el LCP.

• Los iconos de redes sociales y los avatares de Gravatar suelen cargarse desde dominios externos sin optimización.

Resultado: tu LCP es la imagen del hero, esa imagen pesa 380 KB cuando podría pesar 35 KB en WebP, y no hay plugin que lo arregle si el tema está mal hecho.

Cómo lo arreglas con plugins: hasta cierto punto. Combinaciones tipo "ShortPixel + tema bien hecho + CDN de imágenes" llegan a pasar. Pero requiere supervisión técnica constante.

Cómo lo arreglas de verdad: en un frontend desacoplado, tú controlas exactamente cómo se sirve cada imagen. Cloudflare Images, Imgix, o el <Image> component de Astro/Next entregan AVIF + WebP + fallback JPG con srcset correcto y loading=eager solo para la primera imagen del viewport. El LCP de imagen baja de 2 segundos a 400 ms.

Causa 4: Fonts mal cargadas

Las fuentes web son uno de los puntos ciegos más comunes. Tu tema carga 4 pesos diferentes de Open Sans desde Google Fonts, en formato WOFF2, sin precarga, con font-display: swap. Y eso te cuesta 200-500 ms en LCP.

¿Por qué? Porque el texto del hero usa la fuente personalizada, el navegador tiene que descargarla antes de poder pintar ese texto, y mientras tanto el LCP está esperando.

Cómo lo arreglas con plugins: instalando "OMGF" para autoalojar Google Fonts, "Asset CleanUp" para eliminar pesos no usados, y manualmente añadiendo <link rel="preload"> en el header. Otra vez: técnico y frágil.

Cómo lo arreglas de verdad: en un frontend desacoplado, defines exactamente qué fuentes cargas, cuándo, con qué font-display, y con preload del peso crítico. Es 4 líneas de código que afectan directamente a tu LCP.

Causa 5: El tema está mal hecho (y nadie te lo dice)

Aquí viene la verdad incómoda: el 70% de los temas WordPress comerciales (incluso los caros, incluso los famosos) están mal optimizados. Cargan jQuery cuando no lo necesitan. Inyectan CSS de elementos que no usas. Hacen requests a servidores propios para cargar fuentes o iconos. Tienen JavaScript bloqueante en el <head>.

Los plugins de caché capturan el resultado, pero el problema de raíz sigue ahí: estás sirviendo un HTML hinchado.

He visto webs donde el problema principal era literalmente que el tema cargaba 3 versiones distintas de Font Awesome, una desde un CDN externo, una desde el plugin de elementos del tema, y otra desde un widget de redes sociales. 800 KB de iconos de los que se usaban 6.

Cómo lo arreglas con plugins: revisión manual exhaustiva (perfmatters, asset cleanup, debug bar, query monitor). Posible, pero requiere tiempo de un especialista y se rompe con cada actualización.

Cómo lo arreglas de verdad: rehaciendo el frontend en una tecnología donde tú controlas cada byte. Astro, por diseño, no inyecta nada que no le pidas explícitamente. El HTML que sale del build es exactamente el HTML que tú escribiste.

¿Y si solo tengo un sitio pequeño?

Si tu web tiene menos de 1.000 visitas al mes y tu LCP está en 3 segundos, tienes dos opciones realistas:

1. Sufrir el SEO penalizado y aceptar que vas a posicionar peor que tu competencia que sí lo arregla.

2. Migrar a un setup desacoplado, que para una web pequeña cuesta 2.500-4.000 € y se amortiza en 12-18 meses solo por la mejora de tráfico orgánico (más conversión + menos rebote + ranking).

Lo que no te recomiendo es seguir 6 meses más probando plugins. Llevas ya muchos meses haciéndolo. Si no ha funcionado, no va a funcionar.

Cuando el problema NO son los plugins

Tres casos donde headless no es la solución:

• Tu hosting es malísimo y no lo sabes. Antes de cualquier migración, asegúrate de que tu hosting actual cumple lo básico: PHP 8.1+, SSD, 4 GB de RAM mínimo, ubicación geográfica cercana a tu audiencia. Si estás en hosting compartido cutre por 3 €/mes, primero arregla eso.

• Tienes un plugin de membresías o foros muy activo. Los sitios con mucha funcionalidad dinámica de usuario logueado no son buenos candidatos a 100% headless. Sí pueden hibridar, pero la migración es más compleja.

• Tu base de datos está corrupta o llena de basura. He visto webs con 5 GB de "transients" porque un plugin de caché mal configurado dejaba residuos. Un DROP de transients y una optimización de base de datos puede mejorarte 800 ms de TTFB sin migrar nada.

Antes de hablar de migración, siempre hago un diagnóstico de 15 minutos para descartar estos tres casos. Si tu problema es uno de ellos, te sale más barato arreglarlo que migrar.

Cómo saber si tu caso es de los que mejoran con headless

Test rápido. Responde sí/no a estas preguntas:

1. ¿Tu LCP móvil está por encima de 2,5 segundos en PageSpeed Insights?

2. ¿Has probado al menos dos plugins de caché diferentes sin éxito?

3. ¿Tu web es mayoritariamente contenido (blog, páginas, fichas) y no funcionalidad de usuario logueado?

4. ¿Tienes objetivos de SEO o conversión relevantes?

5. ¿Te preocupa que un pico de tráfico tumbe la web?

Si has respondido SÍ a 3 o más, tu caso es probablemente de los que mejoran con WordPress headless. No te lo digo porque venda el servicio (que sí lo vendo), te lo digo porque arquitectónicamente tu web ya no encaja con el modelo PHP+base de datos por visita.

¿Qué haces ahora?

Tienes tres caminos:

Camino 1: Seguir intentándolo con plugins. Tiempo medio para llegar al verde: 3-6 meses, sin garantías, con caos cada actualización. No lo recomiendo, pero es válido si presupuesto cero.

Camino 2: Contratar a un especialista para optimizar tu WordPress al máximo posible. Un técnico bueno te puede llevar el LCP de 3,5 s a 1,8-2,2 s. Mejor que el verde, pero no mucho más. Coste: 800-1.500 € de consultoría. Funciona si quieres mejorar pero no migrar.

Camino 3: Migrar a WordPress headless. Coste 2.500-12.000 € según complejidad. Tiempo: 3-6 semanas. Resultado: LCP en 0,6-1,2 s, PageSpeed 95+, hosting frontend gratis. Es lo que recomiendo si te tomas en serio el tráfico orgánico.

Si quieres entender el camino 3 a fondo, en mi servicio de WordPress headless tienes el detalle de cómo lo hago, los tres stacks que ofrezco (Astro, Next.js, Faust.js) y los precios reales sin trampa.

Lecturas relacionadas

• ¿Qué es WordPress headless? Guía sin jerga técnica para empresas — el "qué" antes del "cómo".

• Cómo migré jaime.digital de WordPress a Astro headless: el caso real — mi propia migración con cifras LCP antes/después.

• Astro vs Next.js vs Faust.js para WordPress headless — qué stack elegir si decides migrar.

• WordPress headless vs WordPress tradicional: 8 diferencias reales con costes — la comparativa cuantitativa.

Resumen rápido

• Los plugins de caché capturan el HTML pero no eliminan el problema de fondo: PHP + base de datos por visita.

• Las 5 causas reales de mal LCP en WordPress son: arquitectura PHP+DB, JavaScript bloqueante, imágenes mal servidas, fonts sin precarga, temas mal optimizados.

• Solo 3 de estas causas se pueden mitigar con plugins. Las otras 2 requieren rehacer el frontend.

• WordPress headless las resuelve todas a la vez porque elimina el modelo dinámico y sirve HTML estático desde un CDN.

• No es para todos: si tienes hosting cutre, plugins de membresías muy activos o base de datos corrupta, arregla eso primero.

¿Tu LCP está disparado y quieres saber si tu caso es candidato a headless? Pídeme un diagnóstico gratuito y te lo digo en una llamada.