How Turbopack chunks your JavaScript

Vercel · 2026 · 3. Quy mô lớn · Độ khó: Khó — bài gốc

Vercel vừa làm framework Next.js vừa bán nền tảng chạy nó; nhận định về sản phẩm của họ trong trang này đều là "theo Vercel". Bài do một thực tập sinh của đội Turbopack viết.

Bối cảnh

• Chunking là quyết định code nào nằm trong file JS nào. Theo bài có bốn cách: một chunk cho cả app (cache hit cao nhưng mỗi trang tải JS của mọi trang); một chunk mỗi trang (không thừa, nhưng <Footer /> bị tải lại mỗi trang, mất cache); một chunk mỗi module (không thừa, nhưng hàng trăm request nhỏ, nén gzip kém); hay gộp.
• Hai mục tiêu (tải ít byte, ít request) xung đột nhau: chunk lớn thì ít request nhưng kém tái sử dụng giữa trang.

Thay đổi chính

• Chunk group: tập chunk được tải cùng nhau cho một trang. Chỉ gộp chunk trong cùng group, nên gộp không thêm gì trang chưa phải tải.
• Ước lượng lợi hại của việc gộp hai chunk A và B theo phân bố các nhóm dùng chỉ A, chỉ B, hoặc cả hai, và theo hai loại phiên: tải một trang rồi rời (gộp luôn lợi: ít request hơn) và đi tiếp sang trang thứ hai (chỉ lợi khi trang kia cần cả hai; nếu cần chỉ A thì phải tải lại A). Mặc định giả định 2/3 phiên chỉ một trang, 1/3 từ hai trang trở lên.
• Đo trên nextjs.org: mặc định giảm hơn một nửa số request so với không gộp, thậm chí gửi ít code hơn một chút; gộp tối đa giảm request thêm nhưng gửi nhiều hơn 10% code (điều hướng càng nhiều càng thiệt).
• Next.js 16.3 (experimental): (1) generateComponentChunks: phát cả bản chunk chưa gộp bên cạnh bản gộp; lúc chạy, runtime biết cái gì đã tải và chọn bản gộp hay chỉ tải phần thiếu. (2) Chunking theo số liệu thật: firstPageLoadPriority (mặc định 0,67, gần tỷ lệ bounce), priorityRoutes, clusters các route hay đi cùng nhau. (3) Giảm thứ gửi đi: tree-shaking cho CommonJS, một runtime dùng chung thay runtime riêng mỗi trang (bớt một request chặn và khoảng 10 KB JS mỗi lần điều hướng sau lần đầu), runtime mặc định nhẹ hơn (không kèm WebAssembly/Web Worker nếu không dùng).

Vì sao

• Quyết định gộp chunk chốt ở lúc build, trước khi biết trình duyệt đã cache gì và người dùng đi đường nào; vì vậy phải giả định, và thêm lối cho runtime hoặc chủ site chỉnh theo thực tế.

Bài học cho SWE

• Số request và số byte là hai chi phí đánh đổi nhau; mỗi request có overhead cố định (HTTP/2 giảm nhưng không xoá), nên gộp là kiểu batching ở tầng tài nguyên.
• Quyết định tĩnh dựa trên giả định hành vi người dùng nên cho phép cấu hình bằng số liệu thật (bounce rate, route ưu tiên).

Liên quan

• Vercel 2024 · Vercel 2026 · Etsy 2017
• Kiến trúc frontend · Batching và khấu hao round-trip