Las Core Web Vitals (CWV) han pasado de ser un término técnico desconocido a una prioridad para quienes gestionamos sitios web. Desde que Google las incluyó como factor de posicionamiento, cada vez más usuarios de WordPress se preguntan cómo afectan a sus páginas, cómo medirlas y, sobre todo, cómo mejorarlas sin tener que ser desarrolladores avanzados.

En este artículo te explico de forma clara y práctica qué son las Core Web Vitals, por qué deberías preocuparte por ellas si usas WordPress, cómo medirlas y qué acciones concretas puedes tomar para mejorarlas en tu sitio.

¿Qué son las Core Web Vitals?

Tiempos de las Core Web Vitals

Las Core Web Vitals son un conjunto de métricas centradas en el rendimiento y la experiencia del usuario. Evalúan tres aspectos clave de una web:

  • Velocidad de carga perceptible (LCP)
  • Capacidad de respuesta (INP)
  • Estabilidad visual (CLS)

Google ha establecido estas métricas como señal de ranking porque reflejan cómo se percibe una web desde el punto de vista de quien la visita.

No basta con que la web cargue rápido según los tests: debe sentirse rápida, estable e interactiva para las personas.

Es decir, es como aquello de «no basta con ser bueno, también hay que parecerlo».

  1. ¿Qué son las Core Web Vitals?
  2. Un poco de historia
  3. ¿Por qué son importantes las CWV?
  4. Herramientas para medir las CWV
  5. Search Console
  6. LCP (Largest Contentful Paint)
  7. INP (Interaction to Next Paint)
  8. CLS (Cumulative Layout Shift)
  9. Interpretando las Core Web Vitals
  10. Errores comunes al optimizar las Core Web Vitals en WordPress
  11. Mitos comunes sobre las Core Web Vitals
  12. Estrategias avanzadas y sostenibles para optimizar las Core Web Vitals en WordPress
  13. Casos reales y ejemplos aplicados
  14. Recursos y enlaces oficiales
  15. Conclusión

También tienes este contenido en formato webinar en directo con preguntas de la audiencia en nuestro canal de YouTube. ¡Esperamos que te guste tanto como esta entrada en el blog!

Un poco de historia

Ya en agosto del 2008 escribía una entrada sobre optimización1, un mes antes del lanzamiento del navegador Google Chrome. En ese artículo nombraba a YSlow2 (proyecto iniciado por Yahoo3), una extensión para el extinto Firebug.

Extensión YSlow de Yahoo

Hace ahora unos 20 años, Yahoo era toda una referencia en la optimización web y las 34 normas (divididas en 6 categorías), sentaron las bases de la optimización web y aún son de aplicación en la actualidad, salvo pequeñas excepciones.

Y decimos que un poco de historia, porque las Core Web Vitals de Google, aunque no derivan de las reglas de YSlow, sí que se basan en las técnicas de WPO de Yahoo (de las que surgió YSlow) y podríamos decir que son la evolución resumida de dichas reglas.

Las Core Web Vitals son las reglas para el WPO enfocadas a la velocidad de nuestra web y que el usuario tenga una mejor experiencia web (ser rápido y parecer rápido).

Reglas YSlow

Las reglas que medía YSlow son las siguientes:

Optimización de contenido:

  • Reducir llamadas HTTP
  • Reducir búsquedas DNS
  • Evitar redirecciones
  • Ajax cacheable
  • Retrasar la carga de componentes
  • Precargar componentes
  • Reducir el número de elementos DOM
  • Separar componentes con dominios
  • Minimizar el número de Iframes
  • Evitar 404

Optimización del servidor

  • Usar CDN (Content Delivery Network)
  • Agregar Expires o Cache-Control Header
  • Compresión Gzip
  • Configurar ETags
  • Vaciar Buffer temprano
  • Usar GET para peticiones AJAX

JavaScript y CSS

  • Scripts en el pie
  • JavaScript y CSS externos
  • Minimizar JavaScript y CSS
  • Eliminar los scripts duplicados
  • Minimizar accesos al DOM
  • Delegación de eventos
  • Hojas de estilo en la cabecera
  • Evitar expresiones CSS
  • Link mejor que @import
  • Evitar el uso de filtros

Optimización de Cookies

  • Reducir el tamaño de las cookies
  • Componentes en dominio libre de cookies
  • Optimización de imágenes

Optimizar imágenes

  • Optimizar Sprites CSS
  • No escalar imágenes en HTML
  • Favicon.ico, ligero y cacheable

Optimización para móviles

  • Archivos no superiores a 25K
  • Empaquetar componentes en documento multiparte

¿Por qué son importantes las CWV?

Las mejoras en las métricas de las CWV (Core Web Vitals)se traducen en:

  • Mejoras en el posicionamiento SEO.
  • Menor tasa de rebote.
  • Mayor tiempo de permanencia en la página.
  • Mejoras en la conversión (ventas, registros, etc.).

En el ecosistema WordPress tenemos una gran ventaja: muchas optimizaciones están disponibles sin tocar código, aplicando un plugin.

Pero esta ventaja también se acaba convirtiendo en un reto: el ecosistema de temas, plugins y editores visuales puede hacer que la web se sobrecargue sin darnos cuenta y a base de unos pocos clics.

Optimizar las CWV en WordPress es posible y más que recomendable, casi imprescindible.

Además, si estás en la plataforma de WordPress.com, ya tienes diferentes herramientas a mano para hacerlo de una forma aún más fácil.

Herramientas para medir las CWV

Hoy en día disponemos de cantidad de herramientas gratuitas que podemos usar para medir el rendimiento de las CWV en nuestra web. Algunas de las más usadas y útiles:

  • PageSpeed Insights: te muestra datos reales de campo (usuarios reales) y de laboratorio.
  • Lighthouse: disponible en Chrome DevTools y navegadores basados en Chrome (Opera, Vivaldi o Edge). Ofrece informes detallados.
  • WebPageTest.org: excelente para ver tiempos de carga y optimizaciones posibles. Mide las CWV pero no el INP (muestra el Total Blocking Time).
  • GTmetrix: herramienta muy completa y con posibilidad de exportar informes (herramienta de pago). Mide las CWV pero no el INP (muestra el Total Blocking Time).
  • Yellow Lab Tools: Una completísima herramienta Open Source que nos permite opciones como medir un sitio protegido con autenticación HTTP. No mide las CWV, pero nos sirve para complementar las mediciones junto con otras herramientas.

Si la web está alojada en WordPress.com, desde el panel de control de tu web (Alojamiento -> Vista General -> Rendimiento) puedes realizar una prueba de rendimiento de las CVW para móvil o escritorio de cualquiera de tus páginas.

Análisis de CVW desde WordPress.com

Por último, si somos desarrolladores y nos manejamos con la consola, podemos instalar lighthouse en el sistema para realizar pruebas directamente desde consola y generar un HTML con los resultados y/o integrarlo en nuestro flujo de trabajo.

Lo instalamos con el siguiente comando:

npm install -g lighthouse

y lo ejecutamos con:

lighthouse <url>
lighthouse desde consola

Con esto podemos ejecutar lighthouse en cada commit de nuestro código con la integración de lighthouse CI, asegurándonos que los cambios introducidos en el código con esa última modificación no van a repercutir negativamente en las CWV de nuestra web.

Podemos implementar Lighthouse CI manualmente en nuestro repositorio o por medio de una acción automatizada de GitHub.

Search Console

Google Search Console es otra fuente para comprobar las CWV con los datos de campo que veremos en breve, pero adelantamos que, estos son los datos reales de los usuarios y no una medición de laboratorio en el momento actual.

Aquí podemos ver los datos de CWV de todas las páginas de las que se tienen datos tanto en móvil como en escritorio y ver si debemos mejorar algunas páginas o se mantiene todo correcto a lo largo del tiempo.

Esta es una herramienta fundamental y que debemos tener configurada con nuestro dominio, tanto por temas de SEO, como de seguridad y de WPO.

CVW en Google Search Console

LCP (Largest Contentful Paint)

La métrica del LCP mide cuánto tarda en mostrarse el contenido más grande dentro de la ventana visible del navegador (por ejemplo, una imagen destacada o un título grande).

  • ✅ Bueno: menos de 2,5 segundos.
  • ⚠️ Mejorable: entre 2,5 y 4 segundos.
  • ❌ Malo: más de 4 segundos.

Cómo mejorar el LCP:

  • Optimiza el peso de las imágenes.
  • Usa formatos modernos de imagen, como WebP y AVIF.
  • Carga crítica primero (evita lazy load en el hero).
  • Elige un tema ligero y bien estructurado.

INP (Interaction to Next Paint)

Sustituto de FID4. Mide cuánto tarda la web en responder de forma visual a una interacción (clic, toque, teclado).

  • ✅ Bueno: menos de 200 ms.
  • ⚠️ Mejorable: entre 200 y 500 ms.
  • ❌ Malo: más de 500 ms.

Cómo mejorar el INP:

  • Minimiza el uso de JavaScript.
  • Evita scripts que bloqueen la página.
  • Usa defer y async en scripts no esenciales.
  • Elimina plugins innecesarios o mal optimizados.

CLS (Cumulative Layout Shift)

Mide cuánto se mueven los elementos de una página mientras se carga. Seguro que has visto páginas donde el texto salta o los botones cambian de sitio mientras lees.

  • ✅ Bueno: menos de 0,1.
  • ⚠️ Mejorable: entre 0,1 y 0,25.
  • ❌ Malo: más de 0,25.

Cómo mejorar el CLS:

  • Siempre define el tamaño de imágenes, iframes y vídeos.
  • Evita fuentes externas sin font-display: swap.
  • Cuidado con los anuncios, sliders y bloques embebidos.

Interpretando las Core Web Vitals

Cuando medimos las Core Web Vitals en la web de pagespeed tendremos un resultado similar al de la siguiente captura que vamos a analizar.

interpretando las Core Web Vitals

En el punto 1 se muestran los datos de móvil o de escritorio; según cambiemos entre uno y otro, veremos unos u otros resultados.

En las CVW podemos tener datos de laboratorio y datos de campo. Los datos de laboratorio, son los que obtenemos en un entorno controlado y los datos de campo son los datos reales de usuarios de nuestra web.

En este caso, los datos de laboratorio son los que obtenemos con lighthouse en nuestro ordenador o en una medición en la página en las condiciones actuales, que conocemos y controlamos.

Los datos de campo, son los datos reales de los usuarios que visitan la página y envían dichos datos anónimamente desde su navegador basado en Chromium. Estos datos nos dan una imagen diferente de los resultados de nuestra web.

Por ejemplo, si vendemos camisetas Premium con un precio cercano a los 1.000 euros por unidad (de hecho es un caso real), podemos esperar que nuestros usuarios se conecten con iPhone o smartphones de gama alta y una buena conexión.

Si la web se dedica a ofrecer microcréditos a gente con bajos recursos en África y América (también es un caso real), esperamos que las conexiones sean más inestables y los dispositivos con los que se conectan sean de gama baja.

Si se tratase de la misma web (aunque aquí estamos hablando de dos webs diferentes), tendríamos los mismos datos de laboratorio, pero datos de campo muy diferentes si se tratase del primer grupo o del segundo.

Es muy importante entender esto para los puntos 2 y 3 y tener claro que si nuestra web no tiene las suficientes visitas (es muy nueva, no se ha indexado, etc), no dispondremos de los datos de «Descubre lo que experimentan tus usuarios reales» o los datos de campo mostrados no serán solo de la URL analizada sino de todo el dominio (punto 2, Esta URL u Origen).

Los resultados mostrados en el punto 3 son los datos de campo recopilados por CrUX (Chrome UX Report) desde el navegador en los últimos 28 días.

Y por último, en el punto 4 es donde vemos los datos que acabamos de analizar ahora mismo (datos de laboratorio) y para los cuales podemos emular una conexión más lenta, menor procesador, cambiar la localización, no aceptar compresión, desactivar AVIF, etc, mediante las herramientas de desarrollo del navegador.

Developer tools, pruebas de laboratorio

Si la medición se ha realizado desde la web de pagespeed, para las pruebas de móvil y ordenador se establecen las siguientes limitaciones:

Móvil:

  • Moto G Power emulado con Lighthouse 12.6.0
    • Potencia de la CPU o de la memoria no limitada: 1178
    • Limitación de CPU: 1,2x slowdown (Simulada)
    • Emulación de pantalla: 412×823, DPR 1.75
    • Versión de Axe: 4.10.3
  • Limitación de 4G lenta
    • Limitación de red: 150 ms TCP RTT, 1638,4 kb/s throughput (Simulada)
    • Ubicación del navegador: Europa (depende de nuestra localización)
  • Usando HeadlessChromium 135.0.7049.114 con lr
    • User-agent (red): «Mozilla/5.0 (Linux; Android 11; moto g power (2022)) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Mobile Safari/537.36»

Ordenador:

  • Escritorio emulado con Lighthouse 12.6.0
    • Potencia de la CPU o de la memoria no limitada: 960
    • Limitación de CPU: 1x slowdown (Simulada)
    • Emulación de pantalla: 1350×940, DPR 1
    • Versión de Axe: 4.10.3
  • Limitación de red:
    • 40 ms TCP RTT, 10.240 kb/s throughput (Simulada)
    • Ubicación del navegador: Europa (depende de nuestra localización)
  • Usando HeadlessChromium 135.0.7049.114 con lr
    • User-agent (red): «Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36»

Después de estos datos y análisis, podemos ver las pruebas pasadas y las que tienen que mejorar y algunos consejos para llevar a cabo las optimizaciones.

Errores comunes al optimizar las Core Web Vitals en WordPress

  1. Instalar muchos plugins de caché que se pisan entre sí.
  2. Subir imágenes sin comprimir ni redimensionar.
  3. Temas visualmente atractivos pero con código incorrecto o poco optimizado.
  4. Usar tipografías externas mal implementadas.
  5. Embeber vídeos o redes sociales sin control.

Mitos comunes sobre las Core Web Vitals

  1. “Solo necesito una buena puntuación en PageSpeed Insights” → No. Lo importante es la experiencia real, no el color verde.
  2. “Si uso un buen hosting, no necesito optimizar” → Falso. El hosting ayuda y mucho, pero tú decides qué recursos cargas en cada caso.
  3. “Esto solo afecta a webs grandes” → No. Cualquier web se beneficia de una optimización de las CWV.
  4. “Los temas de WordPress siempre están optimizados” → Depende mucho del tema. Algunos son muy pesados.
  5. “El plugin X e Y lo arreglan todo” → Los plugins ayudan, pero no hacen magia, la magia la podemos hacer nosotros.

Estrategias avanzadas y sostenibles para optimizar las Core Web Vitals en WordPress

Carga condicional de scripts

Hay muchos scripts y hojas de estilos que se cargan en toda la web, aunque solo los necesitemos en una página en concreto.

Un ejemplo muy claro es el formulario de contacto Contact Form 7. Esto no es debido a que esté mal programado, sino a que el plugin no sabe si en una determinada página está o no insertado su shortcode (aunque hay algunas técnicas que se podrían utilizar para evitar este problema), por eso su CSS y scripts se inserta en todas las páginas, aunque no sea necesario.

En el caso de CF7, el propio autor nos dice en su página cómo debemos hacer para realizar dicha carga condicional.

Pero en otros casos (por ejemplo un slider), deberemos localizar dónde se carga su CSS y/o JS y copiar su identificador (id) para descargar dicho script o CSS si no se trata de la página que nos interesa.

Si, por ejemplo, el JS de nuestro supuesto es el siguiente:

Script a descargar

Y queremos cargar el slider solo en la página con slug conocenos, ahora que sabemos el id del script, deberemos crear el siguiente código en nuestro plugin de personalizaciones o en el archivo funcions.php de nuestro tema hijo.

function cl_dequeue_unused_styles_scripts() {
	if ( ! is_page( 'conocenos' ) ) {
		wp_dequeue_script( 'cl-slider-test' );
	}
}
add_action( 'wp_enqueue_scripts', 'cl_dequeue_unused_styles_scripts', 100 );

Con este código, lo que estamos haciendo en el action del encolado de scripts por parte de WordPress, es comprobar si la página es distinta de la que tiene el slug conocenos y en ese caso quitar de la cola de scripts el JavaScript con el identificador cl-slider-test.

Carga condicional de plugins

Si la carga condicional de scripts nos beneficia en el frontend, la carga condicional de plugins va un paso más allá y, además de no cargar CSS o JS, también evitamos la carga completa del plugin.

Esto implica el que no se ejecute código PHP, llamadas a la base de datos, etc. pudiendo aligerar enormemente la carga de nuestra web, ya que hay muchos plugins que solo se deben cargar en la parte de administración, en ciertas condiciones, cuando el usuario está conectado o viceversa, etc.

Fernando Puente fue el precursor de esta técnica en España y puedes ver varias charlas y talleres que ha dado en diferentes WordCamps acerca de esta técnica que se puede adaptar a multitud de situaciones.

Aunque hay algunos plugins que hacen «algo similar», esta es una técnica avanzada y muy potente que debemos realizar a medida para cada web y situación, por medio de un plugin mu (must use).

Optimiza imágenes de forma precisa

Debemos optimizar las imágenes en cuanto a tamaño, formato, precarga… (te recomiendo este artículo Domina la optimización de imágenes y conquista el WPO)

  • Usa tamaños correctos.
  • Aplica lazy load selectivo.
  • Usa formatos AVIF o WebP.

Precarga recursos importantes

Si tenemos un recurso que seguro vamos a utilizar en la página y es primordial que esté disponible desde el inicio, podemos preconectar al dominio y precargar el recurso que posteriormente necesitaremos, como por ejemplo la fuente principal de la web.

<link rel="preconnect" href="https://fonts.googleapis.com" crossorigin>
<link rel="preload" href="https://fonts.googleapis.com/fonts/tipografia.woff2" as="font" type="font/woff2" crossorigin>

Reduce el tiempo hasta que la página sea interactiva

Una buena opción es usar los atributos async y defer cuando importamos archivos JavaScript para no bloquear la carga y ejecución en la página web.

Defer y Async en JavaScript

Casos reales y ejemplos aplicados

Blog personal con muchas fotos

  • Se reemplazan imágenes pesadas por AVIF.
  • Lazy load bien aplicado.
  • Resultado: mejora en LCP y CLS.

Tienda online con WooCommerce

  • Scripts no esenciales deshabilitados.
  • Jetpack Boost activado.
  • Resultado: INP optimizado.

Web educativa con vídeos

  • Se sustituyen los vídeos embebidos por miniaturas con botón.
  • Tamaños fijos en iframes.
  • Resultado: CLS casi nulo.

Recursos y enlaces oficiales

Conclusión

Las CWV ya no son opcionales. Mejorarlas es una forma directa de ofrecer una experiencia superior y destacar frente a la competencia.

Como hemos visto en este artículo, tenemos cantidad de herramientas online e integradas en nuestro navegador para mediar las Core Web Vitals, simular diferentes entornos e incluso automatizar las mediciones.

La plataforma de WordPress.com incorpora herramientas de medición de las CWV que permiten analizar nuestras webs sin necesidad de salir del panel de administración.

Es importante diferenciar entre los datos de campo (obtenidos de CrUX) y los datos de laboratorio, para saber interpretar correctamente los resultados de los análisis.

Google nos proporciona una inmensa cantidad de documentación para poder mejorar las CWV de nuestra web, pero además hay una serie de vídeos sumamente interesantes. Es una pena que estos videos estén solo disponibles en inglés.

En muchas ocasiones, mejorar las métricas de las CVW de nuestra web son un simple ejercicio de análisis y lógica:

  • La web muestra en el pie de página un mapa de Google con la localización de nuestras oficinas. ¿Necesitamos cargar los mapas de Google y todos sus scripts para mostrar ese mapa en el que nadie hace clic? ¿Y si lo sustituimos por una imagen igual que lo que se muestra y con un enlace a dicho mapa en Google? Una implementación rápida y que mejorará mucho nuestros resultados.
  • Tenemos en la web cantidad de videos de YouTube, ¿no sería mejor sustituirlos por una imagen igual que la que muestra el video y que al hacer clic se carguen los scripts y vídeos de YouTube? Pero eso da mucho trabajo para cada video subido… No si usamos un plugin que realice ese trabajo automáticamente por nosotros (como WP YouTube Lyte o Lazy Load for Videos).
  • El captcha de Google se carga en todas las páginas y aumenta bastante la cantidad de JavaScript. ¿Es imprescindible usar el captcha de Google? Tenemos opciones más livianas e incluso con un mejor UX (verificar los visitantes web sin CAPTCHA), que molestan menos al usuario, como la opción gratuita Cloudflare Turnstile (no es necesario usar los servicios de CloudFlare para usar Turnstile).

Tenemos una gran cantidad de opciones que a veces solo requieren de un análisis de las necesidades de la web y sus usuarios y aplicar un poco de lógica.

Recomendaciones finales:

  • Mide tu sitio con PageSpeed
  • Corrige lo más fácil: imágenes, fuentes, plugins.
  • Mide de nuevo.
  • Repite.
  1. Optimización de la web de Foto DNG (parte I) ↩︎
  2. YSlow en español. ↩︎
  3. On April 29, Yahoo also released updates for YSlow, its developer solution for crafting high-performance Websites https://archive.ph/20120731002123/http://www.eweek.com/c/a/Application-Development/Yahoo-Launches-YQL-Execute-Updates-YSlow-660481/#selection-835.0-835.114 ↩︎
  4. El Fisrt Input Delay dejó de utilizarse oficialmente en favor del INP el 9 de septiembre de 2024. ↩︎