Next.js 15.1+ pada praktiknya tidak bisa digunakan di lingkungan selain Vercel

 (omarabid.com)
13 poin oleh GN⁺ 2025-06-13 | 5 komentar | Bagikan ke WhatsApp
  • Sejak Next.js 15.1.8, cara pemrosesan metadata berubah, sehingga menimbulkan masalah serius di lingkungan deployment selain Vercel
    • Metadata tidak lagi dirender langsung ke HTML head, melainkan dikirim terpisah melalui metode yang disebut "metadata streaming"
  • Jika mesin pencari tidak menjalankan JavaScript, metadata sama sekali tidak akan terlihat sehingga SEO rusak parah
    • Ada penanganan pengecualian melalui deteksi crawler (htmlLimitedBots), tetapi tidak sempurna
  • Netlify, Cloudflare, AWS, dan lainnya yang bukan Vercel mencoba kompatibel melalui OpenNext, tetapi pada praktiknya Next.js terlalu terikat kuat pada infrastruktur Vercel sehingga porting sendiri sulit dan penuh bug
  • Bahkan build statis pun tidak menyertakan metadata di HTML head, sehingga semua lingkungan deployment dipaksa mengadopsi struktur rumit yang mengandalkan deteksi crawler/eksekusi JS
  • Isu keamanan (kerentanan kritis yang diumumkan pada Maret 2025)
    • Jika tetap bertahan di versi lama untuk menghindari metadata streaming, Anda akan terekspos pada kerentanan keamanan serius (patch hanya tersedia di 15.2.3)
  • Metadata streaming pada kenyataannya menyembunyikan masalah performa halaman, dan juga berdampak negatif pada SEO
  • Kesimpulan:
    Next.js terlihat seperti open source, tetapi pada praktiknya telah menjadi framework dengan ketergantungan berat pada Vercel, sehingga lebih bijak mempertimbangkan pilihan lain untuk proyek baru

Ikhtisar

  • Mulai versi Next.js 15.1.8, muncul masalah serius dalam pemrosesan metadata di lingkungan selain Vercel
  • Hal ini pada dasarnya memperdalam ketergantungan pada infrastruktur Vercel dalam Next.js, menurunkan optimasi mesin pencari (SEO), bahkan memunculkan ancaman keamanan

Awal masalah: diperkenalkannya metadata streaming

  • Pada 2024, Vercel memperkenalkan fitur eksperimental bernama metadata streaming
  • Berbeda dari cara lama, metadata (tag seperti title, description, Open Graph, dll.) tidak dirender langsung ke HTML head, melainkan dikirim terpisah setelah pemuatan awal halaman
  • Fitur ini membuat eksekusi JavaScript menjadi diperlukan

Penjelasan teknis Vercel dan masalah nyata di lapangan

  • Latar belakang penerapan: untuk mengatasi bottleneck komputasi dalam pembuatan metadata
  • Namun pada kenyataannya, metadata umumnya statis dan berukuran kecil (kurang dari 1KB)
  • Biaya server round-trip lebih besar daripada pemrosesan inline
  • Metadata dinamis hanyalah kasus pengecualian yang sangat sedikit
  • Implementasi metadata streaming justru menambah kompleksitas dan kebingungan

Latar belakang masalah performa

  • Beberapa developer mengalami isu performa berupa keterlambatan pembuatan metadata, misalnya saat terhubung ke API eksternal
  • Untuk mengatasi masalah ini, Vercel mengembangkan metode streaming

Crawler mesin pencari dan dampaknya pada SEO

  • Mesin pencari yang tidak menjalankan JavaScript tidak dapat membaca metadata
  • Akibatnya, hal ini berdampak buruk besar pada SEO
  • Sebagai solusi, Vercel menyediakan fitur htmlLimitedBots, di mana server akan melewati streaming dan menaruh metadata di HEAD jika mendeteksi crawler

Keterbatasan penyedia cloud lainnya

  • Netlify, Cloudflare, AWS, dan lainnya juga membuat proyek adaptor bernama OpenNext agar kompatibel dengan Next.js
  • Namun karena Next.js terlalu bergantung erat pada Vercel, proses porting memerlukan reverse engineering
  • Karena masalah kualitas OpenNext, pada praktiknya hasilnya tidak berjalan dengan baik

Bahkan build statis pun tidak lengkap

  • Bahkan build situs statis (Static Build) kini tidak lagi menyertakan metadata di HTML head
  • Karena dibundel bersama React Server Components, eksekusi JavaScript menjadi perlu
  • Demi metadata HTML dasar saja, muncul kejanggalan bahwa kita bahkan harus mengimplementasikan logika deteksi crawler sendiri

Kerentanan keamanan serius dan masalah pembaruan

  • Pada 21 Maret 2025, kerentanan kritis (peringkat keamanan 9.1, GHSA-f82v-jwr5-mffw/CVE-2025-29927) diumumkan
  • Kerentanan ini memungkinkan bypass keamanan autentikasi middleware melalui manipulasi header tertentu
  • Patch kerentanan diterapkan pada Next.js 15.2.3, tetapi jika tetap bertahan di 15.1.8 untuk menghindari metadata streaming, maka keamanannya menjadi sangat rentan

Dampak negatif dari penerapan streaming

  • Metadata streaming semakin menyembunyikan masalah performa yang tersembunyi
  • Ketika pemrosesan metadata halaman terlambat, pengguna nyata tidak akan menyadarinya
  • Crawler mesin pencari akan memberikan penalti skor SEO akibat respons yang lambat

Kesimpulan

  • Next.js telah berubah menjadi vendor lock-in Vercel yang menyamar sebagai framework open source
  • Saat memilih tech stack untuk proyek berikutnya, lebih bijak mempertimbangkan framework lain alih-alih Next.js

Bacaan terkait

5 komentar

 
kansm 2025-06-13

Kalau begitu, remix jadi alternatifnya, kan?
 
bth15923 2025-06-13

Seperti yang disebutkan di isi artikel, vendor lock-in yang berlebihan, perilaku yang terlalu terasa seperti black box, dan API yang tidak intuitif. Selain itu, dari pihak React sendiri juga terang-terangan memasarkan model pengembangan seperti merender di server ini seolah-olah merupakan cara pengembangan standar React. Menurut saya, sebagian besar aplikasi sudah cukup dengan SPA berbasis Vite.
 
pcj9024 2025-06-13

Vendor lock-in sampai batas tertentu saya akui, tetapi kalau melihat opini tentang teknologi Next.js itu sendiri, rasanya tidak lebih dari sekadar level "saya tidak mau membaca artikelnya".
 
ndrgrd 2025-06-13

Sejak dulu mereka terus bersikap seolah terbuka, padahal langkah-langkahnya tertutup, dan akhirnya kini hampir sepenuhnya menutup pintu.
 
GN⁺ 2025-06-13
Opini Hacker News

  • Sama sekali tidak merekomendasikan memakai Next. Pengalaman developernya mengerikan, vendor lock-in parah, dan karena banyak konvensi aneh yang tidak terdokumentasi, rasanya penuh ranjau di mana-mana kecuali untuk SaaS B2B sederhana yang fokus CRUD. Saya bahkan pernah mengalami kasus di mana tag Next <Image /> menjatuhkan FPS scene WebGL di halaman yang sama sampai 2

    • Saya heran bagaimana Vercel pelan-pelan merebus pengguna React umum ke dalam vendor lock-in. React adalah proyek dari Meta yang menekankan open source, dan saya berharap open source bisa mencegah vendor lock-in, tetapi kenyataannya tidak begitu, dan itu mengecewakan

    • Sangat setuju. Baru-baru ini saya memakai Next lagi setelah lama, dan pengalaman developernya sangat mengecewakan. Dokumentasinya ambigu dan sulit dicari, dan aplikasi itu sendiri terasa lambat secara default. Saat mencoba deploy ke AWS dengan Docker, saya mengalami banyak kesulitan karena sample Dockerfile yang disediakan Vercel

    • Saya penasaran apakah isu <Image /> itu dianalisis langsung, atau hanya dugaan bahwa itu masalah NextJs. Saya bekerja dengan kombinasi NextJs, <Image>, dan RTF, tetapi belum pernah mengalami masalah seperti itu

  • Saya memakai Next.js untuk kerja selama 3 tahun terakhir, dan rasanya benar-benar menyakitkan. Kami hosting di Vercel, dan perusahaan mengadopsi hampir semua layanan Vercel, jadi benar-benar merasakan vendor lock-in. Dulu saya pernah membagikan pengalaman buruk di postingan HN yang ditulis Dan soal RSC, dan saya merasa penilaiannya tepat. Seperti katanya, "RSC sendiri sekarang sudah cukup solid, tetapi framework seperti Next.js masih agak kasar". Secara keseluruhan React sendiri sekarang rasanya di bawah rata-rata, dan Next.js justru mempercepat reputasi buruk itu. Sebaiknya dijauhi

  • Vercel mungkin akan memperbaiki bug kali ini, tetapi sekarang saya sudah lelah dengan Next.js karena masalah-masalah kecil seperti ini terus menumpuk. Contohnya, cara mengidentifikasi prefetch di middleware sudah rusak selama beberapa minggu, atau mungkin beberapa bulan. Masalah kecil seperti ini terus terakumulasi, jadi rasa lelah terhadap Next.js makin besar. Tapi saya masih suka ekosistem JS itu sendiri

    • Saya keluar dari Next.js dan pindah ke Astro. Saya ingin kembali ke dasar, tetapi malas menyiapkan route/template/static asset/build sendiri. Astro menangani semua itu dan SSR secara default. Rasanya seperti memakai React/Vue sebagai lapisan interaktivitas sebagaimana niat awalnya, dan itu membuat saya sadar betapa sebenarnya framework JS sering tidak diperlukan. Next makin penuh elemen "ajaib", server action terasa canggung, dan terlalu banyak implementasi yang harus dilakukan dengan "cara NextJS"

    • Saat ini saya masih memakai Next.js untuk kerja dan proyek sampingan, tetapi dulu ini alat yang menyenangkan dan produktif, lalu arahnya terasa mengecewakan setelah transisi dari pages ke app router

    • Sejak versi 15.1.8, beberapa library 1 rusak, sehingga kami terpaksa downgrade ke versi rentan yang disebut penulis

    • Setuju. Ke depan saya hanya berencana memakai Next.js untuk situs statis atau SPA yang dibangun sebelumnya

  • Next sudah sampai jadi bahan lelucon. Setelah Remix berubah menjadi react-router dengan cara yang sulit dipahami, rasanya framework React yang layak jadi sangat sedikit. Akhirnya saya kembali ke kombinasi plain vite dan tanstack router

    • Saya malah heran tulisan kritis seperti ini masih bertahan di Hacker News. Dulu saya pernah memposting bahwa hal yang sama bisa dibuat lebih sederhana dengan Remix, lalu beberapa karyawan Vercel menghubungi saya dan meminta agar postingannya diturunkan atau mengajak meeting. Mereka menghubungi lewat beberapa akun media sosial sekaligus

    • Saya penasaran apakah maksudnya Anda tidak lagi memakai Remix setelah rebranding, atau maksudnya itu bukan lagi framework. RR7 (React Router 7) juga berfungsi normal sebagai framework 1. Saya 15 tahun jadi backend engineer lalu belakangan pindah ke full-stack, memakai RR7 atas rekomendasi teman baik, dan hampir setiap hari terkesan

    • Saya mencoba TanStack Router di proyek baru dan sangat menyukainya, lalu menambahkan TanStack Query dan TanStack Form juga

    • Saya penasaran apa alternatif terbaiknya, dan kenapa memakai Vite. Saya memakai Next untuk proyek kecil, dan katanya keunggulan terbesarnya adalah SEO. Kalau cukup generate file statis lalu upload ke S3, bukankah itu saja sudah cukup?

    • Saya penasaran apa tepatnya masalah dari perubahan Remix menjadi react-router. Dari sudut pandang saya, itu hanya rebranding

  • Sudah bertahun-tahun saya menekankan bahwa React, Next, Svelte, dan sebagainya yang didorong oleh pihak seperti Vercel harus didekati jauh lebih hati-hati. Tujuan mereka seperti Heroku, tetapi jauh lebih agresif dalam mendorong lock-in total di seluruh stack, dari bahasa-runtime-mesin. Perusahaan lain juga punya masalah. Misalnya, tool deploy CLI milik Cloudflare hanya mendukung macOS 13.5+ saja, yang umurnya baru sedikit di atas 2 tahun, dan tidak jelas kenapa. Menyedihkan melihat OS yang rilis 2 tahun lalu sudah dianggap usang. Versi lama wrangler memang masih bisa dicoba, tetapi dokumentasi dan fiturnya tidak cocok, dan sepertinya hanya akan makin buruk. Suatu hari kompatibilitasnya juga bisa diputus. Sementara itu tool lain seperti vim, neovim, emacs, dan sebagainya masih berjalan di OS X lama. Saya rasa itu karena tool open seperti ini tidak punya insentif lock-in

  • Next dan RSC adalah hal paling membuat frustrasi yang pernah saya tangani di frontend. Frontend saja sudah cukup bikin pusing, lalu ditambah "sihir" Next dan vendor lock-in ke Vercel. Minggu ini tim kami akan beralih ke tanstack router dan vite untuk mencoba membuat CSA biasa, dan saya menantikannya

    • Saya penasaran apa yang begitu membuat frustrasi dari RSC. Dalam pengalaman saya, itu bekerja sangat baik, dan satu-satunya alasan saya masih memakai Next.js justru karena RSC

  • Semua orang perlu lebih banyak membahas fenomena Next.js di mode development yang butuh 10 detik untuk compile route. Rasanya compiler Rust sedang santai merokok di pojok sambil menonton

    • Sudah sampai level tidak bisa dipakai. Itu devx terburuk yang pernah saya alami. Terakhir kali saya sebegitu bencinya pada sebuah stack cuma saat membantu situs Sharepoint

    • Sekarang bahkan JS yang cuma bahasa scripting harus melewati tahap build/compile berkali-kali, sampai lebih lama dari compiler C++. Rasanya memasukkan Clang ke browser pun bisa jadi pengalaman yang lebih baik. Sebagai referensi, di kantor kami juga memakai PHP dan masalahnya mirip. Saya kira karena bahasa scripting akan sederhana, tetapi karena keterbatasan performa PHP sendiri, kami harus menambahkan tahap pre-generate kode dan build Composer terpisah. Masalahnya, build buatan developer PHP itu juga lambat. Mungkin karena bukan dibuat oleh orang-orang yang membuat GCC

    • Anehnya, opsi next dev —-turbo juga tidak lebih cepat di codebase perusahaan kami

    • Compiler Rust benar-benar melakukan pekerjaan kompilasi, jadi saya penasaran apakah compiler Next.js sebenarnya melakukan pekerjaan yang memang serumit itu

  • Sedih melihat kondisi Next.js sekarang. Saya masih memakainya, tetapi sampai harus mem-fork dan mem-patch sendiri. next.config.js adalah jalur pelarian yang berat untuk mengubah perilaku default, padahal menurut saya opsi seperti ini seharusnya disediakan sebagai extension point sejak awal, bukan disembunyikan di balik "feature flag". Sekarang framework ini terasa nyaris seperti spaghetti code dengan nilai D

  • Kalau bukan NextJS, apa kombinasi yang direkomendasikan untuk keseluruhan stack? Saya backend developer dengan pengalaman 15 tahun, tetapi frontend pertama saya sejak AngularJS. Belakangan saya ingin membuat aplikasi full-stack untuk side project, dan setelah mencari-cari, Gemini maupun dokumentasi resmi sama-sama merekomendasikan NextJS. Saya masih di tahap awal, jadi ingin belajar alternatif. Semuanya akan saya jalankan sendiri dengan Docker di VPS, jadi saya menghindari Vercel/Netlify

    • Kalau tidak butuh server rendering, saya merekomendasikan React tanpa framework dengan Vite 1. Saat development dijalankan dengan Vite, dan untuk build produksi hasilnya cuma file HTML + JS, jadi tinggal diunggah ke static hosting seperti S3. Saya sudah memakainya lebih dari 10 tahun tanpa masalah. Untuk backend, pakai apa pun yang paling nyaman bagi Anda; akhir-akhir ini saya banyak memakai PostgREST 2. Untuk pemanggilan API dari client, saya merekomendasikan react-query 3

    • Saya penasaran sedang mengembangkan proyek seperti apa. Saya membuat web app SaaS yang cukup tipikal, dan kombinasi React/Refine.dev/Vite terasa sangat bagus. Berkat Refine.dev, saya bisa fokus mengembangkan fitur tanpa perlu terlalu memikirkan halaman CRUD

  • Menurut saya isu ini dibesar-besarkan. Bagi orang yang paham bagaimana streaming bekerja di React, seharusnya sudah jelas bahwa HTML tidak bisa di-stream satu baris per satu baris. First paint tidak boleh tertahan hanya karena metadata, dan yang dimaksud di sini adalah HTML, bukan JS. Mengecualikan sebagian user agent untuk perilaku seperti ini terdengar masuk akal. Untuk mayoritas traffic, yang penting adalah menampilkan sesuatu secepat mungkin. Saya penasaran bagaimana seharusnya menangani pengguna yang metadata-nya butuh waktu lama untuk dimuat