Límites de tamaño de subida de imágenes y archivos para mantener tu app rápida

Por qué las reglas de subida importan antes de que tu app crezca

Al principio las subidas son fáciles de ignorar. Unas pocas fotos y PDFs funcionan bien, las páginas se sienten ágiles y nadie se queja. Luego llegan usuarios reales y contenido real, y cada pantalla empieza a sentirse más pesada de lo que debería.

Las subidas no solo ocupan espacio. Definen qué tan rápida se siente tu app cada día. Si no fijas límites claros desde el inicio, acabarás arreglando el rendimiento bajo presión.

Velocidad de subida no es lo mismo que velocidad de carga

La velocidad de subida es cuánto tarda un usuario en enviar un archivo al servidor. La velocidad de carga es cuánto tardan los demás en ver ese archivo después.

Alguien puede esperar 3 segundos para subir una foto de 12 MB y pensar “Perfecto.” Pero ahora cada página de perfil, listado y feed que muestra esa foto tiene que descargarla también. Esa sensación de lentitud se propaga por toda la app, incluso para usuarios que nunca suben nada.

Un ejemplo simple: un marketplace lanza con 30 vendedores. Todos suben fotos con el teléfono. La app aún se siente bien. Un mes después hay 1.000 anuncios y la página principal carga docenas de imágenes demasiado grandes. Nada “rompió”, pero la app se siente lenta.

Los costes ocultos se acumulan en silencio

Las subidas grandes y no planificadas crean costes que son difíciles de notar hasta que alcanzas un límite o recibes la factura:

• El almacenamiento crece más rápido de lo esperado, incluso para apps pequeñas.
• Las copias de seguridad tardan más y cuestan más.
• Los almacenes de metadata se inflan si guardas demasiado por archivo.
• Los costes de CDN y ancho de banda suben porque los usuarios vuelven a descargar archivos grandes.
• El tiempo de soporte aumenta cuando las subidas fallan en redes móviles.

El objetivo es simple: decide tus reglas una vez y haz que se apliquen en todas partes. Eso significa los mismos límites en la interfaz, en la API, en trabajos en segundo plano y en cualquier herramienta de administración.

Si heredaste una app generada por IA en la que las subidas se añadieron rápido y de forma inconsistente, esto es una limpieza común. Poner reglas coherentes primero hace que todas las demás mejoras de rendimiento sean más fáciles y previsibles.

Qué cuentan como reglas de imagen y archivo (en lenguaje llano)

Cuando la gente dice “reglas de subida”, no se refieren a un documento técnico largo. Quieren unos límites claros que todos sigan para que las subidas sean previsibles y las páginas no se vuelvan pesadas.

Las reglas de subida suelen incluir:

• Tamaño máximo por archivo (y a veces por acción de subida)
• Dimensiones máximas de imagen (ancho y alto en píxeles)
• Formatos permitidos (qué tipos aceptas)
• Límite de cantidad de archivos (por elemento, por mensaje, por usuario)
• Dónde se almacenan los archivos y cómo se entregan de vuelta a los usuarios

No todos los archivos se comportan igual, así que los límites no deberían ser idénticos.

Las imágenes se muestran dentro de tu app, por eso afectan la carga y el desplazamiento. Los documentos (PDF, hojas de cálculo) a menudo se descargan y abren fuera, así que pueden ser más grandes sin ralentizar cada página. El vídeo es otra categoría: puede consumir los planes de datos móviles y tardar mucho en conexiones lentas. Muchas apps tratan el vídeo por separado o lo evitan al principio.

“Original” vs “display” vs “thumbnail”

Estos términos parecen elegantes, pero son sencillos:

• Original: el archivo que sube el usuario. Puedes conservarlo para copia o edición futura.
• Versión de visualización: una copia redimensionada y más ligera que la app realmente muestra en pantalla.
• Miniatura: una vista previa pequeña usada en listas, rejillas y resultados de búsqueda.

Si solo almacenas y sirves el original, tu app terminará enviando archivos enormes a cada usuario, incluso cuando solo necesitan una vista previa pequeña.

El problema suele aparecer primero en móviles. Una foto “normal” de 6 MB puede sentirse instantánea en Wi‑Fi, pero puede congelar una página de producto en datos móviles, gastar batería y hacer que la app parezca rota.

Paso a paso: define límites y formatos desde el principio

La forma más rápida de establecer reglas es partir de lo que el usuario intenta hacer. “Subir” no es una sola cosa. Un avatar, una foto de producto y un recibo en PDF tienen necesidades distintas. Si los tratas igual, normalmente acabarás permitiendo archivos enormes por todas partes.

Escribe las acciones de subida que tu app soporta (o soportará pronto). Para cada una, decide qué significa “suficiente” en pantalla. La mayoría de las imágenes se ven más pequeñas de lo que la gente piensa.

Un método simple de 5 pasos

1. Define el caso de uso y dónde aparece (perfil, tarjeta de listado, galería, solo admin, solo descarga).
2. Fija un tamaño máximo que coincida con el comportamiento real (lo que los usuarios suelen subir, no lo que podrían subir).
3. Fija dimensiones máximas en píxeles para imágenes (esto evita que se cuele un original de 6000 x 4000).
4. Elige un formato por defecto y un pequeño conjunto de formatos permitidos.
5. Añade límites que prevengan abuso (archivos por ítem y almacenamiento total por usuario).

Ahora transforma esas decisiones en números concretos. Mantenlos fáciles de entender y de aplicar. Puedes permitir límites más generosos para imágenes destinadas a descargas o edición y límites más estrictos para imágenes públicas.

Puntos de partida concretos que puedes ajustar:

• Avatares: máximo 1 a 2 MB, máximo 512 a 1024 px, salida en WebP o JPEG
• Fotos de producto: máximo 3 a 5 MB, máximo 1600 a 2400 px, salida en WebP (mantener JPEG como permitido)
• Recibos (imágenes): máximo 5 a 10 MB, máximo 2500 a 3500 px, salida en JPEG o WebP
• PDFs: máximo 10 a 20 MB, mantener como PDF (no convertir)
• Otros documentos: máximo 10 a 20 MB, permitir solo lo que realmente necesites

Los formatos son donde los equipos se complican de más. Un defecto práctico es: WebP para fotos, JPEG como respaldo y PNG solo cuando necesites transparencia o gráficos tipo UI muy nítidos.

Finalmente, añade límites de “cuántos”. Por ejemplo: hasta 10 fotos por producto, hasta 50 adjuntos por proyecto, más un tope total por usuario. Estos límites protegen la velocidad y los costes, y reducen la probabilidad de que tu almacenamiento se convierta en un vertedero.

Elegir formatos sin sobrepensarlo

No necesitas una estrategia de formatos perfecta. Necesitas valores por defecto que mantengan las páginas ligeras y predecibles, y una o dos excepciones.

Para fotos, elige un por defecto moderno. WebP suele ser la ganancia más fácil porque mantiene buena apariencia con tamaños de archivo menores. Si WebP no es una opción en una herramienta concreta, usa JPEG como fallback. Guarda PNG para cuando realmente necesites transparencia.

“PNG para todo” es un error común porque PNG está pensado para bordes nítidos y transparencia, no para fotos de cámara. Una foto en PNG puede ser varias veces más grande que su versión en WebP o JPEG sin beneficio visible. Ese peso extra se traduce en feeds más lentos, páginas de producto más lentas y mayores costes de ancho de banda.

SVG es distinto. Es ideal para iconos y logos simples porque se mantiene nítido a cualquier tamaño. Pero SVG también es un formato de documento que puede contener scripts y contenido inesperado. Para subidas de usuarios, solo permite SVG si lo sanitizas o lo conviertes a un formato seguro primero. Si no, trata SVG como “activos del equipo”, no como “cualquiera puede subir”.

Un mapeo sencillo que puedes poner en tu especificación:

• Avatares: WebP (o JPEG), recorte cuadrado, no PNG salvo que necesites bordes transparentes
• Galería o fotos de producto: WebP primero, JPEG como fallback, evitar PNG
• Capturas de pantalla: WebP en la mayoría de casos, PNG solo si texto pequeño queda borroso después de comprimir
• Logos e iconos: SVG para tus propios archivos, PNG como fallback cuando no puedas usar SVG
• Documentos: PDF para compartir, y bloquear formatos ejecutables por defecto

Manténlo simple: un por defecto para fotos (WebP), un fallback (JPEG) y una excepción (PNG para transparencia). Todo lo demás es un caso especial que decides a propósito.

Redimensiona y comprime para que las páginas sigan rápidas

La forma más rápida de ralentizar una app es aceptar subidas enormes y luego servirlas en todas partes. Una foto de teléfono puede pesar 3 a 10 MB. Si la muestras en una lista con 200 px de ancho, el navegador seguirá descargando el archivo completo a menos que crees versiones más pequeñas.

Un enfoque práctico es redimensionar en la subida y generar unos tamaños estándar. Conserva el original solo si lo necesitas verdaderamente (edición, impresión o descargas en alta resolución). De lo contrario, guardar únicamente “el gran original” hace que cada página pague el precio.

Un conjunto simple de tamaños

Elige tamaños que coincidan con cómo tu UI muestra realmente las imágenes:

• Miniatura (listas): 200 a 300 px de ancho
• Imagen de tarjeta (rejillas): 600 a 800 px de ancho
• Imagen detalle (páginas de producto): 1200 a 1600 px de ancho
• Opcional: un original guardado solo para admin o descarga

Luego haz que la app use miniaturas en listas y el tamaño detalle en las páginas de producto. Esta decisión suele dar la mayor mejora en tiempos de carga.

Ajustes de calidad, en términos sencillos

La compresión es un intercambio: archivo más pequeño vs imagen más nítida. La mayoría de la gente no nota la diferencia entre “alta” y “muy alta” calidad en una pantalla típica, pero sí notará una página más lenta.

Apunta al archivo más pequeño que aún se vea bien en el tamaño en que lo muestras. Si una foto de producto de 1200 px se ve bien con 250–400 KB, rara vez hay motivo para enviarla a 2 MB.

La compresión del lado del cliente (en el navegador) puede ayudar porque los usuarios suben menos y esperan menos. Pero no basta por sí sola. Aún necesitas comprobaciones y procesamiento en el servidor porque se puede evitar el navegador y subir archivos que no coinciden con lo declarado.

Ejemplo: una app de marketplace muestra 30 artículos en la página principal. Si cada “miniatura” es en realidad un original de 4 MB, esa página puede convertirse silenciosamente en 120 MB. Si generas miniaturas reales en la subida, la misma página puede bajar a unos pocos megabytes y sentirse instantánea.

Aplica las reglas en los lugares correctos

Si solo aplicas las reglas en un sitio, los usuarios encontrarán formas de evitarlas. Aplica los mismos límites en tres capas: la UI, el servidor y la configuración de almacenamiento y entrega.

1) En la UI (útil, no confiable)

Las comprobaciones en el cliente evitan que la gente pierda tiempo subiendo algo que será rechazado. Muestra las reglas antes de que el usuario elija un archivo y valida inmediatamente tras la selección.

Comprobaciones útiles en la UI:

• Tipo de archivo (según la extensión y lo que el navegador reporte)
• Tamaño del archivo
• Dimensiones de la imagen
• Cantidad de archivos
• Una vista previa clara de lo que se va a subir

Trata las comprobaciones en la UI como una comodidad. Cualquiera puede saltárselas con peticiones personalizadas.

2) En el servidor (el verdadero guardián)

La validación en el servidor es innegociable. Revisa todo otra vez aunque ya lo hayas comprobado en la UI.

Como mínimo, valida:

• Tipo inspeccionando el contenido real del archivo (magic bytes), no solo el nombre
• Límites de tamaño (rechazo firme de subidas que excedan)
• Dimensiones de imagen (rechaza píxeles enormes que puedan disparar memoria durante el procesamiento)
• Cantidad por petición (para prevenir abuso y ralentizaciones)
• Seguridad del nombre de archivo (genera tus propios nombres y limpia caracteres riesgosos)

También bloquea tipos riesgosos que no necesites. Una buena regla es: permite solo lo que tu producto realmente soporta.

3) En almacenamiento y entrega (evitar errores caros)

La configuración de almacenamiento debe reforzar tus reglas. Asegúrate de que las subidas no sean escribibles públicamente y de que la app sirva las versiones correctas (como imágenes redimensionadas) en vez del original. Si almacenas originales, mantenlos separados de lo que se muestra en páginas.

Haz mensajes de error específicos. “Subida fallida” genera tickets. “Solo JPEG, PNG o WebP hasta 5 MB y máximo 3000 x 3000” dice al usuario qué corregir.

Errores comunes que hacen las subidas lentas y riesgosas

La mayoría de los problemas ocurren porque la primera versión funcionó, así que nadie la vuelve a tocar. Meses después, las páginas pesan, los costes de almacenamiento suben y se descubren brechas de seguridad en la canalización de subidas.

Los errores que causan más dolor:

• Permitir “cualquier archivo” para desbloquear la funcionalidad. Si los usuarios pueden subir cualquier cosa, acabarás soportándolo todo.
• Confiar en lo que el navegador dice del archivo. Extensiones y MIME types del cliente son fáciles de falsificar.
• Comprobar solo el tamaño en bytes, no las dimensiones en píxeles. Una imagen de 1–2 MB puede ser de 8000 x 8000 píxeles.
• Servir las subidas originales directamente en la UI. El original rara vez es lo adecuado para listas, rejillas y vistas detalladas.
• Poner subidas dentro de la base de datos principal. Las bases son buenas para metadata, no para archivos binarios grandes.

Estos errores también crean riesgos de seguridad: formatos inseguros, malware en archivos disfrazados y filtrado de datos privados a través de metadata EXIF. Reglas básicas de validación (tipo, tamaño, dimensiones y procesamiento seguro) mantienen el rendimiento predecible y reducen sorpresas.

Lista rápida que puedes copiar en tu especificación

Escribe estas reglas ahora y evitarás páginas lentas, facturas enormes y errores de subida confusos más adelante. Pega esto en tu spec y ajusta los números según tu app.

Reglas base:

• Límites (por tipo): Imágenes máximo 5 MB cada una. Documentos (PDF, DOCX) máximo 15 MB cada uno. Total por acción de subida máximo 25 MB. Si soportas vídeo o audio, define límites separados en lugar de “todo vale”.
• Imágenes (dimensiones + formatos): Máx. 3000 x 3000 px. Permitidos: JPEG, PNG, WebP. Bloquea HEIC a menos que lo conviertas en servidor.
• Entrega (tamaños que servirás): Genera siempre (1) una miniatura para listas (por ejemplo 300 px de ancho) y (2) un tamaño detalle para la vista completa (por ejemplo 1200 px de ancho). No cargues originales en listas o rejillas.
• Seguridad (qué rechazas y qué limpias): Bloquea subidas ejecutables y con scripts (EXE, JS, SH, BAT, MSI). Nunca confíes en extensiones. Valida el tipo real del archivo.
• Experiencia de usuario (qué ve el usuario): Muestra un error claro con el límite y cómo arreglarlo.

Un mensaje de error simple que ahorra tiempo de soporte:

"El archivo pesa 9.2 MB. El máximo para imágenes es 5 MB. Prueba exportarlo como WebP o JPEG a 1200 px de ancho y súbelo de nuevo."

Ejemplo: fotos de producto que silenciosamente ralentizan toda tu app

Una historia común: lanzas un pequeño marketplace con 20 anuncios. Cada vendedor sube unas fotos y todo parece bien. Meses después tienes 5.000 anuncios y de repente las páginas pesan. Los mensajes de soporte empiezan a sonar igual: “La página tarda una eternidad”, “Funciona en Wi‑Fi pero no en mi teléfono”, “La app se congela al desplazar”.

El culpable suele ser simple: los vendedores suben fotos de 10–20 MB directas desde el móvil. Un anuncio puede tener 6 fotos, así que una sola carga de página puede convertirse en 60–120 MB de imágenes si no tienes cuidado.

Antes: sin reglas (o reglas en la cabeza de alguien)

Los vendedores suben lo que tengan. Algunas fotos son enormes, otras con formas raras y otras en el formato equivocado. Tu app muestra imágenes a tamaño completo en sitios que solo necesitan vistas previas pequeñas. Las páginas se vuelven más lentas conforme crece el inventario y acabas discutiendo si “la app está lenta” o “la internet del usuario es lenta”.

Después: reglas sencillas que mantienen la velocidad

No necesitas políticas complicadas. Necesitas unas pocas vallas:

• Limitar subidas de imágenes (ej.: 5 MB por imagen)
• Convertir subidas a WebP (mantén JPEG, PNG solo cuando haga falta)
• Generar varios tamaños (miniatura, tarjeta, completo) y servir el apropiado
• Limitar el número de fotos por anuncio (ej.: 8–12)

En la práctica, esto convierte una foto de 15 MB en un WebP más pequeño y una miniatura ligera. Las páginas de listado se sienten ágiles porque cargan muchas miniaturas pequeñas en lugar de unos pocos originales enormes.

Siguientes pasos: fija las reglas ahora y limpia lo que ya tienes

Empieza por ver lo que realmente tienes, no lo que crees. Elige 20–50 subidas recientes (mezcla de imágenes y otros archivos) y anota tres cosas por cada una: tipo de archivo, tamaño y dónde aparece en la app. Luego carga tu página más lenta en una conexión móvil normal y observa cuánto tarda hasta que es usable.

Busca archivos mucho más grandes de lo que la pantalla necesita. Una foto “simple” de producto puede ser un PNG de 6 MB que solo se muestra como miniatura. Ese archivo puede añadir segundos a cada vista de página.

Con datos reales, enfócate en las pocas reglas que evitan la mayoría de problemas:

• Fija límites claros de tamaño (cap diferenciados para imágenes y documentos)
• Restringe formatos permitidos (solo lo que realmente soportas)
• Añade redimensionado y compresión automática para imágenes
• Endurece la validación (comprueba tipo, tamaño y contenido, no solo el nombre)
• Define un fallback (qué pasa cuando una subida es rechazada)

Despliega con cuidado para no romper usuarios existentes. Aplica las nuevas reglas solo a subidas nuevas y registra lo que habría sido rechazado para ver el impacto antes de aplicarlo por completo. Después planifica limpieza para archivos antiguos: identifica el 10% más grande, genera versiones web‑friendly y elimina duplicados innecesarios.

Si heredaste un código generado por IA, las subidas suelen ser donde se acumulan problemas: reglas inconsistentes, comprobaciones faltantes en el servidor, secretos expuestos y páginas que se hacen más lentas conforme crece el contenido. FixMyMess (fixmymess.ai) hace diagnóstico y reparación de codebases generadas por IA, incluyendo endurecimiento de subidas, redimensionado y seguridad.

Termina escribiendo tus reglas en la spec como oraciones sencillas. Si un nuevo compañero puede seguirlas sin preguntarte, has terminado.