Transforma Cloudinary: probá y medí tus transformaciones

En pocas palabras: Transforma es un workbench para desarrolladores, publicado el 14 de octubre de 2026 en DEV Community, que usa Next.js y el SDK de Node.js de Cloudinary para armar transformaciones de imágenes, compararlas con el original, medir bytes y tiempos de descarga, y exportar la URL o el código.

Transforma Cloudinary, el workbench que un desarrollador publicó el 14/10/2026 en DEV Community, sirve para armar, comparar y medir transformaciones de imágenes desde el navegador. Usa Next.js, TypeScript, Tailwind CSS y el SDK oficial de Node.js de Cloudinary, según la nota original del autor.

Transforma es una herramienta para desarrolladores que se apoya en Cloudinary para subir una imagen, configurar parámetros de transformación (ancho, modo de recorte, formato y calidad), comparar el resultado contra el original y medir qué cambia en la entrega. Al final exporta la URL o el código para pegar en una aplicación. Es un proyecto de la comunidad, no un lanzamiento de Cloudinary ni de Vercel.

¿Qué problema resuelve Transforma Cloudinary?

Transforma apunta a cuatro problemas que el autor detecta en apps con muchas imágenes: archivos sobredimensionados, transformaciones difíciles de manejar a mano, trade-offs entre peso y calidad, y falta de medición para comparar estrategias. Con la herramienta probás configuraciones en una interfaz en vez de editar URLs una por una, y exportás la que te sirve.

Ponele que tenés una plataforma con fotos de espacios de trabajo, avatares y publicaciones de usuarios. Una tarjeta de perfil no necesita lo mismo que un banner de escritorio a pantalla completa.

Eso sí: es un proyecto personal. Nadie de Cloudinary ni de Vercel lo respalda, así que tomalo como una buena forma de explorar y no como referencia oficial. El autor lo resume en el lema “Transform. Optimize. Measure.”. En desplegar una app React con Vite profundizamos sobre esto.

¿Qué parámetros de transformación permite probar Transforma?

Con Transforma probás cinco anchos preestablecidos (320, 640, 800, 1200 y 1920 px), cuatro modos de recorte, formato y calidad automáticos, y tres opciones avanzadas: dpr_auto para densidad de píxeles, g_auto para recorte según el sujeto (donde esté soportado) y fl_strip_profile para sacar metadatos de perfil. Para comparar tiene un slider antes/después y una vista lado a lado.

Modo	Qué hace (según la fuente)	Cuándo lo usaría (criterio propio)
c_fit	Ajusta la imagen dentro de las dimensiones pedidas	Cuando no podés perder nada de la escena
c_fill	Llena las dimensiones, recortando si hace falta	Avatares cuadrados y tarjetas de tamaño fijo
c_crop	Extrae una región de la imagen original	Cuando ya sabés qué zona querés (no es para achicar)
c_scale	Escala a las dimensiones pedidas	Achicar por optimización; si pasás ancho y alto juntos, revisá que no se deforme

La documentación de optimización de Cloudinary (actualizada el 7 de octubre de 2026) recomienda agregar q_auto y f_auto a cada URL de entrega, y usar c_scale si solo querés redimensionar. Con f_auto, cada navegador recibe el formato óptimo para él, por ejemplo AVIF o WebP en vez del JPG original. Ese ejemplo de la doc baja un JPG de 0,68 MB a unos 0,16 MB, alrededor de 75% menos.

Un detalle que conviene mirar: el ejemplo de la nota escribe f_auto,q_auto,w_800 con comas, y la doc de Cloudinary aclara que q_auto y f_auto van como componentes separados, con barra. Revisá qué URL te exporta la herramienta antes de pegarla. Un ejemplo hipotético para un contenedor de 800 px:

https://res.cloudinary.com/<tu_cloud>/image/upload/w_800,c_scale/q_auto/f_auto/<public_id>

¿Cómo mide Transforma el rendimiento real de entrega de las imágenes?

Transforma hace requests reales a los endpoints de entrega de Cloudinary para cuatro escenarios (la imagen original, una optimizada automáticamente, una redimensionada con optimización y una variante de mayor calidad) y mide bytes descargados, dimensiones, formato entregado, duración del request y ahorro de bytes contra la línea base. El tiempo sale de performance.now(). Cubrimos ese tema en detalle en publicar tu web gratis en Vercel.

El flujo que describe la nota:

1. Generar las URLs de los escenarios elegidos.
2. Pedir las imágenes a la CDN de Cloudinary.
3. Medir el tiempo con performance.now().
4. Leer metadatos de la respuesta o el tamaño del Blob.
5. Inspeccionar dimensiones y formato cuando se pueda.
6. Armar el reporte comparativo.

La fórmula de ahorro es (tamaño original − tamaño transformado) / tamaño original × 100. Aplicada a las cifras redondeadas de la doc de Cloudinary (0,68 MB y 0,16 MB), da cerca de 76%, coherente con el “alrededor de 75%” que publica la documentación. Ojo: es un ejemplo de Cloudinary, no una medición de Transforma.

¿Qué límites tiene un benchmark de imágenes hecho en el navegador?

Un benchmark desde el navegador sirve para comparar configuraciones entre sí, pero no para afirmar cuánto va a tardar tu página. El propio autor lo reconoce: las restricciones cross-origin pueden impedir leer ciertos headers, las respuestas en caché se comportan distinto, y un parámetro de query único no garantiza un edge cache frío. Además, la duración de un request no equivale al rendimiento de la página completa.

¿La nota publica cifras de ahorro de Transforma? No. Acá no inventamos ninguna.

Lo que sí podés hacer, sabiendo todo esto, es usar los resultados como una señal para decidir qué variante probar en serio. Lo que no podés es citar un porcentaje de una sola corrida como si fuera un dato de producción (a mí esa es la parte que más me preocupa de cualquier “benchmark” casero).

Una propuesta editorial para verificar, que no viene de la fuente ni la probamos nosotros: Sobre eso hablamos en comparamos Vercel con AWS Amplify.

• Documentá las condiciones: navegador, red, hora y si la carga es la primera o la segunda.
• Repetí las corridas y mirá la dispersión, no un solo número.
• Cruzá los bytes que reporta la herramienta con la pestaña Network de DevTools.
• Confirmá a ojo con el slider que la variante liviana no muestre artefactos visibles.
• Probá con tus imágenes reales, porque el resultado depende de la imagen de origen, del navegador y de la entrega, como aclara la nota.

¿Cómo se suben imágenes a Cloudinary sin exponer el API secret?

Firmás la subida en el servidor y subís directo desde el navegador con esa firma. En Transforma, el navegador pide autorización a POST /api/sign-upload (un Route Handler de Next.js), el servidor firma los parámetros permitidos con cloudinary.utils.api_sign_request usando process.env.CLOUDINARY_API_SECRET, y el navegador recibe la firma y la configuración pública, nunca el secret.

Según la documentación de firmas de Cloudinary (última actualización: 14 de junio de 2026), el api_secret no debe generarse ni vivir del lado del cliente, y la firma vale una hora desde el timestamp. Los métodos del SDK usan SHA-1 por defecto, y podés pasar a SHA-256 con el parámetro signature_algorithm. El ejemplo de la nota firma folder: "transforma-pipeline" y el timestamp.

Dos reglas de la doc que suelen morder: los campos que mandás en el POST tienen que ser idénticos a los que firmaste (excepto file, cloud_name, resource_type y api_key), y si cambiás el payload tenés que regenerar la firma. Para llamadas server-side a la Upload API, la doc aclara que Basic Authentication es más simple porque no exige calcular firmas.

La firma no alcanza. La nota insiste en validar en el servidor los parámetros de subida y restringir tipos y tamaños de archivo, porque la validación en el cliente sola no sirve.

Qué puede reutilizar un equipo: las URLs y los snippets que exporta la herramienta, como punto de partida. Qué debe validar por su cuenta: que la URL siga la convención de la doc, los límites de tipo y tamaño, y las mediciones con sus propias imágenes. Ya lo cubrimos antes en otras alternativas a Vercel para hospedar.

Qué está confirmado y qué no

• Confirmado por la nota (14/10/2026): el stack, los presets de ancho, los cuatro modos de recorte, las opciones avanzadas, los dos modos de comparación visual, los cuatro escenarios de benchmark, las cinco métricas y la ruta POST /api/sign-upload.
• Confirmado por Cloudinary: la recomendación de usar q_auto y f_auto, la regla de no usar f_auto en transformaciones entrantes ni nombradas, y la validez de una hora de la firma.
• Sin confirmar: cuánto ahorra Transforma en casos reales (no hay cifras publicadas), la precisión de sus mediciones entre navegadores y si hay demo o repositorio público (la copia de la nota que tuvimos a mano se corta en la sección del transformation builder).

Errores comunes al optimizar imágenes con Cloudinary

• Meter f_auto en una transformación entrante o nombrada. La doc de Cloudinary lo desaconseja porque el formato se resuelve por request en la CDN. Dejá el resto en la nombrada y encadená f_auto después, por ejemplo t_square/f_auto.
• Usar c_crop para achicar. Extrae una región, no escala. Si solo querés bajar el tamaño, c_scale.
• Dar por cierto un ahorro medido una sola vez. Con caché de por medio, un número aislado no dice nada. Repetí y anotá las condiciones.
• Firmar menos campos de los que enviás. La firma no coincide y la subida falla. Firmá exactamente lo que mandás y regenerala si cambia el payload.
• Confiar en la validación del navegador para los archivos. Se saltea con facilidad. Validá tipo y tamaño en el servidor.

Preguntas Frecuentes

¿Qué es Transforma y para qué sirve con Cloudinary?

Transforma es un workbench de código abierto o no (la nota no lo aclara) hecho con Next.js para construir, comparar y medir transformaciones de imágenes de Cloudinary. Sirve para probar anchos, recortes, formato y calidad, y exportar la URL o el código resultante.

¿Cómo se mide cuánto ahorra f_auto,q_auto en una imagen?

Se compara el peso descargado de la imagen original contra el de la transformada con la fórmula (original − transformada) / original × 100. Cloudinary muestra en su documentación un JPG de 0,68 MB que baja a unos 0,16 MB, pero el ahorro real depende de tu imagen y del navegador.

¿Cómo subir imágenes a Cloudinary sin exponer el API secret?

Generá la firma en tu servidor con el SDK (api_sign_request) y mandá al navegador solo la firma y la configuración pública. La firma vale una hora, y tenés que validar tipos y tamaños de archivo también del lado servidor.

¿Qué diferencia hay entre c_fit, c_fill, c_crop y c_scale?

c_fit ajusta la imagen dentro de las dimensiones pedidas, c_fill las llena recortando si hace falta, c_crop extrae una región del original y c_scale escala a las dimensiones indicadas. Para solo redimensionar con fines de optimización, la doc de Cloudinary sugiere c_scale.

¿Se puede confiar en un benchmark de imágenes hecho desde el navegador?

Sirve para comparar configuraciones entre sí, no para predecir el rendimiento de tu página. La caché, las restricciones cross-origin y el hecho de que un query único no garantiza un edge cache frío limitan las conclusiones, así que repetí las corridas y documentá las condiciones.

Conclusión

Transforma no trae cifras ni promete mejoras, y eso me parece lo más honesto del proyecto: junta en una pantalla lo que muchos equipos hacen a ojo con URLs sueltas. Si tenés una app con muchas imágenes, usalo (o armá algo parecido) para probar anchos y recortes con tus propias fotos, exportá la URL siguiendo la convención de la doc de Cloudinary y verificá el ahorro con corridas repetidas y DevTools antes de darlo por bueno. Y si vas a subir archivos desde el navegador, firmá en el servidor y validá ahí también.

Fuentes

• Cloudinary – documentación oficial de optimización de imágenes (q_auto, f_auto, resize)
• Cloudinary – documentación oficial de firmas de autenticación
• DEV Community – Building Transforma: A Cloudinary Image Transformation and Benchmarking Playground