Cara Mengurangi Biaya Hosting untuk Aplikasimu

Untuk mengurangi biaya hosting, cari tahu apa yang sebenarnya berjalan dan kenapa, lalu biarkan semuanya tidur saat tidak ada yang memakainya. Di host yang scale to zero, aplikasi yang idle dan database yang tidur hampir tidak memakan biaya, jadi penghematan terbesar biasanya datang dari menghapus apa pun yang membuatnya tetap terjaga, paling sering kode yang memeriksa database setiap beberapa detik, lalu dari memperkecil bandwidth dan menghapus aplikasi yang tidak dipakai.

Kebanyakan aplikasi kecil tidak punya masalah trafik. Mereka punya masalah “selalu menyala”. Panduan ini menunjukkan cara menemukan dan memperbaikinya, dengan prompt yang bisa kamu berikan kepada pembuat aplikasi AI.

Apa yang sebenarnya kamu bayar

Tagihan hosting untuk aplikasi kecil berasal dari beberapa hal. Mengetahui mana yang besar akan menunjukkan ke mana kamu harus melihat.

Banyak host modern, termasuk Mythex, scale to zero: ketika tidak ada yang memakai aplikasi, server berhenti dan tidak memakan biaya compute, lalu bangun saat kunjungan berikutnya. Itu mengubah pertanyaannya dari “seberapa besar server saya?” menjadi “kenapa server saya terus terjaga?”

Langkah 1: Lihat ke mana uangmu pergi

Sebelum mengubah apa pun, buka halaman penggunaan host kamu dan cari tahu:

• Proyek mana yang paling mahal. Sering kali satu aplikasi menyumbang sebagian besar tagihan.
• Kategori mana: compute, database, bandwidth, atau storage.
• Kapan biaya itu muncul. Garis datar sepanjang malam, saat tidak ada pengguna, adalah petunjuk bahwa ada sesuatu yang membuat aplikasi tetap terjaga.

Di Mythex, Usage details menampilkan 30 hari terakhir yang dibagi menjadi Build (agent AI) dan Run (hosting, bandwidth, database, dan penyimpanan file), dengan rincian per proyek.

Langkah 2: Biarkan aplikasi dan database idle tidur

Ini adalah tuas utama untuk sebagian besar aplikasi kecil. Database yang tidur saat idle dan bangun saat ada permintaan hampir tidak memakan biaya di jam sepi. Database yang diquery setiap beberapa detik tidak pernah idle, jadi kamu membayarnya sepanjang hari.

Batasan hosting Mythex untuk hosting limits menjelaskan cara kerjanya untuk aplikasi publish: aplikasi yang tidur tidak memakan biaya compute, database dimulai dari ukuran terkecil, tumbuh saat sibuk, tidur setelah 5 menit idle, dan ditagih sesuai ukuran dikali waktu ia terjaga. Jadi aplikasi yang mengquery databasenya bahkan sekali setiap beberapa menit, siang dan malam, ditagih seolah-olah selalu sibuk, sedangkan aplikasi yang sama tanpa aktivitas latar belakang yang tidak perlu biayanya sangat kecil.

Hal-hal umum yang membuat aplikasi tetap terjaga:

• Polling. Halaman yang bertanya ke server “ada yang baru?” setiap 2–5 detik. Biarkan tab itu terbuka di satu laptop dan database tidak pernah tidur.
• Dashboard yang refresh otomatis dan memuat ulang data pada timer, meski tidak ada yang melihatnya.
• Monitor uptime yang melakukan ping ke aplikasi setiap menit.
• Loop latar belakang di kode server, misalnya setInterval yang membersihkan atau menyinkronkan data tanpa henti.
• Permintaan “keep-alive” terjadwal yang seseorang tambahkan untuk menghindari kunjungan pertama yang lambat. Cara kerjanya adalah mencegah tidur, dan itulah yang sebenarnya membuat biaya.

Minta AI untuk mencarinya:

Cari di kode apa pun yang berjalan pada timer atau terus-menerus mengquery database: polling, setInterval, auto-refresh, loop latar belakang. Daftar setiap item, seberapa sering ia berjalan, dan apakah ia tetap berjalan saat tidak ada yang membuka halaman. Jangan ubah apa pun dulu.

Lalu perbaiki satu per satu:

Dashboard melakukan polling ke /api/orders setiap 3 detik. Ubah agar hanya refresh saat tab browser terlihat, dan setiap 60 detik alih-alih 3. Tambahkan tombol Refresh manual.

Jika aplikasimu benar-benar membutuhkan update langsung (chat, skor langsung), tanyakan apakah update bisa didorong hanya saat ada perubahan, alih-alih terus bertanya. Untuk banyak aplikasi, “refresh saat pengguna kembali ke tab” sudah cukup.

Langkah 3: Sesuaikan ukuran server

Mesin yang lebih besar memakan biaya lebih per jam. Banyak aplikasi yang dibuat dengan AI mulai dari ukuran default yang sudah cukup; masalahnya muncul ketika orang meminta “lebih banyak tenaga” untuk memperbaiki kelambatan yang sebenarnya disebabkan oleh query yang lambat.

• Pertahankan ukuran terkecil yang melayani trafikmu tanpa error.
• Jika muncul crash karena memori, tanyakan dulu ke AI apakah aplikasi memuat terlalu banyak data ke memori (misalnya seluruh tabel alih-alih satu halaman hasil).
• Tambah mesin hanya jika kamu punya trafik terukur yang membutuhkannya.

Di Mythex, ukuran mesin dipilih saat publish berdasarkan kebutuhan aplikasi, dan mesin tambahan hanya dimulai saat trafik sedang tinggi lalu kembali tidur ketika trafik turun. Biaya mengikuti ukuran, jadi tanyakan di chat untuk ukuran yang lebih kecil jika kamu rasa ukurannya terlalu besar.

Langkah 4: Kurangi bandwidth

Bandwidth adalah data yang diunduh pengunjung. Gambar biasanya bagian terbesarnya.

• Kompres gambar dan sajikan format modern seperti WebP atau AVIF.
• Ubah ukuran gambar sesuai ukuran tampilannya. Foto 4.000 piksel yang ditampilkan sebagai thumbnail 400 piksel membuang sebagian besar data yang diunduh.
• Lazy-load gambar di bawah area layar pertama.
• Cache file statis (script, style, gambar) agar pengunjung yang kembali tidak mengunduhnya lagi. Lihat apa itu caching.
• Jangan biarkan aplikasi memberikan file besar di setiap tampilan halaman.

Periksa setiap gambar di aplikasi. Ubah ukurannya ke ukuran terbesar yang ditampilkan, ubah ke WebP, dan lazy-load semua yang berada di bawah layar pertama. Beri tahu saya total ukurannya sebelum dan sesudah.

Kecepatan halaman yang lebih baik dan bandwidth yang lebih rendah biasanya berjalan bersama. Lihat cara membuat website lebih cepat.

Langkah 5: Bersihkan yang tidak dipakai siapa pun

• Unpublish aplikasi lama: deployment uji coba, eksperimen yang sudah selesai, situs acara tahun lalu.
• Hapus upload, log, dan ekspor lama yang tidak kamu perlukan.
• Hapus tautan preview bersama yang tidak kamu pakai lagi. Di Mythex, membuka tautan preview membangunkan proyek dan berjalan dengan kredit kamu, jadi tautan yang terlupakan dan terus dibuka orang tetap memakan biaya.
• Hapus layanan yang tidak dipakai, misalnya server API atau worker yang tidak lagi dipanggil aplikasi.

Langkah 6: Pertimbangkan situs statis

Jika situsmu tidak punya login, tidak menyimpan data pengguna, dan tidak punya logika server (misalnya situs pemasaran, portofolio, atau menu), ia bisa menjadi situs statis: file biasa yang disajikan dari CDN. Tidak ada server atau database yang harus terus berjalan. Di Mythex, situs statis tidak memakai kredit saat diam.

Situs ini tidak punya login atau data tersimpan. Bisakah dibangun ulang sebagai situs statis tanpa server? Apa yang akan hilang?

Langkah 7: Awasi panggilan API berbayar

Untuk aplikasi yang memanggil model AI, peta, atau SMS, tagihan pihak ketiga bisa jauh lebih besar daripada hosting.

• Wajibkan login untuk apa pun yang berbiaya per panggilan.
• Tambahkan batas per pengguna (lihat apa itu rate limiting).
• Cache jawaban yang tidak berubah, misalnya geocoding alamat yang sama.
• Atur batas pengeluaran atau notifikasi di setiap penyedia.

Kesalahan umum

• Menebak alih-alih mengukur. Periksa rincian penggunaan dulu; bagian yang mahal sering kali bukan yang kamu kira.
• Membeli server lebih besar untuk memperbaiki kelambatan. Index database yang hilang atau memuat terlalu banyak data biasanya penyebab sebenarnya.
• Melakukan polling untuk semuanya. Setiap timer beberapa detik adalah alasan database tetap terjaga.
• Melakukan ping ke aplikasi agar tetap “hangat”. Itu menghilangkan penghematan yang diberikan scale-to-zero. Terima sedikit jeda saat kunjungan pertama, atau bayar untuk always-on secara sengaja.
• Melupakan deployment lama. Aplikasi yang tidak dipakai dengan database dan background job diam-diam menambah biaya.
• Gambar yang tidak dikompres. Sering kali ini menjadi biaya bandwidth terbesar di situs kecil.

Daftar periksa

• Saya tahu proyek dan kategori mana (compute, database, bandwidth, storage) yang paling mahal.
• Tidak ada yang melakukan polling ke database setiap beberapa detik saat tidak ada yang melihat.
• Dashboard refresh dengan interval yang masuk akal atau hanya saat tab terlihat.
• Tidak ada monitor uptime atau loop latar belakang yang membuat aplikasi tetap terjaga tanpa alasan.
• Server berukuran paling kecil yang tetap berfungsi.
• Gambar sudah diubah ukurannya, dikompres, dan di-lazy-load; file statis sudah di-cache.
• Aplikasi lama sudah di-unpublish, file lama dihapus, tautan preview yang tidak dipakai dihapus.
• Situs tanpa data atau login dibuat statis.
• API berbayar memiliki login, batas per pengguna, dan notifikasi pengeluaran dari penyedia.

Mengurangi biaya di Mythex

Mythex memakai satu saldo kredit untuk membangun dan hosting, jadi penghematan hosting menyisakan lebih banyak kredit untuk membangun. Beberapa poin khusus Mythex:

• Aplikasi publish dan database-nya tidur saat idle dan bangun saat kunjungan berikutnya. Database tidur setelah 5 menit idle, jadi menghapus polling terus-menerus biasanya menjadi kemenangan terbesar.
• Paket Pro membayar setengah tarif Free untuk hosting, database, bandwidth, penyimpanan file, dan preview sandbox; biaya AI sama di kedua paket. Lihat Credits.
• Kamu mendapat email sebelum saldo rendah bisa menjeda aplikasi publish, dan aplikasi yang dijeda tetap menyimpan database dan file-nya.

Untuk gambaran yang lebih besar tentang biaya operasional, lihat berapa biaya membangun aplikasi dan apa itu web hosting.

Pertanyaan