SSG vs SSR vs CSR
Penjelasan perbedaan static site generation, server-side rendering, dan client-side rendering — beserta ISR dan mode hibrida, dan cara memilih untuk tiap halaman.
Tiga singkatan ini menjawab satu pertanyaan: kapan HTML halamanmu dibuat?
| Mode | HTML dibuat | Oleh |
|---|---|---|
| SSG | Saat build, sebelum ada yang berkunjung | Komputer build |
| SSR | Saat halaman diminta | Server |
| CSR | Setelah halaman termuat | Browser pengunjung |
Itu inti seluruh perbedaannya. Sisanya adalah konsekuensi.
SSG — dirender saat build
Semua halaman dirender jadi berkas HTML saat kamu menjalankan npm run build. Hasilnya diunggah ke CDN, dan pengunjung menerima berkas jadi.
Kelebihannya: paling cepat yang mungkin — tidak ada yang dihitung saat pengunjung datang, cuma berkas dikirim dari lokasi terdekat. Paling murah, karena tidak ada server yang berjalan. Paling sedikit yang bisa rusak. Dan paling ramah mesin pencari, karena isinya sudah ada di HTML sejak awal.
Kekurangannya: setiap perubahan isi butuh build ulang. Untuk situs 100 halaman itu hitungan detik. Untuk 50.000 halaman, build-nya bisa berpuluh menit.
Cocok untuk: blog, dokumentasi, landing page, portofolio, situs perusahaan — semua yang isinya sama untuk setiap pengunjung.
SSR — dirender saat diminta
Tiap kali ada permintaan, server menjalankan kodemu, mengambil data terbaru, dan menyusun HTML saat itu juga.
Kelebihannya: isinya selalu mutakhir, dan bisa berbeda untuk tiap pengunjung — dasbor yang menampilkan data pribadi, harga yang berubah tiap menit, halaman di balik login. Mesin pencari tetap menerima HTML yang lengkap.
Kekurangannya: lebih lambat, karena pengunjung menunggu server bekerja. Lebih mahal, karena tiap kunjungan memanggil function. Dan lebih banyak yang bisa rusak — kalau databasemu lambat, situsmu ikut lambat.
Cocok untuk: halaman yang isinya bergantung pada siapa yang membuka, atau data yang berubah dalam hitungan detik.
CSR — dirender di browser
Server mengirim HTML nyaris kosong plus berkas JavaScript. Browser menjalankan JavaScript itu, mengambil data, lalu menyusun halamannya sendiri.
Ini yang dilakukan aplikasi React atau Vue biasa tanpa framework tambahan.
Kelebihannya: setelah termuat, perpindahan antar halaman terasa instan — tidak ada permintaan halaman penuh lagi. Servernya sesederhana mungkin: cuma berkas statis.
Kekurangannya: tampilan pertama paling lambat, karena pengunjung menunggu JavaScript diunduh dan dijalankan sebelum melihat apa pun. Dan untuk mesin pencari, ini yang paling berisiko.
Google memang menjalankan JavaScript saat merayapi halaman, jadi situs CSR bisa terindeks. Tapi prosesnya tertunda dan tidak dijamin — dan mesin pencari lain, serta perayap AI, sering tidak menjalankan JavaScript sama sekali. Kalau kamu bergantung pada trafik pencarian, jangan pilih CSR.
Cocok untuk: aplikasi di balik login — dasbor admin, alat internal, papan kerja. Halaman yang memang tidak perlu ditemukan mesin pencari.
ISR — jalan tengah yang paling sering benar
Incremental Static Regeneration menggabungkan yang terbaik dari SSG dan SSR: halaman disajikan dari cache seperti berkas statis, tapi dibangun ulang secara berkala di latar belakang.
// Next.js
export const revalidate = 600;// Nuxt
routeRules: {
'/blog/**': { isr: 600 }
}Pengunjung selalu mendapat respons instan dari cache. Servermu hanya bekerja sesekali, bukan tiap kunjungan.
Untuk sebagian besar situs berbasis konten yang datanya berubah — toko, portal berita, blog dengan CMS — ini biasanya jawaban yang benar, bukan SSR penuh. Banyak orang memilih SSR padahal yang mereka butuhkan cuma ISR, lalu membayar biaya function untuk halaman yang isinya sama sepanjang jam.
Kamu tidak harus memilih satu untuk seluruh situs
Ini yang paling sering disalahpahami. Framework modern membiarkan kamu menentukan mode per halaman.
Situs toko yang wajar kira-kira begini:
| Halaman | Mode | Alasan |
|---|---|---|
| Beranda | SSG | Jarang berubah, harus cepat |
| Tentang, kontak | SSG | Nyaris tidak pernah berubah |
| Daftar produk | ISR | Berubah, tapi tidak tiap detik |
| Detail produk | ISR | Sama |
| Keranjang belanja | CSR | Khas tiap pengguna, tidak perlu diindeks |
| Riwayat pesanan | SSR | Di balik login, data pribadi |
Aturan praktisnya satu kalimat: pakai mode paling statis yang masih memenuhi kebutuhan halaman itu.
Cara memutuskan
Untuk tiap halaman, jawab berurutan:
- Apakah isinya sama untuk semua pengunjung? Kalau tidak — SSR atau CSR.
- Kalau sama, seberapa sering berubah?
- Jarang, dan build ulang tidak masalah → SSG
- Sering, tapi telat beberapa menit tidak apa-apa → ISR
- Harus mutakhir tiap detik → SSR
- Perlu ditemukan mesin pencari? Kalau ya, hindari CSR.
Cara mengecek mode halamanmu sekarang
Jangan menebak. Ada dua cara memastikannya.
Lihat sumber halaman. Klik kanan lalu View Page Source — bukan Inspect, karena Inspect menampilkan hasil setelah JavaScript berjalan. Kalau isi artikelmu ada di situ, halamanmu SSG, ISR, atau SSR. Kalau yang terlihat cuma <div id="root"></div>, itu CSR.
curl -s https://situsku.com/ | grep -c "kata-dari-artikelmu"Hasil 0 berarti isinya tidak ada di HTML awal.
Baca keluaran build. Next.js mencetak tabel mode tiap rute setelah npm run build. Di situ ketahuan kalau ada halaman yang kamu kira statis ternyata dinamis.
Ringkasan
| SSG | ISR | SSR | CSR | |
|---|---|---|---|---|
| Kecepatan tampil pertama | Terbaik | Terbaik | Sedang | Paling lambat |
| Kesegaran data | Saat build | Berkala | Selalu | Selalu |
| Biaya per kunjungan | Nol | Nyaris nol | Satu function | Nol |
| Ramah mesin pencari | Ya | Ya | Ya | Berisiko |
| Isi per pengguna | Tidak | Tidak | Ya | Ya |
Untuk memahami arsitektur yang membuat SSG jadi pilihan utama, lihat apa itu Jamstack. Untuk dampaknya pada kecepatan yang diukur Google, lihat optimasi Core Web Vitals di situs statis.