Next.js Lambat Cobain Trik ISR Biar SSG Kamu Gak Perlu Nge-Build Terus
Kalau kamu sudah pernah main-main dengan Next.js, pasti kamu tahu betul sensasi kecepatan kilat yang ditawarkan oleh Static Site Generation (SSG). Next.js memang keren, dia bisa membuat website kamu sangat cepat karena semua halaman sudah di-render duluan menjadi file HTML statis saat proses build. Ketika user mengakses, dia tidak perlu menunggu server memproses data, tinggal langsung sajikan file statisnya. Ini adalah mimpi para developer dan kunci sukses SEO.
Tapi, ada tapinya.
Coba bayangin kamu punya website e-commerce besar atau portal berita dengan ribuan artikel. Setiap kali ada perubahan kecil pada satu data, misalnya update harga produk atau koreksi typo di satu artikel, apa yang harus kamu lakukan? Jawabannya: Full rebuild. Kamu harus menjalankan perintah next build lagi, yang artinya semua ribuan halaman itu akan di-render ulang.
Awalnya mungkin cuma butuh 5 menit. Tapi ketika website kamu semakin besar, waktu build bisa melonjak drastis, kadang sampai 30 menit atau lebih. Kalau kamu sering deploy konten baru, kamu akan menghabiskan waktu berjam-jam hanya untuk menunggu proses build selesai. Performanya di runtime memang cepat, tapi developer experience dan kecepatan deployment kamu jadi sangat lambat.
Inilah masalah klasik Next.js yang membuat banyak developer pusing. Untungnya, Next.js (yang selalu update dengan solusi canggih) sudah menyiapkan jurus pamungkas untuk mengatasi sakit kepala ini: Incremental Static Regeneration (ISR).
*
ISR: Static Site Generation yang Jadi Lebih Cerdas
Next.js SSG itu ibarat kamu membuat kue dalam jumlah banyak (semua halaman) dan menyimpannya di toples. Kalau ada satu kue yang rusak, kamu harus membuat ulang semua kue di semua toples. Repot, kan?
Nah, ISR adalah solusi cerdas yang mengisi celah antara SSG (sangat cepat tapi data statis) dan Server Side Rendering / SSR (data selalu fresh tapi sering lambat karena di-render saat request).
Sesuai namanya, Incremental Static Regeneration memungkinkan kamu untuk memperbarui halaman statis secara inkremental (bertahap) tanpa perlu melakukan full rebuild seluruh aplikasi.
Kunci utama ISR adalah konsep Stale-While-Revalidate.
Maksudnya gini: Next.js akan tetap menyajikan halaman statis yang sudah ada (halaman lama/statis) kepada user untuk memastikan kecepatan maksimal, bahkan jika kontennya sudah stale (basi/sudah ada update baru di database). Namun, secara bersamaan, dia akan mengatur timer untuk mengecek apakah halaman tersebut perlu di-generate ulang di background.
Ketika timer habis, dan ada request baru yang datang, Next.js akan:
- Langsung menyajikan konten stale yang sudah di-cache kepada user.
- Secara diam-diam (di background), memicu proses revalidation (pembaharuan).
- Setelah proses revalidation selesai, konten baru akan disimpan.
- User berikutnya yang datang akan langsung mendapatkan konten yang sudah fresh.
Jadi, hanya user pertama yang datang setelah cache habis yang mungkin melihat konten lama, tapi dia tidak akan mengalami latency atau loading yang lambat. Sementara itu, semua user berikutnya akan menikmati kecepatan SSG dengan data yang sudah terbarukan. Keren, kan?
Inilah mengapa di Javapixa Creative Studio, kami sangat mengutamakan implementasi ISR untuk klien-klien yang membutuhkan performa tinggi namun dengan konten dinamis, seperti portal media atau platform manajemen inventori besar. Karena kami paham, kecepatan build adalah kunci efisiensi tim development.
*
Bagaimana Menerapkan ISR di Next.js?
Penerapan ISR di Next.js itu gampang banget, asalkan kamu sudah familiar dengan fungsi getStaticProps. Ingat, ISR hanya bisa bekerja pada halaman yang menggunakan getStaticProps.
Jika di SSG murni kamu hanya mengembalikan props, di ISR kamu hanya perlu menambahkan satu key lagi di objek yang kamu kembalikan, yaitu revalidate.
1. Implementasi Dasar dengan revalidate
Mari kita asumsikan kamu memiliki halaman detail produk /products/[slug].js. Kamu ingin halaman ini cepat (SSG), tapi kamu mau data harganya di-update maksimal setiap 60 detik.
javascript
// pages/products/[slug].jsimport React from 'react';export async function getStaticProps(context) {
// Misalnya kita ambil data dari API/database
const productData = await fetchProduct(context.params.slug);if (!productData) {
return {
notFound: true,
};
}return {
props: {
product: productData,
},
// Ini dia magic-nya: revalidate dalam detik
revalidate: 60, // Halaman akan di-rebuild paling cepat setiap 60 detik
};
}Apa yang terjadi di sini?
Angka 60 berarti Next.js akan melayani halaman yang sudah di-cache selama 60 detik. Ketika 60 detik berlalu, dan ada request baru datang, user tersebut tetap akan mendapatkan halaman lama (cepat). Pada saat yang sama, Next.js akan memanggil ulang getStaticProps di background untuk mendapatkan data terbaru. Setelah data terbaru siap, halaman lama akan digantikan oleh halaman baru, siap untuk dilayani pada request berikutnya.
Ini jauh lebih efisien daripada harus next build setiap ada perubahan data.
2. Menangani Dynamic Routes dengan getStaticPaths
Hampir semua kasus ISR melibatkan dynamic routes (misalnya halaman detail produk, artikel, atau profil). Di Next.js, dynamic routes harus menggunakan getStaticPaths untuk memberi tahu Next.js, halaman mana saja yang harus di-pre-render saat build time.
Dalam konteks ISR, getStaticPaths menjadi krusial karena kita harus menentukan kebijakan fallback.
javascript
export async function getStaticPaths() {
// Ambil semua slug produk yang sangat populer
const popularSlugs = await fetchPopularSlugs();const paths = popularSlugs.map((slug) => ({
params: { slug },
}));Ada tiga opsi fallback di sini, dan ini wajib kamu pahami:
fallback: false: Ini adalah SSG murni. Hanya paths* yang didefinisikan yang di-generate. Jika user mengakses path yang tidak ada, akan muncul 404. Tidak cocok untuk ISR dinamis. fallback: true: Ini adalah ISR yang soft. Ketika user mengakses path yang belum pernah di-generate (misalnya produk baru yang baru diinput), user akan melihat loading state* (fallback state) sementara Next.js menjalankan getStaticProps dan meng-generate halaman tersebut pertama kalinya. Setelah selesai, halaman tersebut akan di-cache dan tunduk pada aturan revalidate. fallback: 'blocking': Ini yang paling sering direkomendasikan Javapixa Creative Studio. Ketika user mengakses path baru, user akan "terblokir" sebentar (tanpa melihat loading state*) sampai halaman selesai di-generate oleh getStaticProps. Setelah halaman pertama kali selesai, ia akan langsung disajikan dan di-cache, sama seperti SSG murni, dan tunduk pada aturan revalidate. Ini memberikan UX yang paling mulus.
Pilihlah fallback: 'blocking' jika kamu ingin user selalu melihat konten final tanpa loading state saat mengakses halaman yang baru dibuat.
*
Kapan Sebaiknya Menggunakan ISR? (Use Cases)
Meski ISR terdengar seperti solusi ajaib, ia bukan obat untuk semua penyakit. Kamu tetap perlu menggunakan SSR jika datanya harus real-time (misalnya saldo bank atau live chat).
Namun, ISR bersinar terang pada kasus-kasus ini:
1. Blog atau Portal Berita
Ini adalah kasus klasik. Halaman utama mungkin sering di-update, tapi detail artikel (ribuan jumlahnya) hanya perlu di-revalidate sesekali. Jika kamu set revalidate: 3600 (satu jam) pada halaman artikel, maka ribuan artikel kamu hanya akan diperbarui jika ada user yang mengaksesnya setelah timer 1 jam habis. Ini menghemat build time yang sangat besar.
2. E-commerce Product Pages
Halaman produk harus cepat (SSG) untuk SEO dan user experience. Tapi, harganya bisa berubah. Dengan ISR 5 menit (revalidate: 300), kamu memastikan harga ter-update secara otomatis tanpa perlu rebuild seluruh katalog.
3. Dokumen Teknis dan Static Content yang Sering Berubah
Jika kamu menggunakan CMS seperti Contentful atau Strapi, dan konten markdown atau gambar sering diubah oleh tim konten, ISR adalah jembatan terbaik agar perubahan bisa langsung terlihat dalam hitungan menit, bukan jam build.
*
Tips Lanjut dan Perangkap ISR yang Harus Dihindari
Meskipun sederhana, ada beberapa detail teknis yang perlu kamu perhatikan agar implementasi ISR kamu efektif dan tidak menyebabkan masalah:
1. Hati-hati dengan Waktu revalidate
Jangan menyetel revalidate terlalu kecil (misalnya revalidate: 1). Jika kamu set 1 detik, artinya hampir setiap request yang datang akan memicu getStaticProps di background. Ini sama saja kamu melakukan SSR, hanya saja tertunda 1 detik. Efeknya, beban API backend kamu akan meningkat drastis.
Idealnya, tentukan waktu berdasarkan toleransi data stale yang bisa diterima:
- Berita/E-commerce Harga: 60-300 detik.
- Blog/Dokumentasi: 3600 detik (1 jam) atau lebih.
2. Memaksa Revalidation (On-Demand ISR)
Bagaimana jika kamu tidak mau menunggu revalidate habis? Misalnya, tim admin baru saja meng-update data, dan mereka ingin data itu langsung live tanpa menunggu 60 detik.
Next.js 12 memperkenalkan fitur On-Demand ISR. Ini memungkinkan kamu untuk memicu proses revalidation secara manual melalui sebuah API endpoint rahasia.
Kamu bisa membuat handler API di Next.js:
javascript
// pages/api/revalidate.js
export default async function handler(req, res) {
// Pastikan ada token rahasia untuk keamanan
if (req.query.secret !== process.env.MYSECRETTOKEN) {
return res.status(401).json({ message: 'Invalid token' });
}Dengan cara ini, tim kamu bisa menekan tombol di CMS (yang akan memanggil API ini) segera setelah konten di-update. Ini memberikan kontrol data real-time penuh, sambil tetap mempertahankan manfaat kecepatan SSG.
3. Integrasi dengan CDN dan Hosting (Vercel)
ISR bekerja paling optimal jika kamu menggunakan platform hosting yang memang dirancang untuk Next.js, seperti Vercel. Vercel secara otomatis mengelola cache di Edge Network mereka, memastikan bahwa proses revalidation dan penyajian konten stale berjalan sangat cepat karena berada dekat dengan user.
Jika kamu menghosting di platform lain, pastikan kamu mengkonfigurasi CDN kamu (seperti Cloudflare atau AWS CloudFront) untuk menghormati cache-control headers yang dikeluarkan oleh Next.js agar ISR bisa berjalan sebagaimana mestinya.
Kesimpulan: Next.js Cepat Tanpa Harus Rewel Nge-Build
Menggunakan Next.js seharusnya membuat pekerjaan kita lebih mudah dan hasil produk lebih cepat. Namun, jika kamu terus-terusan stuck menunggu proses build setiap kali ada data berubah, itu artinya kamu belum memaksimalkan potensi penuh dari framework ini.
Incremental Static Regeneration (ISR) adalah solusi elegan yang ditawarkan Next.js untuk menjaga performa SSG yang super cepat, sambil memberikan fleksibilitas dinamis dari SSR/CSR. Ini adalah cara modern untuk membangun website berskala besar.
Jika kamu atau bisnismu membutuhkan solusi website atau aplikasi yang bukan hanya cepat dimata user, tetapi juga efisien dan cepat dalam proses deployment dan update data, maka implementasi ISR adalah keharusan. Javapixa Creative Studio telah menguasai teknik ini, memastikan setiap proyek yang kami kerjakan mendapatkan performa terbaik dengan arsitektur yang future-proof. Jangan sampai website kamu lambat hanya karena kamu takut nge-build. Pindah ke ISR sekarang, dan rasakan perbedaannya.