Core Web Vitals en WordPress: qué son y por qué te afectan

Las Core Web Vitals son tres métricas que Google usa para medir la experiencia real de tus usuarios:

• Largest Contentful Paint (LCP): cuándo se carga el contenido principal.
• Interaction to Next Paint (INP): cómo de rápido responde la página cuando el usuario hace clic, toca o teclea.
• Cumulative Layout Shift (CLS): cuánto “bailan” los elementos de la página mientras carga.

A efectos prácticos: si tu WordPress es lento, responde tarde o se mueve mientras se carga, tus Core Web Vitals van a salir mal. Y eso implica peor experiencia, menor conversión y, con el tiempo, menos visibilidad en buscadores.

La buena noticia es que en WordPress se pueden mejorar de forma bastante sistemática si sabes dónde tocar.

Paso 1: Medir bien antes de tocar nada

Antes de instalar plugins “milagro”, mide:

1. PageSpeed Insights (URL pública de Google)
2. GTmetrix o similares para ver el waterfall y el peso real de la página
3. Si puedes, Search Console → Experiencia de página → “Métricas web principales”

Páginas que sí debes medir:

• Home
• Una landing de servicios
• Un post tipo
• Fichas de producto (si usas WooCommerce)

Qué te interesa mirar:

• LCP: valor en segundos y qué elemento lo provoca (imagen, bloque de texto, slider…)
• CLS: qué elementos cambian de posición (banners, fuentes, anuncios, imágenes sin tamaño…)
• INP: qué interacciones tardan (botones de menú, acordeones, sliders, scripts de terceros…)

Guárdate capturas o apunta los valores. Vas a necesitar comparar antes/después.

Paso 2: Empezar por el hosting y la caché básica

Si el servidor es lento, todo lo demás es parches.

2.1. Hosting mínimo aceptable

Requisitos razonables para WordPress:

• PHP actualizado (8.x)
• Caché de servidor (NGINX FastCGI, LiteSpeed, etc.) o al menos OPcache bien configurado
• Certificado SSL correcto y HTTP/2/HTTP/3 activos
• Recursos mínimos decentes (CPU/RAM) si estás en un hosting compartido

Si tu TTFB (Time to First Byte) en PageSpeed y GTmetrix es sistemáticamente alto, plantéate:

• Migrar de un compartido saturado a uno mejor
• Usar un VPS gestionado si tienes varios proyectos o tráfico serio

2.2. Un solo plugin de caché de página, bien configurado

Regla básica: solo un plugin de caché de página.

En nivel intermedio, lo razonable es:

• Usar un plugin todo-en-uno tipo FlyingPress o similar (de pago), o
• Combinar un plugin de caché sólido gratuito con otros de optimización si quieres afinar más.

La mejora en LCP empieza aquí: HTML cacheado, menos trabajo en cada carga y menor TTFB percibido.

Si aquí detectas un cuello de botella de servidor o de configuración que no sabes aislar, en nuestros servicios WordPress orientados a rendimiento revisamos hosting, caché y estabilidad con una metodología clara. Puedes ver también nuestro método de revisión técnica.

Paso 3: Mejorar LCP (Largest Contentful Paint)

En la mayoría de webs WordPress, el LCP suele ser:

• Una imagen grande (hero, slider, cabecera)
• Un bloque de texto grande
• Un contenedor del constructor (Elementor, Bricks, Gutenberg…)

3.1. Reducir peso y tamaño del elemento LCP

Acciones directas:

• Comprime la imagen LCP de forma agresiva (WebP, AVIF si tu stack lo soporta).
• Ajusta el tamaño: nada de subir fotos de 4000 px cuando tu contenedor son 1200 px.
• Si el LCP es texto, revisa si no estás metiendo el hero dentro de tres capas de secciones del maquetador.

3.2. Cargar antes lo importante

• Asegúrate de que la imagen LCP no está lazy-loaded si es la imagen principal del hero.
• Usa plugins que permitan priority hints, fetchpriority="high" o preloads del recurso principal (varios plugins de rendimiento lo soportan ya).

3.3. Reducir el CSS y JS que bloquea el renderizado

• Activa minimización y combinación de CSS/JS solo cuando tenga sentido.
• Usa funciones de “Remove unused CSS” si tu plugin de rendimiento lo incluye.
• Evita plantillas con CSS infinito para cosas que no usas.

La idea: que el navegador pueda pintar el hero cuanto antes sin tener que tragarse media tonelada de estilos y scripts antes.

Paso 4: Mejorar INP (Interaction to Next Paint)

INP mide si tu web responde rápido cuando el usuario hace algo (clic, scroll, abrir menú).

En WordPress, lo que destroza el INP suele ser:

• Constructor visual con muchos widgets y scripts
• Sliders pesados
• Formularios complejos cargados en todas las páginas
• Scripts de terceros (chat, analítica, mapas, iframes…)

4.1. Reducir JavaScript en la carga inicial

• Activa en tu plugin de rendimiento la opción de “delay JavaScript hasta interacción” o equivalente.
• Excluye de ese delay solo lo que rompe visualmente (por ejemplo, JS crítico del menú).
• Quita sliders y efectos innecesarios de la home: son bonitos, pero penalizan mucho.

4.2. Cargar scripts solo donde hacen falta

Aquí entra en juego un plugin tipo Asset Cleanup o similar:

• Desactiva plugins que solo se usan en páginas concretas (formularios, tablas, popups…) en el resto del sitio.
• Deshabilita scripts de WooCommerce en páginas que no son tienda si tienes blog+tienda.

Menos JS cargado por defecto = mejor INP.

4.3. Controlar scripts de terceros

• Revisa uno por uno: chat, popups, mapas, reproductores, píxeles de seguimiento.
• Si puedes:
  • Carga los scripts de analítica de forma local.
  • Retrasa la carga de herramientas de mapa o vídeo hasta que el usuario interactúe (botón “ver mapa”, “ver vídeo”).

Paso 5: Mejorar CLS (Cumulative Layout Shift)

El CLS mide cuánto se “desplaza” el contenido mientras la página termina de cargar.

En WordPress, los culpables de siempre:

• Imágenes sin ancho/alto definido
• Fuentes externas que cambian el ancho de texto
• Banners o anuncios que empujan el contenido hacia abajo
• Elementos pegajosos (sticky) mal implementados

5.1. Fijar dimensiones de imágenes y contenedores

• Usa siempre imágenes con atributos width y height o estilos que reserven espacio (los constructores visuales modernos ya lo hacen, pero hay excepciones).
• Asegúrate de que los bloques de banners, sliders o anuncios tienen un alto fijo definido en CSS.

5.2. Controlar fuentes y cambios de estilo

• Evita cargar muchas familias y variantes de Google Fonts.
• Si puedes, hostea las fuentes de forma local y usa font-display: swap para evitar flashes raros.
• Revisa si el maquetador no está cambiando pesos de fuente después del primer renderizado.

5.3. Revisar anuncios, popups y barras flotantes

• Si usas anuncios, reservales un espacio fijo.
• Configura popups y barras solo tras interacción o transcurrido un tiempo, no en el primer milisegundo de carga.
• Comprueba en móvil: muchas veces el CLS está bien en escritorio y fatal en pantallas pequeñas.

Paso 6: Optimizar imágenes de forma global

Las imágenes afectan a LCP, CLS y a la sensación general de velocidad.

Checklist básico:

• Usar un plugin de optimización de imágenes que:
  • Convierta a WebP (o AVIF si tu entorno lo soporta)
  • Aplique compresión con pérdida razonable
  • Haga lazy load de todo salvo el LCP
• No subir nunca imágenes a tamaño “de cámara” directa.
• Comprobar el peso total de la página en el waterfall: objetivo razonable, < 1 MB, ideal < 500 KB en páginas clave.

Paso 7: Depurar el panel de administración y el backend

Aunque las Core Web Vitals se centran en la experiencia del usuario, si el backend va lento, al final terminas improvisando y añadiendo cosas sin probar.

Acciones útiles:

• Desactivar en el backend plugins que no necesitas en todas las pantallas.
• Limitar peticiones HTTP externas desde el admin (licencias, avisos, banners, telemetría).
• Limpiar transients y opciones de autoload que no tienen sentido seguir cargando.

Resultado: un entorno más ordenado, menos ruido y menos probabilidad de romper algo al optimizar.

Paso 8: Seguridad sin matar el rendimiento

Plugins de seguridad mal planteados pueden tumbar tus Core Web Vitals, sobre todo en móvil.

Pautas sensatas:

• Nada de escaneos pesados en horario de tráfico. Si los haces, que sea en staging.
• Usa varias capas:
  • Firewall a nivel de CDN / WAF
  • Reglas en servidor (Apache/Nginx)
  • Firewall ligero a nivel WordPress, no un monstruo cargado de funciones que escanea todo constantemente

La seguridad bien configurada devuelve la web a su rendimiento “base”. No mejora Core Web Vitals, pero evita que se desplomen por malware o ataques.

Paso 9: Medir otra vez y ajustar

Después de aplicar cambios:

1. Vuelve a pasar PageSpeed Insights en las mismas URLs.
2. Mira:
   • ¿Ha bajado el LCP al menos 0,3–0,5 s?
   • ¿El CLS está ya en verde?
   • ¿El INP ha mejorado al retrasar scripts y reducir JS?
3. Si tienes Search Console:
   • Revisa el informe de Core Web Vitals tras unas semanas.

No intentes arreglar todo en un día. Mejora por bloques:

1. Caché + hosting
2. LCP (hero, imágenes, CSS crítico)
3. INP (JS, terceros)
4. CLS (layouts, fuentes, anuncios)

Paso 10: Buenas prácticas para no volver atrás

Para no tirar el trabajo por la borda en seis meses:

• Antes de instalar un plugin nuevo, pregúntate si de verdad lo necesitas.
• Testea cualquier plugin de rendimiento o caché en staging (entorno de pruebas) antes de activarlo en producción.
• Documenta tu stack: qué plugin hace qué (caché, imágenes, JS, fuentes…).
• Haz una revisión de Core Web Vitals al menos cada cierto tiempo o tras cambios grandes de diseño.

Si estás afinando Core Web Vitals, enlaza este análisis con por qué WordPress responde lento aunque no siempre falle, con los cuellos de botella más habituales de una web que carga pesada y con esta guía para reducir el peso de las imágenes sin romper la maquetación.