Qué hace una CDN de imágenes
Una CDN guarda copias de tus archivos en servidores cercanos a tus visitantes y los envía desde allí. Para la mayoría de los archivos ese es todo el trabajo: los bytes que salen del edge son los mismos que sirvió tu origen. Una CDN de imágenes añade un paso. Entre su caché y el visitante puede cambiar la propia imagen, y lo hace por cuatro motivos.
Formato. En fotografías, WebP y AVIF suelen pesar mucho menos que el JPEG que subiste: en nuestra medición, una foto de noticia de 262.025 bytes quedó en 113.860 bytes como WebP y en 86.936 como AVIF. La CDN de imágenes convierte cada imagen a un formato que acepta el navegador del visitante, de modo que un navegador que maneja AVIF recibe AVIF y uno más antiguo sigue recibiendo una imagen que puede mostrar.
Tamaño. Un móvil que muestra una foto a 400 píxeles de ancho no necesita la subida de 2.400 píxeles. Con un ancho o un alto en la URL, la CDN de imágenes reduce la imagen a lo que la página muestra de verdad.
Compresión. Aunque el formato no cambie, recodificar con una calidad sensata y descartar datos que la pantalla nunca usa quita bytes a casi cualquier subida: la misma foto de noticia, recodificada como JPEG, pasó de 262.025 a 186.137 bytes.
Caché. Cada resultado se guarda en el edge. La conversión se hace una vez por variante y cada visitante posterior recibe la copia guardada a la velocidad normal de la CDN.
Tus originales se quedan donde están: subes un único archivo de buena calidad y cada variante se produce a partir de él en el camino de entrega. No hay que volver a exportar nada cuando llega un formato nuevo o un diseño cambia de tamaño.
Una URL, varios formatos: Accept y Vary
Cada petición de imagen que hace un navegador lleva una cabecera Accept con los formatos que puede mostrar. Chrome envía image/avif,image/webp,image/apng,image/svg+xml,image/*,*/*;q=0.8; un navegador sin soporte de AVIF no incluye image/avif. La CDN de imágenes lee esa lista en cada petición y responde en la misma URL con AVIF, WebP o el formato original. El nombre del archivo no cambia, así que photo.jpg puede llegar como AVIF: lo que se envió de verdad lo dice la cabecera Content-Type.
Como una URL tiene ahora varias respuestas correctas, la respuesta tiene que indicarlo con Vary: Accept. Esa cabecera avisa a cada caché entre el edge y el visitante, desde un proxy de empresa hasta la caché del propio navegador, de que la respuesta depende de Accept. Sin ella, una caché compartida puede guardar el AVIF que recibió un visitante y entregárselo al siguiente, cuyo navegador no sabe decodificarlo.
La caché de la propia CDN sigue la misma regla, y aquí importa un detalle. Las cadenas Accept cambian entre navegadores y entre versiones de un mismo navegador, así que una caché que usa la cabecera en bruto como clave guarda una copia casi idéntica por cada variante de la cadena. Una CDN de imágenes bien hecha reduce la cabecera a la decisión que contiene (AVIF, WebP o ninguno) y guarda una copia de cada una.
La alternativa es decidir en el HTML: un elemento <picture> enumera un <source> AVIF y otro WebP, y el navegador toma el primer tipo que admite. No necesita negociación, pero cada variante la produces, la almacenas y la referencias tú. Con una CDN de imágenes el marcado sigue siendo un <img> normal; <picture> queda como herramienta de dirección de arte, para cuando un móvil debe recibir otro encuadre y no una copia más pequeña de la misma imagen.
Redimensionar desde la URL
La negociación de formato no exige cambiar tus páginas; el redimensionado sí, porque solo la página sabe a qué ancho se mostrará una imagen. Las CDN de imágenes toman el tamaño de la URL, normalmente como parámetros de consulta: photo.jpg?w=640 pide una copia de 640 píxeles de ancho. Un servicio sensato mantiene la proporción cuando das una sola dimensión, encaja la imagen dentro del recuadro cuando das las dos y nunca amplía una imagen por encima de su tamaño original.
Junto con srcset y sizes, un solo archivo de origen sirve para todas las pantallas. Enumeras varios anchos de la misma URL e indicas a qué ancho se muestra la imagen, y el navegador descarga la copia más pequeña que sigue viéndose nítida con la densidad de pantalla del visitante. La CDN de imágenes produce cada ancho de la lista la primera vez que alguien lo pide y desde entonces lo sirve de la caché.
Mantén la lista corta y fija. Cada ancho distinto es una conversión aparte y un objeto de caché aparte, así que cinco anchos usados en todo el sitio aprovechan la caché mucho mejor que lo que cada plantilla calcule por su cuenta. Algunos servicios aceptan más parámetros, como recorte, calidad o punto focal, y cada uno multiplica las variantes de la misma manera.
Una imagen de origen, cinco anchos: el navegador elige el que necesita
<img
src="https://example.com/media/photo.jpg?w=960"
srcset="https://example.com/media/photo.jpg?w=320 320w,
https://example.com/media/photo.jpg?w=640 640w,
https://example.com/media/photo.jpg?w=960 960w,
https://example.com/media/photo.jpg?w=1280 1280w,
https://example.com/media/photo.jpg?w=1920 1920w"
sizes="(max-width: 720px) 100vw, 720px"
width="1920" height="1080" alt="">Cada variante es un objeto de caché propio
Una CDN de imágenes convierte un archivo en una familia. Una foto pedida en tres formatos y cinco anchos son quince objetos en la caché, cada uno con su propia clave. De ahí salen tres consecuencias.
La clave de caché debe incluir el tamaño. Si una regla ignora la cadena de consulta para subir la tasa de aciertos, ?w=320 y ?w=1920 comparten clave, y el tamaño que se pidió primero se envía a todo el mundo. Mantén los parámetros de tamaño en la clave aunque descartes otros.
La primera petición paga la conversión. Una variante que nadie ha pedido todavía se produce al vuelo: el edge trae el original, lo codifica y guarda el resultado en caché. Ese visitante espera un poco más; todos los que vienen después reciben la copia de la caché. Para páginas que deben ser rápidas desde la primera visita, unas cuantas peticiones después de un despliegue o de una purga calientan la caché por adelantado.
La purga y la caducidad afectan a toda la familia. Cuando un original cambia con el mismo nombre, todos los formatos y tamaños hechos a partir de él tienen que desaparecer. Una purga por prefijo de ruta los alcanza a todos; la purga de una única URL exacta puede dejar atrás las copias redimensionadas. Activar la conversión es el caso fácil: cuando el formato forma parte de la clave de caché, cada copia convertida es un objeto nuevo y sale desde la primera petición. Solo las copias que ya tienen los navegadores de los visitantes se quedan como estaban hasta que caducan allí.
Calidad y tamaño: cuándo pierde una conversión
Todo formato con pérdida cambia bytes por detalle mediante un ajuste de calidad, y las CDN de imágenes eligen un valor por defecto que parece intacto al tamaño de visualización normal. Si lo bajas, las fotos se ablandan y aparecen bloques; si lo subes, el ahorro se reduce. El texto, los bordes nítidos y los colores planos son los primeros en mostrar el daño, y por eso las capturas de pantalla y los logotipos necesitan un trato más suave que las fotografías.
El formato pesa tanto como el ajuste, y el ganador cambia con la imagen. El 5 de octubre de 2026 pasamos tres imágenes por el optimizador de imágenes de CDN.com.tr con su configuración de producción y contamos los bytes.
Foto de noticia, JPEG. Original 262.025 bytes; WebP 113.860; AVIF 86.936. El caso de manual: AVIF lleva la misma imagen en aproximadamente un tercio de los bytes del original.
Captura del panel, PNG. Original 105.078 bytes; PNG optimizado 40.379; WebP 41.218; AVIF 27.942. Un PNG con paleta es muy bueno con colores planos y texto, y aquí el WebP salió más grande que él; AVIF ganó igualmente.
Favicon, PNG, 16×16. Original 701 bytes; PNG optimizado 483; WebP 314; AVIF 682. A este tamaño la sobrecarga fija del contenedor AVIF pesa más que su mejor compresión, y WebP gana con claridad.
Ningún formato gana en todas partes, y una conversión puede producir un archivo más pesado que la mejor versión del original. Una buena CDN de imágenes codifica, compara los bytes y envía el archivo más pequeño; una que convierte a ciegas hace más pesadas parte de tus imágenes y aun así las da por optimizadas. Nuestra guía AVIF vs WebP tiene todas las mediciones y sus motivos.
¿CDN de imágenes u optimización en el build?
Puedes conseguir los mismos formatos sin una CDN de imágenes. Un paso de build, un hook de subida o un plugin pueden convertir cada imagen una vez, escribir las variantes junto a los originales y dejar que una CDN normal las entregue con marcado <picture>. Qué camino es mejor depende de dónde vienen tus imágenes.
La optimización en el build gana en un sitio cuyas imágenes viven en el repositorio: una web corporativa, documentación, una app estática. El conjunto se conoce de antemano, cada archivo se puede ajustar a mano, no se procesa nada mientras espera un visitante y lo que sale es exactamente lo que probaste.
Una CDN de imágenes gana cuando las imágenes llegan más rápido de lo que nadie puede procesarlas: fotos de producto subidas desde el panel de una tienda, el archivo de un periódico, una biblioteca de medios de WordPress con años de subidas, imágenes que publican tus usuarios. También gana cuando el número de tamaños crece con cada diseño nuevo, cuando el marcado lo escribe un tema o un CMS alojado, y cuando prefieres no ejecutar un conversor en tu propio servidor.
Los dos se combinan bien: gráficos de cabecera ajustados a mano desde el build, y todo lo que se sube al CMS desde la CDN de imágenes. Los logotipos e iconos dibujados, no fotografiados, conviene mantenerlos en SVG en cualquier caso: no hay nada que convertir y se ven nítidos a cualquier tamaño.
Fallos que conviene revisar antes de activarla
La mayoría de los problemas con las CDN de imágenes vienen de unos pocos sitios, y cada uno se puede comprobar antes de que lo note un visitante.
Falta Vary. Una respuesta que cambia con Accept pero no lleva Vary: Accept es el fallo de esta lista que puede mostrar a un visitante una imagen rota. Comprueba qué envía tu CDN y qué deja pasar cualquier proxy que tenga delante.
Parámetros de tamaño fuera de la clave de caché. Un solo tamaño para todos: pide dos anchos de la misma imagen y compara lo que vuelve.
Parámetros sin límite. Si se acepta cualquier ancho, cualquiera puede pedir miles de tamaños y hacerte pagar cada conversión. Una lista fija de anchos en tus plantillas limita tus propias páginas a unas pocas variantes; las peticiones de fuera solo las frena un límite del lado del servicio, como una lista de anchos permitidos o un límite de peticiones.
Resultados más pesados. Mide tu propia mezcla de imágenes. Si el servicio no compara bytes, los gráficos planos y los iconos son donde más se nota.
Formatos que pasan sin cambios. Los GIF animados, los SVG y las imágenes que ya son WebP suelen salir tal cual; comprueba qué formatos convierte tu servicio.
Coste de procesamiento y cuotas. Codificar, sobre todo en AVIF, consume mucha más CPU que enviar un archivo de la caché, y los servicios lo miden: por transformación, por byte procesado o contra la cuota de un plan. Lee cómo cuenta el tuyo antes de activarlo para todas las imágenes a la vez.
Copias antiguas. Las imágenes que los navegadores cargaron antes del cambio se quedan en su caché hasta que caducan, y ninguna purga de la CDN llega hasta ellas. Juzga el resultado con una petición nueva, como la del comprobador de abajo, y no con una recarga.
Comprueba qué sirve tu sitio
El comprobador de abajo muestra lo que hace una CDN de imágenes, o su ausencia, en una página real. Lee el HTML de la página, toma hasta 20 imágenes de <img>, srcset, <picture> y og:image, y pide cada una dos veces: una como la pide un navegador actual (Accept: image/avif,image/webp,…) y otra como un cliente que acepta cualquier cosa (Accept: */*). Lee los primeros bytes de cada respuesta para saber el formato real, diga lo que diga el nombre del archivo, cuenta los bytes e informa de Vary y del estado de la caché. También puedes introducir la dirección de una sola imagen.
Si las dos peticiones reciben el formato original en todas las imágenes, nada en el camino convierte tus imágenes. Si la petición moderna recibe AVIF o WebP pero la respuesta no lleva Vary: Accept, corrige eso primero. La página propia del comprobador explica cada resultado y sus límites.
Optimización de imágenes en CDN.com.tr
La optimización de imágenes es un interruptor para toda tu cuenta o para una sola regla de entrega. El edge convierte las imágenes JPEG y PNG a WebP, o a AVIF y WebP si eliges WebP + AVIF para la cuenta, y cada navegador recibe un formato que acepta; los navegadores que no aceptan ninguno de los dos reciben la imagen en su formato original. Con WebP + AVIF la respuesta sale de la misma URL, con Vary: Accept; con solo WebP, los navegadores que aceptan WebP se redirigen a una copia .webp. En ambos casos tu HTML conserva las mismas URL de imagen. A tamaño completo, una imagen recién convertida solo se envía si es más pequeña que el original. Si una conversión falla, el edge sirve en su lugar la imagen original. El procesamiento cuenta para tu cuota mensual.
Las mediciones de arriba salen de ese optimizador. Con WebP + AVIF, la foto de noticia de 262.025 bytes sale como 86.936 bytes de AVIF y la captura del panel de 105.078 bytes como 27.942. Las imágenes PNG pequeñas o de colores planos de hasta un megapíxel (iconos, capturas, ilustraciones) también tienen que superar a nuestro propio PNG optimizado, así que un navegador que acepta WebP pero no AVIF recibe esa captura como el PNG de 40.379 bytes, y el favicon sale como el WebP de 314 bytes y no como el AVIF de 682.
El redimensionado funciona desde la URL: añade ?w=, ?h= o ambos a la dirección de una imagen. Un solo valor mantiene la proporción, los dos encajan la imagen dentro de ese recuadro y una imagen nunca se amplía por encima de su tamaño original. Las imágenes redimensionadas también se convierten, pero no se comparan con el original. Una regla mantiene w y h en su clave de caché mientras conserve la cadena de consulta, que es lo predeterminado; una regla que ignora todos los parámetros de consulta guarda en caché un solo tamaño para todos.
Las copias que el edge convirtió antes de que llegara la comparación a tamaño completo se quedan como estaban hasta que caducan o se purgan, y los navegadores que ya cargaron una imagen conservan su copia hasta que caduca en el navegador. Con solo WebP, la redirección a la copia .webp no lleva Vary: Accept, y eso es lo que señala el comprobador de arriba; WebP + AVIF responde a todos los navegadores desde la misma URL con Vary: Accept. AVIF cuenta para la cuota a una tasa mayor que WebP porque codificarlo requiere más procesamiento; el panel muestra la tasa actual debajo del interruptor. El tema de ayuda sobre optimización de imágenes recorre los interruptores, la elección de formato y la purga.
WordPress. En un sitio WordPress detrás de CDN.com.tr la conversión la hace el edge: las imágenes de tu biblioteca de medios se convierten al pasar por la CDN, así que tu servidor no gasta CPU en codificar, no se escriben archivos WebP o AVIF adicionales en la biblioteca y los temas y maquetadores siguen funcionando porque las URL de las imágenes no cambian. Si un sitio no está en nuestra CDN, el plugin gratuito CDNTR puede convertir las imágenes a WebP, y a AVIF donde el servidor lo admita, en el propio servidor del sitio. Usa uno u otro: con la conversión en el edge activada, deja desactivada la conversión local del plugin para que el edge trabaje a partir de tus originales.
Preguntas frecuentes
¿Qué diferencia hay entre una CDN y una CDN de imágenes?
Una CDN guarda copias de tus archivos cerca de tus visitantes y las envía sin cambios. Una CDN de imágenes también lo hace, y además cambia las imágenes por el camino: las convierte a un formato que acepta cada navegador, las redimensiona cuando la URL pide un tamaño y guarda en caché cada resultado. Muchas CDN ofrecen la optimización de imágenes como un interruptor, así que a menudo son la misma red con una función activada.
¿Una CDN de imágenes modifica mis archivos originales?
No. Los originales se quedan en tu servidor o almacenamiento tal como los subiste; las copias convertidas y redimensionadas se producen en el camino de entrega y viven en la caché de la CDN. Cuando las imágenes convertidas salen con las URL originales, al desactivar la conversión los visitantes vuelven a recibir los originales a medida que las copias de la caché caducan o se purgan.
¿Sigo necesitando el elemento <picture>?
Para los formatos, no. Con una CDN de imágenes que negocia, un <img> normal recibe AVIF, WebP o el original según el navegador, así que puedes quitar las líneas <source type="image/avif">. Conserva <picture> para la dirección de arte, cuando una pantalla pequeña debe recibir otro encuadre y no una copia más pequeña de la misma imagen.
¿Puede una imagen convertida salir más pesada?
Sí, más pesada que la mejor versión del original, si el servicio convierte sin comparar. En nuestra medición, un favicon de 16×16 ocupó 682 bytes como AVIF frente a 483 como PNG optimizado y 314 como WebP, y una captura del panel salió más grande como WebP (41.218 bytes) que como PNG optimizado (40.379). Un buen servicio comprueba los bytes y envía el archivo más pequeño. En CDN.com.tr, una imagen a tamaño completo recién convertida solo sale si es más pequeña que el original, y un PNG pequeño o de colores planos de hasta un megapíxel solo si además supera a nuestro PNG optimizado.
¿Merece la pena una CDN de imágenes para WordPress?
Normalmente sí, porque los sitios WordPress son donde las imágenes se acumulan más rápido de lo que nadie las optimiza. La conversión en el edge llega a las imágenes JPEG y PNG de toda la biblioteca de medios, subidas antiguas incluidas, sin un conversor en tu servidor ni archivos adicionales en wp-content/uploads. Para un sitio que no está en una CDN, la alternativa es un plugin que convierta en local, como CDNTR.
¿Cómo se factura el procesamiento de imágenes en CDN.com.tr?
Cuenta para la cuota mensual de la cuenta, igual que el tráfico; no hay un paquete aparte que comprar. AVIF cuenta a una tasa mayor que WebP porque codificarlo requiere más procesamiento, y el panel muestra la tasa actual debajo del interruptor.