CWV PARA WORDPRESS

Qué es lo que realmente influye en los índices LCP, INP y CLS en una página web real de WordPress, según alguien que ha puesto en marcha miles de ellas.

Rendimiento y Core Web Vitals guía 3 min de lectura revisado 21 jun 2026

← Todas las guías Todas las guías de este tema

En esta página
  1. Los umbrales, en resumen
  2. Por qué WordPress obtiene una puntuación baja por defecto
  3. Las soluciones que realmente marcan la diferencia
  4. Errores habituales en WordPress
  5. Mide como lo hace Google

Los umbrales, en resumen

Tres métricas, medidas en el percentil 75 de los visitantes reales: LCP inferior a 2,5 segundos, INP inferior a 200 milisegundos y CLS inferior a 0,1. Google obtiene estos datos a partir de la información de campo del Informe sobre la experiencia de usuario de Chrome, no de tu ejecución de Lighthouse, por lo que una puntuación verde en el laboratorio es necesaria, pero no suficiente.

Conclusión clave: WordPress puede superar las pruebas de Core Web Vitals, pero sus ajustes predeterminados te lo ponen difícil: temas pesados, exceso de plugins y archivos multimedia no optimizados. Empieza por optimizar los archivos multimedia y el almacenamiento en caché; a continuación, reduce el número de plugins; y comprueba los resultados con datos de campo, no con puntuaciones de laboratorio.

Por qué WordPress obtiene una puntuación baja por defecto

  • Temas pesados y constructores de páginas. Los temas polivalentes y los constructores como Elementor y Divi incluyen paquetes de CSS y JavaScript de gran tamaño, gran parte de los cuales no se utilizan en ninguna página concreta.
  • Exceso de complementos. Cada complemento activo puede añadir sus propios scripts y estilos en todo el sitio web, incluso en páginas que nunca lo utilizan.
  • Archivos multimedia no optimizados. La biblioteca multimedia muestra tal y como se han subido. Las imágenes principales de gran tamaño, sin formato WebP y sin ajustar su tamaño, son la causa más habitual de un LCP elevado.
  • Por defecto, no se utiliza el almacenamiento en caché. Una instalación estándar de WordPress ejecuta el código PHP en cada solicitud. Sin el almacenamiento en caché de páginas, el tiempo hasta el primer byte se ve afectado cuando hay mucha carga.

Las soluciones que realmente marcan la diferencia

Por orden de importancia: añade el almacenamiento en caché de páginas y una CDN; optimiza y ajusta correctamente el tamaño de las imágenes (WebP, carga diferida por debajo del pliegue); reduce el código JavaScript del tema y los plugins que incluyes; y aloja tu sitio en una infraestructura que mantenga bajo el tiempo hasta el primer byte. Un buen [servidor gestionado o VPS](/blog/best-vps-for-wordpress-2026/) mejora el TTFB más que cualquier plugin. Si tu sitio es tan pesado que nada de esto resulta suficiente, es el momento de plantearte utilizar [WordPress Headless con Astro](/blog/headless-wordpress-astro-setup/), lo que elimina por completo la carga del front-end.

Para ver la versión práctica de esto, consulta mi página [Optimización de la velocidad de WordPress](/wordpress-speed-optimization/); para la lista independiente de la plataforma, consulta la [lista de comprobación de Core Web Vitals](/guides/cwv-checklist/).

Errores habituales en WordPress

  • Se están instalando tres plugins de almacenamiento en caché. Entran en conflicto. Elige un plugin de almacenamiento en caché de páginas (o un servidor con almacenamiento en caché integrado) y deja de instalar más.
  • Optimizar las imágenes manualmente, una sola vez. Las nuevas subidas lo deshacen. Utiliza un plugin o un proceso que las convierta a WebP y las redimensione al subirlas, cada vez.
  • A la caza de los 100 en Lighthouse. Es un juguete de laboratorio. El informe de Search Console y los datos de campo son los que determinan tu posicionamiento.
  • Añadir un complemento de rendimiento sin eliminar la causa. Un minificador sobre un generador sobrecargado es un parche, no una solución. Primero hay que eliminar el exceso de código.

Mide como lo hace Google

No instales nada que solo muestre puntuaciones de laboratorio. Utiliza la sección de datos de campo de PageSpeed Insights y el informe «Core Web Vitals» de Search Console, ya que ambos se basan en datos de usuarios reales. Tras aplicar una corrección, los datos de campo tardan unos 28 días en reflejar plenamente el cambio, así que no te asustes si la puntuación no varía a la mañana siguiente. Sigue la tendencia a lo largo de varias semanas, en lugar de fijarte en la cifra de un solo día, y solo da por resuelta una corrección cuando los datos de campo lo confirmen.

CUANDO QUIERAS HABLAR