Un catálogo de cientos de miles de productos puede necesitar muchas más imágenes que referencias. Cada producto puede tener cuatro o cinco fotografías: distintas vistas, detalles, accesorios o usos. Almacenarlas en nuestros servidores, mantenerlas disponibles y entregarlas cuando el comprador las necesita es una responsabilidad operativa, no un detalle secundario de la tienda.
Por eso ShopinCloud cuenta con un servidor CDN especializado en imágenes, apoyado por Cloudflare para su distribución. Su cometido es preparar las variantes necesarias, conservarlas y servirlas sin repetir trabajo innecesario en cada visita. Aquí explicamos ese recorrido y una mejora concreta del encuadre: el recorte de márgenes.
Cientos de miles de productos, hasta millones de imágenes
Tomemos un ejemplo orientativo: 200.000 productos con cuatro o cinco fotografías cada uno representan entre 800.000 y 1.000.000 de imágenes , antes de contar las variantes de tamaño. No es un inventario medido de nuestro servidor, sino una forma de entender la escala del problema.
Una misma fotografía puede necesitar versiones para la categoría, el buscador y la ficha de producto. Además, se solicita una y otra vez desde distintos dispositivos. Gestionar ese volumen exige controlar almacenamiento, lecturas y escrituras en disco, transferencias y trabajos de transformación.
La responsabilidad no termina al guardar el archivo. También hay que vigilar su disponibilidad, detectar fallos, preservar los originales que no puedan recuperarse y evitar que el procesamiento de nuevas imágenes perjudique la entrega de las que ya están preparadas. El servidor CDN concentra este trabajo especializado; Cloudflare ayuda a distribuir los resultados, pero no sustituye el almacenamiento de origen ni las copias de seguridad.
Preparar una imagen y servirla son trabajos diferentes
Preparar una imagen puede implicar contactar con un proveedor, descargar su fotografía, comprobarla, cambiar sus dimensiones y guardar el resultado. Servir una imagen ya preparada consiste en entregar un archivo existente. La diferencia importa cuando muchas personas consultan un catálogo a la vez.
ShopinCloud conserva variantes de las imágenes para distintos tamaños. Una miniatura y una fotografía de ficha pueden partir del mismo original, pero no tienen por qué ser el mismo archivo. La caché permite aprovechar ese trabajo en peticiones posteriores.
Las tres capas que pueden evitar trabajo
- El navegador: puede reutilizar una imagen que ya descargó, según las instrucciones de caché.
- Cloudflare: puede entregar una copia desde su red sin volver a solicitar el archivo al servidor de origen.
- El servidor de imágenes: conserva los archivos generados. Aunque Cloudflare necesite pedirlos, no hace falta transformarlos otra vez.
Estas capas se complementan, pero no son intercambiables. Tener la imagen en el servidor no significa que todos los nodos de Cloudflare ya tengan una copia. Tampoco significa que el navegador del comprador la haya descargado antes.
Qué ocurre cuando se solicita una imagen nueva
Cloudflare como apoyo en España y Sudamérica
Actualmente nos apoyamos en el servicio gratuito de Cloudflare, que incluye funciones CDN , para distribuir imágenes a los visitantes de nuestras tiendas en España y Sudamérica. En nuestra experiencia hasta la fecha, hemos podido mantener este uso sin impedimentos por parte del servicio. Es una descripción de nuestra operativa actual, no una garantía de capacidad ilimitada o de gratuidad futura.
La combinación tiene dos responsabilidades claras: nuestro servidor prepara y almacena las imágenes; Cloudflare ayuda a distribuir copias . Su red puede acercar la entrega al visitante y reducir solicitudes al origen. El almacenamiento, la generación y el mantenimiento de las imágenes siguen siendo responsabilidad nuestra.
Del original a la variante preparada
La tienda indica qué fotografía necesita y con qué dimensiones. Construir esa URL no genera todavía la imagen: el trabajo comienza cuando un navegador u otro cliente la solicita.
El servicio comprueba si la variante está preparada. Si existe, devuelve su dirección de entrega. Si falta y hay capacidad disponible, obtiene el original, aplica la transformación y guarda el resultado. Después indica al cliente dónde solicitarlo.
El servidor no sube cada imagen a Cloudflare mediante una llamada a su API. Guarda el archivo y devuelve una URL. Cuando el navegador sigue esa dirección, Cloudflare entrega una copia disponible o pide el archivo al origen. Una respuesta HIT identifica una entrega desde la caché de Cloudflare, como explica su documentación oficial sobre respuestas de caché .
Hay un matiz importante: si la petición empieza por la URL de transformación, primero debe resolverse esa consulta. Que Cloudflare tenga la imagen final no elimina necesariamente este primer paso.
Por qué no conviene generar todo a la vez
Una avalancha de solicitudes nuevas puede concentrar descargas, uso de memoria y escrituras en disco. Por eso, las vías principales de generación utilizan límites de concurrencia: controlan cuántas transformaciones costosas pueden avanzar simultáneamente.
El servicio dispone también de una cola para la vía de creación mediante POST, procesada por trabajadores fijos. Se busca reutilizar los trabajos pendientes y evitar multiplicar procesos por cada petición. Una imagen ya preparada no necesita ocupar un turno de transformación. Aun así, la consulta inicial puede esperar si los procesos que la atienden están ocupados.
Las dos vías no se comportan igual cuando falta capacidad. El POST puede dejar trabajo pendiente y ofrecer provisionalmente el original; la petición GET de transformación no lo encola y puede redirigir al original. Esa respuesta provisional no certifica que la variante ya esté terminada. La espera depende del trabajo acumulado y de la respuesta del proveedor, no de un plazo universal.
Optimizar las imágenes: tamaño, peso y presentación
La palabra adecuada es optimizar : preparar cada imagen para que tenga unas dimensiones y un peso apropiados, buscando un equilibrio con su calidad visual. El redimensionado adapta el tamaño; la compresión puede reducir los bytes; y el recorte de márgenes mejora el aprovechamiento del encuadre. Son operaciones diferentes.
El objetivo es que las imágenes ocupen lo menos posible manteniendo una calidad visual adecuada. Un archivo más ligero exige descargar menos datos: esto favorece que las fotos aparezcan antes en el navegador del comprador y contribuye a mejorar la velocidad de la web. Se nota especialmente cuando una página reúne muchas fotografías o se consulta desde una conexión móvil. Reducir el peso también ayuda a contener el almacenamiento y el tráfico; la caché evita volver a generar la misma variante en cada visita.
Optimizar no significa inventar detalle que no existe en el original. La compresión con pérdida puede reducir información, por lo que debe aplicarse con criterio. Una fotografía ligera pero borrosa tampoco cumple su función en una ficha de producto.
En el funcionamiento aquí descrito, las variantes se generan cuando hacen falta y se reutilizan después. Los trabajadores de la cola procesan tareas pendientes: no recorren por sí mismos toda la colección para mejorar cada fotografía. Las herramientas de compresión y revisión son tareas de mantenimiento separadas que deben ejecutarse con límites, sin competir indiscriminadamente con las solicitudes de los compradores.
Un ejemplo real: menos margen, más producto
Algunas fotografías tienen muchos píxeles, pero el artículo ocupa una parte pequeña del encuadre. Reducir toda la imagen conserva también ese espacio vacío y deja el producto diminuto.
La opción trim retira márgenes blancos, casi blancos o transparentes uniformes antes de redimensionar. En el ejemplo comprobado, ambas salidas tienen 565 × 565 píxeles . Lo que cambia es cuánto espacio ocupa el teléfono dentro del mismo cuadrado.
Son capturas de los archivos realmente servidos, no una simulación. No se trata de eliminar fondos mediante inteligencia artificial ni de recuperar detalle inexistente. El recorte tiene límites y no sustituye una fotografía bien preparada.
La variante recortada utiliza una URL diferente de la versión sin recorte. Así puede conservarse la anterior sin confundirla con el nuevo resultado. Este principio es esencial: si cambia el contenido, hay que gestionar también su identidad de caché.
Qué medir y qué revisar en tu catálogo
Para evaluar el servicio conviene separar solicitudes recibidas, imágenes reutilizadas y transformaciones terminadas. Los registros del servidor no incluyen todas las entregas resueltas por Cloudflare; y una imagen reutilizada por el navegador puede no generar ninguna nueva solicitud de red. Las peticiones tampoco equivalen a compradores únicos.
- Parte de originales nítidos y comprueba el encuadre en móvil.
- Utiliza tamaños adecuados al lugar donde aparecerá cada imagen.
- Si sustituyes una fotografía manteniendo su dirección, coordina su actualización: las cachés pueden conservar la versión anterior.
- Conserva una copia de los originales irrecuperables. La caché de Cloudflare no sustituye una copia de seguridad.
La finalidad es reducir trabajo repetido y mantener controlada la generación pendiente. No basta una prueba aislada para prometer un tiempo de carga o una mejora de ventas. Es el mismo criterio de medir y delimitar cambios que explicamos al reducir peticiones innecesarias de bots en ShopinCloud .
¿Tu catálogo necesita revisar tamaños, márgenes o actualización de imágenes? Contacta con el equipo de LiveCommerce y cuéntanos qué estás observando. Encontrarás más casos prácticos en nuestro blog de ecommerce .
Basado en el funcionamiento contrastado el 31 de octubre de 2026. Portada: ilustración conceptual generada. Diagramas: recorridos simplificados. Comparativa: capturas reales del CDN. La IA se ha utilizado como apoyo al desarrollo; no participa en cada solicitud de imagen.
