Slik reduserer du hostingkostnadene for appen din

For å redusere hostingkostnadene må du finne ut hva som faktisk kjører og hvorfor, og så la alt sove når ingen bruker det. På hosting som skalerer til null koster en inaktiv app og en sovende database svært lite. Størst besparelse kommer derfor vanligvis fra å fjerne det som holder dem våkne, oftest kode som sjekker databasen hvert par sekund, og deretter fra å redusere båndbredde og slette apper ingen bruker.

De fleste små apper har ikke et trafikkproblem. De har et «noe er alltid på»-problem. Denne guiden viser hvordan du finner det og fikser det, med ledetekster du kan gi en AI-appbygger.

Hva du faktisk betaler for

Hostingregningen for små apper kommer fra en håndfull ting. Når du vet hvilken som er stor, vet du hvor du skal lete.

Mange moderne hostingtjenester, inkludert Mythex, skalerer til null: når ingen bruker appen, stopper serveren og koster ingenting for beregning, og våkner ved neste besøk. Det endrer spørsmålet fra «hvor stor er serveren min?» til «hvorfor er serveren min våken?»

Steg 1: Se hvor pengene går

Før du endrer noe, åpner du hostingtjenestens bruksside og finner:

• Hvilket prosjekt som koster mest. Ofte er det én app som utgjør det meste av regningen.
• Hvilken kategori: beregning, database, båndbredde eller lagring.
• Når det brukes. En flat linje gjennom natten, når du ikke har brukere, er et tegn på at noe holder appen våken.

På Mythex viser Bruksdetaljer de siste 30 dagene, delt på Build (AI-agenten) og Run (hosting, båndbredde, database og fillagring), med en oversikt per prosjekt.

Steg 2: La inaktive apper og databaser sove

Dette er den egentlige spaken for de fleste små apper. En database som sover når den er inaktiv og våkner ved neste forespørsel, koster nesten ingenting i stille timer. En database som spørres hvert par sekund, blir aldri inaktiv, så du betaler for den hele dagen.

Mythex sine hostingbegrensninger forklarer hvordan dette fungerer for publiserte apper: en sovende app bruker ingenting på beregning, og databasen starter på minste størrelse, vokser når den er travel, sover etter 5 minutter uten aktivitet, og belastes for størrelsen multiplisert med tiden den var våken. En app som spør databasen sin selv én gang hvert par minutt, døgnet rundt, faktureres derfor som om den var travel hele tiden, mens samme app uten bakgrunnsaktivitet koster svært lite.

Vanlige ting som holder en app våken:

• Polling. En side som spør serveren «er det noe nytt?» hvert 2.–5. sekund. La den fanen stå åpen på én laptop, og databasen sover aldri.
• Auto-oppdaterende dashbord som laster data på nytt med en timer, selv når ingen ser på.
• Oppetidsmonitorer som pinger appen hvert minutt.
• Bakgrunnsløkker i serverkoden, for eksempel et setInterval som rydder opp eller synkroniserer data for alltid.
• Planlagte «hold-i-live»-forespørsler som noen la til for å unngå et tregt første besøk. De fungerer ved å hindre søvn, og det er nettopp det som koster penger.

Be AI-en finne dem:

Gå gjennom koden og finn alt som kjører på en timer eller gjentatte ganger spør databasen: polling, setInterval, auto-oppdatering, bakgrunnsløkker. List opp hver enkelt, hvor ofte den kjører, og om den kjører når ingen har siden åpen. Ikke endre noe ennå.

Fiks dem så ett for ett:

Dashbordet poller /api/orders hvert 3. sekund. Endre det slik at det bare oppdaterer mens nettleserfanen er synlig, og hvert 60. sekund i stedet for hvert 3. Legg til en manuell Oppdater-knapp.

Hvis appen din virkelig trenger live-oppdateringer (en chat, en live poengtavle), spør om den kan sende oppdateringer bare når noe endrer seg, i stedet for å spørre hele tiden. For mange apper er «oppdater når brukeren kommer tilbake til fanen» nok.

Steg 3: Velg riktig størrelse på serveren

Større maskiner koster mer per time. Mange AI-bygde apper starter på en standardstørrelse som er fin; problemene kommer når man ber om «mer kraft» for å fikse treghet som egentlig var en treg spørring.

• Behold den minste størrelsen som betjener trafikken din uten feil.
• Ved minnekrasj: spør først AI-en om appen laster for mye inn i minnet (en hel tabell i stedet for én side med resultater).
• Legg bare til flere maskiner når du har målt trafikk som trenger dem.

På Mythex velges maskinstørrelsen ved publisering basert på hva appen trenger, og ekstra maskiner starter bare når trafikken er høy og går tilbake til søvn når den synker. Kostnaden følger størrelsen, så be om en mindre størrelse i chatten hvis du mener den er for stor.

Steg 4: Reduser båndbredden

Båndbredde er det besøkende laster ned. Bilder er vanligvis den største delen.

• Komprimer bilder og bruk moderne formater som WebP eller AVIF.
• Endre størrelsen på bilder til den størrelsen de vises i. Et bilde på 4000 piksler vist som en miniatyr på 400 piksler kaster bort det meste av det som lastes ned.
• Lazy-load bilder under synlig område.
• Cache statiske filer (skript, stiler, bilder) slik at tilbakevendende besøkende ikke laster dem ned på nytt. Se hva caching er.
• Ikke la appen dele ut store filer ved hver sidevisning.

Sjekk hvert bilde i appen. Endre størrelsen til den største størrelsen de vises i, konverter dem til WebP, og lazy-load alt under første skjermbilde. Fortell meg total størrelse før og etter.

Raskere sider og lavere båndbredde går vanligvis hånd i hånd. Se slik gjør du nettstedet ditt raskere.

Steg 5: Rydd opp i det ingen bruker

• Avpubliser gamle apper — testdeployeringer, avsluttede eksperimenter, fjorårets eventside.
• Slett gamle opplastinger, logger og eksporter du ikke trenger.
• Slett delte forhåndsvisningslenker du ikke bruker lenger. På Mythex vekker en åpnet forhåndsvisningslenke prosjektet og bruker kreditter, så en glemt lenke som noen fortsetter å åpne, koster fortsatt.
• Fjern ubrukte tjenester — en API-server eller arbeidsprosess som appen ikke lenger kaller.

Steg 6: Vurder en statisk side

Hvis nettstedet ditt ikke har innlogging, ingen lagrede brukerdata og ingen serverlogikk — en markedsføringsside, en portefølje, en meny — kan det være en statisk side: vanlige filer servert fra et CDN. Det finnes ingen server eller database som må kjøre. På Mythex bruker statiske sider ikke kreditter mens de ligger der.

Denne siden har ingen innlogging eller lagrede data. Kan den bygges om til en statisk side uten server? Hva ville vi miste?

Steg 7: Hold øye med betalte API-kall

For apper som kaller AI-modeller, kart eller SMS, kan tredjepartsregninger overgå hostingen i størrelse.

• Krev innlogging for alt som koster penger per kall.
• Legg til en grense per bruker (se hva rate limiting er).
• Cache svar som ikke endrer seg, for eksempel geokoding av samme adresse.
• Sett utgiftstak eller varsler hos hver leverandør.

Vanlige feil

• Gjette i stedet for å måle. Sjekk bruksfordelingen først; den dyre delen er ofte ikke det du ville tippet.
• Kjøpe en større server for å fikse treghet. En manglende databaseindeks eller for mye innlastet data er vanligvis den egentlige årsaken.
• Polle alt. Hver timer som går hvert par sekund er en grunn til at databasen holder seg våken.
• Pinge appen for å holde den «varm». Det fjerner besparelsen skalering til null gir deg. Godta et kort oppvåkningsforsøk ved første besøk, eller betal bevisst for alltid-på.
• Å glemme gamle deployeringer. Ubrukte apper med databaser og bakgrunnsjobber legger seg stille opp.
• Ukomprimerte bilder. Ofte den enkeltstørste båndbreddekostnaden på små nettsteder.

Sjekkliste

• Jeg vet hvilket prosjekt og hvilken kategori (beregning, database, båndbredde, lagring) som koster mest.
• Ingenting spør databasen hvert par sekund når ingen ser på.
• Dashbord oppdateres med et fornuftig intervall, eller bare mens fanen er synlig.
• Ingen oppetidsmonitor eller bakgrunnsløkke holder appen våken uten grunn.
• Serveren er den minste størrelsen som fungerer.
• Bilder er endret i størrelse, komprimert og lazy-loaded; statiske filer er cachet.
• Gamle apper er avpublisert, gamle filer slettet og ubrukte forhåndsvisningslenker fjernet.
• Sider uten data eller innlogging er statiske.
• Betalte API-er har innlogging, grenser per bruker og varsler om utgifter hos leverandøren.

Redusere kostnader på Mythex

Mythex bruker én kredittbeholdning til både bygging og hosting, så hostingbesparelser gir flere kreditter til bygging. Noen Mythex-spesifikke punkter:

• Publiserte apper og databasene deres sover når de er inaktive og våkner ved neste besøk. Databasen sover etter 5 minutter uten aktivitet, så å fjerne konstant polling er vanligvis den største gevinsten.
• Pro betaler halvparten av Free-prisen for hosting, databaser, båndbredde, fillagring og forhåndsvisningssandkassen; AI koster det samme på begge planene. Se Kreditter.
• Du får en e-post før en lav saldo ville pause en publisert app, og pausede apper beholder databasen og filene sine.

For det større bildet på driftskostnader, se hva det koster å bygge en app og hva webhosting er.

Spørsmål