La conclusión clave: un CDN y la optimización local de imágenes resuelven problemas distintos — un CDN acorta la distancia de red que recorre un archivo, mientras que la optimización local reduce el archivo en sí. Los sitios con mucho tráfico internacional y bibliotecas de medios grandes suelen beneficiarse de ambos; los sitios con visitantes mayormente locales a menudo ganan más corrigiendo primero el formato y el tamaño.
Dos cuellos de botella distintos, a menudo confundidos como uno solo
"Mis imágenes van lentas" puede significar dos cosas distintas, y la solución difiere según cuál sea la que realmente aplica:
- El archivo es demasiado grande. Un JPEG de 2MB es un JPEG de 2MB sin importar cuán cerca esté el servidor. Esto es un problema de formato y compresión.
- El archivo tiene que viajar demasiado lejos. Incluso un archivo WebP de 80KB perfectamente optimizado tarda más en llegar a un visitante en Sídney si tu único servidor está en Ámsterdam. Esto es un problema de latencia de red.
Un CDN (red de distribución de contenido) resuelve el segundo problema cacheando copias de tus archivos en servidores distribuidos globalmente, para que un visitante descargue desde el más cercano en lugar de tu servidor de origen. No hace nada respecto al primer problema — un CDN cachea y sirve un archivo sin optimizar de 2MB tan rápido como lo haría con uno pequeño, desde el punto de vista de la red.
Qué hace realmente la optimización local
"Optimización local" aquí significa procesar imágenes en tu propio servidor WordPress: convertir a formatos modernos (WebP, AVIF), comprimir sin pérdida de calidad visible, redimensionar para que coincida con las dimensiones reales de visualización, y generar las variantes srcset responsivas entre las que los navegadores pueden elegir.
Este es un coste único por imagen. Una vez que una imagen se convierte y dimensiona correctamente, ese trabajo no necesita repetirse en cada solicitud — el archivo más pequeño es simplemente lo que se sirve desde entonces, ya sea desde tu propio servidor o detrás de un CDN.
Erdo Image Optimizer hace exactamente esto: usa la propia librería GD o Imagick de tu servidor para convertir y comprimir imágenes, sin API externa ni tarifa por imagen. Para los detalles técnicos, consulta nuestra guía de conversión de imágenes de WordPress a WebP.
Dónde gana realmente cada opción
| Factor | Optimización local | CDN |
|---|---|---|
| Reduce el tamaño del archivo | Sí — es su función principal | No — sirve lo que se le entregue |
| Reduce la distancia de red | No | Sí — es su función principal |
| Coste único o recurrente | Mayormente procesamiento único | Normalmente recurrente, escala con el ancho de banda |
| Ayuda a una audiencia de una sola región | Sí, directamente | Limitado — poca distancia que acortar |
| Ayuda a una audiencia global | Indirectamente (los archivos más pequeños se transfieren más rápido en todas partes) | Sí, directamente |
| Complejidad de configuración | Instalar plugin + conversión masiva | Configuración DNS/origen, reglas de invalidación de caché |
Una comparación concreta
Considera una imagen hero JPEG sin optimizar de 1,8MB, solicitada por un visitante a 9.000km del servidor de origen:
| Escenario | Tamaño del archivo | Tiempo total de carga aprox.* |
|---|---|---|
| JPEG sin optimizar, sin CDN | 1,8 MB | ~2,9s |
| JPEG sin optimizar, tras un CDN | 1,8 MB | ~2,1s |
| WebP optimizado (~350KB), sin CDN | 350 KB | ~1,3s |
| WebP optimizado (~350KB), tras un CDN | 350 KB | ~0,6s |
*Cifras aproximadas e ilustrativas basadas en supuestos típicos de latencia y ancho de banda para una solicitud de larga distancia — las cifras reales varían según el proveedor de hosting, la conexión y el proveedor de CDN.
El patrón que importa: la optimización de formato por sí sola (fila 3) supera a añadir un CDN a un archivo sin optimizar (fila 2). Ambos combinados (fila 4) superan a cualquiera de los dos por separado con un margen amplio. Si solo puedes hacer una cosa primero, corregir el tamaño del archivo te lleva más lejos que corregir la distancia.
Cuándo merece la pena añadir un CDN
- Tu tráfico es genuinamente internacional, no solo local con visitas extranjeras ocasionales.
- Tu biblioteca de medios es lo bastante grande como para que el ancho de banda o la CPU del servidor de origen se conviertan en un cuello de botella bajo carga.
- Ya sirves formatos y tamaños optimizados, y quieres el siguiente incremento de velocidad.
- Gestionas WooCommerce u otra configuración de alto tráfico donde la carga del servidor de origen durante picos de tráfico es un riesgo real.
Cuándo no es la prioridad
- Tu audiencia está concentrada en un país o región cercana a tu hosting.
- Aún no has convertido tus imágenes a formatos modernos — esto es casi siempre la corrección de mayor impacto que conviene hacer primero.
- Tu hosting actual ya incluye un CDN básico o una capa de caché (común en hostings WordPress gestionados como Kinsta o WP Engine) — comprueba esto antes de pagar por un segundo.
Cómo comprobar qué necesita realmente tu sitio
En lugar de adivinar, ejecuta un diagnóstico rápido:
- Abre PageSpeed Insights y revisa la sección "Diagnóstico" en busca de imágenes marcadas — si señala problemas de formato o tamaño, es un problema de optimización local, no de distancia.
- Usa una herramienta como WebPageTest con una ubicación de prueba lejana a tu servidor (por ejemplo, probando desde Singapur si tu hosting está en Europa). Compara el "Time to First Byte" y el tiempo de conexión con una prueba ejecutada desde una ubicación cercana a tu servidor. Una gran diferencia entre ambos apunta a la latencia, no al tamaño del archivo, como el factor mayor.
- Revisa la documentación de tu plan de hosting — muchos hostings WordPress gestionados (Kinsta, WP Engine, Cloudways) incluyen un CDN o una capa de caché edge por defecto. Pagar por un segundo CDN encima de uno que ya tienes rara vez ayuda.
Algunas trampas de los CDN que conviene conocer
Un CDN no es una ventaja pura una vez añadido — surgen algunos problemas prácticos en configuraciones reales de WordPress:
- Invalidación de caché — reemplazar una imagen en la biblioteca de medios no siempre actualiza de inmediato la copia cacheada del CDN. La mayoría de las integraciones lo gestionan automáticamente, pero merece la pena confirmarlo, especialmente para contenido sensible al tiempo como gráficos de precios.
- Sobrecarga extra de DNS/conexión en sitios pequeños — para una página con solo 2-3 imágenes, la sobrecarga de una nueva resolución DNS y un handshake TLS a un dominio de CDN puede a veces contrarrestar la ganancia de latencia, sobre todo para visitantes ya cercanos al servidor de origen.
- Configuración de CORS — si el CDN sirve recursos desde un subdominio distinto, las fuentes y algunas imágenes cargadas por JavaScript pueden tener errores de CORS a menos que las cabeceras estén configuradas correctamente.
Nada de esto es razón para evitar un CDN por completo — son detalles de configuración que merece la pena revisar en lugar de asumir que un CDN es una ganancia estrictamente gratuita.
Usar ambos juntos
Para los sitios que realmente necesitan ambos, el orden importa: optimizar primero, luego cachear. Erdo Image Optimizer incluye integración opcional con BunnyCDN exactamente por este motivo — las imágenes se convierten a WebP/AVIF y se dimensionan correctamente en local, y luego son esos archivos ya optimizados los que se envían y sirven desde el edge del CDN, en lugar de cachear las subidas originales sobredimensionadas.
Para terminar
Tratar "CDN" y "optimización de imágenes" como soluciones intercambiables para el mismo problema es un error común — abordan capas diferentes del mismo tiempo de carga total. Si las imágenes de tu sitio siguen siendo JPEG y PNG sin procesar, convertirlas y redimensionarlas normalmente marcará más diferencia que añadir un CDN delante de ellas. Si ya has resuelto formato y tamaño y tu tráfico es genuinamente global, un CDN es el siguiente paso lógico. Para la mayoría de los sitios WordPress, el orden correcto es: optimizar primero, y luego decidir si la latencia restante justifica el coste continuo de un CDN.