Apa Itu Jamstack
Penjelasan Jamstack: apa yang membedakannya dari WordPress dan hosting tradisional, kenapa lebih cepat dan lebih aman, serta kapan arsitektur ini tidak cocok.
Jamstack adalah cara membangun situs di mana halaman disiapkan lebih dulu dan disajikan langsung dari CDN, bukan dirakit oleh server tiap kali ada yang berkunjung.
Kalau kamu pernah bertanya kenapa satu situs terbuka seketika sementara yang lain butuh tiga detik memuat halaman yang isinya sama — sering kali inilah jawabannya.
Perbandingan yang membuatnya jelas
Bayangkan sebuah blog. Isi artikelnya sama untuk semua pembaca.
Cara tradisional
Setiap kali ada orang membuka artikel, server bangun dan bekerja: menerima permintaan, menjalankan kode PHP, membuka koneksi ke database, mengambil isi artikel, mengambil komentar, mengambil menu, menyusun semuanya jadi HTML, lalu mengirimkannya.
Seribu pengunjung berarti seribu kali pekerjaan yang sama persis, menghasilkan halaman yang identik.
Cara Jamstack
Saat kamu menerbitkan artikel, halaman HTML-nya dibuat satu kali, lalu disalin ke server-server di seluruh dunia. Setiap pengunjung menerima berkas jadi dari lokasi terdekat.
Seribu pengunjung berarti seribu kali mengirim berkas — pekerjaan yang jauh lebih ringan daripada menyusunnya ulang.
Cara tradisional seperti restoran yang memasak tiap pesanan dari nol saat pelanggan datang. Jamstack seperti toko roti yang memanggang pagi hari — pembeli tinggal ambil. Untuk pesanan yang selalu sama, cara kedua jelas lebih masuk akal.
Dari mana nama itu
JAM adalah singkatan dari JavaScript, API, dan Markup. Awalnya istilah ini dipakai untuk menekankan bahwa situs dibangun dari markup yang sudah jadi, ditambah JavaScript di browser untuk hal-hal interaktif, dan API eksternal untuk data.
Sekarang singkatannya kurang penting dan jarang dijabarkan lagi. Yang tersisa dan tetap relevan adalah prinsipnya: siapkan lebih dulu, sajikan dari edge, jangan menghitung ulang hal yang sama berkali-kali.
Kenapa lebih cepat
Tiga alasan, dan ketiganya bekerja bersamaan.
Tidak ada yang dihitung saat pengunjung datang
Waktu antara permintaan dan byte pertama tiba — TTFB — adalah bagian yang paling sulit diperbaiki di situs tradisional, karena di situlah server bekerja. Di situs statis, bagian itu hampir hilang. Berkasnya sudah ada, tinggal dikirim.
Berkasnya dekat dengan pengunjung
Situs tradisional biasanya hidup di satu server, di satu kota. Pengunjung dari Jakarta yang membuka situs yang server-nya di Virginia harus menunggu data menyeberangi Pasifik — beberapa kali, karena tiap permintaan bolak-balik.
Situs statis disalin ke puluhan lokasi. Pengunjung Jakarta dilayani dari Singapura atau Jakarta sendiri. Penjelasan mekanismenya ada di apa itu CDN dan edge network.
Lonjakan lalu lintas tidak menjatuhkannya
Situs tradisional punya titik jenuh: sekian permintaan per detik, lalu database-nya kewalahan. Kalau artikelmu tiba-tiba ramai, situsmu justru mati saat paling dibutuhkan.
CDN menyajikan berkas statis, dan itu pekerjaan yang skalanya nyaris tak terbatas. Lonjakan seratus kali lipat tidak mengubah apa pun.
Kenapa lebih aman
Ini keuntungan yang jarang disebut padahal besar.
Situs WordPress punya banyak permukaan yang bisa diserang: PHP yang berjalan di server, database yang menerima query, halaman login admin yang terbuka ke publik, dan plugin yang tiap satunya bisa punya celah.
Situs statis tidak punya satu pun dari itu. Tidak ada database untuk di-SQL-inject. Tidak ada halaman login untuk dibobol. Tidak ada kode server untuk dieksploitasi. Yang ada cuma berkas HTML.
Ini bukan berarti kebal — kalau akun Git-mu dibobol, orang bisa mengubah situsmu. Tapi permukaan seranganmu jauh lebih kecil, dan kamu tidak perlu memantau pembaruan keamanan mingguan.
Lalu bagaimana dengan yang dinamis?
Ini keberatan yang paling sering muncul, dan wajar: kalau semuanya statis, bagaimana dengan form, komentar, pencarian, atau login?
Jawabannya: bagian dinamis dipindahkan, bukan dihilangkan.
| Kebutuhan | Ditangani oleh |
|---|---|
| Form kontak | Layanan form bawaan platform |
| Komentar | Layanan komentar pihak ketiga |
| Pencarian | Indeks di sisi klien, atau layanan pencarian |
| Pembayaran | Penyedia pembayaran |
| Login dan data pengguna | Serverless function |
| Isi yang sering berubah | ISR — dibangun ulang berkala |
Serverless function adalah kunci yang membuat ini bekerja. Kamu tetap bisa menjalankan kode server — memanggil database, menyembunyikan kunci API, mengirim email — tapi hanya untuk bagian yang benar-benar membutuhkannya. Sisa situsmu tetap statis.
Bedanya dengan server tradisional: function hanya hidup selama permintaan diproses, lalu mati. Tidak ada yang perlu kamu jaga tetap menyala. Penjelasannya ada di serverless vs edge functions.
Kalau isinya berubah, apa harus build ulang terus?
Dulu ya, dan itu kelemahan nyata Jamstack generasi pertama. Toko dengan 10.000 produk yang harus build ulang tiap kali satu harga berubah jelas tidak masuk akal.
Sekarang ada ISR — halaman disajikan dari cache, lalu dibangun ulang secara berkala di latar belakang, hanya halaman yang diminta.
// Next.js: bangun ulang paling cepat tiap 10 menit
export const revalidate = 600;
Pengunjung tetap mendapat respons instan dari cache. Isinya tetap segar. Dan kamu tidak perlu build ulang seluruh situs. Untuk sebagian besar situs berbasis konten, ini biasanya pilihan yang benar — bukan statis murni, bukan juga dinamis penuh.
Kapan Jamstack tidak cocok
Arsitektur ini bukan jawaban untuk segalanya, dan memaksakannya bisa lebih mahal daripada memakai cara lama.
- Hampir semua halaman berbeda per pengguna. Aplikasi perbankan, jejaring sosial, dasbor internal — kalau tidak ada yang bisa di-cache, keuntungan utamanya hilang.
- Data harus akurat detik itu juga. Papan harga saham, sisa kursi penerbangan. Cache selama sepuluh detik pun bisa jadi masalah.
- Timmu terbiasa dengan CMS tradisional dan tidak ingin berubah. Ini alasan yang sah. Alur kerja yang dikuasai tim lebih berharga daripada arsitektur yang secara teori lebih unggul.
- Situsnya kecil dan sudah jalan baik. Blog WordPress dengan 200 pembaca sebulan tidak akan jadi lebih baik hanya karena dipindah. Migrasi itu pekerjaan; pastikan ada yang benar-benar dipecahkan.
Perbandingan dengan WordPress
| Jamstack | WordPress tradisional | |
|---|---|---|
| Halaman disusun | Saat build | Tiap permintaan |
| Disajikan dari | CDN global | Satu server |
| Database | Tidak ada di jalur sajian | Diakses tiap kunjungan |
| Permukaan serangan | Sangat kecil | PHP, database, plugin, admin |
| Tahan lonjakan | Nyaris tak terbatas | Terbatas |
| Biaya hosting | Sering gratis | Bulanan |
| Pemeliharaan | Nyaris tidak ada | Pembaruan rutin |
| Kemudahan menulis | Perlu penyiapan | Editor bawaan, langsung pakai |
| Ekosistem plugin | Terbatas | Sangat luas |
Dua baris terakhir itu keunggulan nyata WordPress, dan sering menjadi alasan yang menentukan. Perbandingan dari sisi hostingnya ada di hosting statis vs shared hosting cPanel.
Cara mencobanya
Kalau kamu ingin merasakan bedanya sendiri, jalur tercepat:
- Pilih generator. Astro paling ramah kalau kamu datang dari HTML biasa. Hugo paling cepat. Eleventy paling sederhana konsepnya.
- Tulis beberapa halaman dalam Markdown.
- Push ke Git, hubungkan ke platform deploy. Lihat panduan lengkap deploy website.
- Bandingkan waktu muatnya dengan situs lamamu.
Satu sore biasanya cukup untuk situs kecil.
Ringkasan
Jamstack artinya menyiapkan halaman lebih dulu dan menyajikannya dari CDN, alih-alih menyusunnya ulang tiap kunjungan. Hasilnya lebih cepat, lebih aman, lebih murah, dan tahan lonjakan.
Bagian dinamis tidak hilang — ia dipindahkan ke serverless function dan layanan khusus, dan dipakai hanya di tempat yang memang membutuhkannya.
Ia tidak cocok kalau hampir semua halamanmu berbeda per pengguna, atau datamu harus akurat detik itu juga. Untuk sisanya — yaitu mayoritas situs — ini arsitektur yang lebih masuk akal.
Langkah berikutnya: pahami mode rendering supaya kamu bisa memilih per halaman, lalu pilih hostingnya.