SSR vs Static: Panduan Memilih Strategi Render untuk Website Bisnis Indonesia

TL;DR: Server-Side Rendering (SSR) menghasilkan HTML setiap permintaan, sedangkan Static Site Generation (SSG) membuat HTML sekali saat build. Untuk website bisnis Indonesia, pilihan tergantung pada frekuensi update konten, anggaran infrastruktur, dan kebutuhan personalisasi. Mayoritas landing page dan situs marketing lebih cocok pakai SSG atau ISR, sedangkan dashboard dan e-commerce dinamis butuh SSR.

Dalam beberapa proyek terakhir, saya melihat tim marketing dan engineering sering berdebat soal pilihan render strategy tanpa kerangka yang jelas. Akibatnya, situs sederhana dijalankan dengan SSR penuh dan menghabiskan biaya server tidak perlu, atau e-commerce dipaksa SSG dan stok produk telat sinkron. Artikel ini memberi kerangka keputusan berbasis pengalaman menangani lebih dari 20 proyek web sejak 2018.

Konteksnya: di Next.js modern, ada empat mode render utama, SSR, SSG, ISR, dan client-side rendering. Masing-masing punya trade-off jelas yang akan saya bedah satu per satu.

Empat Mode Render dan Karakternya

Studi Kasus: Pilihan untuk Atmo dan Vetmo

Saat membangun Atmo, sistem LMS dengan dashboard kelas yang berubah tiap menit, kami pakai SSR untuk halaman dashboard dan SSG untuk halaman marketing. Dashboard butuh data real-time, jadi SSG akan jadi cache yang terlalu lama. Marketing page tidak butuh personalisasi, jadi SSG memberi kecepatan maksimal.

Untuk Vetmo, pet care platform, mayoritas halaman publik (artikel edukasi, profil dokter, layanan) dibuat dengan ISR. Konten kadang berubah saat dokter update jadwal atau artikel baru terbit. ISR memberi keuntungan SSG plus kemampuan refresh tanpa rebuild penuh. Hasilnya: skor LCP di bawah 1,5 detik di mobile dengan biaya server seperempat dari opsi SSR.

Kerangka Keputusan untuk Bisnis Indonesia

Pakai SSG kalau...

• Konten jarang berubah (kurang dari sekali per hari).
• Tidak ada personalisasi per-user.
• Anggaran server tipis dan ingin scale ke trafik tinggi.
• Contoh: company profile, blog, dokumentasi produk.

Pakai ISR kalau...

• Konten berubah beberapa kali per hari atau per minggu.
• Anda butuh kecepatan SSG tapi tidak ingin rebuild manual.
• Contoh: katalog e-commerce dengan stok stabil, blog editorial, halaman lokasi.

Pakai SSR kalau...

• Setiap user melihat halaman yang berbeda (dashboard, akun, cart).
• Data harus selalu fresh saat halaman dimuat.
• Anda butuh personalisasi berbasis cookie atau auth.
• Contoh: dashboard SaaS, halaman akun, checkout.

Pakai CSR (Client-Side Rendering) kalau...

• Halaman tidak perlu di-index Google.
• Aplikasi internal di balik login.
• Contoh: admin panel, web app B2B.

Trade-off yang Sering Diabaikan

SSR sering dipilih karena dianggap "fleksibel", tapi biayanya nyata. Setiap request memicu komputasi server yang naik linier dengan trafik. Saat trafik melonjak (misal saat campaign di TikTok atau viral konten), tagihan Vercel atau VPS bisa naik 3-5 kali lipat dalam sehari.

SSG mengeliminasi biaya per-request, tapi build time bisa membengkak kalau halaman ribuan. Saya pernah menangani situs dengan 8.000 halaman produk yang build-nya butuh 45 menit. Solusinya: migrasi ke ISR dengan revalidate per kategori, build time turun ke 6 menit.

Dokumentasi resmi Next.js tentang render menjelaskan detail teknis tiap mode.

Rekomendasi Praktis

Untuk mayoritas website bisnis Indonesia di 2026, pendekatan berikut bekerja paling baik:

1. Default ke SSG atau ISR untuk halaman publik.
2. Pakai SSR khusus untuk halaman dengan personalisasi atau data real-time.
3. Manfaatkan partial prerendering di Next.js 15+ untuk hybrid statis dan dinamis di satu halaman.
4. Monitor real user metrics dengan Core Web Vitals Budget supaya pilihan render tetap menghasilkan pengalaman cepat.

Pertanyaan Umum

Apakah SSR lebih baik untuk SEO daripada SSG?

Tidak. Keduanya menghasilkan HTML lengkap saat dilihat crawler. Yang membedakan SEO adalah kecepatan, dan SSG biasanya lebih cepat karena disajikan dari CDN edge.

Bagaimana memilih antara ISR dan SSR untuk e-commerce?

Kalau stok produk berubah dalam hitungan detik (flash sale, low-stock), pakai SSR. Kalau update stok harian sudah cukup, ISR jauh lebih murah dan cepat.

Apakah pemindahan dari SSR ke SSG sulit?

Tergantung. Halaman tanpa state user biasanya mudah dimigrasi. Halaman dengan auth atau personalisasi butuh refactor lebih dalam, kadang harus pisah komponen statis dan dinamis.

Berapa biaya hosting untuk masing-masing?

Untuk situs trafik 100k pageviews per bulan, SSG di Vercel free tier bisa cukup. SSR di tier sama biasanya butuh upgrade ke Pro (sekitar 20 USD per bulan) karena hit Function execution limit.

Apakah Streaming SSR mengubah keputusan ini?

Streaming SSR memperbaiki LCP di SSR, tapi tidak mengubah biaya per-request. Strategi pemilihan tetap sama, hanya saja SSR jadi lebih kompetitif dari sisi performa.

Penutup

Pilihan render strategy bukan keputusan satu-kali. Mulailah dengan default SSG atau ISR, lalu ubah ke SSR hanya untuk halaman yang benar-benar butuh. Tinjau ulang setiap kuartal saat trafik dan kebutuhan bisnis berubah. Strategi yang tepat hari ini bisa jadi mahal enam bulan ke depan kalau pola pengguna bergeser.