Como Reduzir os Custos de Alojamento da Sua App

Para reduzir os custos de alojamento, descubra o que está realmente em execução e porquê, e deixe tudo adormecer quando ninguém está a usar. Em alojamentos que escalam para zero, uma app inativa e uma base de dados em repouso custam muito pouco, por isso as maiores poupanças vêm normalmente de remover o que as mantém acordadas — quase sempre código que consulta a base de dados a cada poucos segundos — e depois de reduzir a banda e apagar as apps que ninguém usa.

A maioria das pequenas apps não tem um problema de tráfego. Tem um problema de "algo está sempre ligado". Este guia mostra como o encontrar e corrigir, com prompts que pode dar a um criador de apps com IA.

O que paga, na prática

As faturas de alojamento das pequenas apps resultam de poucas coisas. Saber qual é a maior indica onde procurar.

Muitas plataformas modernas, incluindo o Mythex, escalam para zero: quando ninguém usa a app, o servidor para e não custa nada em computação, e volta a arrancar na próxima visita. Isso muda a pergunta de "quão grande é o meu servidor?" para "porque é que o meu servidor está acordado?"

Passo 1: Veja para onde vai o dinheiro

Antes de alterar seja o que for, abra a página de utilização do seu alojamento e encontre:

• Qual projeto custa mais. Muitas vezes, uma só app é a maior parte da fatura.
• Qual categoria — computação, base de dados, banda ou armazenamento.
• Quando gasta. Uma linha constante durante a noite, quando não tem utilizadores, é a pista de que algo mantém a app acordada.

No Mythex, Detalhes de utilização mostra os últimos 30 dias divididos entre Build (o agente de IA) e Run (alojamento, banda, base de dados e armazenamento de ficheiros), com uma repartição por projeto.

Passo 2: Deixe as apps e bases de dados inativas adormecer

Esta é a alavanca real para a maioria das pequenas apps. Uma base de dados que adormece quando está inativa e acorda no pedido seguinte custa quase nada nas horas calmas. Uma base de dados consultada a cada poucos segundos nunca fica inativa, por isso paga o dia inteiro.

Os limites de alojamento do Mythex explicam como isto funciona para as apps publicadas: uma app em repouso não gasta nada em computação, a base de dados começa no tamanho mais pequeno, cresce quando está ocupada, adormece após 5 minutos de inatividade e é cobrada pelo tamanho multiplicado pelo tempo em que esteve acordada. Assim, uma app que consulta a base de dados até uma vez a cada poucos minutos, de dia e de noite, é cobrada como se estivesse sempre ocupada — enquanto a mesma app sem atividade de fundo custa muito pouco.

Coisas comuns que mantêm uma app acordada:

• Polling. Uma página que pergunta ao servidor "há algo novo?" a cada 2–5 segundos. Deixe esse separador aberto num portátil e a base de dados nunca adormece.
• Painéis com atualização automática que recarregam os dados num temporizador, mesmo quando ninguém os está a ver.
• Monitores de disponibilidade que fazem ping à app a cada minuto.
• Ciclos em segundo plano no código do servidor — um setInterval que limpa ou sincroniza dados para sempre.
• Pedidos de "keep-alive" agendados que alguém acrescentou para evitar uma primeira visita lenta — funcionam impedindo o repouso, e é exatamente isso que custa dinheiro.

Peça à IA que os encontre:

Procura no código tudo o que corre num temporizador ou consulta a base de dados repetidamente: polling, setInterval, atualização automática, ciclos em segundo plano. Lista cada um, com a frequência com que corre e se corre quando ninguém tem a página aberta. Ainda não alteres nada.

Depois, corrija-os um a um:

O painel faz polling a /api/orders a cada 3 segundos. Altera-o para atualizar apenas enquanto o separador do navegador estiver visível, e a cada 60 segundos em vez de 3. Acrescenta um botão manual de Atualizar.

Se a sua app precisar mesmo de atualizações em tempo real (um chat, um marcador ao vivo), pergunte se pode enviar atualizações apenas quando algo muda, em vez de perguntar constantemente. Em muitas apps, "atualizar quando o utilizador volta ao separador" é suficiente.

Passo 3: Ajuste o tamanho do servidor

Máquinas maiores custam mais por hora. Muitas apps criadas com IA começam num tamanho predefinido que chega; os problemas surgem quando se pede "mais potência" para resolver uma lentidão que, na realidade, era uma consulta lenta.

• Mantenha o tamanho mais pequeno que atende o seu tráfego sem erros.
• Se vir falhas por falta de memória, primeiro pergunte à IA se a app carrega demasiados dados para a memória (uma tabela inteira em vez de uma página de resultados).
• Acrescente máquinas apenas se tiver tráfego medido que as exija.

No Mythex, o tamanho da máquina é escolhido na publicação, com base no que a app precisa, e máquinas extra só arrancam quando o tráfego é intenso e voltam a adormecer quando baixa. O custo acompanha o tamanho, por isso peça no chat um tamanho menor se achar que está sobredimensionado.

Passo 4: Reduza a banda

A banda é o que os visitantes descarregam. As imagens costumam ser a maior parte.

• Comprima as imagens e sirva formatos modernos, como WebP ou AVIF.
• Redimensione as imagens para o tamanho em que são apresentadas. Uma foto de 4000 pixels mostrada como miniatura de 400 pixels desperdiça a maior parte do que é descarregado.
• Use carregamento diferido (lazy-load) nas imagens abaixo da primeira dobra.
• Guarde em cache os ficheiros estáticos (scripts, estilos, imagens) para que os visitantes que regressam não os descarreguem outra vez. Veja o que é cache.
• Não deixe a app entregar ficheiros grandes em cada visualização de página.

Verifica todas as imagens da app. Redimensiona-as para o maior tamanho em que são apresentadas, converte-as para WebP e usa carregamento diferido em tudo o que estiver abaixo do primeiro ecrã. Diz-me o tamanho total antes e depois.

Páginas mais rápidas e menos banda andam normalmente juntas — veja como tornar o seu site mais rápido.

Passo 5: Limpe o que ninguém usa

• Despublique apps antigas — implementações de teste, experiências terminadas, o site de um evento do ano passado.
• Apague uploads, registos e exportações antigos que não precisa.
• Elimine as ligações de pré-visualização partilhadas que já não usa. No Mythex, abrir uma ligação de pré-visualização acorda o projeto e gasta os seus créditos, por isso uma ligação esquecida que alguém continua a abrir continua a custar.
• Remova serviços não usados — um servidor de API ou um worker que a app já não chama.

Passo 6: Considere um site estático

Se o seu site não tem inícios de sessão, não guarda dados de utilizadores e não tem lógica de servidor — um site de marketing, um portefólio, uma ementa —, pode ser um site estático: ficheiros simples servidos a partir de uma CDN. Não há servidor nem base de dados para manter a funcionar. No Mythex, os sites estáticos não consomem créditos enquanto estão parados.

Este site não tem inícios de sessão nem dados guardados. Pode ser recriado como site estático, sem servidor? O que perderíamos?

Passo 7: Vigie as chamadas de API pagas

Para apps que chamam modelos de IA, mapas ou SMS, as faturas de terceiros podem ultrapassar o alojamento.

• Exija início de sessão para tudo o que custa dinheiro por chamada.
• Defina um limite por utilizador (veja o que é limitação de pedidos).
• Guarde em cache respostas que não mudam, como a geocodificação do mesmo endereço.
• Defina limites de gastos ou alertas em cada fornecedor.

Erros comuns

• Adivinhar em vez de medir. Veja primeiro a repartição de utilização; a parte cara muitas vezes não é a que esperava.
• Comprar um servidor maior para resolver a lentidão. Um índice em falta na base de dados ou carregar dados em excesso é normalmente a causa real.
• Fazer polling de tudo. Cada temporizador de poucos segundos é uma razão para a base de dados não adormecer.
• Fazer ping à app para a manter "quente". Isso elimina a poupança que o escalonamento para zero lhe dá. Aceite um pequeno atraso no primeiro acesso, ou pague por estar sempre ligado de propósito.
• Esquecer implementações antigas. Apps não usadas com bases de dados e tarefas em segundo plano somam custos em silêncio.
• Imagens não comprimidas. Muitas vezes é o maior custo de banda em sites pequenos.

Lista de verificação

• Sei qual projeto e qual categoria (computação, base de dados, banda, armazenamento) custa mais.
• Nada consulta a base de dados a cada poucos segundos quando ninguém está a ver.
• Os painéis atualizam com um intervalo razoável ou apenas enquanto o separador está visível.
• Nenhum monitor de disponibilidade ou ciclo em segundo plano mantém a app acordada sem motivo.
• O servidor é o tamanho mais pequeno que funciona.
• As imagens estão redimensionadas, comprimidas e com carregamento diferido; os ficheiros estáticos estão em cache.
• As apps antigas estão despublicadas, os ficheiros antigos apagados e as ligações de pré-visualização não usadas removidas.
• Os sites sem dados nem inícios de sessão são estáticos.
• As APIs pagas têm início de sessão, limites por utilizador e alertas de gastos no fornecedor.

Reduzir custos no Mythex

O Mythex usa um único saldo de créditos para criar e para alojar, por isso as poupanças de alojamento deixam mais créditos para criar. Alguns pontos específicos do Mythex:

• As apps publicadas e as suas bases de dados adormecem quando estão inativas e acordam na visita seguinte. A base de dados adormece após 5 minutos de inatividade, por isso remover o polling constante costuma ser o maior ganho.
• O plano Pro paga metade da taxa do plano Free pelo alojamento, bases de dados, banda, armazenamento de ficheiros e pelo sandbox de pré-visualização; a IA custa o mesmo nos dois planos. Veja Créditos.
• Recebe um email antes de um saldo baixo poder pausar uma app publicada, e as apps pausadas mantêm a base de dados e os ficheiros.

Para a visão geral sobre custos de funcionamento, veja quanto custa criar uma app e o que é alojamento web.

Perguntas