Salah satu keputusan arsitektur terpenting di Next.js adalah memilih strategi rendering. Pilihan yang salah berarti server cost yang tidak perlu, atau konten basi yang membingungkan pengguna. Berikut kerangka yang saya pakai di setiap proyek.
SSG: Default yang Hampir Selalu Benar
Jika konten sama untuk semua pengguna dan jarang berubah — landing page, dokumentasi, halaman produk — generate statis saat build. Tidak ada komputasi per-request, TTFB minimal, dan CDN bisa meng-cache semuanya.
ISR: Statis yang Bisa Segar
Incremental Static Regeneration adalah SSG dengan masa berlaku. Halaman tetap disajikan statis, tapi di-generate ulang di background setelah interval revalidate. Ini pilihan tepat untuk blog, katalog, dan halaman yang datanya dikelola lewat CMS.
- revalidate 60 detik untuk konten yang sering diperbarui
- revalidate 1 jam atau lebih untuk konten stabil
- On-demand revalidation via webhook ketika butuh instan
SSR: Hanya Ketika Benar-Benar Perlu
Server-Side Rendering per-request hanya masuk akal ketika respons bergantung pada siapa yang meminta: dashboard yang dipersonalisasi, halaman dengan otorisasi, atau data real-time. Selain itu, SSR adalah biaya yang tidak perlu dibayar.
Kerangka Keputusan
- Konten sama untuk semua orang dan jarang berubah? SSG.
- Konten sama untuk semua orang tapi berubah berkala? ISR.
- Konten berbeda per pengguna atau real-time? SSR (atau client fetch).
Portfolio ini sendiri memakai ISR dengan revalidate 60 detik — perubahan di CMS muncul otomatis, sementara pengunjung selalu mendapat halaman statis yang cepat.