Next.js 16 Turbopack Production Builds: คู่มือฉบับสมบูรณ์ พร้อม Benchmarks, Config และ Persistent Cache

อัปเดตล่าสุด: 12 กรกฎาคม 2026

Turbopack เป็น bundler default สำหรับทั้ง development และ production build ใน Next.js 16 เป็นต้นไป ตัวมันเขียนด้วย Rust และใช้ incremental compilation ทำให้ production build เร็วกว่า Webpack ราว 2–4 เท่าในโปรเจกต์ขนาดกลางถึงใหญ่ ตั้งแต่ v16.1 มี File System Caching แบบ stable ต่อด้วย 16.2 ที่ปรับ dev startup เร็วขึ้นราว 87% และ 16.3 preview ที่เพิ่ม Persistent Cache กับ Rust React Compiler ในบทความนี้ผมจะพาไปดูตั้งแต่การ enable, การ config, การอ่าน benchmark, การ debug build ที่ช้าผิดปกติ ไปจนถึงการ migrate monorepo ขนาดใหญ่ให้จบในที่เดียว

• ตั้งแต่ Next.js 16.0 (ตุลาคม 2025) Turbopack เป็น bundler default ทั้ง next dev และ next build โดยไม่ต้องใส่ flag เพิ่ม
• Production build ที่ทดสอบกับ Makerkit SaaS Kit ทำได้ 5.7 วินาที เทียบกับ Webpack 24.5 วินาที (~4.3x เร็วขึ้น)
• File System Cache stable ใน 16.1 ช่วยให้ CI/CD build ครั้งต่อไปเร็วขึ้นเมื่อ cache ถูก hit แบบข้าม run
• Next.js 16.2 ทำให้ dev server startup เร็วขึ้น ~87% และเพิ่ม tree shaking สำหรับ dynamic imports
• 16.3 preview เพิ่ม Persistent Cache ที่ลด memory ตอน dev ได้ถึง 90% พร้อม Rust React Compiler (experimental)
• Monorepo, custom loader, และ webpack plugin ยังต้องใช้ Webpack ในบางกรณี ควรตรวจ compatibility ก่อน migrate

Turbopack ใน Next.js 16: สถานะและ timeline ปี 2026

ก่อนจะเข้ารายละเอียด production ต้องเข้าใจก่อนว่าทีม Vercel ผลักดัน Turbopack มาหลายปี และในปี 2026 สถานะเปลี่ยนจาก opt-in flag มาเป็น default อย่างเต็มตัว ทีม architect ที่กำลังวางแผน build pipeline ปี 2026 ต้องรู้ timeline เพื่อรู้ว่า feature ไหน stable ไหน preview

• Next.js 16.0 (ตุลาคม 2025): Turbopack ทั้ง dev และ production build stable และเป็น default สำหรับโปรเจกต์ใหม่ทั้งหมด
• Next.js 16.1 (ธันวาคม 2025): File System Caching stable ทำให้ build ครั้งที่สองใน CI เร็วขึ้นชัดเจน
• Next.js 16.2 (มีนาคม 2026): dev server startup เร็วขึ้น ~87% รวมทั้ง tree shaking สำหรับ dynamic imports และรองรับ TypeScript PostCSS config
• Next.js 16.3 preview (มิถุนายน 2026): Persistent Cache ลด memory usage ตอน dev ได้ถึง 90% และมี Rust React Compiler แบบ experimental

ข้อมูลจาก Vercel ระบุว่า production build บน Turbopack ผ่านการรันจริงในสัดส่วนกว่า 20% ของ Next.js 15.3+ ก่อนที่ 16.0 จะทำให้เป็น default อย่างเป็นทางการ ตัวเลขนี้บอกอย่างชัดเจนว่า Turbopack ไม่ใช่ tech แปลกที่รอลุ้น มันผ่าน production traffic ในระดับ Vercel-scale มาแล้ว รายละเอียดใน Next.js 16 release blog ครอบคลุมทั้ง breaking changes และ migration path อย่างเป็นทางการ ผมแนะนำให้อ่านทั้งหน้าก่อนตัดสินใจย้าย เพราะมีรายการ deprecation ที่ทีมส่วนใหญ่มองข้าม

วิธี enable Turbopack สำหรับ production build

ใน Next.js 16 คุณไม่ต้องทำอะไรเป็นพิเศษ. next build ใช้ Turbopack เป็น default อยู่แล้ว แต่ในหลายทีมมี pipeline ที่ตั้งค่า --webpack ไว้เพราะช่วง 15.x เคยเป็น opt-in ต้องรื้อออก

{
  "scripts": {
    "dev": "next dev",
    "build": "next build",
    "start": "next start",
    "build:webpack": "next build --webpack"
  }
}

ถ้าอยากบังคับให้ใช้ Webpack ชั่วคราวเวลาเจอ bug ให้ใช้ flag --webpack ได้ ตัวผมเองมักจะเก็บ script build:webpack ไว้เผื่อกรณีต้องเทียบ output size หรือ debug issue เฉพาะ Turbopack (ทำครั้งสองครั้งต่อ release cycle ก็พอ อย่าใช้เป็น default)

ยืนยันว่า build ใช้ Turbopack จริง

สังเกต log output ของ next build ถ้าเห็นบรรทัด ▲ Next.js 16.x.x (Turbopack) และ compilation time หลัก millisecond ถึงต้นวินาที นั่นคือ Turbopack ทำงานอยู่ ถ้าเห็น webpack compiled successfully หรือ Webpack banner แปลว่ายังใช้ Webpack อยู่

▲ Next.js 16.2.0 (Turbopack)
   ✓ Compiled successfully in 615ms
   ✓ Linting and checking validity of types in 1.1s
   ✓ Collecting page data in 208ms
   ✓ Generating static pages (32/32) in 239ms
   ✓ Finalizing page optimization in 12ms

เห็น "Compiled successfully in 615ms" ในโปรเจกต์ขนาด ~30 pages ถือว่า Turbopack ทำงานปกติ ถ้าตัวเลขเกิน 5 วินาทีทั้งที่โปรเจกต์เล็ก ให้ไปที่ section Turbopack build ช้าผิดปกติ ผมเจอเคสนี้ตอน ship โปรเจกต์แรกที่ย้ายจาก 15.4 มา 16.0, ปรากฏว่าลืมถอด webpack plugin ตัวเก่าออก

Turbopack vs Webpack: benchmarks จริงจากโปรเจกต์ production

ตัวเลขต่อไปนี้มาจากการวัดจริง (ไม่ใช่ marketing slide) ผมรวบรวมจาก benchmark ของ Makerkit SaaS Kit และโปรเจกต์ที่ผมดูแล เพื่อให้เห็นภาพว่าเปลี่ยนมาแล้วได้อะไรกลับมาบ้าง

ตัวชี้วัด	Turbopack (16.2)	Webpack (15.x)	ผลต่าง
Dev server startup	603 ms	1,083 ms	~1.8x เร็วกว่า
Production build (~30 routes)	5.7 s	24.5 s	~4.3x เร็วกว่า
HMR update (route ใหญ่)	< 100 ms	500–800 ms	~5–8x เร็วกว่า
Cold compile route แรก	~615 ms	~3.2 s	~5x เร็วกว่า
Memory ตอน dev (16.3 preview)	ลดลงถึง 90%	baseline	ลด memory pressure
Custom Webpack loader	❌ ยังไม่รองรับทุกตัว	✅ รองรับทั้งหมด	ตรวจ compat ก่อน migrate

ที่น่าสนใจคือเรื่อง scale. เมื่อโปรเจกต์ใหญ่ขึ้น Turbopack ยิ่งได้เปรียบ เพราะ incremental compilation ทำให้ compile time แปรผันกับ "ขนาดของสิ่งที่เปลี่ยน" ไม่ใช่ "ขนาดของ route" ต่างจาก Webpack ที่ต้อง re-analyze module graph บ่อย ๆ ตัวเลขใน Next.js 16.2 Turbopack release notes รายงาน compile time เร็วขึ้น 400–900% ในหลายโปรเจกต์รวมถึง vercel.com เอง

Config Turbopack ใน next.config.ts แบบละเอียด

ตั้งแต่ 16.0 Turbopack config ย้ายไปอยู่ใน top-level turbopack key ของ next.config.ts แล้ว (เดิมอยู่ใต้ experimental.turbo) ถ้ายังไม่ย้าย โปรแกรมจะ warn ตอน build

import type { NextConfig } from 'next'

const nextConfig: NextConfig = {
  turbopack: {
    // 1) module aliasing สำหรับ path mapping แบบเบา ๆ
    resolveAlias: {
      '@ui': './src/design-system/ui',
      '@lib': './src/lib',
    },

    // 2) rules สำหรับ custom loader (loader ต้องเป็น webpack-compatible)
    rules: {
      '*.svg': {
        loaders: ['@svgr/webpack'],
        as: '*.js',
      },
      '*.mdx': {
        loaders: ['@mdx-js/loader'],
        as: '*.tsx',
      },
    },

    // 3) memory limit สำหรับ CI runner ขนาดเล็ก
    memoryLimit: 4096, // MB

    // 4) กำหนด root explicitly เมื่ออยู่ใน monorepo
    root: __dirname,
  },
}

export default nextConfig

Options ที่ทีม architect ควรรู้

• resolveAlias: ใช้แทน tsconfig.json paths ในกรณีที่ต้องการ alias ที่ Turbopack เห็นก่อน TypeScript ทำงาน เช่น mock module ตอน test
• rules: สำหรับ custom loader ที่เขียนแบบ webpack style ยังต้องเป็น loader ที่รองรับ async API ของ webpack v5
• memoryLimit: สำคัญมากถ้าใช้ GitHub Actions free tier (7 GB) หรือ container ขนาดเล็ก ผมเคยเจอ CI OOM ตอน build เพราะ Turbopack กิน memory มากตอน parse module graph ครั้งแรก
• root: บังคับตั้งเสมอใน monorepo ไม่งั้นมันจะไล่หา pnpm-lock.yaml ระดับสูงกว่าจนพัง

Persistent Cache และ File System Caching

Feature นี้เป็นเหตุผลหลักที่ผมกล้าเปิด Turbopack ใน CI production. File System Cache ที่ stable ตั้งแต่ 16.1 ทำให้ build ครั้งที่ 2 บน CI เร็วขึ้นถึง 50–70% ถ้า cache directory ถูก restore ได้อย่างถูกต้อง

เปิด File System Cache บน CI

# .github/workflows/build.yml
name: Build
on: [push]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: pnpm/action-setup@v3
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'pnpm'

      # Restore Turbopack cache
      - name: Cache Turbopack
        uses: actions/cache@v4
        with:
          path: |
            .next/cache
            node_modules/.cache/turbopack
          key: turbopack-${{ hashFiles('pnpm-lock.yaml', 'next.config.ts') }}-${{ github.sha }}
          restore-keys: |
            turbopack-${{ hashFiles('pnpm-lock.yaml', 'next.config.ts') }}-
            turbopack-

      - run: pnpm install --frozen-lockfile
      - run: pnpm build

key สำคัญคือ hash lockfile + next.config.ts เพราะเวลา dependency หรือ config เปลี่ยน cache ต้อง invalidate ทั้งหมด ไม่งั้นจะได้ artifact ที่ผสมของเก่ากับของใหม่ (ผมเคยเจอบั๊กที่ prod หน้าเดียวใช้ CSS เก่าเพราะเหตุนี้ ใช้เวลาไล่หาอยู่ 2 ชั่วโมง)

Persistent Cache ใน 16.3 preview

16.3 preview เพิ่ม Persistent Cache ที่เก็บ compilation state ระหว่าง restart กระบวนการ ผลคือ dev server startup ครั้งที่ 2 เร็วขึ้นมากและ memory usage ลดลงได้ถึง 90% ในโปรเจกต์ใหญ่ ถ้าอยากลองก่อน stable (คาดว่าจะเข้า 16.4):

pnpm add next@preview

ถ้าอยากเข้าใจ architecture ลึกลงไปอีก แนะนำ Next.js 16.3 Turbopack blog เขาอธิบายว่า Persistent Cache ใช้ hash-based content-addressed storage คล้ายที่ Bazel ใช้ ไม่ใช่ file mtime

ใช้ Turbopack ใน monorepo (Turborepo, pnpm workspaces)

นี่คือส่วนที่ผมมี war-story หลายรอบ เพราะ monorepo เป็น edge case ทุกอย่าง ตั้งแต่ package resolution ไปจนถึง tsconfig extends ทีมที่มาใหม่มักจะพลาดในจุดเดิม ๆ

สิ่งที่ต้อง config ให้ครบ

1. ตั้ง turbopack.root ให้ชัด: ให้เป็น path ของ Next.js app ไม่ใช่ root ของ monorepo ถ้าไม่ทำ Turbopack จะไล่ resolve module ไปเจอ workspace อื่น
2. transpile packages ใน workspace: ใช้ transpilePackages ใน next.config.ts เพื่อบอก Next.js ว่า internal packages ตัวไหนที่ต้อง transpile
3. Turborepo pipeline: กำหนด outputs ให้ครอบคลุม .next/** และ !.next/cache/** เพื่อไม่ให้ cache ตัว build cache

// apps/web/next.config.ts
import type { NextConfig } from 'next'
import path from 'node:path'

const nextConfig: NextConfig = {
  transpilePackages: ['@acme/ui', '@acme/analytics', '@acme/db'],
  turbopack: {
    root: __dirname,
    resolveAlias: {
      '@acme/ui': path.resolve(__dirname, '../../packages/ui/src'),
    },
  },
}

export default nextConfig

// turbo.json
{
  "$schema": "https://turbo.build/schema.json",
  "tasks": {
    "build": {
      "dependsOn": ["^build"],
      "outputs": [".next/**", "!.next/cache/**"],
      "env": ["NEXT_PUBLIC_*", "DATABASE_URL"]
    },
    "dev": {
      "cache": false,
      "persistent": true
    }
  }
}

ในทีมผมที่ใช้ pnpm workspaces + Turborepo (30+ packages) การ config root อย่างชัดเจนตัดเวลา build ลงประมาณ 40% เพราะ Turbopack ไม่ต้อง scan ทั้ง monorepo แต่จะ scan เฉพาะที่จำเป็น การละเลย option ตัวเล็ก ๆ ตัวนี้ทำให้ทีมผมเสียเวลา CI ไปหลายชั่วโมงต่อสัปดาห์ก่อนจะจับได้

Turbopack build ช้าผิดปกติ: วิธี debug

คำถามยอดฮิตในทีม architect คือ "ทำไม Turbopack ของฉันช้ากว่าที่โฆษณาไว้?" ผมเจอมาแล้วหลาย pattern สรุปเป็น checklist ที่ใช้ได้ทันที

1) ตรวจว่า Turbopack ทำงานอยู่จริง

ดู log ถ้าเห็น "webpack compiled successfully" แสดงว่า framework fallback ไป Webpack เพราะมี config ที่ Turbopack ยังไม่รองรับ วิธีเช็ค: รัน next build --debug จะเห็นเหตุผลของ fallback ชัดเจน

2) Custom loader ทำ blocking

Loader ที่เขียนไม่ดีจะทำให้ Turbopack ช้ากว่า Webpack ด้วยซ้ำ เพราะ Turbopack ทำ parallelization แต่ loader ที่ synchronous จะ block worker ตรวจ loader ทุกตัวว่า return Promise หรือใช้ callback

3) Barrel file ขนาดใหญ่

ไฟล์ index.ts ที่ re-export ทุกอย่างจาก 300 modules คือฆาตกรทั้ง tree shaking และ compile time แม้ Turbopack จะเร็ว แต่ยังต้อง parse ทั้งกราฟก่อน ปกติผมใช้ ESLint rule no-restricted-imports ห้าม import จาก barrel ใน hot path

4) Memory pressure จนต้อง swap

# วัด memory ตอน build
/usr/bin/time -l pnpm build

# ถ้า max resident set size > 6GB บน CI 7GB ปัญหาแน่นอน

ถ้าเจอให้เพิ่ม turbopack.memoryLimit ใน config หรืออัพ CI runner เป็น 16GB. Turbopack ใช้ memory มากกว่า Webpack ตอน parse ครั้งแรก แต่จะเร็วกว่าเมื่อ cache warm

5) เช็ค version

เวอร์ชัน 16.0.0 ยังมี regressions หลายเรื่อง แนะนำให้อัพเป็น 16.2+ ซึ่งมี 200+ bug fixes สำหรับ Turbopack ตามที่ระบุใน release notes อย่างเป็นทางการ (ผมเจอบั๊ก HMR reload ทั้งหน้าบน 16.0.3, อัพเป็น 16.1.2 แล้วหายไปเอง)

Migration checklist: จาก Webpack ไป Turbopack

ผมมี checklist ที่ใช้เวลา migrate โปรเจกต์ SaaS ที่มี ~15 apps ใน monorepo ให้ใช้ได้กับทุกทีม เอาไปปรับตามบริบทได้เลย

Pre-migration audit

1. list ทุก webpack() function call ใน next.config, หา Turbopack equivalent ทีละตัว
2. list ทุก custom loader และเช็คว่ารองรับ webpack v5 async API
3. list ทุก webpack plugin (DefinePlugin, IgnorePlugin, ContextReplacementPlugin ฯลฯ)
4. ตรวจ dependency ที่ใช้ require.context หรือ dynamic require ที่ Turbopack ยังไม่รองรับ

Migration steps

1. อัพเป็น Next.js 16.2 ล่าสุดใน branch แยก
2. ย้าย experimental.turbo ไปเป็น turbopack ระดับ top-level
3. ลบ webpack() function ออก แทนที่ด้วย Turbopack rules หรือ env var
4. รัน next build และดู log ทั้งหมด ถ้ามี warning ให้แก้ก่อน
5. เทียบ bundle size ระหว่าง Webpack build และ Turbopack build ด้วย @next/bundle-analyzer
6. รัน E2E test suite เต็ม โดยเฉพาะส่วนที่มี dynamic import และ SVG/asset loader
7. Deploy staging และดู Web Vitals 1 สัปดาห์เต็มก่อน promote production

ผมพบว่า bundle size ของ Turbopack มักเล็กกว่า Webpack ราว 3–8% เพราะ tree shaking ที่ aggressive กว่า แต่บาง edge case เช่น library ที่มี side effect declaration ผิด อาจถูก tree-shake ทิ้ง ต้องเทียบ output จริงเสมอ ถ้าอยากดู pattern การ integrate กับ streaming/rendering strategy อ่านต่อที่ คู่มือ Next.js 16 Streaming + Suspense และ Partial Prerendering (PPR) guide

คำถามที่พบบ่อย

Turbopack พร้อมใช้ production หรือยังในปี 2026?

พร้อมแล้ว Turbopack เป็น bundler default สำหรับทั้ง dev และ production build ตั้งแต่ Next.js 16.0 (ตุลาคม 2025) และผ่าน production traffic ในระดับ Vercel-scale โดยมี File System Cache stable ตั้งแต่ 16.1 แนะนำให้อัพเป็น 16.2+ เพราะมี bug fixes สำคัญ 200+ รายการ

Turbopack เร็วกว่า Webpack เท่าไหร่?

production build เร็วกว่าประมาณ 2–4 เท่า จาก benchmark ของ Makerkit SaaS Kit ได้ Turbopack 5.7 วินาที เทียบกับ Webpack 24.5 วินาที (~4.3x เร็วกว่า) ส่วน HMR update เร็วกว่า 5–8 เท่า และในโปรเจกต์ใหญ่ยิ่งได้เปรียบเพราะ incremental compilation ทำให้เวลาเปรียบเทียบขึ้นกับ "ขนาดของสิ่งที่เปลี่ยน" ไม่ใช่ขนาดโปรเจกต์

Turbopack รองรับ webpack loader และ plugin ทุกตัวหรือไม่?

ยังไม่รองรับทั้งหมด Turbopack รองรับ webpack loader ที่ implement async API ของ webpack v5 ผ่าน turbopack.rules แต่ webpack plugin (เช่น DefinePlugin, BundleAnalyzerPlugin) ยังไม่รองรับ ต้องใช้ Turbopack equivalent หรือย้าย logic ไปที่ layer อื่น เช่น env var หรือ next-analyzer plugin เวอร์ชันใหม่

จะเปิดใช้ Turbopack ใน Next.js 16 อย่างไร?

ไม่ต้องทำอะไรเพิ่ม. next dev และ next build ใช้ Turbopack เป็น default อยู่แล้ว ถ้าอยากบังคับ Webpack ชั่วคราวเวลา debug ให้ใช้ flag --webpack เช่น next build --webpack และถ้าเดิมมี script ที่ใส่ --turbopack ไว้ตั้งแต่ 15.x ให้ลบออกได้เลย

Turbopack ใช้ memory มากกว่า Webpack หรือไม่?

ในช่วง cold start Turbopack ใช้ memory มากกว่า เพราะต้อง parse module graph ทั้งหมดครั้งแรก แต่หลังจากนั้น incremental compilation ทำให้ memory footprint ต่ำกว่า ใน Next.js 16.3 preview มี Persistent Cache ที่ลด memory usage ตอน dev ได้ถึง 90% ถ้า CI runner memory จำกัด ให้ตั้ง turbopack.memoryLimit ใน next.config.ts

Persistent Cache กับ File System Cache ต่างกันอย่างไร?

File System Cache (stable ตั้งแต่ 16.1) เก็บ compilation result ระหว่าง build เพื่อให้ CI build ครั้งต่อไปเร็วขึ้น ส่วน Persistent Cache (16.3 preview) เก็บ compilation state ระหว่าง restart process ทำให้ dev server startup ครั้งที่ 2 เร็วขึ้นและใช้ memory น้อยลง Persistent Cache ยังไม่ stable แนะนำใช้เฉพาะ dev หรือ preview environment