CWV PARA WORDPRESS

Qué realmente mueve LCP, INP y CLS en un sitio WordPress real, según alguien que ha desplegado miles.

Performance & Core Web Vitals supporting 3 min read reviewed 21 jun 2026

← Guides All guides in this topic

on this page
  1. Los umbrales, brevemente
  2. Por qué WordPress tiene baja puntuación por defecto
  3. Las correcciones que realmente funcionan
  4. Errores comunes de WordPress
  5. Mide como lo hace Google

Los umbrales, brevemente

Tres métricas, medidas en el percentil 75 de visitantes reales: LCP menor a 2.5 segundos, INP menor a 200 milisegundos, y CLS menor a 0.1. Google las lee desde datos de campo en Chrome User Experience Report, no desde tu ejecución de Lighthouse, así que una puntuación verde en lab es necesaria pero no suficiente.

Punto clave: WordPress puede pasar Core Web Vitals, pero sus valores predeterminados trabajan en tu contra: temas pesados, proliferación de plugins y medios sin optimizar. Primero arregla los medios y el caché, segundo reduce plugins, y verifica con datos de campo, no con puntuaciones de lab.

Por qué WordPress tiene baja puntuación por defecto

  • Temas pesados y constructores de páginas. Los temas multipropósito y constructores como Elementor y Divi envían bundles grandes de CSS y JavaScript, mucho de lo cual no se usa en ninguna página dada.
  • Proliferación de plugins. Cada plugin activo puede agregar sus propios scripts y estilos en todo el sitio, incluso en páginas que nunca lo usan.
  • Medios sin optimizar. La biblioteca de medios sirve lo que se subió. Las imágenes hero grandes sin WebP y sin dimensionamiento son el asesino de LCP más común.
  • Sin caché de forma predeterminada. Una instalación estándar de WordPress renderiza PHP en cada solicitud. Sin caché de página, el tiempo hasta el primer byte sufre bajo carga.

Las correcciones que realmente funcionan

En orden de impacto: agregar caché de página y un CDN; optimizar y dimensionar correctamente las imágenes (WebP, carga diferida debajo del pliegue); reducir el JavaScript del tema y los plugins que distribuyes; y alojar en infraestructura que mantenga el tiempo hasta el primer byte bajo. Un buen [host administrado o VPS](/blog/best-vps-for-wordpress-2026/) hace más por el TTFB que cualquier plugin. Si tu construcción es lo suficientemente pesada como para que nada de esto sea suficiente, esa es la señal para considerar [WordPress sin encabezado con Astro](/blog/headless-wordpress-astro-setup/), que elimina el peso del front-end por completo.

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

Errores comunes de WordPress

  • Instalar tres plugins de caché. Entran en conflicto. Elige un plugin de caché de página (u un host con caché integrada) y listo.
  • Optimizar imágenes manualmente, una vez. Las nuevas cargas lo deshacen. Usa un plugin o pipeline que convierta a WebP y dimensione en la carga, cada vez.
  • Perseguir un 100 en Lighthouse. Es un juguete de laboratorio. El informe de Search Console y los datos de campo son lo que te clasifica.
  • Agregar un plugin de rendimiento sin eliminar la causa. Un minificador sobre un constructor bloated es una venda, no una solución. Elimina el exceso primero.

Mide como lo hace Google

No instales nada que solo reporte puntuaciones de laboratorio. Usa la sección de datos reales de PageSpeed Insights y el informe Core Web Vitals de Search Console, ambos leen datos de usuarios reales. Después de una corrección, los datos reales tardan aproximadamente 28 días en reflejar completamente el cambio, así que no entres en pánico cuando la puntuación no se mueva la mañana siguiente. Sigue la tendencia durante semanas, no el número de un solo día, y solo da una corrección por terminada una vez que los datos reales la confirmen.

WHEN YOU ARE READY TO TALK