Turbopack แบ่ง JavaScript Chunk อย่างไร: ปรับโหลดหน้าโดยไม่ไล่แตก Bundle แบบเดาสุ่ม

ทีม Next.js อธิบายการแบ่ง JavaScript ของ Turbopack เมื่อ 3 กันยายน 2026 พร้อม experimental controls สำหรับปรับ chunking เป้าหมายไม่ได้มีแค่ทำไฟล์ให้เล็ก แต่ต้องบาลานซ์ initial load, cache reuse, จำนวน request และต้นทุนตอนนำทางระหว่างหน้า

โมดูลที่หลาย route ใช้ร่วมกันควรมีโอกาสอยู่ใน shared chunk เพื่อไม่ต้องดาวน์โหลดซ้ำ แต่ถ้าดึงโค้ดที่แทบไม่ใช้เข้าก้อน shared ใหญ่เกินไป ผู้ใช้ทุกคนจะจ่ายค่า parse/execute ล่วงหน้า การแตกละเอียดเกินไปก็เพิ่ม request และ bookkeeping แทน

วัดก่อนแตะ control

• เก็บ route-level JavaScript ของหน้าเข้าหลัก ไม่ดูแค่ยอดรวมทั้ง build
• วัด cold navigation และ warm navigation แยกกัน
• หา module ใหญ่ที่เข้า initial chunk แต่ไม่ทำงานเหนือ fold
• ดู cache hit หลัง deploy เพราะชื่อ chunk ใหม่ทำให้ cache เดิมหมดประโยชน์ได้
• เทียบ CPU parse/execute บนมือถือ ไม่ใช้ bandwidth เป็นตัวแทนทั้งหมด

experimental controls ควรถูกจำกัดด้วย fixture ที่ใกล้ production และ budget ที่ตรวจใน CI อย่า pin กลยุทธ์กับโครงสร้าง chunk ภายในมากจน upgrade framework ยาก หาก default ดีขึ้นในรุ่นถัดไป override เก่าอาจกลายเป็นตัวถ่วง

จุดตัดสินใจง่ายๆ คือ ถ้าปัญหาเกิดจาก component ถูกโหลดเร็วเกินไป ให้แก้ route/component boundary ก่อน แต่ถ้าหลาย route โหลด dependency ซ้ำหรือ shared chunk โตผิดสัดส่วน ค่อยทดลอง chunk control แล้ววัด navigation จริง

Recap

• แยก initial, cold navigation และ warm navigation metrics
• วัด parse/execute บนอุปกรณ์ช้า ไม่ดูแค่ขนาด gzip
• ใช้ experimental control หลังพิสูจน์ว่า boundary ปกติแก้ไม่ได้
• ตั้ง budget เพื่อจับ regression หลังอัปเกรด Next.js