Next.js 16.4 เปิดตัววันที่ 6 ตุลาคม 2026 โดยให้โปรเจกต์ใหม่จาก create-next-app เปิด Cache Components เป็นค่าเริ่มต้น และเพิ่มเครื่องมือควบคุมว่าเนื้อหาใดต้องเตรียมไว้ล่วงหน้า หรือควรรอจนผู้ใช้เปิดหน้า สำหรับทีมที่มีเว็บอยู่แล้ว สิ่งที่ควรตรวจคือขอบเขต cache และพฤติกรรมการโหลดข้อมูล ก่อนย้ายตามค่าเริ่มต้นของโปรเจกต์ใหม่ อ้างอิง ประกาศ Next.js 16.4
ใครควรสนใจ
ทีมที่ใช้ App Router ทำเว็บบทความ ร้านค้า หรือหน้าที่ผสมข้อมูลสาธารณะกับข้อมูลเฉพาะผู้ใช้ จะได้เครื่องมือแยกการเรนเดอร์แต่ละส่วนให้ชัดขึ้น ตัวอย่างเช่น เนื้อหาบทความอาจเตรียมไว้ล่วงหน้า ส่วนรายการความคิดเห็นที่มีต้นทุนสูงอาจรอจนมีการเปิดหน้า เป็นแนวทางให้ทีมเลือกทดลองกับงานของตน ไม่ใช่ผลวัดประสิทธิภาพจาก Reefsight
กำหนดว่าหน้าไหนต้องเป็น static
ensureStatic เป็นค่าที่ export จาก server page หรือ layout เพื่อกำหนดส่วนของผลลัพธ์ฝั่งเซิร์ฟเวอร์ที่ต้องเป็น static โดยต้องเปิด cacheComponents ก่อน ตาม เอกสาร ensureStatic มีระดับที่ควรแยกให้ออกดังนี้
'shell': ส่วนโครงหน้าที่โหลดล่วงหน้าต้องเป็น static'prefetch': รวมทั้งโครงหน้าและข้อมูลที่โหลดล่วงหน้าสำหรับลิงก์นั้น'navigation': ผลลัพธ์ฝั่งเซิร์ฟเวอร์ของทั้ง route ต้องเตรียมระหว่าง prerender ได้
ระดับ 'navigation' ตรวจทั้งตอนพัฒนาและ build หากมีงานฝั่งเซิร์ฟเวอร์ที่ต้องอาศัย request เช่น อ่าน cookies() หรือข้อมูลที่ไม่ได้ cache จะไม่ผ่าน แม้ใส่ไว้ใน Suspense แล้วก็ตาม จึงควรเริ่มกับหน้าสาธารณะที่ตั้งใจให้เป็น static แทนการใส่ไว้ที่ root layout ทันที
ส่วน 'shell' และ 'prefetch' ต้องใช้ Partial Prefetching จึงให้ผลตามระดับเหล่านี้ และไม่ได้เพิ่มการตรวจ build แบบ 'navigation' การตั้งค่าชื่อคล้ายกันจึงไม่ได้ให้หลักประกันเดียวกันทั้งหมด
เลื่อนงานบางส่วนไปตอนเปิดหน้า
อีกเครื่องมือคือ await navigation() จาก next/cache ให้วางก่อนงานที่ต้องการเลื่อน และครอบ component นั้นด้วย Suspense ระหว่างการเรนเดอร์ขณะใช้งานจริง งานด้านล่างจะรอจนผู้ใช้ไปยังหน้า ส่วนที่โหลดล่วงหน้าจะแสดง fallback แทน ตาม เอกสาร navigation()
แผนภาพเป็นตัวอย่างเชิงแนวคิดเมื่อเปิด Cache Components และ Partial Prefetching ไม่ใช่ benchmark และไม่ได้แสดงทุกเส้นทางการโหลด
ข้อจำกัดสำคัญคือ static prerender ยังอาจรวมเนื้อหานั้นไว้ได้ และ API นี้ไม่เปลี่ยนการโหลดหน้าโดยตรงครั้งแรก หากไม่เปิด Partial Prefetching ลิงก์ที่กำหนด prefetch={true} จะยังโหลดทั้ง route รวมส่วนที่เลื่อนไว้ด้วย จึงไม่ควรสรุปว่าการใส่ navigation() ทำให้ข้อมูลไม่มีวันโหลดก่อนคลิก
นอกจากนี้ ห้ามเรียก navigation() ภายในขอบเขต 'use cache' ให้วางการรอไว้ก่อน แล้วค่อยเรียกฟังก์ชันที่ cache ได้ด้านล่าง การเลื่อนงานเป็นเรื่องจังหวะการโหลด ไม่ได้ใช้แทนการตรวจสิทธิ์เข้าถึงข้อมูล
ทีมควรเริ่มอย่างไร
ข้อเสนอสำหรับการทดลองของทีมคือ เลือก route เดียวที่ทราบพฤติกรรมเดิม แยกข้อมูลสาธารณะออกจากข้อมูลเฉพาะผู้ใช้ แล้วบันทึกการเรียก API และฐานข้อมูลก่อนปรับ จากนั้นเลือกเป้าหมายให้ชัด: ต้องการรักษาทั้งหน้าให้เป็น static หรือเพียงลดงานที่เกิดตอน prefetch
ทดสอบทั้งการเปิด URL โดยตรง การกดลิงก์ การย้อนกลับ และการกลับมาเปิดหน้าเดิม รวมถึงผู้ใช้หลายบัญชีและการแก้ข้อมูลหลัง cache แล้ว ตรวจว่าข้อมูลยังถูกต้อง fallback อ่านรู้เรื่อง และสิทธิ์ไม่เปลี่ยน ก่อนวัดจำนวน request และเวลาโหลดด้วยข้อมูลจริงของแอป
บทความนี้อธิบายประกาศและเอกสาร ณ 12 ตุลาคม 2026 ยังไม่ได้ทดลอง migration หรือ benchmark กับแอปจริง การเปิดค่าใหม่จึงไม่ใช่หลักฐานว่าเว็บจะเร็วขึ้นหรือลดค่าเซิร์ฟเวอร์ได้ทันที ผู้ตรวจควรเช็กเอกสารให้ตรงกับรุ่นที่ติดตั้งและทดสอบพฤติกรรม cache ก่อนเผยแพร่คำแนะนำใช้งาน