Haz que las imágenes de WordPress sean rápidas: Web Vitals y WebP

Última actualización: June 28, 2026

Este es el compañero enfocado en la velocidad de mi guía de optimización de imágenes para WordPress de 2026. Esa guía es la configuración general: plugins, srcset, CDN y htaccess. Esta se centra en una sola pregunta: ¿cómo hacer que las imágenes de WordPress sean lo suficientemente rápidas como para poner los Core Web Vitals en verde? Medí cada paso en mi propio blog con mucho contenido multimedia, y las mejoras a continuación son lo que realmente movió Largest Contentful Paint de 3.8s a 1.1s.

Respuesta rápida: ¿qué hace que las imágenes de WordPress sean rápidas?

Comprime cada imagen a WebP antes de subirla, limita su ancho de visualización para que el navegador nunca descargue un archivo de 4000px para una ranura de 400px, implementa carga diferida (lazy-load) en todo lo que esté debajo del pliegue y coloca un CDN delante de /wp-content/uploads/. En mi propio blog, esos cuatro pasos redujeron el peso total de las imágenes en un 84 por ciento y bajaron el LCP móvil de 3.8s a 1.1s. Largest Contentful Paint en un blog de WordPress casi siempre es una imagen, por lo que ahí reside la velocidad.

¿Por qué las imágenes de WordPress dominan tus Core Web Vitals?

Core Web Vitals califica la velocidad percibida, y el que falla con más frecuencia en WordPress es Largest Contentful Paint, que para un sitio de contenido suele ser la imagen principal o la primera imagen en línea. Ejecuté PageSpeed Insights en 40 de mis propias publicaciones y el elemento LCP fue una imagen en 37 de ellas.

Las imágenes también impulsan las otras métricas indirectamente:

• Un héroe de 4MB bloquea el LCP hasta que termina de descargarse en un Slow 4G.
• El desplazamiento del diseño (Layout shift) aumenta cuando las imágenes llegan sin ancho ni alto definidos.
• INP sufre cuando una cola gigante de imágenes priva al hilo principal durante el análisis.

Google mide esto a partir de usuarios reales de Chrome y lo incorpora en señales de clasificación de búsqueda, documentado en la guía de carga rápida web.dev. La solución rara vez es el servidor. Casi siempre son las imágenes.

¿Cuánto peso de imagen puedes reducir?

Registré los números de un blog antes y después de optimizar. Mismas publicaciones, mismo contenido, solo cambiaron las imágenes.

Esa caída de 9.4MB a 1.1MB no es un caso especial. Es lo que sucede cuando dejas de enviar JPEGs sin comprimir en resolución nativa. La palanca más grande es el formato y las dimensiones, lo cual desglosa métrica por métrica la guía para optimizar imágenes para velocidad web.

¿Qué es LCP y por qué casi siempre es una imagen?

Largest Contentful Paint marca el momento en que se renderiza el elemento visible más grande. En un blog de WordPress, ese elemento es una foto principal (hero), una imagen destacada o la primera gran imagen en línea, no texto. Hasta que esa imagen se descarga, decodifica y pinta, la página aparece como "cargando" para un usuario y para Google.

Hay tres cosas que extienden el LCP de las imágenes, y reviso las tres en cada auditoría:

• El archivo es demasiado grande para el viewport que ocupa.
• La imagen LCP se carga diferidamente por error, por lo que comienza tarde.
• No hay CDN, por lo que el archivo viaja desde un único origen al otro lado del mundo.

Las dos últimas son errores de configuración que puedes arreglar en minutos. El primero es un hábito de subida, cubierto en la guía de tamaño de archivos de imagen.

¿Qué formato de imagen es más rápido para WordPress?

WebP. Es entre 25 y 35 por ciento más pequeño que JPEG con calidad percibida igual, y el núcleo de WordPress ha soportado su carga desde la versión 6.5. AVIF comprime otro 20 a 30 por ciento más pequeño, pero el soporte del navegador y CDN sigue siendo desigual, así que lo trato como una capa de mejora en lugar de la base.

Comprimo a WebP antes de subir y dejo que el CDN negocie AVIF a los navegadores que lo manejan. Para las compensaciones de formato en profundidad, la comparación JPG PNG WebP es la referencia a la que envío a la gente.

¿Cómo sirves el tamaño de imagen correcto para cada dispositivo?

Esta es la mejora que la gente omite. WordPress genera automáticamente tamaños thumbnail, medium, large e intermediate y emite un srcset, pero solo si tu tema llama a wp_get_attachment_image() en lugar de codificar un tag <img> fijo. Un teléfono nunca debe descargar el archivo de 2560px.

El markup que emite WordPress se ve así:

<img
  src="hero-1536x800.webp"
  srcset="hero-768x400.webp 768w,
          hero-1200x628.webp 1200w,
          hero-1536x800.webp 1536w"
  sizes="(max-width: 768px) 100vw, 1200px"
  width="1536" height="800"
  alt="Fotografía hero de Storefront en ancho completo">

Cómo verifico que funciona: abre DevTools, limita a Slow 4G, recarga y observa la pestaña Network. El teléfono debería solicitar el archivo de 768w. Si todos los dispositivos extraen la misma URL, el tema está roto o un constructor de páginas está ignorando el markup responsivo. La lógica de puntos de ruptura vive en la guía de breakpoints de imágenes responsivas.

¿Cómo activas la carga diferida (lazy loading) en WordPress?

Desde WordPress 5.5, cada <img> obtiene loading="lazy" por defecto, y 6.1 añadió una pista fetchpriority="high" a la primera imagen grande para que ya no compita con el cargador perezoso. Rara vez necesitas un plugin para esto hoy en día, lo cual es una gran ganancia de velocidad sin configuración alguna.

Dos reglas que impongo, porque ambas me costaron LCP antes de detectarlas:

• Nunca cargar diferidamente la imagen LCP por encima del pliegue (above the fold).
• Siempre establecer ancho y alto explícitos para evitar el desplazamiento del diseño (layout shift).

La documentación oficial de carga diferida de WordPress enumera los filtros para excluir el elemento LCP y cargar diferidamente iframes. Para las trampas comunes, incluida la errata del héroe, lee nuestro artículo sobre imágenes con carga diferida.

¿Cómo acelera un CDN las imágenes de WordPress?

Un CDN sirve cada imagen desde el borde más cercano al visitante y elimina los viajes de ida y vuelta a tu origen. Después de que moví a un cliente de JPEGs alojados en el origen a Cloudflare con Polish habilitado, el TTFB de las imágenes cayó de 420ms a 60ms para visitantes en Singapur y Brasil, las dos regiones donde su informe PageSpeed era rojo.

Lo que configuro en cada sitio:

• Cloudflare con Polish activado, lossless más WebP.
• Almacenar en caché todo bajo /wp-content/uploads/.
• Una caché de navegador de un año para tipos MIME de imágenes.
• Una capa AVIF negociada por CDN sobre WebP.

El almacenamiento en caché en el borde es más importante para tiendas WooCommerce con muchas imágenes y blogs multi-autor. La configuración completa, incluidos los encabezados de caché y las reglas de purga, está en la guía de CDN de imágenes.

Conclusión clave: la pila de velocidad de cuatro pasos

Si no recuerdas nada más, recuerda estos cuatro, porque son responsables de la caída de LCP que medí:

1. Comprimir a WebP antes de subir, por debajo de 200KB por imagen.
2. Limitar el ancho de visualización y dejar que srcset sirva el archivo correcto.
3. Cargar diferidamente debajo del pliegue, nunca la imagen LCP.
4. Almacenar en caché las imágenes en un borde CDN con un TTL de un año.

Haz esto y tu informe Core Web Vitals se pondrá verde. Omitir el paso responsivo srcset e incluso un WebP perfectamente comprimido seguirá enviando un archivo de escritorio a un teléfono.

Lista de verificación de velocidad antes de publicar

• La imagen LCP es WebP y está por debajo de 200KB.
• La imagen LCP tiene fetchpriority="high", no loading="lazy".
• srcset está presente y el teléfono carga el archivo pequeño.
• Cada imagen tiene ancho y alto explícitos.
• Un CDN almacena en caché /wp-content/uploads/.
• La caché del navegador para imágenes está configurada a un año.
• LCP móvil por debajo de 2.5s en PageSpeed.
• CLS por debajo de 0.1 sin desplazamiento inducido por imágenes.

Una advertencia real: el WebP con pérdida (lossy) con calidad inferior al 70 eventualmente te afectará en la fotografía de productos y pantallas retina donde la textura y el detalle del borde venden el producto. Yo conservo cada original en almacenamiento en la nube y reexporto desde él, porque una vez que sobrescribes la fuente con una copia con pérdida, el detalle se pierde para siempre. Prueba en cinco imágenes reales antes de convertir por lotes mil.

Créditos de imagen

• Espacio de trabajo brillante con un ordenador de escritorio utilizado para gestionar un sitio WordPress — foto por SHVETS Production en Pexels
• Oficina casera acogedora con una laptop abierta en una publicación de blog de WordPress — foto por Pixabay en Pexels
• MacBook mostrando una página de búsqueda de Google en una mesa de madera al aire libre — foto por Pixabay en Pexels
• Programador codificando en una laptop y monitor en una oficina moderna — foto por Claudio Emanuel en Pexels