Optimasi Performa Next.js App Router di Edge: Strategi ISR dan Partial Prerendering

Pukul 2 pagi di ruang server, tatapan saya terpaku pada metrik Grafana yang menunjukkan lonjakan latency hingga 850 milidetik pada halaman utama e-commerce skala masif yang baru saja kami migrasikan. Tim frontend bersikeras bahwa Incremental Static Regeneration (ISR) sudah diaktifkan secara maksimal, sementara tim backend mengeluh database MySQL kami mengalami saturasi koneksi akibat re-validasi halaman secara bersamaan. Di sinilah perdebatan sengit dimulai: apakah kita harus sepenuhnya menyerahkan beban rendering ke Edge menggunakan Partial Prerendering (PPR), atau tetap mempertahankan pola tradisional dengan mengandalkan CDN Workers dan ISR berbasis Next.js App Router? Telepon berdering, manajemen menuntut Core Web Vitals kembali hijau sebelum kampanye flash sale dimulai, memaksa kami melakukan analisis mendalam di medan pertempuran arsitektur web modern.

Sebelum kita masuk ke dalam parit pertempuran kode dan konfigurasi, mari kita lihat matriks perbandingan langsung antara strategi Partial Prerendering (PPR) murni di Edge melawan kombinasi klasik Incremental Static Regeneration (ISR) dengan CDN Workers (Cloudflare Workers). Penilaian ini didasarkan pada pengalaman langsung menguji kedua pendekatan ini di bawah tekanan lalu lintas produksi nyata.

[!IMPORTANT] Jangan pernah berasumsi bahwa teknologi terbaru otomatis menyelesaikan masalah arsitektural lama. PPR membutuhkan pemahaman mendalam tentang React Suspense boundaries, sementara ISR menuntut strategi cache invalidation yang sangat presisi agar tidak terjadi cache stampede di database origin.

Transisi dari kebingungan debugging lokal menuju pemahaman mendalam tentang bagaimana byte dikirimkan ke peramban pengguna menuntut kita untuk membedah filosofi dasar di balik kedua pendekatan ini, dimulai dari cara pandang mereka dalam melayani permintaan klien.

1. Pertarungan Filosofi: Dua Cara Pandang Berbeda dalam Memecahkan Masalah

Ketika kita berbicara tentang menyajikan konten web dengan kecepatan milidetik, pendekatan tradisional web server seperti Nginx yang melayani file statis dari storage S3 atau MinIO sudah teruji puluhan tahun. Namun, web modern menuntut personalisasi instan tanpa mengorbankan kecepatan pemuatan awal. Di sinilah pertempuran filosofi antara Partial Prerendering (PPR) dan ISR dengan CDN Workers bermula.

Di satu sisi, PPR menganut filosofi "Shell Pertama, Konten Menyusul". Dengan memanfaatkan React Suspense, PPR membagi satu halaman HTML menjadi bagian statis yang dirender di muka dan bagian dinamis yang di-stream secara asinkron dari server Node.js atau Edge Runtime. Pengguna langsung melihat kerangka halaman dalam hitungan milidetik, sementara data keranjang belanja atau rekomendasi produk menyusul tanpa memblokir Main Thread.

Di sisi lain, kubu ISR dipadukan dengan Cloudflare Workers memegang teguh filosofi "Cache Adalah Raja". Seluruh halaman atau komponen di-cache di ratusan Edge locations di seluruh dunia. Ketika ada pembaruan data, background re-validation berjalan senyap tanpa membuat pengguna merasakan penundaan TTFB. Masalahnya muncul ketika kita harus berurusan dengan data dinamis tinggi yang berubah setiap detik; di sinilah CDN Workers harus diprogram dengan logika Cache-Control yang sangat rumit menggunakan Stale-While-Revalidate.

[!TIP] Jika aplikasi Anda didominasi oleh konten yang statis untuk setiap pengguna tetapi butuh pembaruan berkala, ISR adalah jalan pintas paling aman. Namun, jika dashboard atau halaman profil Anda memuat komponen statis dan dinamis secara berdampingan, PPR adalah evolusi arsitektur yang Anda butuhkan.

Memahami filosofi ini saja tidak cukup untuk meredakan perdebatan di ruang meeting. Kita harus masuk ke ruang kerja harian untuk merasakan sendiri bagaimana kompleksitas menulis dan memelihara kodenya.

2. Ronde 1: Ergonomi Menulis Kode & Pengalaman Konfigurasi Sehari-hari

Mari kita bedah bagaimana rasanya duduk di depan layar editor kode, menulis implementasi nyata, dan berurusan dengan konfigurasi sistem di balik layar saat tenggat waktu semakin dekat.

Pada Next.js App Router dengan PPR, konfigurasi diaktifkan secara global melalui next.config.js. Anda tidak perlu lagi pusing memikirkan skrip kompleks di Nginx atau aturan cache di Cloudflare dashboard, karena mekanismenya menyatu langsung dengan logika komponen React.

// next.config.js
/** @type {import('next').Next.jsConfig} */
const nextConfig = {
  experimental: {
    ppr: 'incremental',
  },
};

module.exports = nextConfig;

Ketika menulis komponen, tantangannya adalah bagaimana mendefinisikan batasan Suspense dengan benar agar server tahu bagian mana yang harus di-cache sebagai shell dan bagian mana yang harus di-stream secara dinamis:

// app/dashboard/page.tsx
import { Suspense } from 'react';
import StaticHeader from '@/components/StaticHeader';
import DynamicUserProfile from '@/components/DynamicUserProfile';
import UserProfileSkeleton from '@/components/UserProfileSkeleton';

// Mengaktifkan PPR secara eksplisit pada segment rute ini
export const experimental_ppr = true;

export default function DashboardPage() {
  return (
    <main className="min-h-screen bg-slate-900 text-white">
      {/* Bagian ini di-prerender secara statis dan di-cache selamanya */}
      <StaticHeader title="Dashboard Utama" />
      
      {/* Bagian dinamis di-stream secara asinkron menggunakan Suspense */}
      <Suspense fallback={<UserProfileSkeleton />}>
        <DynamicUserProfile />
      </Suspense>
    </main>
  );
}

Bandingkan pengalaman di atas dengan pendekatan klasik menggunakan CDN Workers (seperti Cloudflare Workers) yang dipadukan dengan ISR Next.js. Di sini, beban konfigurasi bergeser dari kode frontend murni ke lapisan jaringan (Edge Network). Anda harus menulis skrip JavaScript/TypeScript di Cloudflare Worker untuk mencegat setiap request, mengatur cache tags, dan menangani KV storage atau D1 database secara manual.

// worker.js (Cloudflare Workers untuk Cache dan Re-validation)
addEventListener('fetch', event => {
  event.respondWith(handleRequest(event.request));
});

async function handleRequest(request) {
  const url = new URL(request.url);
  const cache = caches.default;
  let response = await cache.match(request);

  if (!response) {
    // Fetch dari Origin Server Next.js
    response = await fetch(request);
    let headers = new Headers(response.headers);
    
    // Paksa cache di edge selama 60 detik dengan stale-while-revalidate
    headers.set('Cache-Control', 'public, max-age=0, s-maxage=60, stale-while-revalidate=300');
    
    response = new Response(response.body, { ...response, headers });
    event.waitUntil(cache.put(request, response.clone()));
  }

  return response;
}

[!WARNING] Kesalahan kecil dalam mengatur header s-maxage pada CDN Workers dapat menyebabkan halaman pribadi pengguna (seperti keranjang belanja atau profil) ter-cache secara publik di Edge. Selalu gunakan header Vary: Cookie atau pastikan rute dinamis dikecualikan dari Edge caching global.

Kode yang elegan dan konfigurasi yang rapi tidak ada artinya jika infrastruktur runtuh ketika jutaan pengguna menekan tombol refresh secara bersamaan. Mari kita uji ketahanan kedua pendekatan ini di arena sesungguhnya.

3. Ronde 2: Ketahanan di Bawah Gempuran Beban Ekstrem

Untuk membuktikan mana arsitektur yang lebih tangguh, kami menggelar simulasi beban menggunakan k6 dan wrk untuk mensimulasikan 50.000 virtual users (VUs) yang mengakses halaman produk secara serentak. Skenario ini dirancang untuk melihat titik jenuh CPU pada server origin dan seberapa efektif sistem menahan lonjakan trafik (Traffic Spike).

Pada pengujian kubu ISR + CDN Workers, hasilnya di luar dugaan sangat mulus. Karena 98% request berhasil ditangkap oleh Cloudflare Edge Nodes di berbagai belahan dunia, server origin (Node.js/PHP-FPM di belakang Nginx) hampir tidak merasakan beban sama sekali. Penggunaan CPU server origin bertahan di angka 4%, dan latensi rata-rata (p99) tetap stabil di bawah 45 milidetik.

Sebaliknya, pada kubu Partial Prerendering (PPR) murni yang bergantung pada eksekusi Node.js Edge Runtime atau Serverless Functions untuk merender bagian dinamis pada setiap miss cache, situasinya jauh lebih menantang. Ketika cache pada komponen dinamis kedaluwarsa, lonjakan request langsung menghantam fungsi serverless, memicu lonjakan penggunaan CPU hingga 89%, dan meningkatkan latensi p99 hingga 320 milidetik sebelum sistem Auto-Scaling merespons.

# Perintah k6 untuk simulasi lonjakan beban ekstrem
k6 run --vus 5000 --duration 60s load-test-script.js

// load-test-script.js (Skrip uji beban k6)
import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  stages: [
    { duration: '10s', target: 1000 },
    { duration: '30s', target: 5000 },
    { duration: '20s', target: 0 },
  ],
};

export default function () {
  const res = http.get('https://staging.ecommerce-battle.internal/products/sepatu-lari-pro');
  check(res, {
    'status adalah 200': (r) => r.status === 200,
    'latensi di bawah 200ms': (r) => r.timings.duration < 200,
  });
  sleep(1);
}

[!TIP] Jika aplikasi Anda menghadapi lonjakan trafik yang tidak terduga (seperti penjualan tiket konser atau flash sale), mengandalkan Edge Cache berbasis CDN Workers memberikan lapisan pertahanan pertama yang jauh lebih kebal dibandingkan menyerahkan seluruh proses dinamis langsung ke Serverless Functions.

Performa tinggi tentu harus dibayar dengan sumber daya. Mari kita hitung berapa banyak biaya server dan kapasitas RAM yang harus dikorbankan untuk memelihara kedua arsitektur ini di lingkungan produksi.

4. Ronde 3: Konsumsi Sumber Daya Server & Efisiensi Biaya Nyata

Arsitektur yang hebat bukan hanya soal kecepatan, tetapi juga tentang seberapa ramah ia terhadap anggaran perusahaan. Di sinilah perhitungan biaya infrastruktur menjadi penentu utama bagi seorang Principal Architect.

Pendekatan ISR + CDN Workers memindahkan sebagian besar komputasi dan penyimpanan cache ke infrastruktur pihak ketiga (seperti Cloudflare). Biaya operasional dihitung berdasarkan jumlah permintaan (requests) di Edge dan penyimpanan KV/D1. Untuk server Origin (tempat database MySQL/PostgreSQL dan Redis berjalan), kebutuhan RAM sangat minimal—cukup dengan server 2vCPU dan 4GB RAM untuk melayani database karena sebagian besar beban baca (read load) telah diserap oleh CDN.

Di sisi lain, Partial Prerendering (PPR) menuntut lingkungan Node.js yang aktif atau dukungan penuh dari platform hosting serverless modern (seperti Vercel, AWS Lambda, atau Cloudflare Workers dengan Node compatibility). Meskipun menghemat waktu pengembangan karena integrasinya yang mulus, biaya pemanggilan fungsi serverless (Invocations) dapat melonjak drastis jika aplikasi Anda memiliki jutaan kunjungan unik setiap hari yang memicu Suspense boundary dinamis.

[!IMPORTANT] Perhatikan struktur tagihan bulanan Anda. Jangan sampai adopsi arsitektur berbasis Edge modern membuat biaya komputasi awan membengkak 3x lipat hanya karena cache hit-rate pada komponen dinamis terlalu rendah.

Setelah melihat angka, performa, dan konsumsi sumber daya, tiba masanya untuk mengambil keputusan tegas: kapan Anda harus memilih salah satu dari teknologi ini, dan kapan keduanya justru menjadi pilihan yang salah.

5. Kapan Wajib Menggunakan Partial Prerendering (PPR)

Anda wajib mengadopsi Partial Prerendering (PPR) pada skenario arsitektur berikut:

1. Aplikasi Dashboard yang Sangat Dipersonalisasi: Halaman yang memiliki struktur tata letak (sidebar, header, navigasi) yang persis sama untuk semua pengguna, tetapi memuat data widget spesifik pengguna (seperti saldo akun, grafik penjualan pribadi, atau notifikasi) yang harus selalu fresh.
2. E-commerce dengan Keranjang Belanja Dinamis: Halaman detail produk di mana galeri gambar, deskripsi, dan ulasan bersifat statis, sementara tombol "Tambah ke Keranjang" dan status stok real-time memerlukan data dinamis instan.
3. Tim dengan Fokus Produktivitas Frontend: Ketika tim Anda ingin menghindari kerumitan menulis aturan cache invalidation yang rumit di level CDN, dan ingin menyerahkan manajemen streaming dan Suspense secara otomatis kepada kompiler framework.

6. Kapan Wajib Menggunakan ISR dengan CDN Workers

Sebaliknya, Anda wajib memilih kombinasi ISR dan CDN Workers pada kondisi berikut:

1. Situs Berita dan Media Skala Masif: Portal berita dengan jutaan pembaca harian di mana 99% konten berupa artikel statis yang jarang berubah setelah dipublikasikan, namun membutuhkan TTFB di bawah 50 milidetik secara global.
2. Katalog Produk Statis dengan Trafik Tinggi: Halaman direktori produk atau dokumentasi teknis yang jarang mengalami perubahan personalisasi per individu pengguna, di mana strategi Cache-First mutlak diperlukan untuk menahan serangan trafik ekstrem.
3. Infrastruktur Mandiri (Self-Hosted): Ketika perusahaan mewajibkan seluruh infrastruktur berjalan di atas on-premise servers atau Private Cloud di belakang Nginx/Caddy tanpa ketergantungan penuh pada layanan proprietary Edge vendor tertentu.

7. Keputusan Akhir: Rekomendasi Jujur untuk Tim Engineering

Pertarungan antara optimasi Edge berbasis CDN Workers dan Partial Prerendering bukanlah pertarungan tentang mana yang secara mutlak lebih baik, melainkan tentang mencocokkan karakteristik beban kerja produk Anda dengan kemampuan arsitektur yang tersedia.

Jika produk Anda adalah aplikasi SaaS interaktif yang kompleks dengan data yang sangat dinamis per pengguna, Partial Prerendering adalah masa depan arsitektur web yang akan menyelamatkan kewarasan tim frontend Anda. Namun, jika fokus utama Anda adalah kecepatan distribusi konten publik berskala masif dengan ketahanan mutlak terhadap lonjakan trafik, kombinasi ISR klasik dan CDN Workers tetap menjadi juara bertahan yang paling dapat diandalkan di lapangan.

Evaluasi kembali kebutuhan bisnis Anda, ukur ulang metrik Core Web Vitals saat ini, dan pilihlah strategi yang tidak hanya membuat situs Anda cepat di atas kertas, tetapi juga stabil dan efisien saat badai trafik benar-benar menerjang.