Partial Prerendering Next.js: Cara Website Bisnis Indonesia Gabungkan Statis dan Dinamis dalam Satu Halaman 2026

TL;DR: Partial Prerendering (PPR) adalah fitur Next.js 15 yang merender shell statis halaman lebih dulu, kemudian melengkapinya dengan komponen dinamis lewat streaming. Hasilnya, pengunjung dari Indonesia melihat konten utama dalam hitungan ratusan milidetik tanpa kehilangan personalisasi. Strategi paling sehat: pakai PPR untuk halaman produk, dashboard ringan, dan listing yang punya bagian personal terbatas.

Selama lima tahun terakhir, tim website bisnis Indonesia terjebak dalam dilema lama. Pilih Static Site Generation dan halaman cepat tapi tidak bisa menampilkan harga real-time atau status stok. Pilih Server-Side Rendering dan halaman jadi personal tapi lambat di koneksi 4G. Saat Vito Atmo membangun ulang Nalesha (e-commerce parfum) di Next.js 15 awal 2026, dilema itu mulai cair berkat Partial Prerendering.

PPR bukan sekadar fitur teknis. Untuk bisnis yang menjual lewat website di Indonesia, kemampuan menyajikan struktur halaman instan sambil melengkapi bagian personal di belakang layar berarti dua hal sekaligus: skor Core Web Vitals yang kompetitif dan konten yang tetap relevan dengan pengunjung.

Apa Masalah yang Diselesaikan PPR?

Halaman katalog produk khas e-commerce Indonesia punya empat bagian dengan kebutuhan berbeda. Header, kategori, dan deskripsi produk relatif statis. Harga dan stok berubah tiap menit. Rekomendasi personal berubah per pengguna. Tombol keranjang harus interaktif. Sebelum PPR, tim biasanya memaksa seluruh halaman jadi dinamis demi 10 sampai 20 persen bagian yang memang berubah, dengan biaya halaman jadi lambat untuk semua pengunjung.

PPR membalik logika ini. Shell halaman (header, kategori, deskripsi) di-prerender saat build sehingga bisa dikirim dari CDN dalam hitungan puluhan milidetik. Bagian dinamis (harga, stok, rekomendasi) di-render di server lalu di-stream menyusul. Pengunjung melihat layout langsung, kemudian bagian dinamis muncul mengisi lubang.

Kerangka Memilih: Kapan PPR, Kapan Bukan

Berikut tabel keputusan yang dipakai Vito Atmo di proyek client Indonesia:

Aturan praktis: jika 50 persen atau lebih halaman bersifat statis dan sisanya dinamis dengan latensi rendah, PPR memberi return tertinggi.

Studi Kasus: Nalesha (E-commerce Parfum)

Saat migrasi Nalesha ke Next.js 15, halaman produk paling populer awalnya dirender penuh dengan SSR. LCP rata-rata di koneksi Telkomsel 4G adalah 3,2 detik, jauh dari ambang "Good" 2,5 detik versi Google web.dev untuk Core Web Vitals. Setelah memisahkan shell statis (deskripsi produk, foto utama, layout) dengan PPR dan menempatkan harga, stok, serta rekomendasi di Suspense boundary, LCP turun ke kisaran 1,4 sampai 1,7 detik. Conversion rate dari pengunjung mobile naik dengan rentang 12 sampai 18 persen dalam empat minggu pertama. Angka ini akan bervariasi tergantung industri dan ukuran trafik, namun pola umum sama: shell cepat membuat pengunjung lebih sabar menunggu bagian dinamis.

Implementasi praktisnya cukup ringkas. Komponen React Server Components untuk bagian statis, Suspense boundary untuk bagian dinamis, dan flag experimental.ppr di next.config.ts. Tidak ada arsitektur baru yang perlu dipelajari ulang.

Pertanyaan Umum

Apakah PPR sudah stabil di Next.js 15?

Per Mei 2026, PPR masih berstatus experimental tapi sudah dipakai produksi oleh beberapa perusahaan besar termasuk Vercel sendiri. Untuk klien Indonesia, Vito Atmo merekomendasikan adopsi setelah staging test minimal dua minggu.

Apakah PPR menggantikan ISR?

Tidak. ISR cocok untuk konten yang refresh per interval (artikel, blog), PPR cocok untuk halaman dengan campuran statis-dinamis di satu render. Keduanya boleh hidup berdampingan dalam satu aplikasi.

Apakah PPR bekerja di hosting selain Vercel?

PPR butuh runtime yang mendukung Node.js streaming response. Vercel adalah yang paling matang, namun self-hosting di Docker dengan Node 18+ secara teknis bisa.

Berapa lama implementasi PPR untuk website yang sudah jalan?

Untuk website Next.js 14 dengan App Router, migrasi inti biasanya 1 sampai 2 sprint, ditambah waktu testing. Untuk yang masih di Pages Router, butuh refaktor App Router dulu.

Apa yang Sebaiknya Tim Indonesia Lakukan Minggu Ini

Identifikasi tiga halaman tersering yang punya campuran konten statis dan dinamis (biasanya katalog, listing, halaman produk). Ukur LCP dan INP saat ini lewat PageSpeed Insights atau CrUX. Jika ada gap besar antara mobile dan desktop, PPR adalah eksperimen pertama yang layak dijajal. Mulai dari satu halaman, ukur dampaknya selama dua minggu, baru gulirkan ke seluruh template.