ISR vs SSG di Next.js: Kapan Pakai yang Mana

TL;DR: Di Next.js, SSG (Static Site Generation) membangun halaman sekali saat build sehingga paling cepat tapi kaku, sementara ISR (Incremental Static Regeneration) memperbarui halaman statis secara berkala tanpa rebuild penuh. Pakai SSG untuk konten yang jarang berubah, ISR untuk konten yang sering diperbarui tapi tetap butuh kecepatan statis.

Pertanyaan yang sering muncul saat membangun website konten di Next.js bukan soal framework mana, tapi strategi rendering mana. Pilihan ini menentukan kecepatan, biaya, dan seberapa segar konten yang dilihat pengunjung.

Banyak yang langsung memilih server-side rendering untuk semua halaman karena terasa paling fleksibel, lalu kaget melihat performa dan biaya server membengkak. Padahal sebagian besar halaman konten tidak butuh itu.

Tiga Strategi Dasar

Next.js menawarkan beberapa cara merender halaman. Tiga yang paling relevan untuk website konten:

SSG menghasilkan HTML statis sekali saja, jadi pengiriman ke pengunjung instan, tapi setiap perubahan konten butuh rebuild dan deploy ulang.

Di Mana ISR Masuk

ISR adalah jalan tengah. Halaman tetap statis dan cepat seperti SSG, tetapi Next.js meregenerasinya di latar belakang setelah jangka waktu tertentu (revalidate) atau saat dipicu. Pengunjung mendapat versi statis yang cepat, sementara konten tetap bisa diperbarui tanpa rebuild seluruh situs. Penjelasan teknis lengkapnya ada di dokumentasi resmi Next.js tentang ISR.

Untuk website dengan ratusan atau ribuan artikel, ini krusial. Rebuild penuh setiap kali satu artikel terbit jelas tidak praktis.

Studi Kasus: Memilih untuk Situs Konten

Di vitoatmo.com sendiri, halaman artikel dan glosarium memakai pendekatan statis dengan revalidasi, sehingga konten baru dan pembaruan schema bisa tampil tanpa rebuild manual, tapi pengunjung tetap mendapat kecepatan halaman statis. Halaman seperti profil yang isinya stabil cukup SSG murni. Prinsip yang saya pakai: default ke statis, naik ke ISR saat konten sering berubah, dan simpan SSR hanya untuk halaman yang benar-benar personal per pengguna. Pendekatan ini menjaga Core Web Vitals tetap sehat sekaligus menekan biaya server.

Pertanyaan Umum

Apakah ISR selalu lebih baik dari SSG?

Tidak. Jika konten sebuah halaman praktis tidak pernah berubah, SSG murni lebih sederhana dan tanpa overhead regenerasi. ISR baru unggul saat konten perlu diperbarui berkala.

Apakah ISR buruk untuk SEO?

Tidak. Pengunjung dan crawler tetap menerima HTML statis yang sudah jadi, sehingga ramah untuk SEO. Yang berubah hanya kapan versi statis itu diperbarui di latar belakang.

Bagaimana memilih nilai revalidate?

Sesuaikan dengan seberapa sering konten berubah dan seberapa toleran terhadap data sedikit basi. Konten harian bisa direvalidasi tiap beberapa menit hingga jam, konten yang jarang berubah cukup harian.

Pilih Berdasarkan Konten, Bukan Tren

Tidak ada strategi rendering yang menang mutlak. Petakan dulu tiap jenis halaman berdasarkan seberapa sering kontennya berubah dan seberapa personal datanya, baru pilih SSG, ISR, atau SSR. Keputusan yang sadar di tahap ini menghemat banyak biaya dan keluhan performa di kemudian hari.