Klien saya kebanyakan datang dengan satu masalah yang sama: mereka butuh situs yang menjelaskan apa yang mereka jual, punya beberapa halaman, dan bisa dibuka cepat dari HP. Delapan halaman. Kadang sepuluh. Isinya teks, beberapa gambar, satu formulir kontak, dan tombol WhatsApp.
Untuk kebutuhan seperti itu, saya sekarang hampir selalu memilih Astro. Bukan karena Astro sedang naik daun, tapi karena setiap alternatif yang saya pertimbangkan membawa sesuatu yang tidak dibutuhkan proyek ini.
Masalah dengan default yang “modern”
Kalau saya membuka diskusi framework hari ini, pilihan default yang muncul biasanya Next.js. Dan Next.js memang bagus — saya pakai di proyek lain. Tapi untuk situs katalog layanan delapan halaman, ada beberapa hal yang harus saya terima sebagai konsekuensi.
Pertama, JavaScript. Situs marketing isinya 95% teks. Teks tidak butuh React untuk tampil. Tapi begitu saya memilih framework berbasis komponen, saya membawa runtime, hydration, dan bundel yang harus diunduh sebelum halaman bisa interaktif. Di jaringan 4G yang tidak stabil — dan sebagian besar pengunjung situs klien saya pakai 4G — itu ongkos nyata, bukan teori.
Kedua, server. Next.js dengan SSR butuh proses Node yang hidup dua puluh empat jam. Itu berarti satu service yang harus dipantau, di-restart kalau mati, di-update kalau ada celah keamanan, dan dibayar tiap bulan walaupun tidak ada yang membuka situs jam tiga pagi.
Ketiga, permukaan serang. Setiap proses yang hidup adalah pintu. Setiap dependency adalah kode orang lain yang jalan di server saya. Untuk situs yang isinya tidak berubah setiap hari, itu risiko yang tidak menghasilkan apa-apa.
Apa yang Astro berikan
Astro membalik default-nya: nol JavaScript di client, kecuali kamu minta.
Komponen .astro dirender jadi HTML saat build, lalu selesai. Tidak ada
runtime yang dikirim ke browser. Kalau saya butuh interaktif — toggle tema,
command palette, pencarian — saya tulis JavaScript seperlunya, dan hanya itu
yang dikirim.
Hasilnya, halaman yang saya bangun untuk Argus Studio keluar sebagai HTML biasa dengan bundel CSS kecil dan beberapa kilobyte skrip. Tidak ada hidrasi. Tidak ada layout shift dari komponen yang muncul belakangan. Halaman selesai dimuat saat HTML-nya selesai di-parse.
Astro juga punya astro:assets yang menangani optimasi gambar saat build:
setiap gambar saya konversi ke webp dengan beberapa ukuran, srcset dibuat
otomatis, dan width/height diisi eksplisit supaya tidak ada pergeseran
layout. Untuk situs yang isinya banyak foto — seperti situs tour and travel —
ini menghilangkan satu kelas bug yang biasanya saya tangani manual.
Biaya hosting yang mendekati nol
Karena output-nya file statis, hosting-nya bisa apa saja yang bisa menyajikan file: nginx, object storage, CDN. Tidak ada proses yang harus hidup.
Situs yang saya kelola jalan di satu container nginx di VPS yang sudah ada.
Build-nya jalan sekali saat deploy, hasilnya satu folder dist. Kalau
container-nya mati, tidak ada yang perlu di-restart secara khusus — cukup
hidupkan lagi. Kalau trafiknya naik sepuluh kali, tidak ada yang perlu
di-scale, karena menyajikan file statis itu pekerjaan paling murah yang bisa
dilakukan server.
Bandingkan dengan SSR: biaya hosting ikut jumlah request, dan biaya pemeliharaan ikut jumlah waktu. Untuk klien yang bayarnya sekali di awal, model statis jauh lebih jujur.
Keamanan yang lebih sederhana
Situs statis punya satu kelas kerentanan yang hilang sepenuhnya: tidak ada server aplikasi yang bisa disusupi. Tidak ada endpoint API yang bisa dienumerasi, tidak ada sesi yang bisa dicuri dari cookie yang salah konfigurasi, tidak ada dependency Node di server yang perlu di-patch tiap minggu.
Ini bukan berarti situsnya mustahil diserang — XSS lewat konten tetap mungkin, dan formulir kontak tetap butuh backend. Tapi permukaannya jauh lebih kecil, dan yang paling penting: tidak ada yang bisa saya lupakan untuk di-update. Situs statis yang saya deploy dua tahun lalu tidak akan tiba-tiba punya celah baru karena satu paket npm di server saya ketinggalan versi.
Kapan saya tidak pakai Astro
Supaya ini tidak jadi iklan, ada kondisi di mana saya meninggalkannya.
Kalau aplikasinya butuh state yang rumit di client — dashboard dengan filter bertumpuk, editor, kolaborasi real-time — Astro tetap bisa, tapi saya harus menambahkan pulau-pulau interaktif, dan pada titik tertentu saya cuma menulis aplikasi SPA di dalam shell statis. Di situ Next.js atau Remix lebih masuk akal.
Kalau butuh autentikasi dan data per pengguna yang dirender server, SSR jadi kebutuhan, bukan pilihan.
Tapi untuk situs marketing delapan halaman? Menambahkan framework aplikasi di atasnya bukan keputusan arsitektur, itu kebiasaan.
Yang saya cari dari sebuah pilihan teknis
Saya menilai pilihan teknis dari seberapa banyak hal yang tidak perlu saya urus setelahnya. Astro untuk situs klien menang karena menghapus banyak hal sekaligus: tidak ada runtime, tidak ada server, tidak ada proses yang harus hidup, tidak ada dependency yang menua diam-diam.
Situsnya cepat karena tidak ada yang perlu dijalankan, bukan karena saya mengoptimalkan sesuatu dengan susah payah. Itu jenis kemenangan yang saya sukai — datang dari arsitektur, bukan dari kerja lembur.
Yang biasanya ditanyakan
“Kalau butuh interaktif, harus pindah framework?” Tidak. Astro punya mekanisme pulau: satu komponen bisa dibuat interaktif dengan React, Vue, atau Svelte, sementara sisa halaman tetap HTML statis. Saya pernah memakai ini untuk satu form pencarian. Yang dikirim ke browser hanya JavaScript untuk pulau itu, bukan seluruh halaman.
“Bagaimana kalau klien mau edit sendiri?” Ini pertanyaan yang paling sering muncul dan paling sering dijawab salah. Banyak yang langsung menyarankan CMS berbasis database seperti WordPress atau Strapi. Untuk situs delapan halaman, itu berarti menambah satu service yang harus hidup terus, satu database yang harus di-backup, dan satu panel admin yang harus diamankan.
Pendekatan yang saya pilih: konten disimpan sebagai file Markdown di repo, dan klien mengeditnya lewat panel berbasis git. Hasil edit jadi commit, build jalan otomatis, situs ter-update. Klien tetap mendapat form di browser — tidak menyentuh kode sama sekali — tapi tidak ada database yang perlu dirawat. Riwayat perubahan juga gratis, karena git sudah menyimpannya.
“Kalau kontennya sering berubah, build ulang terus?” Build situs ini selesai dalam hitungan detik, dan deploy-nya incremental. Untuk volume perubahan yang wajar di situs marketing, tidak ada masalah. Kalau kontennya berubah ratusan kali sehari, itu bukan situs marketing lagi — itu aplikasi, dan saya akan memilih arsitektur yang lain.
Satu hal yang saya korbankan
Supaya jelas: saya kehilangan beberapa hal yang framework aplikasi berikan gratis.
Tidak ada API routes bawaan, jadi setiap kebutuhan backend — formulir kontak, pengiriman email, integrasi pembayaran — harus jadi service terpisah. Tidak ada middleware untuk redirect dinamis; kalau butuh aturan redirect yang rumit, saya harus menuliskannya di konfigurasi server. Tidak ada ISR atau revalidasi on-demand; setiap perubahan konten berarti build ulang.
Untuk situs marketing, ketiga hal itu jarang jadi masalah. Tapi saya perlu tahu batasnya sebelum menerima proyek, bukan setelah dua minggu berjalan. Kalau sejak awal klien bilang “nanti mau ada login member dan dashboard”, saya tidak memilih Astro untuk itu.
Kesimpulan yang bisa dibawa
Pilih arsitektur berdasarkan apa yang tidak perlu kamu urus setelah deploy. Untuk situs yang isinya teks dan gambar, daftar itu panjang: tidak ada runtime, tidak ada server, tidak ada database, tidak ada proses yang bisa mati jam tiga pagi.
Astro bukan jawaban untuk semua orang. Tapi untuk delapan halaman marketing, menambahkan framework aplikasi di atasnya bukan keputusan arsitektur — itu kebiasaan yang tidak pernah diuji ulang.