Limites de tamanho para uploads de imagens e arquivos que mantêm seu app rápido

Por que regras de upload importam antes do seu app crescer

Uploads são fáceis de ignorar no começo. Algumas fotos e PDFs funcionam bem, as páginas parecem rápidas e ninguém reclama. Aí vêm usuários reais e conteúdo real, e cada tela começa a ficar mais pesada do que deveria.

Uploads não só ocupam espaço. Eles moldam a sensação de rapidez do seu app no dia a dia. Se você não definir limites claros cedo, acaba corrigindo performance depois, sob pressão.

Velocidade de upload não é o mesmo que velocidade de carregamento

Velocidade de upload é quanto tempo um usuário leva para enviar um arquivo ao servidor. Velocidade de carregamento de página é quanto tempo leva para todo mundo ver esse arquivo depois.

Alguém pode esperar 3 segundos para subir uma foto de 12 MB e achar “ok”. Mas agora toda página de perfil, listagem e feed que mostra essa foto tem que baixá-la também. Essa sensação de lentidão se espalha pelo app inteiro, inclusive para usuários que nunca enviam nada.

Um exemplo simples: um marketplace lança com 30 vendedores. Todos enviam fotos de telefone direto da câmera. O app ainda parece ok. Um mês depois há 1.000 anúncios, e a página inicial carrega dezenas de imagens exageradas. Nada “quebrou”, mas o app ficou lento.

Custos ocultos se acumulam silenciosamente

Uploads grandes e não planejados criam custos difíceis de notar até você estourar um limite ou receber uma fatura:

• O armazenamento cresce mais rápido do que o esperado, mesmo para apps pequenos.
• Backups demoram mais e custam mais.
• Stores de metadados incham se você guardar demais por arquivo.
• Custos de CDN e largura de banda sobem porque usuários ficam baixando arquivos grandes repetidamente.
• Tempo de suporte aumenta quando uploads falham em redes móveis.

O objetivo é simples: decida suas regras uma vez e as aplique em todo lugar. Isso significa os mesmos limites na UI, na API, em jobs de background e nas ferramentas de admin.

Se você herdou um app gerado por IA onde uploads foram adicionados de forma rápida e inconsistente, esse é um cleanup comum. Ter regras consistentes primeiro facilita todas as outras correções de performance.

O que contam como regras de imagem e arquivo (em linguagem simples)

Quando as pessoas dizem “regras de upload”, não querem um documento técnico longo. Querem alguns limites claros que todos sigam para que uploads permaneçam previsíveis e páginas não fiquem pesadas no futuro.

Regras de upload normalmente incluem:

• Tamanho máximo de arquivo (por arquivo, e às vezes por upload)
• Dimensões máximas de imagem (largura e altura em pixels)
• Formatos permitidos (quais tipos você aceita)
• Limites de quantidade de arquivos (por item, por mensagem, por usuário)
• Onde os arquivos são armazenados e como são entregues aos usuários

Nem todo arquivo se comporta do mesmo modo, então os limites não devem ser idênticos para tudo.

Imagens aparecem dentro do seu app, então afetam tempo de carregamento e rolagem. Documentos (PDFs, planilhas) frequentemente são baixados e abertos em outro lugar, então podem ser maiores sem deixar cada página lenta. Vídeo é outra categoria: ele pode arrasar o plano de dados móvel e demorar em conexões lentas. Muitos apps lidam com vídeo separadamente ou o evitam no começo.

“Original” vs “display” vs “thumbnail”

Esses termos soam sofisticados, mas são simples:

• Original: o que o usuário faz upload. Você pode guardá-lo para backup ou edições futuras.
• Versão de exibição (display): uma cópia redimensionada e mais leve que seu app realmente mostra na tela.
• Thumbnail: uma prévia pequena usada em listas, grades e resultados de busca.

Se você só armazenar e servir o original, seu app acaba empurrando arquivos enormes para todo usuário, mesmo quando só precisam de uma prévia.

A dor costuma aparecer primeiro para usuários móveis. Uma foto “normal” de 6 MB pode ser instantânea em Wi‑Fi, mas congelar uma página de produto numa conexão celular, queimar bateria e deixar seu app parecendo quebrado.

Passo a passo: escolha limites de tamanho e formatos desde o início

A forma mais rápida de definir regras de upload é partir do que o usuário quer fazer. “Upload” não é uma coisa só. Um avatar, uma foto de produto e um recibo em PDF têm necessidades diferentes. Se você tratá‑los igual, normalmente vai acabar permitindo arquivos enormes em todo lugar.

Anote as ações de upload que seu app suporta (ou suportará em breve). Para cada uma, decida o que é “bom o bastante” na tela. A maioria das imagens é vista menor do que as pessoas imaginam.

Um método simples em 5 passos

1. Defina o caso de uso e onde aparece (perfil, cartão de listagem, galeria, só admin, só download).
2. Estabeleça um tamanho máximo de arquivo que combine com o comportamento real (o que usuários realmente enviam, não o que poderiam enviar).
3. Determine dimensões máximas em pixels para imagens (isso impede um original 6000 x 4000 de entrar).
4. Escolha um formato padrão e um pequeno conjunto de formatos permitidos.
5. Adicione limites para prevenir abuso (arquivos por item e armazenamento total por usuário).

Agora transforme essas escolhas em números específicos. Mantenha fáceis de entender e fáceis de aplicar. Você pode permitir limites maiores para imagens internas e limites menores para imagens públicas.

Pontos de partida concretos que você pode ajustar:

• Avatares: máximo 1 a 2 MB, máximo 512 a 1024 px, saída em WebP ou JPEG
• Fotos de produto: máximo 3 a 5 MB, máximo 1600 a 2400 px, saída em WebP (manter JPEG permitido)
• Recibos (imagens): máximo 5 a 10 MB, máximo 2500 a 3500 px, saída em JPEG ou WebP
• PDFs: máximo 10 a 20 MB, manter como PDF (não converter)
• Outros documentos: máximo 10 a 20 MB, permitir apenas o que realmente precisa

Formatos são onde times complicam demais. Um padrão prático: WebP para fotos, JPEG como fallback e PNG só quando precisar de transparência ou gráficos nítidos de UI.

Por fim, adicione limites de “quantos”. Exemplo: até 10 fotos por produto, até 50 anexos por projeto, mais um teto total por usuário. Esses limites protegem velocidade e custos e reduzem a chance de seu armazenamento virar um depósito desorganizado.

Escolhendo formatos sem pensar demais

Você não precisa de uma estratégia perfeita de formatos. Precisa de padrões que mantenham as páginas leves e previsíveis, mais uma ou duas exceções.

Para fotos, escolha um padrão moderno. WebP costuma ser o ganho mais fácil porque fica bom com tamanhos de arquivo menores. Se WebP não for opção por alguma ferramenta ou fluxo, use JPEG como fallback. Use PNG apenas quando realmente precisar.

“PNG para tudo” é um erro comum porque PNG foi feito para bordas nítidas e transparência, não para fotos de câmera. Uma foto em PNG pode ser várias vezes maior que uma versão WebP ou JPEG sem benefício visível. Esse peso extra aparece como feeds mais lentos, páginas de produto mais lentas e custo de banda maior.

SVG é diferente. É ótimo para ícones e logos simples porque permanece nítido em qualquer tamanho. Mas SVG também é um formato de documento que pode conter scripts e conteúdo inesperado. Para uploads de usuário, só permita SVG se você sanitizar ou convertê‑lo antes. Caso contrário, trate SVG como “ativos da equipe”, não “qualquer usuário pode enviar”.

Um mapeamento simples para sua especificação:

• Avatares: WebP (ou JPEG), corte quadrado, sem PNG a menos que precise de transparência
• Galeria ou fotos de produto: WebP primeiro, JPEG como fallback, evitar PNG
• Capturas de tela: WebP na maioria dos casos, PNG só se texto pequeno ficar borrado após compressão
• Logos e ícones: SVG para arquivos próprios, PNG como fallback quando SVG não for possível
• Documentos: PDF para compartilhamento, bloquear formatos executáveis por padrão

Mantenha simples: um padrão para fotos (WebP), um fallback (JPEG) e uma exceção (PNG para transparência). Todo o resto é caso especial decidido de propósito.

Redimensione e comprima para manter páginas rápidas

A maneira mais rápida de deixar um app lento é aceitar uploads enormes e depois servi‑los em todo lugar. Uma foto de telefone pode ter 3 a 10 MB. Se você a mostra numa lista com 200 px de largura, o navegador ainda baixa o arquivo inteiro a menos que você crie versões menores.

Uma prática é redimensionar no upload e gerar alguns tamanhos padrão. Mantenha o original apenas se realmente precisar (edição, impressão ou download em alta resolução). Caso contrário, armazenar só “o grande original” faz com que toda página pague o preço.

Um conjunto simples de tamanhos

Escolha tamanhos que batam com o que sua UI realmente mostra:

• Thumbnail (para listas): 200 a 300 px de largura
• Imagem em card (para grades): 600 a 800 px de largura
• Imagem detalhada (para páginas de produto): 1200 a 1600 px de largura
• Opcional: um original mantido apenas para admin ou download

Então faça seu app usar thumbnails em listas e o tamanho de detalhe nas páginas de produto. Essa decisão costuma trazer a maior melhoria no tempo de carregamento.

Configurações de qualidade, em termos simples

Compressão é um trade‑off: arquivo menor vs imagem mais nítida. A maioria das pessoas não vê diferença entre “alta” e “muito alta” em uma tela típica, mas sentirão a página mais lenta.

Almeje o menor arquivo que ainda pareça bom no tamanho em que é exibido. Se uma foto de produto de 1200 px ficar bem com 250–400 KB, raramente há razão para enviá‑la a 2 MB.

Compressão no cliente (no navegador) ajuda porque usuários enviam menos dados e esperam menos. Mas não é suficiente. Você ainda precisa de checagens e processamento no servidor porque usuários podem burlar o navegador, enviar de scripts ou enviar arquivos que não correspondem ao que declaram.

Exemplo: um marketplace mostra 30 itens na home. Se cada “thumbnail” for na verdade um original de 4 MB, essa página pode virar silenciosamente 120 MB. Se você gerar thumbnails reais no upload, a mesma página pode cair para alguns megabytes e ficar instantânea.

Aplique as regras nos lugares certos

Se você aplicar regras de upload só em um ponto, usuários ainda vão achar um jeito de contorná‑las. Aplique os mesmos limites em três lugares: UI, servidor e configurações de armazenamento/entrega.

1) Na UI (útil, mas não confiável)

Checagens no cliente evitam que as pessoas percam tempo enviando algo que será rejeitado. Mostre as regras antes do usuário escolher um arquivo e valide logo após a seleção.

Checagens úteis na UI:

• Tipo de arquivo (com base na extensão e no que o navegador reporta)
• Tamanho do arquivo
• Dimensões da imagem
• Quantidade de arquivos
• Uma prévia clara do que será enviado

Trate checagens na UI como conveniência. Qualquer um pode contorná‑las com requisições customizadas.

2) No servidor (o verdadeiro porteiro)

Validação no servidor é inegociável. Verifique tudo novamente, mesmo que já tenha checado na UI.

No mínimo, valide:

• Tipo, inspecionando o conteúdo real do arquivo (magic bytes), não só o nome
• Limites de tamanho (rejeição dura para uploads acima do limite)
• Dimensões da imagem (rejeitar pixels enormes que podem estourar memória durante o processamento)
• Quantidade por requisição (para prevenir abuso e lentidão)
• Segurança do nome do arquivo (gere seus próprios nomes e remova caracteres arriscados)

Também bloqueie tipos de arquivo arriscados que você não precisa. Uma boa regra: permita apenas o que seu produto realmente suporta.

3) Nas configurações de armazenamento e entrega (evite erros caros)

Suas configurações de armazenamento devem reforçar suas regras. Garanta que uploads não sejam publicamente graváveis e assegure que seu app sirva as versões certas (como imagens redimensionadas) em vez do original. Se você armazenar originais, mantenha‑os separados do que exibe nas páginas.

Faça mensagens de erro específicas. “Upload falhou” gera tickets de suporte. “JPEG, PNG ou WebP apenas, até 5 MB, máximo 3000 x 3000” diz ao usuário o que corrigir.

Erros comuns que deixam uploads lentos e arriscados

A maioria dos problemas de upload acontece porque a primeira versão funciona, então ninguém revisita. Meses depois, páginas ficam pesadas, custos de armazenamento sobem e você descobre brechas de segurança no pipeline de upload.

Erros que causam mais dor:

• Permitir “qualquer arquivo” para liberar a feature. Se usuários podem enviar qualquer coisa, você acaba suportando tudo.
• Confiar no que o navegador diz sobre o arquivo. Extensões e MIME types do cliente são fáceis de falsificar.
• Checar só tamanho em MB, não dimensões em pixels. Uma imagem de 1–2 MB pode ainda ter 8000 x 8000 pixels.
• Servir uploads originais diretamente na UI. O original raramente é o certo para listas, grades e páginas de detalhe.
• Colocar uploads dentro do banco de dados principal. Bancos são bons para metadados, não para blobs grandes.

Esses erros também criam riscos de segurança: formatos inseguro, malware em arquivos disfarçados e dados privados vazando por metadados EXIF. Regras básicas de validação (tipo, tamanho, dimensões e processamento seguro) mantêm a performance previsível e reduzem surpresas.

Checklist rápido que você pode copiar para sua especificação

Escreva essas regras agora e você evita páginas lentas, faturas gigantes e erros confusos de upload depois. Cole isso na sua spec e ajuste os números conforme seu app.

Regras base:

• Limites (por tipo): Imagens até 5 MB cada. Documentos (PDF, DOCX) até 15 MB cada. Total por ação de upload até 25 MB. Se suportar vídeo ou áudio, defina limites separados em vez de “vale tudo”.
• Imagens (dimensões + formatos): Máx 3000 x 3000 px. Permitidos: JPEG, PNG, WebP. Bloquear HEIC a menos que você converta no servidor.
• Entrega (tamanhos que realmente vai servir): Gere sempre (1) uma thumbnail para listas (ex.: 300 px de largura) e (2) um tamanho de detalhe para visualização completa (ex.: 1200 px). Não carregue originais em listas ou grades.
• Segurança (o que recusar e o que limpar): Bloqueie uploads executáveis e com scripts (EXE, JS, SH, BAT, MSI). Nunca confie em extensões. Valide o tipo real do arquivo.
• Experiência do usuário (o que o usuário vê): Mostre um erro claro com o limite e a solução.

Uma mensagem de erro simples que economiza tempo de suporte:

"Arquivo tem 9,2 MB. Máx para imagens é 5 MB. Tente exportar como WebP ou JPEG com 1200 px de largura e tente novamente."

Exemplo: fotos de produto que deixam todo o app lento sem perceber

Uma história comum: você lança um pequeno marketplace com cerca de 20 anúncios. Cada vendedor envia algumas fotos e tudo parece bem. Alguns meses depois você tem 5.000 anúncios, e subitamente as páginas de listagem ficam pesadas. Mensagens de suporte começam a repetir: “A página demora”, “Funciona no Wi‑Fi mas não no meu celular”, “O app trava ao rolar”.

O culpado geralmente é simples: vendedores estão enviando fotos de 10 a 20 MB direto do celular. Um anúncio pode ter 6 fotos, então um único carregamento de página pode virar 60 a 120 MB de imagens se você não tiver cuidado.

Antes: sem regras (ou regras que existem só na cabeça de alguém)

Vendedores enviam o que têm. Algumas fotos são enormes, outras com formato estranho, algumas no formato errado. Seu app mostra imagens full‑size onde só precisa de prévias. As páginas ficam mais lentas conforme o inventário cresce e você discute se “o app está lento” ou “a internet do usuário está lenta”.

Depois: regras simples que mantêm tudo rápido

Você não precisa de políticas complicadas. Precisa de alguns guardrails:

• Limitar uploads de imagem (ex.: 5 MB por imagem)
• Converter uploads para WebP (manter JPEG e PNG só quando necessário)
• Gerar alguns tamanhos (thumbnail, card, full) e servir o certo
• Limitar quantidade de fotos por anúncio (ex.: 8–12)

Na prática, isso transforma uma foto de 15 MB em um WebP menor mais uma thumbnail leve. Páginas de listagem ficam rápidas porque carregam muitas thumbnails pequenas em vez de alguns originais massivos.

Próximos passos: defina regras agora e depois limpe o que já existe

Comece vendo o que você realmente tem, não o que imagina. Pegue 20 a 50 uploads recentes (mistura de imagens e outros arquivos) e anote três coisas para cada um: tipo de arquivo, tamanho e onde aparece no app. Depois carregue sua página mais lenta numa conexão de celular comum e registre quanto tempo leva até ficar utilizável.

Procure arquivos muito maiores do que a tela precisa. Uma foto “simples” pode ser um PNG de 6 MB que só é exibido como uma pequena thumbnail. Esse arquivo pode somar segundos a cada visualização de página.

Quando tiver dados reais, foque nas poucas regras que evitam a maioria dos problemas:

• Defina limites claros de tamanho (capas diferentes para imagens e documentos)
• Trave formatos permitidos (apenas o que suporta de fato)
• Adicione redimensionamento e compressão automáticos (no upload)
• Endureça validação (tipo, tamanho e conteúdo, não só nome de arquivo)
• Defina um fallback (o que acontece quando um upload é rejeitado)

Implemente de forma gradual para não quebrar usuários existentes. Aplique novas regras só para uploads novos primeiro e registre o que teria sido rejeitado para avaliar o impacto antes de aplicar integralmente. Depois planeje limpeza de arquivos antigos: identifique os 10% maiores, gere versões web‑friendly e remova duplicatas desnecessárias.

Se você herdou um codebase gerado por IA, uploads costumam ser onde problemas se acumulam: regras inconsistentes, checagens de servidor ausentes, segredos expostos e páginas que ficam mais lentas conforme o conteúdo cresce. FixMyMess (fixmymess.ai) faz diagnóstico e reparo de codebases gerados por IA, incluindo reforço de validação de upload, redimensionamento e hardening de segurança.

Termine escrevendo suas regras em frases simples na spec. Se um novo colega conseguir segui‑las sem te perguntar nada, você terminou.