Partial Prerendering untuk Website Bisnis Indonesia: Cara Halaman Tetap Cepat Sambil Menyajikan Data Live di 2026

TL;DR: Partial Prerendering (PPR) memungkinkan website bisnis Indonesia menampilkan halaman dalam hitungan ratusan milidetik, sambil tetap menyajikan harga, stok, dan data user secara real-time. Per Mei 2026, fitur ini stabil di Next.js 15+ dan jadi solusi utama untuk e-commerce yang tertekan antara kecepatan SEO dan akurasi data komersial.

Selama lima tahun terakhir, developer Indonesia menghadapi pilihan yang tidak nyaman. Pakai SSG (static), website cepat tapi harga sering basi. Pakai SSR (server render), data segar tapi LCP molor di atas 3 detik. Pakai ISR, sebagian masalah teratasi tapi data masih bisa stale beberapa menit.

Dalam beberapa proyek terakhir, saya melihat tim engineering memilih kompromi yang tidak optimal hanya karena tooling belum siap. PPR mengubah situasi itu.

Dilema Klasik: Cepat atau Fresh?

Pikirkan halaman produk e-commerce. Komponennya:

• Header, navigasi, footer (jarang berubah)
• Foto produk dan deskripsi (jarang berubah)
• Harga, diskon, stok (sering berubah)
• "Disukai oleh user X" (per-user, dinamis)
• Rekomendasi produk lain (dinamis)

Dengan SSG, semua di-cache statis, tapi harga dan stok bisa salah. Dengan SSR, semua dibangun ulang setiap request, LCP lambat. Dengan ISR, ada jendela inkonsistensi 30-300 detik.

Pilihan ini memaksa marketer dan developer berdebat. Marketer ingin cepat untuk SEO, finance ingin akurat untuk margin.

Bagaimana PPR Memecahkan Dilema

Partial Prerendering memecah halaman jadi dua lapisan:

Pengguna langsung melihat shell halaman dalam 200-500 ms. Komponen dinamis muncul di slot yang sudah disiapkan via React Suspense, mengisi dalam 1-2 detik berikutnya. LCP terhitung dari shell, jadi tetap di bawah 2,5 detik.

Tidak ada lagi pilihan keras antara cepat dan fresh. Anda dapat keduanya, asalkan tahu komponen mana yang harus dibungkus Suspense.

Studi Kasus

Saat membantu Nalesha (e-commerce parfum) merombak halaman produk, kami beralih dari ISR 60 detik ke PPR. Sebelum migrasi, Core Web Vitals hijau, tapi customer service sering komplain karena stok di halaman tidak sinkron dengan inventory. Setelah PPR, LCP tetap di sekitar 1,8 detik, tapi stok dan harga dijamin live.

Yang berubah secara teknis hanya tiga hal:

1. Aktifkan experimental.ppr: true di next.config.ts
2. Bungkus komponen <HargaStok /> dan <RekomendasiProduk /> dengan <Suspense fallback={...}>
3. Pastikan komponen dinamis pakai dynamic rendering (akses cookies, headers, atau data fetch tanpa cache)

Hasilnya, customer service tidak lagi menerima keluhan harga salah, dan SEO tetap stabil di posisi atas untuk kata kunci produk.

Kapan Tidak Pakai PPR

PPR bukan solusi universal. Hindari kalau:

• Hampir seluruh halaman dinamis (dashboard internal, app SaaS) - SSR biasa lebih sederhana
• Konten purely statis (blog, dokumentasi) - SSG cukup
• Tim engineering belum familiar dengan Suspense boundary - debugging bisa rumit

Untuk website company profile dan landing page bisnis tanpa data real-time, Edge Functions dengan ISR sudah lebih dari cukup.

Cara Migrasi ke PPR

Langkah 1: Audit halaman Anda

Identifikasi komponen yang benar-benar butuh data live versus yang bisa di-cache. Sering kali developer mengasumsikan banyak komponen dinamis padahal aslinya statis.

Langkah 2: Bungkus komponen dinamis dengan Suspense

<Suspense fallback={<HargaSkeleton />}>
  <HargaStok productId={id} />
</Suspense>

Langkah 3: Verifikasi dengan Lighthouse

Setelah migrasi, jalankan Lighthouse atau cek di PageSpeed Insights untuk pastikan LCP membaik dan tidak ada regresi CLS.

Langkah 4: Monitor di production

Pakai Vercel Speed Insights atau alat serupa untuk pastikan PPR bekerja di traffic nyata, bukan hanya di environment test.

Detail teknis lengkap ada di dokumentasi resmi Next.js.

Pertanyaan Umum

Apakah PPR butuh Vercel?

Tidak wajib, tapi paling mudah di Vercel karena infrastruktur PPR sudah disiapkan. Self-hosted juga bisa selama runtime Next.js mendukung streaming.

Apakah PPR berdampak negatif ke SEO?

Tidak. Googlebot meng-render shell statis pertama kali (yang cepat dan lengkap dari sisi struktur HTML), lalu mengeksekusi JavaScript untuk konten dinamis. Sinyal Core Web Vitals justru membaik.

Bagaimana PPR menangani data per-user (login)?

Bagian per-user (misal "Halo, Vito") dibungkus Suspense terpisah. Shell publik di-cache untuk semua, slot per-user di-stream khusus untuk request yang login. Tidak ada bocoran data antar user.

Bagaimana cara debug saat komponen tidak streaming?

Cek dua hal: (1) komponen di dalam Suspense benar-benar trigger dynamic rendering (akses cookies/headers atau pakai fetch dengan cache: "no-store"), dan (2) tidak ada parent yang force whole page jadi dynamic.

Apakah PPR berbeda dengan Islands Architecture?

Filosofinya mirip, statis dulu lalu dinamis di pulau. Bedanya, PPR adalah implementasi Next.js spesifik dengan integrasi React Server Components, sementara Islands Architecture lebih general dan dipakai di Astro atau framework lain.

Halaman Cepat Bukan Lagi Trade-off

PPR menutup salah satu trade-off paling lama di web development. Anda tidak perlu lagi memilih antara performa dan akurasi data. Untuk website bisnis Indonesia yang serius soal SEO dan revenue, fitur ini layak masuk roadmap migrasi 2026.

Yang dibutuhkan adalah disiplin memetakan komponen statis vs dinamis. Sisanya, framework yang menyelesaikan.