Turbopack di Next.js 16: Panduan 2026

Q: Bagaimana cara kembali ke Webpack di Next.js 16?

Tambahkan flag --webpack : next dev --webpack atau next build --webpack . Ini opt-out temporer yang sah kalau Anda punya plugin Webpack yang belum kompatibel, tapi hindari menjadikannya default permanen. Turbopack akan menjadi satu-satunya pipeline di rilis Next.js mendatang.

Diperbarui: 3 Agustus 2026

Turbopack adalah bundler resmi Next.js 16 yang menggantikan Webpack sebagai default untuk next dev dan next build. Ditulis dalam Rust, Turbopack menawarkan Fast Refresh 5–10x lebih cepat, build produksi 2–5x lebih cepat, dan sejak Next.js 16.1 (Desember 2025) mendukung filesystem cache stabil yang bertahan antar-build. Untuk sebagian besar proyek, upgrade ke Next.js 16 mengaktifkan Turbopack tanpa perubahan konfigurasi apapun. Bendera --turbopack tidak lagi diperlukan dan sudah dihapus dari package.json scripts.

Turbopack menjadi default di Next.js 16 (Oktober 2025) untuk next dev dan next build tanpa flag apapun.
Filesystem cache stabil di 16.1 memangkas build CI/CD setelah run pertama; build kedua bisa turun dari 3 menit 52 detik menjadi 51 detik.
Konfigurasi berpindah dari experimental.turbo ke turbopack top-level; codemod next-experimental-turbo-to-turbopack menangani migrasi otomatis.
Turbopack mendukung Webpack loaders tetapi bukan plugins — audit dependensi build sebelum upgrade.
Bundle size bisa membesar signifikan (kasus Cal.com: +117% shared chunk); pantau First-load JS pasca-migrasi.
Jika ada custom webpack config, build akan gagal secara sengaja; gunakan --webpack untuk opt-out atau migrasikan ke rules Turbopack.

Status Turbopack di 2026 dan mengapa jadi default

Next.js 16 dirilis 21 Oktober 2025 dan itu adalah versi pertama yang menjadikan Turbopack sebagai bundler default untuk seluruh lifecycle, bukan hanya next dev, tapi juga next build. Perjalanan menuju status stabil ini panjang: eksperimen di 13, dev stabil di 15, produksi stabil di 16. Sebagai orang yang menghabiskan satu quarter memigrasikan monorepo perusahaan dari Vercel-fork Webpack ke Turbopack, saya melihat perubahan ini bukan sekadar swap bundler; ini adalah reset arsitektur build system Next.js.

Turbopack ditulis di Rust dengan mesin memoization di intinya (mereka menyebutnya "Turbo Engine"): setiap pemanggilan fungsi dicatat hasilnya, dependensinya dilacak, dan invalidasi terjadi seminimal mungkin. Ketika satu file berubah, hanya komputasi yang terpengaruh yang dijalankan ulang. Berbeda dari Webpack yang graph-walking-heavy, Turbopack lebih mirip incremental build server. Efek praktisnya: pada aplikasi 200+ komponen, dev server startup turun dari ~1083ms menjadi ~603ms (44% lebih cepat), sementara build produksi turun dari ~45 detik menjadi ~17 detik (2,6x lebih cepat).

Yang membuat 16 istimewa dibanding 15 bukanlah performa dev, karena itu sudah ada. Yang baru adalah Turbopack Builds, yaitu pipeline build produksi yang sekarang matang dan sudah dijalankan di production sites Vercel, ChatGPT, dan v0 sepanjang 2024. Kalau tim Anda sempat menahan diri karena "belum production-ready", 16 adalah versi yang menghapus alasan tersebut.

Bagaimana cara mengaktifkan Turbopack di Next.js 16?

Anda tidak perlu mengaktifkan apapun. Upgrade ke next@16, jalankan next dev atau next build, dan Turbopack sudah berjalan. Bendera --turbopack dan --turbo yang biasa Anda pasang di package.json sekarang menjadi no-op dan bahkan direkomendasikan untuk dihapus agar script tetap bersih.

{
  "scripts": {
    "dev": "next dev",
    "build": "next build",
    "start": "next start"
  },
  "dependencies": {
    "next": "^16.2.0",
    "react": "^19.1.0",
    "react-dom": "^19.1.0"
  }
}

Kalau Anda butuh sementara kembali ke Webpack (misalnya karena satu plugin belum kompatibel), ada dua flag opt-out:

# Development kembali ke Webpack
next dev --webpack

# Build produksi kembali ke Webpack
next build --webpack

Saran saya: jangan jadikan opt-out sebagai default permanen. Setiap kali Anda menjalankan --webpack di CI, Anda mensubsidi utang teknis. Buka issue di GitHub Turbopack untuk plugin yang bermasalah, dokumentasikan alasan opt-out di README, dan pasang tanggal target untuk menghapus flag tersebut.

Konfigurasi Turbopack: rules, resolveAlias, dan filesystem cache

Di Next.js 15, opsi Turbopack tinggal di experimental.turbo. Di Next.js 16 opsi itu naik ke top-level turbopack dan namespace lama akan dihapus. Migrasi bisa dilakukan otomatis dengan codemod resmi:

npx @next/codemod@latest next-experimental-turbo-to-turbopack .

Berikut struktur konfigurasi lengkap yang saya pakai di monorepo produksi. Perhatikan bahwa built-in support Turbopack sudah mencakup CSS, TypeScript, dan JSX modern, jadi Anda hanya butuh rules untuk file type non-standar seperti SVG-as-component atau MDX.

// next.config.ts
import type { NextConfig } from 'next'

const nextConfig: NextConfig = {
  turbopack: {
    // Loader custom per glob pattern
    rules: {
      '*.svg': {
        loaders: [
          {
            loader: '@svgr/webpack',
            options: { icon: true, svgo: true },
          },
        ],
        as: '*.js',
      },
    },
    // Alias modul (mirip resolve.alias di Webpack)
    resolveAlias: {
      '@ui': './packages/ui/src',
      '@lib': './packages/lib/src',
    },
    // Extension tambahan untuk auto-resolve
    resolveExtensions: [
      '.tsx', '.ts', '.jsx', '.js', '.mjs', '.json',
    ],
  },
  experimental: {
    // Filesystem cache untuk build produksi (opt-in di 16.1+)
    turbopackFileSystemCacheForBuild: true,
  },
}

export default nextConfig

Filesystem cache: loncatan besar untuk CI

Fitur paling berdampak di 16.1 menurut saya adalah filesystem cache. Sebelumnya, setiap run next build di CI mulai dari nol, kompilasi ulang seluruh module graph meski cuma satu file yang berubah. Sekarang Turbopack menyimpan compiler artifacts ke disk di antara build. Build pertama tetap lambat (cold cache), tapi build kedua dan seterusnya menggunakan cache dan melewati modul yang tidak berubah.

Di CI kami (GitHub Actions dengan cache actions/cache pada .next/cache), rata-rata build turun dari 3 menit 52 detik menjadi 51 detik pada branch build. Untuk deploy 20x per hari, penghematan itu langsung terlihat di billing runner. Pastikan Anda cache directory .next/cache (bukan hanya .next/) dan pertahankan cache key stabil (gunakan hash dari pnpm-lock.yaml, bukan timestamp).

# .github/workflows/build.yml
- uses: actions/cache@v4
  with:
    path: |
      .next/cache
    key: ${{ runner.os }}-nextjs-${{ hashFiles('**/pnpm-lock.yaml') }}-${{ hashFiles('**/*.[jt]s', '**/*.[jt]sx') }}
    restore-keys: |
      ${{ runner.os }}-nextjs-${{ hashFiles('**/pnpm-lock.yaml') }}-

Bagaimana cara migrasi dari Webpack ke Turbopack?

Ini urutan yang saya rekomendasikan berdasarkan migrasi tiga aplikasi produksi (SaaS multi-tenant, e-commerce headless, dan admin dashboard internal). Ikuti sebagai checklist, bukan sebagai naskah tegar. Setiap codebase pasti punya kejutan sendiri.

Audit webpack config Anda. Jalankan grep -rn "webpack:" next.config.*. Kategorikan setiap modifikasi: loader (bisa dipindah), plugin (potensial blocker), atau alias/optimization (mudah dipindah).
Coba dulu di dev. Sebelum menyentuh CI, jalankan next dev lokal. Hydration error, dynamic import yang gagal resolve, dan CSS-in-JS quirk biasanya muncul di menit pertama.
Jalankan codemod. Codemod next-experimental-turbo-to-turbopack hanya menangani lokasi konfigurasi, bukan konten. Anda masih harus menerjemahkan setiap webpack.rules ke turbopack.rules.
Bandingkan output bundle. Jalankan next build --webpack lalu next build --turbopack berturut-turut. Simpan .next/analyze/ keduanya (aktifkan @next/bundle-analyzer) dan diff route paling ramai traffic. Ini adalah langkah paling sering diabaikan dan paling mahal untuk dilewati (lihat bagian trade-off di bawah).
Setup performance budget di CI. Gagalkan PR jika First-load JS untuk route kritis (home, product, checkout) naik di atas ambang batas. Saya pakai size-limit dengan target per-route.
Rollout bertahap. Deploy Turbopack ke staging selama minimal satu sprint. Pantau Real User Monitoring (RUM), khususnya LCP dan INP.

Untuk urusan optimasi asset yang bergantung pada Webpack loaders custom, sebagian besar bisa dipertahankan. Kalau Anda sedang menyentuh pipeline gambar sekalian, lihat panduan optimasi gambar Next.js 16 dengan AVIF dan LCP. Beberapa transformasi yang dulu dilakukan lewat loader sekarang lebih baik didelegasikan ke next/image.

Turbopack vs Webpack: benchmark nyata dan trade-off bundle size

Angka marketing dari Vercel sangat mengesankan, tapi angka yang benar-benar penting adalah angka pada codebase Anda. Berikut ringkasan benchmark dari beberapa aplikasi produksi yang saya sudah lihat langsung atau ambil dari laporan tim lain di 2026:

Metrik	Webpack	Turbopack (16.2)	Perubahan
Dev startup (200+ komponen)	~1083ms	~603ms	44% lebih cepat
Build produksi (medium app)	~45 detik	~17 detik	2,6x lebih cepat
Fast Refresh (edit komponen)	~1200ms	~45ms	96% lebih cepat
Memory usage (build besar)	Baseline	~25–35% lebih rendah	Turun 25–35%
Compile time (16.2 vs 16.0)	Baseline	Ditingkatkan	400–900% lebih cepat
Shared client chunk (Cal.com)	180 KB	391 KB	+117% lebih besar
First-load JS median (Cal.com)	Baseline	+279 KB	+72% lebih besar

Baris terakhir dua baris di atas adalah alasan saya menyebut migrasi ini sebagai "reset arsitektur build system", bukan "swap bundler". Studi kasus Cal.com (aplikasi produksi Next.js open-source yang cukup serius) menunjukkan bahwa seluruh 153 route di aplikasinya ship JavaScript lebih banyak setelah migrasi Turbopack. Median First-load JS naik 72%. Untuk pengguna 3G di negara berkembang, itu bukan trade-off yang bisa diabaikan.

Tapi laporan tidak konsisten. Beberapa tim melaporkan bundle lebih kecil berkat tree-shaking Turbopack yang lebih agresif dan akurat. Perbedaannya biasanya bergantung pada seberapa banyak Anda mengandalkan dynamic import, bagaimana konvensi barrel export tersusun, dan seberapa dalam dependency graph vendor Anda. Ukur, jangan tebak.

Berkaitan dengan strategi caching di sisi server juga: setelah build lebih cepat, bottleneck biasanya pindah ke runtime. Pelajari strategi data fetching dan caching Next.js 16 dengan use cache dan Partial Prerendering untuk memastikan gain build tidak dihabiskan oleh cache miss saat produksi.

Turbopack di monorepo: strategi rollout bertahap

Di monorepo besar (kami punya 40+ packages dengan pnpm workspace), pendekatan big-bang adalah resep untuk minggu yang penuh insiden. Yang bekerja adalah package-by-package rollout:

Mulai dari app yang paling terisolasi, biasanya admin dashboard internal dengan traffic rendah dan surface area kecil.
Aktifkan Turbopack untuk app itu saja dengan menjaga custom webpack config di next.config.js app tersebut. Package shared UI tidak perlu berubah.
Jalankan Turbopack di app tersebut selama 2 sprint. Kumpulkan issue tentang loader yang gagal, alias yang bocor antar-workspace, atau import path yang harus dinormalisasi.
Rambatkan ke app berikutnya. Refactor shared config ke package @internal/next-config agar konfigurasi Turbopack tidak duplikat.
Aplikasi customer-facing (marketing site, checkout) terakhir, hanya setelah Anda punya baseline performance budget dan telemetry.

// packages/next-config/turbopack.ts — konfigurasi shared
import type { NextConfig } from 'next'

export const sharedTurbopack: NextConfig['turbopack'] = {
  resolveAlias: {
    '@ui': '../../packages/ui/src',
    '@lib': '../../packages/lib/src',
    '@icons': '../../packages/icons/dist',
  },
  rules: {
    '*.svg': {
      loaders: ['@svgr/webpack'],
      as: '*.js',
    },
  },
}

// apps/admin/next.config.ts
import { sharedTurbopack } from '@internal/next-config/turbopack'

export default {
  turbopack: sharedTurbopack,
} satisfies NextConfig

Poin krusial di monorepo: Turbopack tidak mengikuti symlink pnpm dengan sempurna di semua kasus (khususnya kalau Anda pakai node-linker=hoisted). Gunakan node-linker=isolated jika memungkinkan, dan verifikasi bahwa resolveAlias Anda menunjuk ke path relatif dari root workspace, bukan path relatif dari app. Untuk aspek route dan navigasi di monorepo, panduan Parallel Routes dan Intercepting Routes di Next.js 16 membantu ketika Anda mulai berbagi layout antar-app.

Apa saja limitasi Turbopack di Next.js 16?

Turbopack sudah stable, tapi bukan berarti feature parity 100% dengan Webpack. Berikut daftar limitasi yang perlu Anda ketahui sebelum menetapkan tanggal migrasi:

Webpack plugins tidak didukung

Ini adalah blocker tunggal yang paling sering menghentikan migrasi. Loader (kode transformasi per file) didukung; plugin (yang meng-hook ke seluruh lifecycle build) tidak. Kalau Anda memakai SentryWebpackPlugin, BundleAnalyzerPlugin versi lama, atau plugin custom internal, cek dulu apakah vendor sudah merilis alternatif Turbopack-native. Sentry sudah, banyak vendor lain belum.

Bundle output bisa lebih besar

Seperti dijelaskan di bagian benchmark, ada risiko regresi bundle size. Ini bukan bug, tapi trade-off algoritma splitting yang berbeda. Mitigasi: aktifkan bundle analyzer, set performance budget di CI, dan pertahankan monitoring RUM untuk LCP/INP di route paling ramai. Kalau regresi terlalu parah, jangan ragu opt-out lewat --webpack sampai release berikutnya.

Module Federation belum matang

Kalau arsitektur Anda memakai Module Federation untuk micro-frontend, dukungan Turbopack masih on the roadmap Q2–Q3 2026. Sampai itu rilis, tim micro-frontend biasanya tetap di Webpack. Bagi tim seperti ini, opt-out permanen sah untuk sementara.

Beberapa custom loader belum kompatibel

Loader Webpack yang mengasumsikan API tertentu (khususnya yang memakai this.emitAsset dengan cara non-standar) mungkin gagal. Tim Turbopack di Next.js docs aktif menutup gap ini, tapi verifikasi loader Anda dengan next dev lokal sebelum commit ke migrasi CI.

Error message berbeda

Pesan error Turbopack berbeda format dari Webpack. Kalau Anda punya observability yang parse error message (misalnya Sentry rule untuk group build failures), Anda perlu menyesuaikan rules. Untuk konteks error handling runtime, panduan error handling Next.js 16 dengan error.tsx dan global-error.tsx membahas polanya secara mendetail.

Pertanyaan yang Sering Diajukan

Apakah Turbopack sudah stabil untuk production di 2026?

Ya. Sejak Next.js 16 (Oktober 2025), Turbopack stable untuk next dev dan next build. Vercel menjalankannya di ChatGPT.com dan v0 sejak 2024, dan Next.js 16.1 menambahkan filesystem cache stabil yang membuat build CI/CD 3–5x lebih cepat setelah warm cache.

Bagaimana cara kembali ke Webpack di Next.js 16?

Tambahkan flag --webpack: next dev --webpack atau next build --webpack. Ini opt-out temporer yang sah kalau Anda punya plugin Webpack yang belum kompatibel, tapi hindari menjadikannya default permanen. Turbopack akan menjadi satu-satunya pipeline di rilis Next.js mendatang.

Apakah Turbopack mendukung Tailwind CSS dan PostCSS?

Ya. Turbopack punya dukungan built-in untuk PostCSS dan Tailwind — tidak butuh css-loader atau postcss-loader tambahan. Pastikan file postcss.config.js ada di root project. Untuk Tailwind v4, Turbopack mengenali @tailwindcss/postcss plugin tanpa konfigurasi ekstra.

Apakah build produksi Turbopack menghasilkan bundle lebih kecil?

Tergantung. Beberapa proyek melaporkan tree-shaking Turbopack lebih agresif dan bundle turun; proyek lain (kasus Cal.com yang terkenal) melihat shared chunk membesar 117% dan First-load JS median naik 72%. Selalu ukur dengan @next/bundle-analyzer sebelum dan sesudah migrasi pada branch produksi.

Kapan sebaiknya menunda migrasi Turbopack?

Tunda jika: Anda mengandalkan Webpack plugin yang belum ada alternatif Turbopack-nya, arsitektur Anda memakai Module Federation, CI Anda berjalan di container dengan memory limit sangat ketat, atau Anda punya monorepo enterprise besar yang belum divalidasi. Untuk sisanya (mayoritas proyek), upgrade dan pantau baik-baik minggu pertama.