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

TL;DR: SSG membangun halaman sekali saat build sehingga paling cepat, tapi konten statis. ISR menggabungkan kecepatan static dengan kemampuan memperbarui halaman secara berkala tanpa build ulang penuh. Untuk website bisnis, ISR sering jadi titik tengah ideal antara kecepatan dan kesegaran konten.

Salah satu keputusan paling berdampak saat membangun website di Next.js bukan soal desain, melainkan strategi render. Pilihan ini diam-diam menentukan seberapa cepat halaman dimuat dan seberapa segar kontennya. Banyak tim memilih asal, lalu bingung kenapa situs terasa lambat atau konten telat update.

Dari pengalaman membangun beberapa website bisnis dengan Next.js, saya melihat satu pola: kebanyakan kasus tidak butuh server rendering penuh. Mereka butuh static yang bisa diperbarui. Di situlah ISR bersinar.

Tiga Strategi Render, Tiga Karakter Berbeda

Memahami karakter masing-masing strategi lebih berguna daripada menghafal definisi.

• SSG (Static Site Generation): halaman dibangun sekali saat build. Paling cepat, paling murah, ideal untuk konten yang jarang berubah. Detailnya dibahas di static site generation.
• ISR (Incremental Static Regeneration): halaman static yang bisa diperbarui otomatis setelah interval tertentu, tanpa build ulang seluruh situs. Lihat ISR.
• SSR (Server-Side Rendering): halaman dirender di server setiap permintaan. Paling segar, tapi paling berat. Dibahas di server-side rendering.

Tabel Keputusan Praktis

Patokan sederhananya: mulai dari static, naik ke ISR jika konten perlu diperbarui, baru pakai SSR jika benar-benar butuh data per permintaan. Strategi render yang tepat juga berdampak langsung pada Core Web Vitals dan TTFB. Dokumentasi resmi Next.js menjelaskan trade-off ini secara rinci dalam panduan rendering mereka.

Studi Kasus: Memilih ISR untuk Website Konten

Pada website yang menerbitkan artikel dan glosarium secara berkala, kami sempat menimbang SSR agar konten selalu terbaru. Tapi setelah ditelaah, kebutuhannya bukan kesegaran per detik, melainkan per jam. SSR berarti server bekerja di setiap kunjungan, padahal konten tidak berubah secepat itu.

Solusinya ISR dengan interval revalidasi yang masuk akal. Halaman tetap secepat static bagi pengunjung, tetapi konten baru muncul otomatis tanpa deploy ulang. Hasilnya, beban server rendah, kecepatan halaman tinggi, dan konten tetap segar. Ini contoh nyata bahwa pilihan render yang tepat menyelesaikan dua masalah sekaligus.

Pertanyaan Umum

Apakah ISR selalu lebih baik dari SSG?

Tidak. Jika konten benar-benar statis dan jarang berubah, SSG lebih sederhana dan tetap paling cepat. ISR berguna ketika kontennya perlu diperbarui tanpa build ulang.

Apakah SSR membuat website lebih lambat?

Tidak selalu, tapi SSR menambah waktu proses di server setiap permintaan. Untuk konten yang tidak per-pengguna, static atau ISR umumnya memberi kecepatan lebih baik dengan beban lebih ringan.

Bisakah satu website memakai ketiganya?

Bisa, dan justru itu kekuatan Next.js App Router. Anda bisa menentukan strategi render per halaman sesuai kebutuhannya masing-masing.

Pilih Berdasarkan Kebutuhan, Bukan Tren

Tidak ada strategi render yang paling unggul secara mutlak. Yang ada adalah strategi yang paling cocok untuk kebutuhan halaman tertentu. Mulai dari yang paling ringan, naikkan kompleksitas hanya saat benar-benar diperlukan. Prinsip ini menjaga website tetap cepat tanpa mengorbankan kesegaran konten.