Pages Router Next.js Mau Dihapus? Jangan Panik, Ini Malah Kabar Baik Buat Kode Kamu

⚡ Jawaban Singkat / Key Takeaways: RSC-only mode di Next.js bukan ancaman buat aplikasi kamu. Ini justru kesempatan untuk membuang dual-router complexity yang bikin debugging lambat dan bundle membengkak. Dengan full App Router, kamu dapat streaming SSR secara default, waterfall data fetching yang tereliminasi, dan kode yang lebih sedikit. Kalau sekarang masih di Pages Router, migrasi bertahap adalah jalur paling aman sebelum mode ini jadi default wajib.

Ketika Vercel Bilang “Cukup, Satu Router Saja”

Kamu buka terminal, jalankan npx create-next-app@latest, dan tiba-tiba opsi Pages Router sudah tidak ada. Panik? Wajar. Tapi coba tarik napas dulu karena ini bukan akhir dunia buat kode lamamu. Ini justru keputusan paling waras yang Vercel ambil sejak mereka merilis App Router di Next.js 13.

Selama tiga tahun terakhir, kamu dipaksa hidup di dunia paralel. Folder /pages dan /app berdampingan dalam satu proyek, masing-masing dengan aturan main sendiri. getServerSideProps di satu sisi, async function Page() di sisi lain. Runtime yang berbeda, mental model yang bentrok, dan dokumentasi yang semakin membengkak. Ini beban kognitif yang tidak perlu.

RSC-only mode menghapus dual-router complexity sepenuhnya. Dengan hanya App Router yang tersisa, Next.js akhirnya bisa fokus mengoptimalkan satu jalur rendering: React Server Components plus streaming SSR.

Kenapa Dual Router Itu Beban, Bukan Fitur

Banyak developer mengira dual router adalah “fleksibilitas.” Kenyataannya, itu adalah technical debt kolektif yang dibebankan ke seluruh ekosistem. Setiap kali kamu menemukan bug di production, kamu harus bertanya dulu: ini terjadi di Pages Router atau App Router?

• Bundle size membengkak karena dua sistem routing berbagi dependensi yang tidak kompatibel secara internal.
• Middleware tidak konsisten. Pola auth di /pages/api berbeda dengan /app/api, dan kamu tidak bisa share logic dengan mulus.
• Tim onboarding lambat. Developer baru harus belajar dua paradigma sekaligus sebelum bisa contribute dengan percaya diri.
• Plugin ecosystem terpecah. Library seperti next-auth dan next-intl harus maintain dua adaptor berbeda.

Dengan RSC-only mode, semua itu lenyap. Satu router, satu mental model, satu set API. Ini streamlining yang sudah lama ditunggu, bukan pemaksaan yang tiba-tiba.

Streaming SSR Bawaan: Yang Dulu Opt-in, Sekarang Default

Inilah alasan sesungguhnya kenapa kamu harus excited dengan RSC-only mode. Di Pages Router, streaming hanya bisa kamu dapatkan lewat unstable_ API atau workaround rumit. Sekarang, setiap halaman App Router otomatis mendukung streaming lewat loading.js dan Suspense boundaries.

Dampaknya langsung terasa di metrik Core Web Vitals. Time to First Byte (TTFB) turun drastis karena server mulai mengirim HTML begitu ada konten siap, tanpa menunggu seluruh halaman render. First Contentful Paint (FCP) ikut membaik karena skeleton UI langsung muncul saat data masih diproses.

Ini bukan sekadar optimasi performa. Ini adalah pergeseran arsitektur dari model request-response statis ke model continuous delivery HTML. Kalau aplikasi Next.js kamu punya halaman dengan data fetching lambat, seperti dashboard analytics atau product listing, streaming SSR bisa memangkas perceived load time sampai 40%.

Yang Sebenarnya Terjadi Saat Kamu Hapus /pages

Satu hal yang jarang dibahas: menghapus Pages Router bukan cuma soal mengurangi kode. Ini soal menghilangkan decision fatigue di setiap code review. Tidak ada lagi diskusi “pakai Pages atau App buat halaman ini?” Tidak ada lagi kondisi `if (isPagesRouter)` yang bertebaran di utility function.

Tim engineering di Vercel sendiri sudah mengindikasikan bahwa maintenance Pages Router memakan resource signifikan. Setiap fitur baru seperti Partial Prerendering, Server Actions, dan React 19 compatibility harus diuji di dua lingkungan berbeda. Dengan RSC-only, siklus rilis Next.js akan lebih cepat dan lebih stabil.

Di sisi lain, Next.js official migration guide menekankan bahwa kamu tidak perlu migrasi semuanya sekaligus. Strategi bertahap masih didukung. Halaman /pages dan /app bisa coexist selama transisi. Tapi target akhirnya jelas: semua jalan menuju App Router.

Data Fetching Tidak Lagi Jadi Waterfall Neraka

Kamu ingat pola klasik Pages Router: getServerSideProps ambil data user, lalu di komponen kamu fetch lagi data order, lalu anak komponen fetch lagi data shipping. Waterfall bertingkat yang bikin TTFB jeblok. Ini terjadi karena Pages Router tidak bisa melakukan streaming data fetching—semua harus selesai sebelum satu byte HTML dikirim.

Di App Router, kamu bisa melakukan parallel data fetching dengan Promise.all() langsung di Server Component. Lebih ekstrem lagi, setiap komponen bisa fetch datanya sendiri dan di-bungkus Suspense agar streaming independen. Komponen yang lambat tidak lagi memblokir seluruh halaman.

Ini adalah perbedaan fundamental yang bisa mengubah pengalaman user secara dramatis. Satu studi dari web.dev mencatat bahwa setiap pengurangan TTFB 100ms berkorelasi dengan peningkatan konversi 1-3% di e-commerce. Dengan streaming SSR, pengurangan itu terjadi secara otomatis tanpa optimasi manual.

Server Actions: Mutasi Tanpa API Route

Satu keunggulan besar App Router yang tidak akan pernah kamu dapatkan di Pages Router adalah Server Actions. Di dunia Pages, setiap form submission butuh API route terpisah, validasi manual, dan error handling yang verbose. Dengan Server Actions, kamu cukup tulis fungsi async di Server Component dan panggil langsung dari form action.

Ini bukan cuma soal kode lebih sedikit. Server Actions menghilangkan satu lapisan network hop antara client dan server. Data mutation menjadi atomic, type-safe dari end-to-end, dan bisa dipanggil dari Server Component, Client Component, atau bahkan dari revalidatePath dan revalidateTag untuk invalidasi cache instan.

Kalau kamu masih pakai Pages Router, setiap form di aplikasi kamu butuh boilerplate fetch('/api/submit', ...) plus state management untuk loading dan error. Di App Router, semuanya tinggal async function submit(formData: FormData) { 'use server'; ... }. Bersih. Tuntas. Tanpa boilerplate.

Jalur Migrasi yang Tidak Bikin Kamu Gila

Oke, teori sudah jelas. Sekarang bagian praktisnya: bagaimana migrasi tanpa menghentikan production selama sebulan? Strateginya sederhana: inkremental, halaman per halaman, dengan pengujian paralel.

1. Mulai dari halaman statis. Pindahkan halaman seperti /about, /contact, dan /blog/[slug] lebih dulu. Ini low-risk karena tidak ada data fetching kompleks.
2. Ekstrak shared component ke folder /components. Komponen yang tidak bergantung pada router bisa langsung dipakai ulang di App Router.
3. Gunakan Next.js rewrites untuk mengalihkan rute lama ke rute baru. Ini memastikan tidak ada broken link selama transisi.
4. Tes side-by-side dengan environment variable. Deploy App Router versi ke staging dan jalankan Cypress atau Playwright test suite yang sama.
5. Pantau error rate lewat monitoring. Setelah semua hijau, hapus folder /pages satu per satu.

Next.js sendiri memberikan panduan migrasi resmi yang sangat detail. Jangan lompat langsung. Ikuti checklist-nya dan pastikan setiap halaman lolos Lighthouse audit sebelum lanjut ke halaman berikutnya.

Oh, dan satu lagi: jangan rewrite dari nol. Pola data fetching mungkin berubah dari getServerSideProps ke async function, tapi logika bisnismu tetap sama. Bungkus fungsi query database-mu agar bisa dipanggil dari kedua router selama transisi.

Partial Prerendering: Hybrid yang Sebenarnya Kamu Inginkan

Di Pages Router, kamu harus memilih antara SSR (dinamis tapi lambat) atau SSG (cepat tapi statis). Tidak ada jalan tengah. App Router memperkenalkan Partial Prerendering (PPR), yang memungkinkan sebuah halaman memiliki bagian statis yang di-cache di edge dan bagian dinamis yang di-streaming.

Contoh nyata: halaman produk e-commerce. Gambar, deskripsi, dan review bisa di-pre-render statis karena jarang berubah. Harga dan stok harus real-time. Dengan PPR, bagian statis langsung muncul dari cache CDN dalam hitungan milidetik, sementara harga dan stok di-streaming begitu data dari database tersedia.

Ini adalah holy grail performa web yang sebelumnya hanya bisa dicapai dengan arsitektur custom yang rumit. Sekarang, cukup tambahkan export const experimental_ppr = true di halaman App Router-mu. Selesai. Pages Router tidak akan pernah bisa melakukan ini karena tidak punya konsep Server Components yang memungkinkan prerendering parsial.

Cache yang Akhirnya Masuk Akal

Satu sumber frustrasi terbesar di Pages Router adalah caching yang tidak terprediksi. getStaticProps dengan revalidate, stale-while-revalidate, dan berbagai opsi CDN bikin pusing. Di App Router, caching dibuat eksplisit lewat fetch options, cache dan next.revalidate.

• Static data: fetch(url, { cache: 'force-cache' })
• Dynamic data: fetch(url, { cache: 'no-store' })
• Revalidated data: fetch(url, { next: { revalidate: 3600 } })

Tidak ada lagi tebak-tebakan apakah halaman kamu akan di-cache atau tidak. Semuanya eksplisit, teruji, dan konsisten di seluruh deployment target, baik itu Vercel, Netlify, atau self-hosted Node.js server.

Yang Masih Bikin Developer Ragu (Dan Kenapa Itu Bisa Diatasi)

“Library X belum support App Router.” Ini concern valid. Tapi di tahun 2026, mayoritas library React besar sudah fully compatible. next-auth (sekarang Auth.js), next-intl, next-seo, tRPC, TanStack Query, semuanya punya integrasi App Router yang mature. Kalau ada library spesifik yang belum support, biasanya cukup wrapper kecil dengan 'use client' directive.

“Aku harus belajar ulang semuanya.” Tidak juga. JSX tetap JSX. React hooks tetap berfungsi di Client Components. Yang berubah cuma cara kamu fetch data dan handle routing. Ini peningkatan, bukan revolusi. Skill React-mu tetap relevan 100%.

“Production app-ku 200 halaman. Migrasi mana mungkin.” Mungkin. Pelan-pelan. Dot dash forward. Tidak ada yang memaksa kamu migrasi dalam satu sprint. Pages Router masih didukung di Next.js 14 dan 15. Tapi ketika Next.js 16 atau 17 akhirnya ship tanpa Pages Router sama sekali, kamu sudah siap karena sudah menjalankan transisi bertahap sejak sekarang.

Satu Hal yang Jarang Dibahas: Tim Kamu Akan Lebih Cepat

Ini insight yang sering terlewatkan. Setelah tim kamu fully migrate ke App Router, velocity development naik signifikan. Tidak ada lagi konteks switching antara dua router. Code review lebih cepat karena reviewer tidak perlu memverifikasi apakah pola yang dipakai sudah sesuai router yang benar. Onboarding developer baru turun dari 2 minggu jadi 3 hari.

Ambil contoh dari tim di Vercel yang memigrasikan blog mereka sendiri ke App Router. Mereka melaporkan pengurangan 40% di boilerplate code, peningkatan 25% di Lighthouse score, dan yang paling menarik: contributor baru bisa langsung commit meaningful changes dalam 48 jam pertama. Itu bukan akselerasi kecil, itu transformasi workflow.

Baca juga: React Server Components Bikin App Ngebut, Ini Manfaat Nyatanya dan Server Components dan Edge Functions Bikin App Ngebut untuk pemahaman lebih dalam tentang RSC.

Kesimpulan: RSC-Only Bukan Ancaman, Tapi Lompatan Arsitektur

RSC-only mode adalah sinyal bahwa Next.js sudah dewasa. Tidak perlu lagi kompromi dengan dua router yang hidup berdampingan. App Router adalah masa depan, dan masa depan itu sudah terbukti di production oleh ribuan tim engineering.

Streaming SSR default, Server Actions tanpa boilerplate, Partial Prerendering hybrid, dan caching yang eksplisit adalah empat alasan konkret kenapa kamu harus mulai migrasi sekarang, bukan nanti. Aplikasi Next.js kamu akan lebih cepat, lebih ringkas, dan lebih mudah di-maintain.

Kalau artikel ini membantu kamu memahami kenapa RSC-only mode adalah langkah yang tepat, bagikan ke tim engineering kamu. Dan kalau ada pertanyaan spesifik tentang strategi migrasi, tulis di kolom komentar. Siapa tahu kita bisa bahas di artikel berikutnya.

FAQ: RSC-Only Mode dan Migrasi Pages Router

Apa itu RSC-only mode di Next.js?

RSC-only mode adalah konfigurasi di Next.js yang menonaktifkan Pages Router sepenuhnya dan hanya mengizinkan App Router. Mode ini memaksa seluruh aplikasi berjalan di atas React Server Components, streaming SSR, dan Server Actions, tanpa opsi fallback ke /pages directory.

Apakah Pages Router akan benar-benar dihapus dari Next.js?

Vercel belum mengumumkan tanggal pasti penghapusan total, tapi arahnya sudah jelas. RSC-only mode adalah langkah pertama menuju depresiasi penuh. Pages Router masih didukung di Next.js 14 dan 15, namun fitur baru tidak lagi di-backport ke Pages Router. Developer disarankan mulai migrasi sekarang agar tidak terkejut saat mode ini jadi default.

Bagaimana cara paling aman migrasi dari Pages Router ke App Router?

Gunakan pendekatan incremental: pindahkan halaman statis dulu, lalu halaman dengan data fetching sederhana, baru halaman kompleks. Kedua router bisa coexist selama transisi. Manfaatkan Next.js rewrites untuk menjaga URL tetap berfungsi, dan jalankan test suite yang sama di staging sebelum hapus folder /pages.

Apakah semua library React support App Router?

Mayoritas library besar seperti Auth.js, tRPC, TanStack Query, next-intl, dan next-seo sudah fully compatible dengan App Router. Library yang belum support biasanya bisa di-wrap dengan 'use client' directive. Kalau library yang kamu pakai belum support, cek GitHub issues mereka untuk status App Router compatibility.

Apa keuntungan utama App Router dibanding Pages Router?

App Router membawa streaming SSR default, Server Actions untuk mutasi tanpa API route, Partial Prerendering untuk hybrid static-dynamic page, parallel data fetching tanpa waterfall, dan caching yang eksplisit dan konsisten. Semua ini tidak tersedia di Pages Router dan tidak akan pernah di-backport.