Cara Marketer Indonesia Pasang Server-Side Rendering Selektif di Next.js untuk Halaman Katalog Dinamis 2026

TL;DR: Server-Side Rendering selektif di Next.js dipakai hanya untuk halaman dengan data dinamis seperti katalog produk, dashboard, dan hasil pencarian. Halaman statis seperti tentang dan glosarium tetap di-render dengan Static Site Generation agar hemat biaya server. Kunci eksekusi ada di pemilihan strategi per route, bukan menyeragamkan semua halaman.

Di banyak proyek Next.js yang saya audit selama dua tahun terakhir, kesalahan paling umum bukan di pemilihan framework, tapi di pemerataan strategi render. Tim memilih SSR untuk semua halaman, lalu mengeluh biaya hosting Vercel naik tiga kali lipat tanpa kenaikan trafik yang sebanding. Padahal Next.js 15 sudah mendukung campuran SSR, SSG, dan ISR di project yang sama.

Tulisan ini mengurai kapan harus pakai Server-Side Rendering, kapan cukup SSG, dan bagaimana mengkonfigurasi keduanya berdampingan. Sasaran: Anda bisa membuat keputusan strategi render per route dengan dasar yang jelas, bukan ikut tren.

Kapan Halaman Wajib Pakai SSR

Tidak semua halaman butuh data terbaru tiap request. Praktik standar di industri membagi halaman ke tiga kategori berdasarkan kebutuhan data.

Halaman katalog yang berisi 500 produk dengan stok berubah tiap menit lebih cocok SSR karena ISR 60 detik bisa menampilkan stok lama. Tapi halaman kategori dengan filter ringan lebih hemat di SSG plus query parameter di client-side.

Implementasi SSR Selektif di Next.js 15 App Router

Di App Router, default-nya adalah Static Rendering. Untuk mengaktifkan SSR per route, ada tiga cara resmi sesuai dokumentasi Next.js.

Cara pertama, pakai dynamic API seperti cookies(), headers(), atau searchParams. Begitu salah satu dipanggil, Next.js otomatis switch ke dynamic rendering. Cara kedua, pasang export const dynamic = 'force-dynamic' di file page.tsx route yang relevan. Cara ketiga, pakai fetch(url, { cache: 'no-store' }) untuk memaksa fetch tiap request.

Cara kedua paling eksplisit dan mudah di-review tim. Contoh untuk halaman dashboard:

export const dynamic = 'force-dynamic'

export default async function DashboardPage() {
  const data = await fetchUserDashboard()
  return <DashboardView data={data} />
}

Untuk halaman katalog yang masih boleh agak basi 30 detik, ISR jauh lebih hemat:

export const revalidate = 30

Detail teknis lebih dalam ada di dokumentasi resmi Next.js Caching dan Google Search Central Rendering.

Studi Kasus Nalesha: Pisahkan SSR dan SSG untuk Hemat Biaya

Saat membangun ulang katalog Nalesha (e-commerce parfum) di Next.js 15, kami menemukan halaman produk individual cocok SSG karena spec produk jarang berubah. Tapi halaman kategori /parfum-pria butuh ISR 60 detik karena stok dan harga sering update. Halaman checkout dan akun pakai SSR penuh karena harus validasi sesi.

Hasil setelah pemisahan strategi selama 30 hari, biaya function execution Vercel turun dari sekitar 480 ribu per bulan ke 180 ribu per bulan. LCP halaman produk turun dari 2,8 detik ke 1,4 detik di mobile. Angka ini terukur di lab CrUX dan tidak bisa di-generalisasi ke project lain dengan ukuran asset berbeda.

Pelajaran utama: jangan pukul rata strategi render. Audit per route, klasifikasikan berdasarkan frekuensi perubahan data, lalu pilih strategi yang sesuai. Untuk konteks personalisasi lebih lanjut, lihat studi kasus Atmo LMS soal passkey yang menggunakan kombinasi SSR + auth.

Pertanyaan Umum

Apakah SSR di Next.js butuh server VPS sendiri?

Tidak. Vercel dan Cloudflare Pages mendukung SSR via edge function tanpa Anda mengelola server. Untuk proyek baru, mulai dari hosting serverless lebih praktis sebelum pindah ke VPS.

Bagaimana mengukur dampak SSR ke SEO?

Pantau dua metrik di Google Search Console: jumlah halaman terindeks dan rata-rata posisi. SSR biasanya mempercepat indeks halaman baru karena HTML utuh sejak crawl pertama. Bandingkan periode 30 hari sebelum dan sesudah perubahan strategi.

Apakah SSR memperbaiki Core Web Vitals?

Hanya untuk LCP. INP dan CLS lebih dipengaruhi oleh kualitas JavaScript dan layout shift, bukan strategi render. SSR mengurangi waktu tunggu konten muncul, tapi tidak otomatis memperbaiki interaktivitas.

Apakah SSR cocok untuk landing page sederhana?

Tidak. Landing page tanpa data per-user lebih cocok SSG karena bisa di-cache di CDN dan disajikan dalam milidetik. SSR justru menambah latency karena harus eksekusi di server tiap request.

Penutup: Render Strategy Itu Keputusan Bisnis

Memilih SSR atau SSG bukan keputusan teknis murni. Setiap strategi punya trade-off biaya, kecepatan, dan kompleksitas operasional. Marketer yang paham trade-off ini bisa berdialog dengan tim engineering tanpa kalah suara dan tanpa over-engineering. Mulai dari audit per route, klasifikasi data, lalu pilih strategi paling hemat yang masih memenuhi kebutuhan pengguna.