Next.js Kamu Lambat Karena Data Fetching Coba Atur Caching dan SSG Begini Caranya

Next.js itu sering dielu-elukan sebagai framework dewa untuk membangun website yang super cepat, SEO-friendly, dan punya developer experience yang menyenangkan. Tapi, jujur saja, banyak banget developer muda yang baru pindah ke Next.js—atau bahkan yang sudah pakai lama—mengeluh, "Kok website gue masih lambat ya? Padahal sudah pakai Next.js!"

Seringkali, masalah utamanya bukan pada Next.js itu sendiri, melainkan pada cara kita melakukan data fetching dan mengelola caching. Kita terlalu sering memaksa Next.js untuk bekerja secara dynamic (melakukan rendering di setiap permintaan) padahal konten kita sebenarnya bisa di-cache atau di-generate sebelumnya.

Kalau kamu merasakan website Next.js-mu terasa "berat" saat diakses banyak user secara bersamaan, ini saatnya kita bongkar strategi caching dan static generation modern yang ada di Next.js (terutama di App Router). Kami di Javapixa Creative Studio melihat ini sebagai salah satu area kritis yang membedakan website yang cepat banget dengan yang cuma "cepat biasa."

Kita akan bahas tuntas, santai, dan tanpa jargon yang bikin pusing.

---

Kenapa Next.js Kamu Lambat? Tiga Dosa Utama Data Fetching

Next.js terkenal karena fleksibilitasnya dalam memilih strategi rendering: SSG (Static Site Generation), SSR (Server-Side Rendering), dan terbaru, Server Components. Namun, fleksibilitas ini bisa jadi bumerang kalau kita salah pilih.

Masalah utama kenapa website kamu lambat biasanya berasal dari tiga hal:

  1. "Anxiety" Terhadap Data Lama: Kamu selalu ingin data yang paling fresh dan real-time, sehingga kamu cenderung memilih SSR (atau Dynamic Rendering) untuk hampir semua halaman. Padahal, 80% konten website (seperti landing page, blog, atau deskripsi produk) jarang berubah.
  2. Over-fetching di Client Side: Meskipun Next.js mendorong Server Components, masih banyak yang menggunakan effect dan state di Client Components untuk mengambil data, yang menyebabkan waterfall request dan loading spinner yang menyebalkan.
  3. Lupa Atur Cache: Ini yang paling sering terjadi. Next.js 13 ke atas (App Router) secara default sudah menerapkan caching agresif pada fungsi fetch(). Tapi, kalau kamu pakai library lain atau lupa mengontrolnya, kamu bisa kehilangan manfaat caching bawaan Next.js.

Intinya, jika setiap kali ada user mengakses halaman, server harus mengambil data dari database, memprosesnya, dan merender HTML-nya dari awal, maka performa kamu akan tergerus, terutama di bawah beban tinggi.

Solusi Ajaib: Memaksa Next.js Jadi Lebih Malas (Caching Strategy)

Di Next.js versi terbaru, manajemen caching menjadi jauh lebih sederhana karena terintegrasi langsung dengan fungsi fetch() standar JavaScript.

1. Memahami Caching Otomatis di fetch() (Data Cache)

Di App Router (folder app/), semua fungsi fetch() yang kamu panggil di Server Component secara default akan di-cache. Artinya, hasil dari panggilan API atau database akan disimpan, dan Next.js tidak akan memanggilnya lagi sampai revalidation terjadi.

Ini adalah keuntungan besar! Kamu tidak perlu lagi repot-repot mengatur header cache atau library eksternal.

Contoh Caching Default:

javascript
// Ini di Server Component (app/page.js)
async function getProducts() {
  // Secara default, data ini akan di-cache
  // dan digunakan kembali untuk request berikutnya.
  const res = await fetch('https://api.domain.com/products')
  return res.json()
}

2. Kapan Harus Memaksanya Tidak Menggunakan Cache (no-store)

Tentu saja, ada kalanya kamu membutuhkan data yang benar-benar real-time, misalnya data keranjang belanja user yang spesifik atau token sesi. Untuk kasus ini, kamu harus secara eksplisit memberi tahu Next.js untuk tidak menyimpan data.

javascript
async function getRealTimeCart(userId) {
  const res = await fetch(https://api.domain.com/cart/${userId}, {
    cache: 'no-store', // Next.js TIDAK akan menyimpan hasil fetch ini.
  })
  return res.json()
}

Tips dari Javapixa Creative Studio: Gunakan cache: 'no-store' sehemat mungkin. Setiap kali kamu menggunakan opsi ini, kamu mengaktifkan SSR (atau Dynamic Rendering) untuk bagian halaman tersebut, dan itu berarti server kamu harus bekerja keras untuk setiap permintaan.

3. Solusi Tengah: Time-based Revalidation (ISR Modern)

Ini adalah sweet spot yang paling sering diabaikan. Bagaimana jika data kamu tidak harus real-time (per detik), tetapi juga tidak boleh statis (berbulan-bulan)?

Jawabannya adalah Time-based Revalidation yang dilakukan melalui opsi revalidate di fetch(). Ini adalah implementasi modern dari Incremental Static Regeneration (ISR).

javascript
async function getBlogPosts() {
  const res = await fetch('https://api.domain.com/blog', {
    next: {
      revalidate: 3600, // Revalidate (periksa data baru) setiap 1 jam (3600 detik)
    },
  })
  return res.json()
}

Bagaimana cara kerjanya?

  1. Permintaan pertama (misalnya jam 10:00) akan mengambil data, merendernya, dan menyimpannya di cache.
  2. Semua permintaan berikutnya hingga jam 11:00 akan langsung disajikan dari cache (Super Cepat!).
  3. Saat permintaan datang tepat setelah jam 11:00, Next.js akan menyajikan konten yang lama dulu (stale), tetapi di belakang layar, ia akan memicu proses revalidation untuk mengambil data baru.
  4. Permintaan berikutnya akan mendapatkan konten yang sudah diperbarui.

Ini adalah teknik yang brilian karena menggabungkan kecepatan SSG dengan kemampuan untuk memperbarui konten tanpa harus membangun ulang seluruh aplikasi. Ini adalah salah satu kunci utama performa Next.js yang optimal.

SSG dan ISR: Super Power Next.js yang Wajib Kamu Kuasai

Tadi kita sudah bahas caching data di level fetch(). Sekarang, mari kita naikkan levelnya ke strategi rendering halaman secara keseluruhan: SSG dan ISR.

A. Static Site Generation (SSG)

SSG adalah teknik di mana Next.js merender halaman menjadi file HTML murni saat build time (saat kamu menjalankan npm run build). Hasilnya? Kecepatan loading tak tertandingi karena tidak ada proses server yang perlu dilakukan saat permintaan datang; file HTML langsung disajikan dari CDN.

Kapan menggunakan SSG?

  1. Halaman yang jarang berubah (landing pages).
  2. Dokumentasi atau halaman "About Us."
  3. Blog post atau artikel lama yang isinya sudah final.

Sebelum App Router, kita menggunakan getStaticProps tanpa revalidate. Di App Router, SSG menjadi default untuk semua Server Components yang tidak menggunakan cache: 'no-store' atau tidak menggunakan fungsi yang memaksa dynamic rendering (seperti cookies() atau headers()).

B. Incremental Static Regeneration (ISR)

ISR adalah SSG yang diberi waktu kedaluwarsa. Ini sangat penting untuk website konten yang besar, seperti e-commerce atau portal berita, di mana kamu tidak mungkin membangun ulang 10.000 halaman setiap kali ada perubahan kecil di satu produk.

Implementasi ISR di App Router:

Selain menggunakan opsi revalidate di level fetch() seperti yang kita bahas di atas, kamu juga bisa mengatur revalidasi di level page segment (halaman) secara keseluruhan.

Untuk memaksa seluruh segmen (halaman) di-revalidate pada interval tertentu, kamu bisa menggunakan variabel revalidate di layout atau page file:

javascript
// app/blog/[slug]/page.js
export const revalidate = 600 // Halaman ini akan di-revalidate setiap 10 menit

Jika kamu mengatur revalidate pada level halaman, ia akan menimpa semua cache dari fetch() yang ada di dalamnya, memastikan bahwa setiap 10 menit, halaman tersebut berpotensi mendapatkan data terbaru.

Integrasi Lanjutan: Tag-Based Revalidation (Manual Cache Busting)

Strategi Time-based (ISR) memang keren, tapi kadang kita butuh kontrol lebih. Bagaimana jika produkmu di-update di database saat detik ke-59, dan kamu tidak mau menunggu detik ke-60?

Di sinilah Tag-Based Revalidation (atau On-Demand Revalidation) berperan. Next.js 13+ memungkinkan kamu melabeli hasil fetch() dengan tag tertentu.

Contoh Fetching dengan Tag:

javascript
async function getLatestNews() {
  const res = await fetch('https://api.domain.com/news', {
    next: {
      tags: ['berita-utama'], // Memberi tag pada data ini
    },
  })
  return res.json()
}

Jika ada update data, kamu bisa memicu revalidation dari mana saja (misalnya dari webhook CMS atau dashboard admin) menggunakan API Next.js:

javascript
// Contoh Endpoint API untuk Revalidate (Manual Cache Busting)
import { revalidateTag } from 'next/cache'

Teknik ini adalah jurus pamungkas untuk memastikan kecepatan maksimum (karena sebagian besar waktu disajikan dari cache) sambil menjamin data terbaru segera ditampilkan tanpa menunggu interval waktu.

Membangun Arsitektur yang Optimal Bersama Javapixa

Menguasai caching dan rendering di Next.js adalah pondasi utama dalam menciptakan aplikasi yang tidak hanya indah, tetapi juga mampu menopang jutaan pengguna. Di Javapixa Creative Studio, kami selalu menekankan pentingnya performance budgeting dari awal proyek.

Kami melihat tiga kesalahan umum yang dilakukan developer saat mencoba menerapkan strategi di atas:

  1. Mencampuradukkan Kebutuhan Caching: Mereka mencampur API Keys yang private dengan data yang bisa di-cache, yang memaksa seluruh segmen jadi dynamic. Solusinya: Pisahkan fetching data sensitif dan data statis.
  2. Lupa Revalidate Dynamic Routes: Khusus untuk halaman dengan dynamic slug (misalnya /blog/[slug]), mereka lupa mendefinisikan generateStaticParams() yang wajib untuk SSG/ISR, sehingga halaman tersebut fallback ke SSR yang lambat.
  3. Menggunakan Library yang Tidak Mendukung Cache Next.js: Saat menggunakan ORM atau database adapter (seperti PostgrSQL atau MongoDB), pastikan kamu membungkusnya dalam fungsi yang didukung oleh cache Next.js, atau gunakan library yang sudah terintegrasi baik dengan Server Components.

Checklist Caching Next.js Kamu:

  • Apakah landing page kamu sudah menggunakan SSG murni?
  • Apakah halaman blog atau produkmu menggunakan ISR (revalidate: X)?

Apakah semua panggilan fetch() yang tidak harus real-time* sudah diatur revalisasinya (atau dibiarkan default di-cache)? Apakah kamu sudah menggunakan Tag-Based Revalidation* untuk konten yang sensitif terhadap waktu update?

Jika jawaban dari beberapa poin di atas masih abu-abu, berarti masih banyak potensi kecepatan yang bisa kamu maksimalkan.

Next.js adalah alat yang luar biasa, tetapi performa maksimalnya hanya bisa dicapai jika kita tahu bagaimana memanfaatkan fitur caching dan static generation secara cerdas. Jangan biarkan website kamu yang seharusnya cepat malah tersendat hanya karena kamu terlalu malas untuk mengatur kapan data harus di-cache dan kapan harus diperbarui. Jika kamu membutuhkan bantuan ahli untuk mengaudit dan mengoptimalkan performa aplikasi Next.js kamu hingga titik darah penghabisan, tim profesional di Javapixa Creative Studio siap membantu merancang arsitektur yang blazing fast dan skalabel.