Next.js 15.1+ แทบใช้งานไม่ได้จริงนอกเหนือจากบน Vercel

• ตั้งแต่ Next.js 15.1.8 เป็นต้นมา วิธีจัดการ metadata ได้เปลี่ยนไป ทำให้เกิดปัญหาร้ายแรงในสภาพแวดล้อมการดีพลอยที่ไม่ใช่ Vercel
  • metadata จะไม่ถูกเรนเดอร์ลงใน HTML head โดยตรงอีกต่อไป แต่ถูกส่งแยกต่างหากด้วยวิธีที่เรียกว่า "metadata streaming"
• หากเสิร์ชเอนจินไม่รัน JavaScript จะมองไม่เห็น metadata เลย ทำให้ SEO เสียหายอย่างรุนแรง
  • มีการทำข้อยกเว้นด้วยการตรวจจับ crawler (htmlLimitedBots) แต่ก็ไม่ได้สมบูรณ์แบบ
• ผู้ให้บริการที่ไม่ใช่ Vercel เช่น Netlify, Cloudflare, AWS พยายามทำให้เข้ากันได้ผ่าน OpenNext แต่ในความเป็นจริง Next.js ผูกติดกับโครงสร้างพื้นฐานของ Vercel มากเกินไปจนพอร์ตได้ยากและมีบั๊กจำนวนมาก
• แม้แต่ static build ก็ยังไม่ใส่ metadata ไว้ใน HTML head และโครงสร้างใหม่นี้บังคับให้ทุกสภาพแวดล้อมการดีพลอยต้องรองรับการตรวจจับ crawler/การรัน JS ที่ซับซ้อน
• ประเด็นด้านความปลอดภัย (ช่องโหว่ร้ายแรงที่เปิดเผยในเดือนมีนาคม 2025)
  • หากยึดติดกับเวอร์ชันเก่าเพื่อหลีกเลี่ยง metadata streaming ก็จะเสี่ยงต่อช่องโหว่ความปลอดภัยร้ายแรง (แพตช์มีให้เฉพาะใน 15.2.3)
• metadata streaming ซ่อนปัญหาด้านประสิทธิภาพของหน้าเว็บจริง ๆ และยังส่งผลลบต่อ SEO
• สรุป:
  Next.js ดูเหมือนโอเพนซอร์ส แต่ในทางปฏิบัติได้กลายเป็นเฟรมเวิร์กที่พึ่งพา Vercel อย่างหนัก ดังนั้นสำหรับโปรเจกต์ใหม่ การพิจารณาตัวเลือกอื่นน่าจะเป็นทางที่รอบคอบกว่า

---

ภาพรวม

• ตั้งแต่ Next.js เวอร์ชัน 15.1.8 เป็นต้นมา เกิดปัญหาร้ายแรงกับการจัดการ metadata ในสภาพแวดล้อมที่ไม่ใช่ Vercel
• สิ่งนี้สะท้อนถึง การพึ่งพาโครงสร้างพื้นฐานของ Vercel ที่ลึกขึ้นโดยเนื้อแท้ ของ Next.js พร้อมทั้งก่อให้เกิดการลดลงของ Search Engine Optimization (SEO) และแม้กระทั่ง ภัยคุกคามด้านความปลอดภัย

จุดเริ่มต้นของปัญหา: การนำ metadata streaming มาใช้

• ในปี 2024 Vercel ได้นำฟีเจอร์ทดลองชื่อ metadata streaming มาใช้
• ต่างจากแนวทางเดิม metadata (แท็กอย่าง title, description, Open Graph เป็นต้น) จะไม่ถูกเรนเดอร์ลงใน HTML `` โดยตรง แต่จะถูก ส่งแยกหลังจากการโหลดหน้าเริ่มต้น
• ฟีเจอร์นี้ทำให้ ต้องมีการรัน JavaScript

คำอธิบายเชิงเทคนิคของ Vercel และปัญหาที่เกิดขึ้นจริง

• เหตุผลของการนำมาใช้: เพื่อแก้คอขวดด้านการประมวลผลในการสร้าง metadata
• แต่ในความเป็นจริง metadata ส่วนใหญ่เป็นข้อมูล คงที่และมีขนาดเล็ก (น้อยกว่า 1KB)
• ต้นทุนของ server round-trip สูงกว่าการจัดการแบบ inline
• metadata แบบไดนามิกเป็นเพียง กรณียกเว้นส่วนน้อยมาก
• ความซับซ้อนในการนำ metadata streaming ไปใช้ยิ่งเพิ่ม ความสับสน

ที่มาของปัญหาด้านประสิทธิภาพ

• นักพัฒนาบางส่วนเคยเจอปัญหาด้านประสิทธิภาพจาก ความล่าช้าในการสร้าง metadata เช่นตอนเชื่อมต่อกับ external API
• Vercel จึงพัฒนา แนวทางแบบสตรีมมิง เพื่อแก้ปัญหานี้

ผลกระทบต่อ search engine crawler และ SEO

• เสิร์ชเอนจินที่ไม่รัน JavaScript จะอ่าน metadata ไม่ได้
• ส่งผลให้ SEO ได้รับผลกระทบอย่างมาก
• เพื่อเป็นทางแก้ Vercel จึงมีฟีเจอร์ htmlLimitedBots ที่ให้เซิร์ฟเวอร์ตรวจจับ crawler แล้วข้ามการสตรีม พร้อม ใส่ metadata ลงใน HEAD

ข้อจำกัดของผู้ให้บริการคลาวด์รายอื่น

• Netlify, Cloudflare, AWS และรายอื่น ๆ ก็สร้างโปรเจกต์ adapter ชื่อ OpenNext เพื่อให้เข้ากันได้กับ Next.js
• แต่เพราะ Next.js ผูกติดกับ Vercel มากเกินไป จึงต้องอาศัยการ reverse engineering เมื่อต้องพอร์ต
• ด้วยปัญหาด้านคุณภาพของ OpenNext ทำให้ในทางปฏิบัติใช้งานได้ไม่ดีนัก

แม้แต่ static build ก็ยังไม่สมบูรณ์

• แม้แต่ static site build ก็ไม่ใส่ metadata ลงใน HTML head อีกต่อไป
• เพราะถูก bundle มาพร้อม React Server Components จึง ต้องรัน JavaScript
• เกิดความไม่สมเหตุสมผลที่แม้เพียงต้องการ HTML metadata พื้นฐาน ก็ยังต้องลงมือทำ ตรรกะตรวจจับ crawler เอง

ช่องโหว่ความปลอดภัยร้ายแรงและปัญหาเรื่องการอัปเดต

• เมื่อวันที่ 21 มีนาคม 2025 มีการเปิดเผย ช่องโหว่ร้ายแรง (ระดับความปลอดภัย 9.1, GHSA-f82v-jwr5-mffw/CVE-2025-29927)
• ช่องโหว่นี้ทำให้สามารถข้ามการยืนยันตัวตนด้านความปลอดภัยของ middleware ได้ผ่านการดัดแปลง header บางตัว
• แม้แพตช์ของช่องโหว่นี้จะถูกใส่มาใน Next.js 15.2.3 แต่ถ้าค้างอยู่ที่ 15.1.8 เพื่อหลีกเลี่ยง metadata streaming ก็จะ เสี่ยงด้านความปลอดภัยอย่างมาก

ผลลบที่เกิดจากการนำสตรีมมิงมาใช้

• metadata streaming ยิ่งทำให้ ปัญหาด้านประสิทธิภาพที่ซ่อนอยู่ ถูกมองไม่เห็นมากขึ้น
• เมื่อการประมวลผล metadata ของหน้าล่าช้า ผู้ใช้จริงจะ ไม่ทันสังเกตเห็น
• แต่ search engine crawler จะ ให้บทลงโทษด้านคะแนน SEO ตามความช้าของการตอบสนอง

บทสรุป

• Next.js ได้กลายสภาพเป็น vendor lock-in ของ Vercel ที่สวมหน้ากากว่าเป็นโอเพนซอร์สเฟรมเวิร์ก
• เมื่อต้องเลือกเทคโนโลยีสำหรับโปรเจกต์ถัดไป การ พิจารณาเฟรมเวิร์กอื่นแทน Next.js จึงน่าจะเป็นทางเลือกที่ฉลาดกว่า

[kansm]

งั้น remix ก็กลายเป็นทางเลือกแทนสินะ?

[bth15923]

ตามที่กล่าวไว้ในบทความ มีทั้งการผูกติดกับผู้ให้บริการมากเกินไป พฤติกรรมที่เป็นกล่องดำมากเกินไป และ API ที่ไม่เป็นธรรมชาติ นอกจากนี้ฝั่ง React เองก็ยังทำการตลาดอย่างเปิดเผยราวกับว่าการพัฒนาแบบเรนเดอร์บนเซิร์ฟเวอร์เช่นนี้คือแนวทางการพัฒนามาตรฐานของ React อีกด้วย ผมมองว่าแอปส่วนใหญ่ แค่ใช้ SPA ที่อิงกับ Vite ก็เพียงพอแล้ว

[pcj9024]

ผมยอมรับได้ระดับหนึ่งว่าการผูกติดกับผู้ขายย่อมเกิดขึ้นได้ แต่พอดูความเห็นเกี่ยวกับเทคโนโลยี Next.js เองแล้ว มันก็เหมือนยังไม่พ้นระดับประมาณว่า "ผมไม่อยากอ่านบทความ" เท่านั้นเอง

[ndrgrd]

ก่อนหน้านี้ก็ทำท่าเหมือนเปิดกว้างมาโดยตลอด แต่ในทางปฏิบัติกลับเดินเกมแบบปิด สุดท้ายก็แทบจะลงกลอนประตูไปเลยครับ

[GN⁺]

ความคิดเห็นจาก Hacker News

• ไม่แนะนำให้ใช้ Next เด็ดขาด ประสบการณ์นักพัฒนาแย่มาก vendor lock-in หนัก และมีธรรมเนียมประหลาดที่ไม่ได้เขียนไว้ในเอกสาร จนรู้สึกว่าถ้าไม่ใช่ B2B SaaS ง่าย ๆ ที่เน้น CRUD ก็มีทุ่นระเบิดซ่อนอยู่เต็มไปหมด โดยเฉพาะเคยเจอกรณีที่แท็ก Next <Image /> ทำให้ FPS ของฉาก webgl บนหน้าเดียวกันตกลงไปถึง 2

  • สงสัยว่า Vercel ค่อย ๆ ต้มผู้ใช้ React ทั่วไปให้ติด vendor lock-in ได้อย่างไร React เป็นโปรเจกต์ที่ Meta เน้นความเป็นโอเพนซอร์ส และเคยหวังว่าโอเพนซอร์สจะช่วยป้องกัน vendor lock-in แต่ความจริงกลับไม่เป็นแบบนั้น จนน่าผิดหวัง

  • เห็นด้วยเต็มที่ ไม่นานมานี้ได้กลับมาใช้ Next อีกครั้งหลังห่างไปนาน และผิดหวังกับประสบการณ์พัฒนาอย่างมาก เอกสารคลุมเครือ หาอ่านยาก และตัวแอปเองก็ให้ความรู้สึกช้าเป็นค่าเริ่มต้น ตอนพยายาม deploy ไป AWS ด้วย Docker ก็เจอปัญหามากมายเพราะ Dockerfile ตัวอย่างที่ Vercel ให้มา

  • อยากรู้ว่าได้วิเคราะห์ปัญหา <Image /> โดยตรงหรือแค่คาดว่าเป็นปัญหาของ NextJs เพราะผมทำงานกับชุด NextJs, <Image>, RTF และไม่เคยเจอปัญหาแบบนั้น

• ใช้ Next.js ในงานมาตลอด 3 ปีที่ผ่านมา และรู้สึกว่าทรมานจริง ๆ โฮสต์บน Vercel และบริษัทก็ใช้แทบทุกบริการของ Vercel เลยได้สัมผัส vendor lock-in แบบเต็ม ๆ ก่อนหน้านี้เคยแชร์ประสบการณ์แย่ ๆ ใต้โพสต์ HN ที่ Dan เขียนเกี่ยวกับ RSC และรู้สึกว่าข้อสังเกตของเขาตรงมาก อย่างประโยคที่ว่า “ตัว RSC เองตอนนี้ค่อนข้างแข็งแรงแล้ว แต่เฟรมเวิร์กอย่าง Next.js ยังหยาบอยู่พอสมควร” โดยรวมแล้ว React เองตอนนี้ก็ต่ำกว่ามาตรฐานไปแล้ว และ Next.js ก็ยิ่งเร่งให้ภาพลักษณ์แย่ลง ทางที่ดีคืออยู่ให้ห่าง

• Vercel คงแก้บั๊กนี้ได้ แต่ตอนนี้ปัญหาเล็ก ๆ แบบนี้สะสมจนเริ่มเอือมกับ Next.js แล้ว เช่น วิธีระบุ prefetch ใน middleware ก็พังมาหลายสัปดาห์แล้ว หรืออาจหลายเดือน ปัญหาจุกจิกพวกนี้สะสมต่อเนื่องจนรู้สึกล้ากับ Next.js มาก แต่ก็ยังรัก ecosystem ของ JS อยู่

  • ย้ายออกจาก Next.js ไป Astro แล้ว อยากกลับไปหาพื้นฐานมากขึ้น แต่ก็ขี้เกียจตั้งค่า route/template/static asset/build เอง Astro จัดการทั้งหมดนี้ให้ และเป็น SSR โดยปริยาย ให้ความรู้สึกว่าใช้ React/Vue เป็นชั้นสำหรับ interaction ตามเจตนาเดิมจริง ๆ จนทำให้ตระหนักว่า JS framework หลายอย่างไม่จำเป็นแค่ไหน Next มีองค์ประกอบแบบเวทมนตร์มากขึ้นเรื่อย ๆ server action ก็ดูฝืน ๆ และมีวิธีทำแบบ “สไตล์ NextJS” เยอะเกินไป

  • ตอนนี้ยังใช้ Next.js ทั้งในงานและโปรเจกต์ส่วนตัว แต่จากที่เคยเป็นเครื่องมือที่สนุกและช่วยให้ทำงานได้ดี ทิศทางหลังเปลี่ยนจาก pages ไป app router กลับน่าเสียดาย

  • ตั้งแต่เวอร์ชัน 15.1.8 เป็นต้นมา บางไลบรารี1 ใช้งานพัง ทำให้ต้องดาวน์เกรดไปใช้เวอร์ชันที่มีช่องโหว่ตามที่ผู้เขียนพูดถึง

  • เห็นด้วย ต่อจากนี้คงใช้ Next.js แค่กับ static site หรือ SPA ที่ build ไว้ล่วงหน้าเท่านั้น

• Next กลายเป็นเรื่องล้อไปแล้ว พอ Remix เปลี่ยนตัวเองเป็น react-router แบบที่เข้าใจไม่ค่อยได้ ก็ยิ่งรู้สึกว่า React framework ที่ดีเหลืออยู่น้อยมาก สุดท้ายก็กลับไปใช้ plain vite คู่กับ tanstack router

  • แปลกใจที่โพสต์แนววิจารณ์แบบนี้ยังอยู่บน Hacker News เมื่อก่อนผมเคยโพสต์ว่า Remix ทำสิ่งเดียวกันได้ง่ายกว่า แล้วมีพนักงาน Vercel หลายคนส่งข้อความมาหา ขอให้ลบโพสต์หรือชวนคุยประชุม ติดต่อมาพร้อมกันจากหลายบัญชีบนโซเชียล

  • อยากรู้ว่าหมายถึงเลิกใช้ Remix หลังรีแบรนด์ หรือหมายถึงมันไม่ใช่ framework แล้ว RR7 (React Router 7) ก็ยังทำงานเป็น framework ได้ตามปกติ1 ผมเป็นแบ็กเอนด์มา 15 ปี เพิ่งเปลี่ยนมาทำฟูลสแต็กไม่นาน จากคำแนะนำของเพื่อนที่ไว้ใจได้เลยใช้ RR7 และทึ่งทุกวัน

  • ลองใช้ TanStack Router กับโปรเจกต์ใหม่แล้วชอบมาก จนเพิ่ม TanStack Query กับ TanStack Form ต่อเลย

  • อยากรู้ว่าทางเลือกที่ดีที่สุดคืออะไร และทำไมถึงใช้ Vite ผมใช้ Next กับโปรเจกต์เล็ก ๆ เพราะได้ยินมาตลอดว่าจุดแข็งคือ SEO ถ้าสุดท้ายแค่สร้างไฟล์ static แล้วอัปโหลดขึ้น S3 ก็จบ แบบนั้นไม่พอหรือ

  • อยากรู้ว่าจริง ๆ แล้วอะไรคือปัญหาของการที่ Remix กลายเป็น react-router จากมุมผมมันดูเหมือนแค่รีแบรนด์

• ย้ำมาหลายปีแล้วว่าควรระวัง React, Next, Svelte ฯลฯ ที่ขับเคลื่อนโดยบริษัทอย่าง Vercel ให้มาก เป้าหมายของพวกเขาคล้าย Heroku แต่รุกหนักกว่ามาก คือพยายามล็อกผู้ใช้ทั้งสแตกแบบครบวงจรตั้งแต่ภาษา-รันไทม์-เครื่อง บริษัทอื่นก็มีปัญหา เช่นเครื่องมือ deploy ผ่าน CLI ของ Cloudflare รองรับแค่ macOS 13.5+ เท่านั้น ซึ่งก็เพิ่งเกิน 2 ปีมานิดเดียว และไม่ชัดเจนว่าทำไม น่าเศร้าที่ OS อายุ 2 ปีกลับถูกมองว่าเก่า จะลองใช้ wrangler เวอร์ชันเก่าก็พอได้ แต่เอกสารกับความสามารถไม่ตรงกัน และสุดท้ายก็น่าจะแย่ลงอีก วันหนึ่งอาจตัดความเข้ากันได้ทิ้งไปเลยก็ได้ ในทางกลับกัน เครื่องมืออื่นอย่าง vim, neovim, emacs ยังทำงานได้บน OS X รุ่นเก่า ๆ ผมคิดว่าเพราะเครื่องมือโอเพนเหล่านี้ไม่มีแรงจูงใจเรื่อง lock-in

• Next กับ RSC คือสิ่งที่น่าอึดอัดที่สุดที่เคยเจอในฝั่งฟรอนต์เอนด์ ฟรอนต์เอนด์ก็ปวดหัวพออยู่แล้ว ยังต้องมาเพิ่ม “เวทมนตร์” ของ Next และ vendor lock-in ของ Vercel เข้าไปอีก สัปดาห์นี้ทีมเราวางแผนย้ายไปใช้ tanstack router กับ vite เพื่อทำ CSA ธรรมดา ๆ และกำลังตั้งตารอ

  • อยากรู้ว่า RSC น่าอึดอัดตรงไหน จากประสบการณ์ของผมมันทำงานได้ดีมาก และเหตุผลเดียวที่ยังใช้ Next.js อยู่ก็เพราะ RSC นี่แหละ

• ทุกคนควรพูดถึงปัญหาที่ Next.js ในโหมดพัฒนาใช้เวลา 10 วินาทีในการคอมไพล์ route ให้มากกว่านี้ ตัวคอมไพเลอร์ Rust ยังดูเหมือนยืนสูบบุหรี่อยู่ข้าง ๆ

  • ระดับใช้งานไม่ได้เลย devx แย่ที่สุดที่เคยเจอ ครั้งสุดท้ายที่เกลียดสแตกอะไรขนาดนี้คือสมัยต้องไปช่วยงาน Sharepoint site

  • ตอนนี้แม้แต่ JS ซึ่งเป็นภาษาสคริปต์ธรรมดา ก็ยังต้องผ่านขั้น build/compile หลายรอบ และใช้เวลานานกว่า C++ compiler ไปแล้ว ถึงขั้นว่าถ้าเอา Clang ไปใส่ในเบราว์เซอร์อาจยังให้ประสบการณ์ดีกว่า เสริมอีกนิดว่าที่บริษัทก็ใช้ PHP ด้วย และเจอปัญหาแบบเดียวกัน คิดว่าเป็นภาษาสคริปต์น่าจะง่าย แต่เพราะข้อจำกัดด้านประสิทธิภาพของ PHP เอง จึงต้องมีขั้นตอน generate โค้ดล่วงหน้าและขั้น build ของ composer แยกต่างหาก ซึ่ง build ที่นักพัฒนา PHP ทำก็ยังช้า คงไม่ใช่งานของคนที่ทำ GCC

  • แปลกตรงที่ออปชัน next dev —-turbo ก็ไม่ได้เร็วขึ้นเลยในโค้ดเบสของบริษัทเรา

  • คอมไพเลอร์ Rust คอมไพล์งานจริง ๆ แต่ก็สงสัยว่า Next.js compiler ทำงานซับซ้อนขนาดนั้นจริงหรือ

• น่าเสียดายกับสภาพปัจจุบันของ Next.js ยังใช้อยู่ก็จริง แต่ถึงขั้นต้อง fork มาปะช์เอง next.config.js เป็นเหมือนทางหนีฉุกเฉินที่โหดร้ายสำหรับเปลี่ยนพฤติกรรมเริ่มต้น และผมคิดว่าตัวเลือกแบบนี้ควรถูกทำเป็นจุดขยายอย่างเป็นทางการตั้งแต่แรก ไม่ใช่ซ่อนไว้หลัง “feature flag” ตอนนี้มันแทบเป็นเฟรมเวิร์กเกรด D ที่โค้ดสปาเกตตีเต็มตัว

• ถ้าไม่ใช้ NextJS แล้ว มีชุดแนะนำอะไรบ้างสำหรับทั้งสแตก ผมเป็นแบ็กเอนด์มา 15 ปี แต่ฝั่งฟรอนต์นี่แทบไม่ได้แตะมาตั้งแต่ AngularJS ช่วงนี้กำลังจะทำแอปฟูลสแต็กสำหรับโปรเจกต์ส่วนตัว เลยค้นหาข้อมูลและพบว่าทั้ง Gemini กับเอกสารทางการต่างก็แนะนำ NextJS ตอนนี้ยังอยู่ช่วงเริ่มต้น เลยอยากเรียนรู้ทางเลือกอื่น วางแผนจะรันทุกอย่างเองบน VPS ผ่าน Docker จึงหลีกเลี่ยง Vercel/Netlify

  • ถ้าไม่ต้องการ server rendering แนะนำ React แบบไม่มี framework คู่กับ Vite1 ใช้ Vite ตอนพัฒนา และตอน build production ก็จะได้แค่ไฟล์ HTML + JS เอาไปโฮสต์แบบ static อย่าง S3 ก็จบ ใช้มาสิบกว่าปีแล้วไม่มีปัญหา ฝั่งแบ็กเอนด์ก็ใช้สิ่งที่ตัวเองถนัดได้เลย ช่วงนี้ผมใช้ PostgREST2 เป็นหลัก ส่วนการเรียก API จากฝั่งไคลเอนต์แนะนำ react-query3

  • อยากรู้ว่าคุณกำลังพัฒนาโปรเจกต์แบบไหน ผมกำลังทำ SaaS web app ทั่วไป และพบว่าชุด React/Refine.dev/Vite ดีมาก Refine.dev ช่วยให้ไม่ต้องเสียเวลาคิดเรื่องหน้า CRUD และโฟกัสกับการพัฒนาฟีเจอร์ได้เต็มที่

• คิดว่าประเด็นนี้ถูกขยายเกินจริง สำหรับคนที่เข้าใจว่า streaming ใน React ทำงานอย่างไร เรื่องที่ไม่สามารถ stream HTML ทีละบรรทัดได้เป็นสามัญสำนึกอยู่แล้ว ไม่ควรให้ first paint ถูกบล็อกเพราะ metadata (HTML ไม่ใช่ JS) การยกเว้น user agent บางตัวกับพฤติกรรมแบบนี้ถือว่าสมเหตุสมผล เพราะสำหรับทราฟฟิกส่วนใหญ่ การแสดงผลให้เร็วที่สุดสำคัญกว่า ถ้ามีผู้ใช้บางกลุ่มที่ใช้เวลานานในการโหลด metadata ก็อยากรู้ว่าจะมีวิธีแก้อย่างไร