Partial Prerendering Next.js untuk Marketer Indonesia: Cara Halaman Statis Tetap Personalisasi 2026

TL;DR: Partial Prerendering (PPR) adalah fitur Next.js yang merender bagian statis halaman dulu, lalu streaming bagian dinamis kemudian. Hasilnya: pengunjung lihat konten utama dalam <500 ms, sambil widget personalisasi atau data live tetap muncul. Cocok untuk landing page bisnis yang butuh kecepatan dan personalisasi sekaligus.

Dalam beberapa proyek terakhir, saya sering ketemu trade-off klasik. Marketer minta landing page yang personalisasi berdasarkan UTM atau lokasi pengunjung, sementara developer khawatir personalisasi merusak skor Core Web Vitals. Sampai 2024, pilihan biasanya: statis dan cepat, atau dinamis dan lambat.

Per April 2026, Next.js sudah ship Partial Prerendering sebagai fitur stabil. Halaman bisa punya shell statis yang ter-cache di CDN, sambil tetap menampilkan komponen dinamis seperti nama pengunjung atau jumlah stok real-time. Marketer tidak perlu lagi pilih antara kecepatan dan personalisasi.

Cara Kerja Partial Prerendering

Next.js memisahkan halaman jadi dua zona. Zona pertama adalah shell statis: header, hero, body utama, footer. Bagian ini di-prerender saat build, lalu disimpan di edge CDN. Saat pengunjung buka halaman, shell langsung muncul dalam 100-300 ms.

Zona kedua adalah dynamic holes. Komponen seperti "selamat datang [nama]", live counter, atau personalized CTA dikirim sebagai stream HTTP. Mereka muncul beberapa ratus milidetik setelah shell, ditandai loading skeleton sebentar.

Untuk pengunjung, halaman terasa instan. Untuk mesin pencari dan AI Agent, halaman statis utama langsung tersedia. Pelajari arsitektur dasar di App Router Next.js.

Kapan Pakai PPR

Rule of thumb: pakai PPR jika halaman butuh kecepatan statis tapi ada 1-3 elemen yang harus dinamis per visitor. Kalau seluruh halaman dinamis, pakai SSR. Kalau seluruh statis, pakai SSG.

Studi Kasus: Landing Page Vetmo

Saat membantu Vetmo (platform pet care), kami punya kebutuhan unik. Hero dan service breakdown harus statis untuk skor INP yang baik. Tapi widget "klinik terdekat" harus berdasarkan geolokasi pengunjung. Sebelum PPR, kami pakai client-side fetch yang bikin layout shift dan skor CLS turun.

Setelah migrasi ke PPR, shell statis muncul dalam <300 ms. Widget klinik terdekat streaming masuk dalam 800 ms tanpa layout shift karena kita reserve space dengan skeleton. Skor Core Web Vitals naik signifikan dalam 2 minggu observasi pertama.

Outbound: Pedoman Resmi

Baca dokumentasi resmi di Next.js Partial Prerendering. Untuk konteks Core Web Vitals, rujuk web.dev INP guide.

Pertanyaan Umum

Apakah PPR mendukung semua hosting Next.js?

PPR butuh runtime yang mendukung streaming. Vercel sudah penuh support. Untuk self-hosting di Node.js, perlu pastikan reverse proxy tidak buffer response.

Apakah saya perlu refactor seluruh halaman?

Tidak. Cukup tandai komponen dinamis dengan Suspense boundary. Bagian statis tetap pakai default behavior. Migrasi bisa bertahap per halaman.

Bagaimana PPR memengaruhi SEO?

Positif. Karena shell statis terkirim duluan dalam ms pertama, Googlebot dan AI Agent bisa parse konten utama tanpa nunggu komponen dinamis. Indexing jadi lebih efisien.

Coba di 1 Landing Page Dulu

Pilih 1 landing page yang punya 1-2 elemen dinamis. Refactor pakai Suspense boundary, aktifkan PPR experimental di next.config. Ukur skor Core Web Vitals sebelum dan sesudah. Dalam 1-2 minggu Anda akan punya data konkret apakah PPR layak diadopsi di seluruh site.