Com reduir els costos d'allotjament de la teva app

Per reduir els costos d'allotjament, descobreix què està realment en marxa i per què, i després deixa que tot dormi quan ningú no l'usa. En els allotjaments que escalen a zero, una app inactiva i una base de dades adormida costen molt poc, així que els estalvis més grans normalment venen d'eliminar allò que els manté despert —sovint codi que consulta la base de dades cada pocs segons— i després de reduir l'ample de banda i esborrar les apps que ningú no fa servir.

La majoria de les apps petites no tenen un problema de trànsit. Tenen un problema de «alguna cosa està sempre encesa». Aquesta guia explica com trobar-lo i corregir-lo, amb indicacions que pots donar a un constructor d'apps amb IA.

Què pagues realment

Les factures d'allotjament de les apps petites surten d'unes poques coses. Saber quina és la més gran et diu on mirar.

Molts allotjaments moderns, incloent Mythex, escalen a zero: quan ningú no usa l'app, el servidor s'atura i no costa res en còmput, i es torna a activar la següent visita. Això canvia la pregunta de «quant de gran és el meu servidor?» a «per què està despert el meu servidor?».

Pas 1: mira on van els diners

Abans de canviar res, obre la pàgina d'ús del teu allotjament i troba:

• Quin projecte costa més. Sovint una sola app és la major part de la factura.
• Quina categoria: còmput, base de dades, ample de banda o emmagatzematge.
• Quan gasta. Una línia plana durant la nit, quan no tens usuaris, és la pista que alguna cosa manté l'app desperta.

A Mythex, Detalls d'ús mostra els darrers 30 dies dividits en Build (l'agent d'IA) i Run (allotjament, ample de banda, base de dades i emmagatzematge de fitxers), amb un desglossament per projecte.

Pas 2: deixa dormir les apps i les bases de dades inactives

Aquesta és la palanca real per a la majoria d'apps petites. Una base de dades que s'adorm quan està inactiva i es desperta la següent petició gairebé no costa res durant les hores tranquil·les. Una base de dades consultada cada pocs segons mai no queda inactiva, així que pagues tot el dia.

Les limitacions d'allotjament de Mythex expliquen com funciona per a les apps publicades: una app adormida no gasta res en còmput, la base de dades comença a la mida més petita, creix quan està ocupada, s'adorm després de 5 minuts inactius, i es cobra per la seva mida multiplicada pel temps que ha estat desperta. Així, una app que consulta la seva base de dades almenys una vegada cada pocs minuts, de dia i de nit, es factura com si estigués sempre ocupada, mentre que la mateixa app sense aquest soroll de fons costa molt poc.

Coses habituals que mantenen una app desperta:

• Sondeig. Una pàgina que pregunta al servidor «hi ha res de nou?» cada 2–5 segons. Si deixes aquesta pestanya oberta en un portàtil, la base de dades no s'adorm mai.
• Taulers que es refresquen automàticament i recarreguen dades amb un temporitzador, encara que ningú no els estigui mirant.
• Monitors d'uptime que fan ping a l'app cada minut.
• Bucles de fons al codi del servidor: un setInterval que neteja o sincronitza dades per sempre.
• Peticions de «manteniment» programades que algú va afegir per evitar una primera visita lenta. Funcionen impedint que l'app dormi, que és exactament el que costa diners.

Demana a la IA que els trobi:

Revisa el codi buscant qualsevol cosa que s'executi amb un temporitzador o que consulti la base de dades repetidament: sondeig, setInterval, refresc automàtic, bucles de fons. Llista cadascun, amb la freqüència amb què s'executa i si s'executa quan ningú té la pàgina oberta. De moment no canviïs res.

Després corregeix-los un per un:

El tauler sondeja /api/orders cada 3 segons. Canvia-ho perquè només es refresqui mentre la pestanya del navegador és visible, i cada 60 segons en lloc de cada 3. Afegeix un botó de Refresh manual.

Si la teva app necessita actualitzacions en directe de debò (un xat, un marcador en directe), pregunta si pot enviar actualitzacions només quan canvia alguna cosa, en lloc de preguntar constantment. Per a moltes apps, «refresca quan l'usuari torna a la pestanya» és suficient.

Pas 3: ajusta la mida del servidor

Les màquines més grans costen més per hora. Moltes apps creades amb IA comencen amb una mida per defecte que va bé; els problemes venen de demanar més potència per arreglar una lentitud que en realitat era una consulta lenta.

• Mantén la mida més petita que serveixi el teu trànsit sense errors.
• Si veus caigudes per memòria, primer pregunta a la IA si l'app carrega massa a la memòria (una taula sencera en lloc d'una pàgina de resultats).
• Només afegeix màquines si tens trànsit mesurat que les necessiti.

A Mythex, la mida de la màquina es tria en publicar segons el que necessita l'app, i les màquines addicionals només s'activen quan hi ha molt trànsit i tornen a dormir quan baixa. El cost segueix la mida, així que demana en el xat una mida més petita si creus que és sobredimensionada.

Pas 4: redueix l'ample de banda

L'ample de banda és el que descarreguen els visitants. Les imatges solen ser la part més gran.

• Comprimeix les imatges i serveix formats moderns com WebP o AVIF.
• Redimensiona les imatges a la mida en què es mostren. Una foto de 4.000 píxels mostrada com una miniatura de 400 píxels malgasta gairebé tot el que es descarrega.
• Carrega les imatges de manera diferida quan estiguin per sota de la pantalla visible.
• Guarda a la memòria cau els fitxers estàtics (scripts, estils, imatges) perquè els visitants que tornen no els tornin a descarregar. Consulta què és la memòria cau.
• No deixis que l'app entregui fitxers grans en cada visualització de pàgina.

Revisa cada imatge de l'app. Redimensiona-les a la mida més gran en què es mostren, converteix-les a WebP i carrega de manera diferida qualsevol cosa que estigui per sota de la primera pantalla. Digues-me la mida total abans i després.

Pàgines més ràpides i menys ample de banda solen anar juntes; consulta com fer el teu lloc web més ràpid.

Pas 5: neteja el que ningú no fa servir

• Despublica les apps antigues: despleigaments de prova, experiments acabats, el lloc de l'esdeveniment de l'any passat.
• Esborra les pujades, registres i exportacions antigues que no necessitis.
• Esborra els enllaços de previsualització compartits que ja no fas servir. A Mythex, obrir un enllaç de previsualització desperta el projecte i gasta crèdits, així que un enllaç oblidat que algú continua obrint encara costa diners.
• Elimina els serveis que no usis: un servidor d'API o un worker que l'app ja no crida.

Pas 6: considera un lloc estàtic

Si el teu lloc no té inicis de sessió, ni dades d'usuaris desades, ni lògica de servidor —un lloc de màrqueting, un portafolis, una carta— pot ser un lloc estàtic: fitxers simples servits des d'una CDN. No hi ha servidor ni base de dades que mantenir en marxa. A Mythex, els llocs estàtics no gasten crèdits mentre estan allà.

Aquest lloc no té inicis de sessió ni dades desades. Es pot reconstruir com a lloc estàtic sense servidor? Què perdríem?

Pas 7: vigila les crides de pagament a APIs

Per a les apps que criden models d'IA, mapes o SMS, les factures de tercers poden superar amb escreix la d'allotjament.

• Exigeix inici de sessió per a qualsevol cosa que costi diners per crida.
• Afegeix un límit per usuari (consulta què és el rate limiting).
• Guarda a la memòria cau les respostes que no canvien, com la geocodificació de la mateixa adreça.
• Posa límits de despesa o alertes a cada proveïdor.

Errors habituals

• Endevinar en lloc de mesurar. Mira primer el desglossament d'ús; la part cara sovint no és la que esperaries.
• Comprar un servidor més gran per arreglar la lentitud. Un índex de base de dades que falta o carregar massa dades sol ser la causa real.
• Sondejar-ho tot. Cada temporitzador que s'executa cada pocs segons és un motiu perquè la base de dades resti desperta.
• Fer ping a l'app per mantenir-la «calenta». Això elimina l'estalvi que dona escalar a zero. Accepta una petita espera en la primera visita, o paga per tenir-la sempre encesa de manera deliberada.
• Oblidar els despleigaments antics. Les apps no usades amb bases de dades i tasques de fons s'acumulen sense fer soroll.
• Imatges sense comprimir. Sovint és el cost d'ample de banda més gran en els llocs petits.

Llista de comprovació

• Sé quin projecte i quina categoria (còmput, base de dades, ample de banda, emmagatzematge) costa més.
• Res no consulta la base de dades cada pocs segons quan ningú no mira.
• Els taulers es refresquen en un interval raonable o només mentre la pestanya és visible.
• Cap monitor d'uptime ni bucle de fons manté l'app desperta sense motiu.
• El servidor és la mida més petita que funciona.
• Les imatges estan redimensionades, comprimides i carregades de manera diferida; els fitxers estàtics estan a la memòria cau.
• Les apps antigues estan despublicades, els fitxers antics esborrats i els enllaços de previsualització no usats eliminats.
• Els llocs sense dades ni inicis de sessió són estàtics.
• Les APIs de pagament tenen inici de sessió, límits per usuari i alertes de despesa del proveïdor.

Reduir costos a Mythex

Mythex fa servir un únic saldo de crèdits per construir i per allotjar, així que els estalvis d'allotjament deixen més crèdits per construir. Alguns punts específics de Mythex:

• Les apps publicades i les seves bases de dades dormen quan estan inactives i es desperten la següent visita. La base de dades s'adorm després de 5 minuts inactius, així que eliminar el sondeig constant sol ser el guany més gran.
• El pla Pro paga la meitat de la tarifa Free per a l'allotjament, les bases de dades, l'ample de banda, l'emmagatzematge de fitxers i el sandbox de previsualització; la IA costa el mateix en tots dos plans. Consulta Crèdits.
• Reps un correu abans que un saldo baix pausi una app publicada, i les apps pausades conserven la seva base de dades i els fitxers.

Per a una visió més àmplia dels costos de funcionament, consulta quant costa construir una app i què és l'allotjament web.

Preguntes