Turbopack ב-Next.js 16: מדריך הגירה מ-Webpack לביצועי ייצור (2026)

עודכן: 14 ביוני 2026

Turbopack הוא ה-bundler הדיפולטיבי והיציב של Next.js 16, הן ל-next dev והן ל-next build. הוא מחליף את Webpack כברירת מחדל, מבוסס Rust, ובמדידות אמת מציג זמני build של 5.7 שניות מול 24.5 שניות ב-Webpack באותו פרויקט, וזמן startup מקבילי שמתחיל מאות מילישניות. אם אתם מתחזקים מונורפו, design system עם עשרות חבילות פנימיות, או pipeline CI/CD שצובר זמן, Turbopack כבר לא בגדר הימור. הוא כן דורש מכם להבין מה בדיוק נשבר בהגירה.

• Turbopack יציב ודיפולטיבי ב-Next.js 16 (אוקטובר 2025), כולל ל-production builds, ולא רק ל-dev.
• גרסת ה-stable הנוכחית היא 16.2.7 (יוני 2026); 16.2 הוסיפה כ-400% שיפור ב-next dev startup בזכות ניתוח מודולים מקבילי.
• מפתחות webpack ב-next.config.ts שיהיו לא תואמים יכשילו את ה-build. הברירות הן: לעבור ל-Turbopack, להעביר את הלוגיקה ל-Webpack loader חליפי, או להריץ עם דגל --webpack זמני.
• בעיות נפוצות בהגירה: @svgr/webpack, משתני סביבה ללא NEXT_PUBLIC_, ייבוא נכסים סטטיים, ו-OOM ב-containers עם זיכרון מוגבל.
• דרישת Node.js עלתה ל-20.9.0 ומעלה. middleware.ts עברה ל-proxy.ts, ו-Cache Components תופסות את מקום caching ה-implicit.
• זמן ההגירה הריאלי לאפליקציה ייצורית בינונית: 2 עד 10 שעות, רובן על Webpack plugins ייעודיים ו-async params.

מה זה Turbopack ולמה הוא יציב עכשיו

Turbopack הוא bundler כתוב ב-Rust שהחליף את Webpack כברירת המחדל של Next.js. הארכיטקטורה שלו שונה משמעותית. בעוד ש-Webpack מקדד cache ברמת המודול, Turbopack בנוי סביב function-level caching, כך שכל פעולה היא פונקציה טהורה ממומשת (memoized) שמחזירה את אותה תוצאה לאותו קלט. כשמשנים קובץ אחד, רק העץ של הפונקציות שתלויות בו מחושב מחדש, ולא כל ה-module graph.

הדרך לכאן הייתה ארוכה. Turbopack הופיע ב-Next.js 13 ב-2022 בסטטוס alpha, עבר beta ב-15.0, הפך לדיפולטיבי ל-dev ב-15.3, וקיבל אישור יציב מלא ב-Next.js 16 ב-21 באוקטובר 2025. לפי הצוות של Vercel, יותר מ-50% מ-dev sessions ו-20% מ-production builds כבר רצו על Turbopack לפני ה-stable, מספרים שהפכו את האישור לפורמלי יותר מאשר ניסיוני.

החשיבות של היציבות היא לא בקוד עצמו, אלא במחויבות. כשאני מתחזק build-system במונורפו עם 40 חבילות פנימיות, ההבדל בין "beta" ל-"stable" הוא ההבדל בין דיון של שעתיים עם ה-staff על סיכון, לבין PR שכבר עבר. בלוג ההכרזה הרשמי של Next.js 16 מציין שזו המהדורה הראשונה שבה Next.js נטוש לחלוטין מ-Webpack כדיפולטי.

ביצועים: Turbopack מול Webpack בייצור

הביצועים הם הסיבה האמיתית למעבר. במדידות שפרסם צוות Makerkit על פרויקט SaaS Kit ייצורי, Turbopack הוריד את ה-next build מ-24.5 שניות ל-5.7 שניות, שיפור של פי 4.3 לערך. ב-next dev ה-cold start ירד מ-1083ms ל-603ms, ועם File System Caching שהפכה ליציבה ב-16.1 (דצמבר 2025), restart של dev server כבר לא מאפס את ה-cache. ב-Next.js 16.2 (מרץ 2026) נוסף שיפור של כ-400% ב-startup בזכות parallel module analysis. בפועל, אפליקציות עם 500 מודולים או יותר עולות "בשניות במקום עשרות שניות".

אבל המספרים לא נקיים. אנליזה ייצורית של Cal.com הראתה build מהיר ב-19% (לא פי 5 כפי שהשיווק מציע), מול bundles גדולים ב-72%. הסיבה: tree-shaking ב-Turbopack עוד לא מגיע לרמה של webpack 5 בכל המקרים, במיוחד בחבילות שמשתמשות ב-"sideEffects": false אגרסיבי או ב-barrel files. הקריאה הסופית תלויה ב-stack שלכם. בפרויקטים שאני מתחזק, האפליקציות עם הכי הרבה client components הראו את השיפור הכי קטן ב-bundle size, ואת השיפור הכי גדול ב-build time. הגיוני, אם חושבים על זה.

מימד	Webpack (Next.js 15)	Turbopack (Next.js 16)
זמן next build (SaaS Kit)	24.5s	5.7s
זמן next dev cold start	1083ms	603ms (16.0) / ~150ms (16.2)
HMR latency	~700ms	~50ms
שפת מימוש	JavaScript	Rust
ארכיטקטורת cache	Module-level	Function-level memoization
גודל bundle (Cal.com)	בסיס	+72% (ידרוש tuning)
תמיכת loaders מותאמים	מלאה	חלקית, דרך webpack-loader compat
File System Caching	אין	יציבה מ-16.1

איך מהגרים מ-Webpack ל-Turbopack שלב אחר שלב

אז בואו ניגש לפרקטיקה. הגירה אמיתית, במונורפו אמיתי, נראית כך:

1. שדרוג Node.js ל-20.9 ומעלה. Next.js 16 נכשל בכל גרסה נמוכה יותר. בדקו את engines ב-package.json וב-CI. ב-Dockerfile, החליפו ל-node:20.18-slim או חדש יותר.
2. שדרוג חבילות: npm install next@latest react@latest react-dom@latest. אם אתם על pnpm במונורפו, וודאו ש-"next": "^16.2.7" משוקף בכל ה-workspaces.
3. הרצת next dev ראשונה. אם אין לכם webpack ב-config, סביר להניח שזה פשוט יעבוד. אם יש, תקבלו warning ברור על מה לא נתמך.
4. אודיט של next.config.ts: כל ערך תחת webpack(config) => ... צריך להתורגם או להישאר עם flag. ראו את מיפוי תצורות בהמשך.
5. הרצת next build והשוואה לזמן הישן. תעדו את שני המספרים, תצטרכו אותם כדי להצדיק את ה-PR.
6. בדיקת bundle size עם next build --debug או עם @next/bundle-analyzer. אם ה-bundle גדל ביותר מ-20%, חזרו לבדוק barrel imports.
7. QA על staging לפני production. בעיקר client routing, ייבוא SVG, ו-edge runtime.

הניסיון שלי: ה-PR הראשון חייב לעדכן את ה-CI cache key. Turbopack כותב את ה-cache שלו ל-.next/cache/turbopack, וה-action של GitHub Actions שלכם כנראה עדיין מחפש את .next/cache/webpack. אם לא תעדכנו, תאבדו את היתרון הגדול ביותר של file system caching בריצה השנייה. נפלתי על זה פעם אחת ב-PR שניסה לפתור פיצ'ר אחר לגמרי. שעה של תהייה למה ה-CI עדיין איטי.

# .github/workflows/build.yml
- name: Cache Turbopack
  uses: actions/cache@v4
  with:
    path: |
      .next/cache/turbopack
      node_modules/.cache/turbo
    key: turbopack-${{ runner.os }}-${{ hashFiles('pnpm-lock.yaml') }}-${{ hashFiles('app/**/*', 'components/**/*') }}
    restore-keys: |
      turbopack-${{ runner.os }}-${{ hashFiles('pnpm-lock.yaml') }}-

שינויים שוברים נפוצים והפתרונות

אלה הבעיות שתפגשו ב-90% מההגירות:

תצורות Webpack מותאמות

המפתח webpack ב-next.config.ts deprecated. אם יש לכם plugin שאין לו מקבילה ב-Turbopack (למשל case-sensitive-paths-webpack-plugin או custom resolver), שתי האפשרויות שלכם הן: להריץ עם next build --webpack כ-escape hatch זמני, או להזיז את הלוגיקה למקום אחר ב-pipeline (לדוגמה, post-build script). הצוות של Vercel מתכנן הוצאה של הדגל --webpack ב-Next.js 18, ולכן אל תתבססו עליו לטווח ארוך.

משתני סביבה ללא NEXT_PUBLIC_

Turbopack מקפיד יותר. מי שעשה process.env.API_KEY ישירות בקומפוננטת client (כי "זה עבד") יקבל שגיאה מיידית עם Module not found. הפתרון הוא להוסיף את ה-prefix NEXT_PUBLIC_, או להעביר את הקריאה ל-Server Component / Server Action. זו דווקא הזדמנות לאודיט אבטחה: לפעמים יש משתנים שלא היו אמורים להגיע ל-client מלכתחילה.

async params ו-cookies()

זה לא חדש ל-Turbopack ספציפית, אבל Next.js 16 אוכף את זה בקפדנות. params, searchParams, cookies() ו-headers() חייבים להיות מסוננים ב-await. כל route שמשתמש בהם סינכרונית יישבר.

// app/blog/[slug]/page.tsx
type Props = { params: Promise<{ slug: string }> };

export default async function BlogPost({ params }: Props) {
  const { slug } = await params; // חובה, לא params.slug ישיר
  return <article>{slug}</article>;
}

מיפוי תצורות מ-next.config.ts ל-Turbopack

רוב התצורות הנפוצות יש להן מקבילה ישירה תחת המפתח turbopack ב-next.config.ts. ההמרה הבסיסית:

// next.config.ts (Next.js 16)
import type { NextConfig } from 'next';

const config: NextConfig = {
  turbopack: {
    rules: {
      '*.svg': {
        loaders: ['@svgr/webpack'],
        as: '*.js',
      },
      '*.md': {
        loaders: ['raw-loader'],
        as: '*.js',
      },
    },
    resolveAlias: {
      '@ui': './packages/ui/src',
      '@design-tokens': './packages/design-tokens/src',
    },
    resolveExtensions: ['.mdx', '.tsx', '.ts', '.jsx', '.js', '.json'],
    moduleIds: 'deterministic', // ל-cache stability בייצור
  },
  experimental: {
    cacheComponents: true, // לאינטגרציה עם use cache
  },
};

export default config;

שימו לב לארבעה דברים. ראשית, turbopack.rules מקבל אובייקט שבו ה-key הוא glob של קבצים, ולא array של regex כמו ב-Webpack. שנית, ה-loaders עצמם נטענים דרך שכבת תאימות, כך ש-loader webpack מסוים יכול לעבוד עכשיו וליפול אחר כך. שלישית, resolveAlias מחליפה את config.resolve.alias מ-Webpack (שימושי במונורפו). רביעית, ה-flag cacheComponents משולב עם המעבר אבל לא חובה. קראו על זה במדריך שלנו ל-Cache Components ב-Next.js 16.

SVGR וייבוא SVG ב-Turbopack

זה הבאג שמיותר את חצי מההגירות. הסיפור: @svgr/webpack פלאגין שמאפשר import Logo from './logo.svg' כקומפוננטת React. הוא תוכנן ל-Webpack ולא תמיד עובד ב-Turbopack, בעיקר בייצור, שבו ה-import יחזיר undefined בלי שגיאה ברורה. נפלתי על זה ב-PR שניסה לעדכן רק את ה-Node version. גילינו רק ב-staging שהלוגו של המוצר נעלם.

שתי הגישות שעובדות עבורי ב-2026:

1. turbopack.rules עם loader compat (כפי שמופיע למעלה). עובד לרוב הפרויקטים, אבל פוגע מעט בזמן build כי שכבת התאימות אינה native.
2. SVG כ-Component ידני. מעבירים את ה-SVG ל-React component עם @svgr/cli פעם אחת בזמן build script, ומייבאים .tsx במקום .svg. זה מהיר יותר, שולט יותר, ועוקף את כל הבעיה.

// scripts/generate-svg-components.mjs
import { execSync } from 'node:child_process';
execSync(
  'svgr --typescript --out-dir components/icons src/svg-source',
  { stdio: 'inherit' }
);

// package.json
{
  "scripts": {
    "prebuild": "node scripts/generate-svg-components.mjs",
    "build": "next build"
  }
}

Turbopack במונורפו: pnpm workspaces ו-Turborepo

מי שעובד במונורפו יודע שה-build system הוא אזור מלחמה שקט. Turbopack ו-Turborepo (שני מוצרים שונים של Vercel, למרבה הבלבול) משלימים אבל לא תלויים. המפתח הוא להגדיר ל-Turborepo לעקוב אחרי ה-cache של Turbopack:

// turbo.json
{
  "$schema": "https://turborepo.com/schema.json",
  "tasks": {
    "build": {
      "dependsOn": ["^build"],
      "outputs": [".next/**", "!.next/cache/**"],
      "inputs": [
        "app/**",
        "components/**",
        "lib/**",
        "next.config.ts",
        "tsconfig.json"
      ],
      "cache": true
    },
    "dev": {
      "cache": false,
      "persistent": true
    }
  }
}

הנקודה החשובה: outputs מתעלם מ-.next/cache/** כי File System Caching של Turbopack כבר מנהל את עצמו. אם תכניסו את התיקייה ל-Turborepo cache, תקבלו כפילויות גדולות ולחץ על ה-remote cache. בעיה נוספת שראיתי: resolveAlias עובד טוב לחבילות במונורפו רק אם ה-tsconfig.json משקף את אותם paths. אחרת, ה-IDE שלכם יאבד את ה-resolution גם אם ה-build יעבור.

בעיות זיכרון ו-OOM ב-Docker/Kubernetes

Turbopack שומר module graph בזיכרון. אם אתם מריצים אותו בpod של Kubernetes עם memory: 512Mi שעבד מצוין עם Webpack ב-Next.js 15, סביר שתראו OOMKilled ב-Next.js 16. הסיבה היא שילוב של שני דברים: function-level memoization שמחזיק יותר ביניים, ו-RSC rendering engine שמחזיק יותר stream state.

שני פתרונות:

1. הגדילו את ה-memory limit ב-build pod ל-2Gi לפחות. ה-runtime pod יכול להישאר 512Mi כי הוא לא מריץ build.
2. הפרידו build מ-runtime ב-Dockerfile. השלב הראשון בנוי עם image גדול ובלי limit, השני מעתיק את .next/standalone בלבד. זה כבר Best Practice ב-Next.js 16.

# Dockerfile
FROM node:20.18-alpine AS deps
WORKDIR /app
COPY package.json pnpm-lock.yaml ./
RUN corepack enable && pnpm install --frozen-lockfile

FROM node:20.18-alpine AS builder
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .
ENV NEXT_TELEMETRY_DISABLED=1
RUN pnpm build

FROM node:20.18-alpine AS runner
WORKDIR /app
ENV NODE_ENV=production
COPY --from=builder /app/.next/standalone ./
COPY --from=builder /app/.next/static ./.next/static
COPY --from=builder /app/public ./public
EXPOSE 3000
CMD ["node", "server.js"]

מתי לא לעבור עכשיו

למרות הכל, יש מקרים שבהם אני אישית הייתי מחכה. אם המונורפו שלכם מתבסס על Webpack plugin ייעודי שלא נתמך (למשל SentryWebpackPlugin בקונפיגורציה שדורשת hooks מסוימים), כדאי לעקוב אחרי המעקב באישיו בריפו של Next.js לפני שמשקיעים שעות בריפאקטור. גם אם אתם בערב freeze לפני release גדול, ההגירה היא בדיוק סוג השינוי שלא רוצים לעשות בלילה לפני production. תאמינו לי על זה.

למי שעדיין בדרך לשדרוג עצמו, מומלץ לעבור קודם דרך המעבר מ-middleware.ts ל-proxy.ts ולוודא שכל proxy logic עובד, ורק אחר כך לעבור לדאוג ל-bundler. אלה שני שינויים נפרדים מבחינת סיכון, וכדאי לא להלחים אותם ל-PR אחד גדול.

שאלות נפוצות

האם Turbopack יציב ב-Next.js 16 גם לייצור?

כן. החל מ-Next.js 16.0 (אוקטובר 2025) Turbopack יציב ודיפולטיבי גם ל-next build, לא רק ל-dev. גרסת ה-stable הנוכחית בעת כתיבת המדריך היא 16.2.7 (יוני 2026), והיא מומלצת לשימוש בייצור עם בדיקות staging מקדימות.

מה ההבדל בין Turbopack ל-Turborepo?

Turbopack הוא bundler שמחליף את Webpack בתוך Next.js. Turborepo הוא orchestrator של משימות במונורפו, שמריץ build/test/lint על מספר חבילות עם cache משותף. שניהם של Vercel ושניהם כתובים ב-Rust, אבל הם פותרים בעיות שונות לחלוטין ויכולים לעבוד יחד.

איך אני נשאר זמנית על Webpack ב-Next.js 16?

הריצו את הפקודות עם הדגל --webpack: next dev --webpack או next build --webpack. זו אפשרות עוקפת זמנית בלבד שצפויה להיעלם ב-Next.js 18. השתמשו בה כדי לקנות זמן לטיפול ב-Webpack plugins לא נתמכים, לא כפתרון קבע.

למה ה-bundle שלי גדל אחרי המעבר ל-Turbopack?

tree-shaking ב-Turbopack עדיין לא משווה ל-Webpack 5 בכל המקרים, במיוחד כשמשתמשים ב-barrel files (קובץ index.ts שמייצא הכל מתת-תיקייה). הפתרון: ייבוא ישיר של רכיבים (import Button from '@ui/button' במקום import { Button } from '@ui'), והגדרת "sideEffects": false במפורש ב-package.json של כל חבילה פנימית.

האם SVGR עובד עם Turbopack?

חלקית. @svgr/webpack נטען דרך שכבת תאימות שעלולה להיכשל ב-production builds. ההמלצה היא להגדיר את turbopack.rules ל-SVG בקפידה, או, עדיף, להמיר SVG ל-React components ב-prebuild step עם @svgr/cli ולייבא רק .tsx.