Next.js Rendering: SSG vs SSR vs ISR untuk Website Bisnis
TL;DR: Next.js menyediakan tiga strategi rendering utama, SSG untuk halaman statis super cepat, SSR untuk data yang selalu fresh, dan ISR untuk hybrid antara keduanya. Pilihan yang tepat menentukan biaya hosting, skor Core Web Vitals, dan kesiapan SEO website bisnis.
Dalam beberapa proyek terakhir, saya melihat banyak tim membangun website bisnis dengan Next.js, tetapi memakai strategi rendering yang sama untuk semua halaman. Hasilnya, halaman produk yang jarang berubah jadi ikut mahal karena direndering server per request, atau sebaliknya, dashboard user ikut di-cache seperti halaman statis biasa dan datanya tidak fresh.
Keputusan rendering bukan sekadar preferensi developer. Di proyek Atmo LMS dan Nalesha (e-commerce parfum), mencampur strategi secara tepat memangkas biaya server sampai sekitar 30-50% dari baseline SSR penuh, sekaligus menjaga halaman tetap di ambang skor hijau Lighthouse.
Tiga Strategi Rendering Next.js dalam Satu Tabel
| Aspek | SSG | SSR | ISR |
|---|---|---|---|
| Kapan di-render | Build time | Per request | Build + revalidate berkala |
| TTFB | Sangat cepat | Sedang | Sangat cepat |
| Freshness data | Stale sampai rebuild | Selalu fresh | Fresh per interval |
| Biaya server | Paling murah | Paling mahal | Menengah |
| Contoh cocok | Blog, landing, docs | Dashboard, cart | Katalog, listing |
Rumus kasar biaya komputasi per halaman per hari, , dengan jumlah render dan biaya per render. SSG punya sama dengan 1 per build, SSR punya sebesar jumlah request harian, dan ISR berada di tengah, .
Untuk detail tiap metode, lihat glosarium SSG (Static Site Generation), SSR (Server-Side Rendering), dan ISR (Incremental Static Regeneration).
Framework Keputusan, 3 Pertanyaan
Gunakan urutan pertanyaan ini sebelum menulis kode, bukan setelahnya.
Pertama, seberapa sering data halaman berubah? Kalau jawabannya "sangat jarang" (halaman About, kebijakan privasi), pakai SSG. Kalau "setiap detik" (harga saham, stok live), pakai SSR. Kalau "beberapa kali sehari" (daftar artikel, katalog produk), ISR adalah sweet spot.
Kedua, apakah halaman bisa di-share lintas user? Kalau bisa (katalog publik, blog), pola statis (SSG/ISR) aman. Kalau sangat personal (dashboard akun, histori order), harus SSR atau Client-Side Rendering pasca-login.
Ketiga, berapa jumlah halaman total? Kalau di atas 1000 halaman dan rebuild memakan puluhan menit, ISR atau SSG dengan on-demand revalidation jauh lebih praktis daripada full rebuild tiap update.
Studi Kasus, Nalesha Parfum
Saat membangun Nalesha, kami menghadapi trade-off klasik, halaman produk harus cepat untuk SEO dan konversi, tapi stok dan harga bisa berubah harian. Strategi SSR penuh membuat biaya Vercel naik signifikan saat traffic kampanye masuk. Migrasi ke ISR dengan revalidate=300 (5 menit) plus on-demand revalidation saat admin update stok, menurunkan biaya komputasi sekitar 40% dan tetap menjaga LCP di bawah 2.5 detik di perangkat 4G Indonesia.
Pelajaran utamanya, ISR bukan sekadar cache canggih, tapi pilihan arsitektur. Perlu tim konten paham bahwa update bisa telat maksimal revalidate detik, kecuali mereka klik tombol "revalidate sekarang".
Checklist Sebelum Deploy
Praktik standar di industri menunjukkan empat hal yang sering dilewati, pastikan kamu melakukannya, (1) pisahkan halaman per strategi di folder app/ Next.js, jangan campur logic dalam satu route, (2) pasang Structured Data JSON-LD untuk setiap halaman publik, (3) ukur TTFB dan LCP via Lighthouse plus CrUX, jangan cuma lab data, (4) batasi ISR revalidate di level yang bisa dijelaskan ke tim bisnis, misalnya 60-600 detik untuk katalog.
Dokumentasi resmi Next.js App Router Caching adalah referensi wajib untuk memahami interaksi antara Fetch Cache, Data Cache, dan Full Route Cache.
Pertanyaan Umum
Apakah Next.js App Router masih mendukung SSG?
Ya. Di App Router, SSG dicapai dengan default caching, ditambah generateStaticParams untuk dynamic routes. Tidak lagi bernama getStaticProps, tetapi konsepnya sama.
Bagaimana cara memilih antara SSR dan CSR untuk halaman login?
Halaman login sendiri boleh SSR karena perlu indexable dan cepat. Konten pasca-login (dashboard, data akun) biasanya di-render di client setelah cek token, agar tidak tercampur cache publik.
Apakah ISR bagus untuk Programmatic SEO?
Sangat cocok. Programmatic SEO biasanya menghasilkan ribuan halaman yang tidak mungkin full rebuild setiap hari. ISR dengan revalidate 1-24 jam dan on-demand trigger adalah pola yang banyak dipakai.
Apakah Vercel satu-satunya provider yang mendukung ISR?
Tidak. ISR adalah fitur Next.js yang bisa berjalan di Vercel, Netlify, Cloudflare Pages, dan self-hosted Node.js. Perilaku cache bisa sedikit beda tergantung provider.
Keputusan yang Tepat Bukan Soal Tren
Mengadopsi rendering strategi Next.js bukan soal mana yang paling baru, tetapi mana yang paling sesuai dengan profil data dan traffic website. Audit halaman per halaman, terapkan SSG di default, pindahkan ke ISR atau SSR hanya ketika ada alasan konkret. Pola ini menjaga biaya tetap rasional sambil memberikan pengalaman yang cepat buat pengguna Indonesia dengan jaringan yang bervariasi.
Artikel Terkait
Website Bisnis
ISR di Next.js: Konten Dinamis Tetap Secepat Halaman Statis
Website bisnis butuh konten segar tanpa mengorbankan kecepatan. ISR membuat halaman tetap statis cepat sambil memperbarui data otomatis. Begini cara kerjanya.
Website Bisnis
Hreflang: Cara Google Tahu Versi Bahasa yang Tepat
Website dengan beberapa bahasa sering menyajikan versi yang salah ke pengguna yang salah. Hreflang memberi tahu Google versi mana untuk siapa. Begini cara memasangnya tanpa merusak SEO.
Website Bisnis
Soft 404: Error Senyap yang Menggerus SEO Tanpa Terlihat
Halaman tampak normal di mata pengunjung, tapi Google menganggapnya error. Soft 404 adalah masalah teknis yang jarang disadari namun bisa membuang crawl budget dan menurunkan kepercayaan indeks.
Butuh website yang benar-benar bekerja?
Hubungi Vito untuk konsultasi gratis 15 menit.
WhatsApp Sekarang