Website Bisnis

Next.js Rendering: SSG vs SSR vs ISR untuk Website Bisnis

Memilih strategi rendering yang tepat di Next.js berpengaruh langsung ke kecepatan, biaya, dan SEO. Panduan praktis dengan rumus dan studi kasus dari proyek nyata.

A
Admin·22 April 2026·0 kali dibaca·5 min baca
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

AspekSSGSSRISR
Kapan di-renderBuild timePer requestBuild + revalidate berkala
TTFBSangat cepatSedangSangat cepat
Freshness dataStale sampai rebuildSelalu freshFresh per interval
Biaya serverPaling murahPaling mahalMenengah
Contoh cocokBlog, landing, docsDashboard, cartKatalog, listing

Rumus kasar biaya komputasi per halaman per hari, $C = r \times c$, dengan $r$ jumlah render dan $c$ biaya per render. SSG punya $r$ sama dengan 1 per build, SSR punya $r$ sebesar jumlah request harian, dan ISR berada di tengah, $r = \max(1, \lfloor T_{harian} / revalidate \rfloor)$.

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

#nextjs#ssg#ssr#isr#web-performance#core-web-vitals

Butuh website yang benar-benar bekerja?

Hubungi Vito untuk konsultasi gratis 15 menit.

WhatsApp Sekarang →