· turbopack / vite / nextjs

Turbopack năm 2026 — cuối cùng có đánh bại được Vite không?

Turbopack đã stable và là mặc định trong Next.js 16. Nhưng 66% hài lòng so với Vite 98% là tín hiệu thực — đây là lúc nên chuyển và lúc nên ở lại.

Bởi

2.573 từ · 13 phút đọc

Turbopack đã stable và là bundler mặc định trong Next.js 16. Với các dự án mới triển khai trên Vercel và không có nhu cầu plugin phức tạp, việc chuyển sang ngay hôm nay là hợp lý. Còn với mọi stack ngoài Next.js, câu hỏi này không đặt ra — Turbopack không chạy ở đó, và Vite vẫn là lựa chọn duy nhất.

Bài này dành cho ai

Senior JS developer và tech lead đang chọn bundler cho dự án Next.js mới hoặc hiện có. Nếu stack của bạn không phải Next.js — Remix, SvelteKit, Astro, Nuxt, plain React — thì dừng lại ở đây. Turbopack chỉ dành cho Next.js, và không có gì trong bài này ảnh hưởng đến quyết định tooling của bạn.

Chúng tôi đánh giá những gì

Bài viết này tổng hợp từ: release notes chính thức (Next.js 15.3, 15.4, 16, 16.2), báo cáo benchmark của Vercel, bài test độc lập của Catch Metrics trên Cal.com (Next.js 15.5.2), bình luận công khai của Evan You về phương pháp luận trong benchmark 10× HMR, và khảo sát State of JavaScript 2025 với khoảng 20,000 lập trình viên. Các GitHub issue mở được xác minh với Next.js 16.2.6 ngày 2026-05-30. Chúng tôi không tự chạy benchmark; phần caveats giải thích cách bạn có thể tự làm.

Những thay đổi kể từ Next.js 15

Hành trình đưa Turbopack đến stable trải qua nhiều mốc công khai trong khoảng 18 tháng:

Thời điểmMốc
Tháng 10/2024next dev --turbo được tuyên bố stable cho development. Production builds đạt 96% tỉ lệ pass integration test.
Tháng 4/2025 (Next.js 15.3)next build --turbopack đạt alpha. 99.3% trong số 8,298 integration test pass. Docs của Vercel ghi rõ: “Chúng tôi không khuyến nghị dùng trong production cho các ứng dụng mission-critical ở giai đoạn này.” Hơn 50% phiên dev của Next.js 15 đã chạy trên Turbopack.
Tháng 7/2025 (Next.js 15.4)100% trong số 8,298 integration test pass. Production builds được tuyên bố an toàn nhưng chưa phải mặc định.
Tháng 10/2025 (Next.js 16)Turbopack hoàn toàn stable và là bundler mặc định cho tất cả dự án Next.js mới. Tại thời điểm ra mắt, >50% phiên dev và 20% production build trên Next.js 15.3+ đã chạy Turbopack.
Tháng 3/2026 (Next.js 16.2)Tiếp tục cải thiện hiệu năng và parity. Bug hash-mismatch trong CI/CD (GitHub #87737) vẫn chưa đóng.

Thay đổi thực tế: create-next-app giờ tạo dự án Turbopack theo mặc định. Người dùng webpack phải chủ động opt-out với --webpack — trách nhiệm đã đảo chiều.

Benchmark Turbopack vs. Vite — nhìn thẳng vào sự thật

Vercel công bố gì — và ý nghĩa thực sự là gì

Những con số nổi bật của Vercel đến từ việc đo trên chính codebase Vercel.com:

  • Khởi động local server: nhanh hơn tới 76.7% so với webpack
  • Fast Refresh (cập nhật code): nhanh hơn tới 96.3% so với webpack
  • Compile route đầu tiên (không cache): nhanh hơn tới 45.8% so với webpack

Con số “lên đến” trên một ứng dụng production lớn duy nhất chỉ cho bạn thấy hướng đi, không phải kết quả bạn sẽ đạt được. Bài test độc lập của Catch Metrics trên Cal.com (một codebase Next.js lớn khác) cho thấy mức cải thiện thực tế gần hơn với 19% nhanh hơn cho cold build — và còn phát hiện một regression +211 kB trong shared client chunk size. Con số regression đó ảnh hưởng trực tiếp đến TTI khi tải trang lần đầu.

Cả hai kết quả đều có cơ sở. Nhưng không cái nào là con số bạn sẽ gặp trên ứng dụng của mình. Nếu hiệu năng production build là yếu tố quyết định, hãy tự đo trên dự án thực trước khi cam kết.

Về benchmark 10× HMR so với Vite — chuyện gì đã xảy ra

Vercel công bố một benchmark tuyên bố Turbopack chạy “nhanh hơn Vite 10×” về HMR. Evan You (tác giả của Vite) đã bình luận công khai về phương pháp và tìm ra hai vấn đề cụ thể.

Vấn đề 1 — Transform pipeline không tương đương. Benchmark chạy Vite với Babel transforms và Turbopack với SWC. Plugin SWC của Vite không được đưa vào so sánh. Đây không phải phép đo Vite vs. Turbopack — đây là Babel vs. SWC khoác áo bundler.

Vấn đề 2 — Lỗi đo lường. Metric hmr_to_eval trong benchmark đang báo số liệu hmr_to_commit cho Vite, làm phóng đại khoảng cách đo được. Sau khi hiệu chỉnh, lợi thế HMR thực tế ở số lượng module điển hình thu hẹn xuống còn dưới 2× — khoảng 100ms so với 54ms — thay vì 10×. Đánh giá của Evan You về bản gốc: “marketing chiếu trên số liệu chọn lọc, không qua peer-review, và gây hiểu nhầm ở mức đáng kể.”

Câu trả lời thành thật về Turbopack vs. Vite 6 trên HMR: chưa có benchmark trung lập, bên thứ ba nào bao phủ đầy đủ cold start, HMR, và production build trên các dự án có kích thước tương đương. Lợi thế HMR của Turbopack so với Vite có thể là có thật và có thể dưới 2× ở số lượng module điển hình. Nếu bạn cần con số cụ thể cho codebase của mình, hãy clone template Next.js commerce, đo cold start, HMR trên một leaf component, và full production build — lần lượt với Turbopack mặc định, rồi với next build --webpack, rồi so với baseline Vite + React Router 7. Đó là con số duy nhất đáng tin cho setup cụ thể của bạn.

Production build: vẫn còn dấu hỏi

Lợi thế tốc độ của Turbopack ở chế độ development đến từ kiến trúc khác biệt căn bản — Rust, incremental computation, demand-driven evaluation. Những đặc tính này tỏa sáng khi bạn đang iterate: partial rebuild, HMR nhanh. Production build là workload khác hẳn. Production path của Vite (dựa trên Rollup) đã có nhiều năm được tinh chỉnh. Production build của Turbopack là code mới hơn. Tỉ lệ pass integration test cho biết bạn về độ chính xác, không phải tốc độ. Ở thời điểm giữa năm 2026, hiệu năng production build là thứ cần đo, không phải thứ có thể giả định.

Những khoảng trống hệ sinh thái sẽ chặn bạn

Không có plugin system

Đây là hạn chế cấu trúc lớn nhất, và nó không nhỏ. Turbopack không có plugin API dành cho các library author.

Hệ quả thực tế:

Source maps cho Sentry. Integration chuẩn của Sentry dựa vào webpack plugin để upload source maps lúc build. Đường đi chính thức này chưa tồn tại trong Turbopack. Workaround một phần có thể thực hiện qua option uploadSourceMaps của Sentry, nhưng không tương đương với workflow dựa trên plugin và cần kiểm tra thủ công cho từng setup.

Service Workers và PWA libraries. Serwist, Workbox, và các thư viện đăng ký Service Worker qua webpack plugin không có phiên bản tương đương trên Turbopack. Nếu ứng dụng của bạn cần offline support hoặc PWA, bạn vẫn phải dùng webpack.

CSS-in-JS với server-side extraction. Các thư viện extract critical CSS lúc build qua webpack plugin hooks — một số cấu hình của styled-components, Emotion với SSR — chưa có đường migrate sang Turbopack.

Shared Workers và Audio Worklets. Chưa được implement tính đến Next.js 16.2.

Hiện không có ngày phát hành công khai nào cho Turbopack plugin API. Nếu bất kỳ điều nào ở trên ảnh hưởng đến dự án của bạn, webpack vẫn là con đường phải đi. Cửa để migrate là “khi plugin system ra mắt,” không phải “khi Turbopack stable.”

Bug hash-mismatch trong CI/CD

GitHub issue #87737, được mở tháng 12/2025, vẫn còn mở với Next.js 16.2.6 tính đến 2026-05-30. Nguyên nhân gốc: Turbopack tạo hash tham chiếu module ngoài dựa trên cấu trúc node_modules tại thời điểm build. Khi dependency được reinstall trong môi trường khác — Linux CI so với macOS máy dev, pnpm so với npm, hoisting behavior khác nhau — hash thay đổi và runtime không tìm được module.

Có thể tái hiện với: pnpm + Linux CI, người dùng Prisma, người dùng Pino. Hơn 25 người bị ảnh hưởng trên thread tính đến tháng 5/2026. Workaround duy nhất được xác nhận là next build --webpack.

Nếu pipeline của bạn dùng pnpm trên Linux runner, đừng đưa Turbopack lên production cho đến khi vấn đề này được giải quyết. Kiểm tra thread với phiên bản Next.js cụ thể của bạn trước khi build pipeline.

Ngoài Next.js: không nằm trong roadmap

Turbopack được Vercel tài trợ và giới hạn trong Next.js. Không có bản phân phối standalone, không có hỗ trợ Remix, SvelteKit, Nuxt. Một GitHub discussion thread (Next.js #86533) về hướng standalone Turbopack đang mở nhưng không còn hoạt động. Nếu team bạn muốn tooling nhất quán giữa các framework, Vite là lựa chọn duy nhất. Nếu bạn đang migrate từ webpack, xem Vite vs. Webpack để so sánh chi tiết.

Những gì đã hoạt động ổn

Web Workers thông qua pattern chuẩn new Worker(new URL('./worker.js', import.meta.url)) đã được implement và hoạt động tốt. Loader system của Turbopack (turbopack.rules trong next.config.ts) đã dùng được — với lưu ý rằng một lỗi crash khi kết hợp custom loader với Next.js middleware (GitHub #79592, được sửa một phần tháng 9/2025) vẫn còn được báo cáo trong một số cấu hình. Kiểm tra kỹ tổ hợp loader + middleware của bạn trước khi nâng cấp.

Cộng đồng nghĩ gì

Khảo sát State of JavaScript 2025 (~20,000 người tham gia, công bố đầu năm 2026) cho thấy tín hiệu rõ nhất:

  • Mức độ hài lòng với Vite: ~98% — cao nhất trong danh mục build tools với khoảng cách đáng kể
  • Mức độ hài lòng với Turbopack: ~66% — ban tổ chức khảo sát nhận xét đây là con số “đáng lo ngại”
  • Mức độ sử dụng (toàn bộ dự án JS, không chỉ Next.js): webpack 87%, Vite 84%, Turbopack 28%

Con số 28% sử dụng Turbopack phần lớn đến từ việc Next.js 16 đặt nó làm mặc định — những người dùng chạy Turbopack vì framework mang đến, không phải vì họ chủ động chọn. Điều này quan trọng khi đọc con số hài lòng: 34% không hài lòng bao gồm cả những developer chưa từng opt-in và bất ngờ gặp các khoảng trống không ngờ tới.

Đánh giá của ban tổ chức về mức tăng trưởng của Turbopack: “Turbopack đang cho thấy nhiều tiến bộ về mặt sử dụng, chắc chắn được hưởng lợi từ việc được tích hợp sẵn trong Next.js.” Về khoảng cách hài lòng: con số 66% đi cùng xu hướng giảm hài lòng của chính Next.js — hai tín hiệu chỉ về một hướng.

Phản ứng trên GitHub về khoảng trống plugin system khá gay gắt. Một bình luận từ issue #78784: “Thật không may Turbopack cũng không có (chưa có) plugin system package mà các author có thể dùng để thu hẹp khoảng cách này — và không có đề cập gì đến kế hoạch có plugin system.” Về bug CI/CD, thread có người dùng bị ảnh hưởng trên Vercel Serverless, Windows Server 2022, và Linux CI runner tiêu chuẩn — đây không phải edge case.

Kết luận

Nên chuyển sang Turbopack nếu:

  • Dự án Next.js 16+ hoàn toàn mới, không có dependency vào webpack plugin
  • Triển khai trên Vercel — tích hợp chặt nhất, ít overhead cấu hình nhất
  • Tooling stack đơn giản: không dùng Sentry source maps, không có Service Workers, không CSS-in-JS với SSR extraction
  • Bạn đã xác nhận GitHub #87737 không ảnh hưởng đến CI setup của mình (hoặc bạn dùng npm với môi trường nhất quán)

Cần kiểm tra kỹ trước khi chuyển nếu:

  • Bạn dùng Sentry — kiểm tra workaround uploadSourceMaps trong chính pipeline của bạn trước khi giả định nó hoạt động
  • CI của bạn dùng pnpm trên Linux — tái hiện kịch bản hash-mismatch trên staging pipeline trước
  • Bạn có custom loader kết hợp với Next.js middleware — kiểm tra tổ hợp cụ thể đó với trạng thái hiện tại của GitHub #79592

Nên ở lại với Vite nếu:

  • Dự án của bạn không phải Next.js — Turbopack không có mặt ở đó, hết chuyện
  • Bạn triển khai lên Netlify với stack dựa trên Vite — setup đã được kiểm chứng, migrate chỉ thêm rủi ro mà không mang lại lợi ích
  • Tooling của bạn phụ thuộc vào webpack plugin chưa có tương đương trong Turbopack
  • Bạn cần tooling nhất quán giữa nhiều framework (Vite chạy trên Remix, SvelteKit, Astro, Nuxt, plain React)

Nên ở lại với webpack nếu:

  • GitHub #87737 đang ảnh hưởng đến pipeline của bạn và next build --webpack là trạng thái đang hoạt động
  • Bạn có webpack customization sâu qua plugin chưa thể chuyển sang Turbopack loader

Vite ở mức 98% hài lòng so với Turbopack ở 66% là dữ liệu hữu ích nhất trong bài so sánh này. Turbopack đã có tiến bộ kỹ thuật thực sự — stable, là mặc định, 100% integration test parity không phải là cột mốc nhỏ. Nhưng “stable” có nghĩa là “đúng,” không phải “đầy đủ.” Khoảng trống plugin system, bug CI, và dữ liệu hài lòng đều chỉ về cùng một kết luận: Turbopack hoạt động tốt cho trường hợp thông thường ngày hôm nay. Những trường hợp ít phổ biến hơn mới là thứ cần kiểm tra kỹ trước khi cam kết. Để so sánh benchmark trực tiếp, xem Turbopack vs. Vite.

Lưu ý quan trọng

Chúng tôi không tự chạy benchmark cho bài viết này. Con số của Vercel là số liệu peak do vendor tự báo cáo từ codebase của họ. Nghiên cứu của Catch Metrics là một điểm dữ liệu bên thứ ba trên một dự án. Để đánh giá hiệu năng production build, hãy tự đo: time next build có và không có --turbopack trên dự án thực của bạn, lặp lại ba lần, mỗi lần với node_modules sạch.

Toolchew có quan hệ affiliate với Vercel, Netlify, và Sentry. Những quan hệ này không ảnh hưởng đến kết luận. Bug CI/CD và khoảng trống plugin system được mô tả đúng như thực tế; quan hệ affiliate với Vercel không làm mềm ngôn từ ở cả hai điểm này.

GitHub issues #87737 và #78784 đã được xác minh với Next.js 16.2.6 ngày 2026-05-30. Nếu đã có thời gian đáng kể trôi qua kể từ ngày đó, hãy kiểm tra cả hai thread để xem có giải pháp chưa trước khi trích dẫn trạng thái này.

Tài liệu tham khảo