Belajar Next.js - Networking Performance & Caching

#Pendahuluan

Jaringan adalah bagian paling lambat dari sebuah aplikasi web. Request harus melewati DNS, TLS, dan banyak hop server sebelum data tiba. Jawaban untuk ini bukan meng-upgrade server, tapi menghindari kerja berulang melalui caching.

Episode 14 membahas strategi caching dengan Cache-Control dan ISR, edge caching serta integrasi CDN, optimasi pengambilan data untuk mengurangi latensi API, dan prefetching dengan resource scheduling.

#Strategi Caching dengan Cache-Control dan ISR

#Cache-Control di Route Handler

Header Cache-Control memberitahu browser dan CDN berapa lama response boleh disimpan. Atur di route handler:

export async function GET() {
  const data = await ambilData()
 
  return Response.json(data, {
    headers: {
      "Cache-Control": "public, s-maxage=60, stale-while-revalidate=300",
    },
  })
}

Header di atas menandakan response boleh di-cache publik selama 60 detik, dan saat cache usang, konten lama tetap disajikan sambil di-refresh di background selama 300 detik. Ini pola stale-while-revalidate yang dipakai untuk data yang tidak harus selalu segar.

Pola ini juga dikenal sebagai SWR caching dan banyak dipakai halaman berita: pembaca selalu melihat konten tanpa menunggu, sementara data diperbarui di latar belakang. Atur s-maxage sesuai toleransi kesegaran data bisnis kalian — semakin sering data berubah, semakin kecil nilai yang aman.

#Kombinasi dengan ISR

ISR dan Cache-Control bekerja bersama: ISR menentukan kapan halaman statis di-rebuild di server, sedangkan header mengontrol berapa lama hasilnya boleh di-cache di edge dan browser. Untuk halaman statis, gunakan next: { revalidate: 60 } pada fetch; untuk route handler, gunakan header seperti contoh di atas. Keduanya menghasilkan respons cepat dengan data yang cukup segar.

#Edge Caching dan CDN Integration

#Mendekatkan Konten ke Pengguna

CDN (Content Delivery Network) menyimpan salinan konten di banyak server di seluruh dunia. Saat pengguna di Jakarta mengakses aplikasi yang di-deploy di server Amerika, CDN melayani dari server terdekat — memangkas latensi secara drastis.

Cache di browser menyimpan respons untuk satu pengguna; cache di CDN menyimpan untuk banyak pengguna sekaligus dan jauh lebih berdampak pada beban origin. Keduanya dikontrol oleh header yang sama, tapi dengan nilai yang disesuaikan per kebutuhan.

Halaman statis dan aset di folder public di-cache CDN secara otomatis oleh platform seperti Vercel. Untuk memanfaatkan CDN sepenuhnya:

• Halaman statis atau ISR lebih ramah cache daripada halaman dinamis.
• Aset statis diberi hash agar bisa di-cache selamanya.
• Konten yang sering berubah dikecualikan dari cache.

#Pembatasan Cache

Tidak semua konten boleh di-cache. Halaman yang menampilkan data pribadi wajib memakai Cache-Control: private atau no-store. Pemisahan ini penting: satu kesalahan konfigurasi cache bisa membocorkan data pengguna ke pengguna lain. Selalu validasi header di production sebelum merilis halaman baru.

Saat data berubah lebih cepat daripada TTL, kalian butuh cara membatalkan cache secara eksplisit. Platform seperti Vercel menyediakan purge cache API, atau gunakan revalidatePath dari episode 6 untuk memicu pembaruan halaman sebelum TTL berakhir.

#Optimasi Data Fetching dan Mengurangi Latensi API

#Menghindari Fetch Berulang

Latensi API berasal dari waktu jaringan dan pemrosesan server. Strategi yang efektif: gabungkan beberapa data dalam satu endpoint, hindari request waterfall (menunggu request A sebelum mengirim request B), dan parallel-kan request yang independen:

const [userRes, postsRes] = await Promise.all([
  fetch("/api/user"),
  fetch("/api/posts"),
])

Promise.all di atas menjalankan dua fetch bersamaan, memangkas total waktu tunggu menjadi waktu request terlama, bukan jumlah keduanya. Next.js juga menyimpan hasil fetch yang sama dalam cache selama satu request dijalankan.

Kesalahan umum adalah meng-cache halaman dinamis dengan data pribadi. Selalu pisahkan konten publik dan privat: halaman privat memakai no-store, sementara halaman publik memanfaatkan CDN sepenuhnya. Kesalahan konfigurasi di area ini bisa membocorkan data pengguna ke pengguna lain.

Untuk API publik yang dipakai aplikasi lain, dokumentasikan kebijakan cache dengan header yang eksplisit dan sediakan versi endpoint bila kontraknya berubah.

#Deduplikasi dan Cache Data

Atur cache data yang jarang berubah di sisi klien dengan TanStack Query — query yang sama tidak akan di-fetch ulang saat komponen lain memakainya. Kombinasi cache server dan klien ini mengurangi jumlah panggilan API secara signifikan.

Perhatikan juga ukuran respons: mengambil seratus field padahal hanya tiga yang dipakai membuang bandwidth dan memperlambat parse. Pilih field dengan selektor yang disediakan API, atau buat endpoint khusus yang ringkas.

#Prefetching dan Resource Scheduling

#Prefetching Link dan Data

Next.js sudah menangani prefetching dasar: komponen Link memuat halaman tujuan sebelum diklik. Untuk data, gunakan opsi prefetch pada TanStack Query untuk query yang besar kemungkinan dibutuhkan — misalnya saat pengguna mengarahkan mouse ke tombol detail produk. Resource scheduling penting lainnya: beri priority pada gambar LCP, defer skrip non-kritis, dan hindari memblokir render dengan JavaScript besar.

• Prioritaskan fetch yang menyediakan konten LCP di atas fold.
• Tunda skrip pihak ketiga dengan atribut defer atau muat saat idle.
• Batasi jumlah font dan pasang preconnect ke asal font sejak awal.
• Lazy-load media dan komponen yang berada di bawah fold.

#Mengukur Dampak Caching

Setiap perubahan strategi caching harus diukur: bandingkan TTFB dan LCP sebelum serta sesudah, dan pantau hit rate cache di dashboard platform. Caching yang baik meningkatkan hit rate tanpa mengorbankan kesegaran data. revalidate: 60 adalah contoh opsi yang bisa diukur dampaknya terhadap kesegaran data versus kecepatan respons.

#Penutup

Inti yang harus dibawa pulang:

• Cache-Control mengontrol caching di browser dan CDN.
• stale-while-revalidate menyajikan data usang sambil refresh di background.
• CDN memangkas latensi dengan menyalin konten mendekati pengguna.
• Data pribadi wajib memakai private atau no-store.
• Promise.all mem-parallel-kan request yang independen.
• Prefetching link dan data mengantisipasi kebutuhan pengguna.

Di episode 15 selanjutnya kita akan membahas performance optimization — profiling dengan React DevTools dan tool browser, code splitting dan bundle analysis dengan tree shaking, optimasi Core Web Vitals, serta mengurangi payload JavaScript memakai server components dan dynamic import. Aplikasi kalian akan diukur dan dioptimasi secara metodis.