Turbopack στο Next.js 15: Πλήρης Οδηγός για Ταχύτερα Builds και Dev Server (2026)

Ενημερώθηκε: 17 Αυγούστου 2026

Το Turbopack είναι ο νέος bundler του Next.js, γραμμένος σε Rust από την ομάδα της Vercel, που αντικαθιστά σταδιακά το Webpack για να προσφέρει έως και 76% ταχύτερο startup του dev server και σχεδόν στιγμιαία Fast Refresh. Στο Next.js 15 το next dev --turbopack είναι stable, ενώ το next build --turbopack έχει περάσει σε beta με στόχο το πλήρες production-ready status. Σε αυτόν τον οδηγό δείχνω πώς να το ενεργοποιήσετε, πώς μετριέται η διαφορά με τα DevTools και πού ακόμα «σκοντάφτει».

• Το Turbopack είναι το επίσημο Rust-based bundler του Next.js, ενσωματωμένο ως αντικατάσταση του Webpack για next dev και next build.
• Στο Next.js 15 το dev server είναι stable, με 53%-76% ταχύτερο cold start και έως 96% ταχύτερο Fast Refresh σε μεγάλα projects.
• Ενεργοποιείται με το flag --turbopack ή αλλάζοντας το script σε next dev --turbopack, χωρίς να χρειάζεται νέο next.config.js.
• Δεν υποστηρίζει ακόμη όλα τα Webpack loaders. Χρησιμοποιεί δικό του σύστημα μέσω turbopack.rules στο next.config.ts.
• Για production builds προτείνεται τουλάχιστον Next.js 15.3+, ώστε να είναι διαθέσιμο το next build --turbopack σε beta.
• Ένα σωστό benchmark απαιτεί καθαρό .next cache και σύγκριση σε 3-5 runs. Η πρώτη μέτρηση είναι πάντα παραπλανητική.

Τι είναι το Turbopack;

Το Turbopack είναι ένα incremental bundler γραμμένο σε Rust, σχεδιασμένο από τον Tobias Koppers (τον αρχικό δημιουργό του Webpack) και την ομάδα της Vercel, με σκοπό να αντικαταστήσει τόσο το Webpack όσο και τα Rust-based εργαλεία, όπως το SWC και το esbuild, σε ενιαία pipeline. Ο σχεδιασμός του βασίζεται σε ένα σύστημα function-level caching που ονομάζεται Turbo Engine: κάθε συνάρτηση που κάνει transform ή bundle ένα module αποθηκεύει το αποτέλεσμά της σε memoization graph, ώστε στο επόμενο rebuild να ξανατρέξει μόνο ό,τι πραγματικά άλλαξε.

Αυτό είναι θεμελιωδώς διαφορετικό από το Webpack, που ακόμα και με persistent cache πρέπει να διαβάσει και να επεξεργαστεί το dependency graph. Στη δική μου εμπειρία, σε ένα project με 900+ αρχεία που δουλεύω, ένα Fast Refresh στο Webpack έπαιρνε 3.2s. Με Turbopack έπεσε στα 210ms. Δεν είναι μαγικό. Απλά το compilation γίνεται lazy, per-request και όχι upfront για ολόκληρο το graph. Για μια εμβάθυνση στην πραγματική αρχιτεκτονική, μπορείτε να δείτε το επίσημο Turbopack API reference.

Turbopack vs Webpack: πρακτικές διαφορές

Αν έχετε ήδη ένα Next.js project σε παραγωγή με Webpack, η μετάβαση δεν είναι απλός διακόπτης. Υπάρχουν συγκεκριμένα σημεία που αλλάζουν. Ο παρακάτω πίνακας συνοψίζει τι πρέπει να ξέρετε, πριν βάλετε το flag στο package.json.

Χαρακτηριστικό	Turbopack	Webpack (Next.js default παλαιότερα)
Γλώσσα	Rust	JavaScript (Node.js)
Cold start (μεγάλο project)	~1.8s	~7.6s
Fast Refresh (μέσος όρος)	~180ms	~1.2s
Loaders	Υποκατηγορία webpack-compatible μέσω turbopack.rules	Πλήρες οικοσύστημα npm loaders
Custom Webpack config	Δεν υποστηρίζεται	Πλήρης πρόσβαση σε webpack()
Production build	Beta (Next.js 15.3+)	Stable
Memory footprint	~40% χαμηλότερο	Υψηλό, ειδικά με source maps
Ενσωμάτωση	Built-in flag --turbopack	Default

Η πιο σημαντική πρακτική διαφορά είναι η απώλεια του webpack() hook. Αν το project σας βασίζεται σε custom loaders (π.χ. raw-loader, svgr, MDX plugins), θα χρειαστεί να τα μεταφράσετε σε turbopack.rules ή να χρησιμοποιήσετε τη native λύση του Next.js. Για MDX ειδικότερα, το @next/mdx είναι πλέον Turbopack-aware και δεν χρειάζεται custom config.

Πώς ενεργοποιείται το Turbopack στο Next.js 15;

Η ενεργοποίηση είναι κυριολεκτικά μία λέξη στο package.json. Δεν χρειάζεται εγκατάσταση, δεν υπάρχει ξεχωριστό package, γιατί το Turbopack έρχεται μέσα στο next. Πρόσθεσε το --turbopack flag στα scripts σου.

{
  "scripts": {
    "dev": "next dev --turbopack",
    "build": "next build --turbopack",
    "start": "next start",
    "lint": "next lint"
  }
}

Μετά τρέξε npm run dev. Στο terminal θα δείτε την ένδειξη ▲ Next.js 15.x.x (Turbopack). Αν λείπει, το flag δεν εφαρμόστηκε σωστά. Για ελέγχους CI, μπορείτε επίσης να το ενεργοποιήσετε μέσω environment variable:

# .env.local ή CI variables
TURBOPACK=1

Επαλήθευση ότι δουλεύει

Ο πιο γρήγορος τρόπος να επιβεβαιώσετε ότι το Turbopack είναι ενεργό είναι να ανοίξετε τα Chrome DevTools, μετά Network tab και να φιλτράρετε _next/static/chunks. Τα Turbopack chunks έχουν πρόθεμα _next/static/chunks/[app-router]- και είναι σημαντικά μικρότερα από τα αντίστοιχα Webpack. Επίσης, στο Performance tab του Chrome, μπορείτε να καταγράψετε ένα trace κατά τη διάρκεια ενός Fast Refresh. Με Turbopack θα δείτε ελάχιστη δραστηριότητα στο main thread, ενώ με Webpack θα δείτε bursts από compile activity κάθε φορά που αποθηκεύετε ένα αρχείο.

Είναι το Turbopack πράγματι πιο γρήγορο;

Ναι, αλλά ο βαθμός εξαρτάται από το μέγεθος του project. Οι μετρήσεις της Vercel σε projects πάνω από 30.000 modules δείχνουν 96% ταχύτερη ενημέρωση κώδικα, ενώ σε μικρά projects (κάτω από 200 αρχεία) η διαφορά είναι πιο περιορισμένη, γύρω στο 30-40%. Για να το επιβεβαιώσετε στη δική σας βάση κώδικα, χρησιμοποιήστε το ενσωματωμένο --profile ή τρέξτε ένα ελεγχόμενο benchmark:

# Καθαρίστε το cache πριν από κάθε run
rm -rf .next

# Χρόνος cold start
time npm run dev -- --turbopack &
# Περιμένετε το "Ready in" μήνυμα, καταγράψτε το χρόνο

# Επαναλάβετε 5 φορές, κρατήστε τον διάμεσο (median), όχι τον μέσο όρο

Χρησιμοποιήστε τον διάμεσο και όχι τον μέσο όρο, γιατί ένα αργό run λόγω filesystem cache pressure θα σας παραπλανήσει. Στο δικό μου test σε ένα production project με 1.400 modules (Tailwind, tRPC, Drizzle), τα αποτελέσματα ήταν: Webpack cold start 8.4s median, Turbopack cold start 2.1s median. Τέσσερις φορές πιο γρήγορα. Το ίδιο pattern εμφανίζεται και στα Fast Refresh cycles.

Πώς μετριούνται οι βελτιώσεις με τα Chrome DevTools

Για να δείξετε στην ομάδα σας ότι η αναβάθμιση έχει αξία, ανοίξτε τα Performance DevTools και πατήστε το κουμπί record λίγο πριν αποθηκεύσετε ένα αρχείο. Θα δείτε δύο βασικές αλλαγές: (1) ο χρόνος από το fs.write event μέχρι το HMR update accepted στο console κατεβαίνει δραματικά, και (2) το CPU flame graph δεν εμφανίζει πλέον τα μεγάλα κόκκινα blocks του Webpack compile phase. Είναι από τα λίγα upgrades όπου η βελτίωση φαίνεται με γυμνό μάτι, χωρίς εξειδικευμένα profiling εργαλεία.

Configuration, loaders και custom rules

Το Turbopack χρησιμοποιεί το κλειδί turbopack μέσα στο next.config.ts, όχι το παλιό experimental.turbo που ίσχυε στο Next.js 14. Παρακάτω ένα παράδειγμα configuration για SVG imports ως React components και για custom aliases:

import type { NextConfig } from 'next'

const nextConfig: NextConfig = {
  turbopack: {
    rules: {
      // Χρήση @svgr/webpack loader για SVG imports
      '*.svg': {
        loaders: ['@svgr/webpack'],
        as: '*.js',
      },
    },
    resolveAlias: {
      // Custom path alias, αντικαθιστά το tsconfig paths σε build time
      '@/lib': './src/lib',
      '@/ui': './src/components/ui',
    },
    resolveExtensions: [
      '.mdx',
      '.tsx',
      '.ts',
      '.jsx',
      '.js',
      '.json',
    ],
  },
}

export default nextConfig

Το turbopack.rules δέχεται τα ίδια Webpack loaders που είναι grouped ως pure functions (χωρίς side effects πάνω στο compilation graph). Loaders που περιμένουν πλήρες Webpack context, π.χ. παλιοί CSS Modules preprocessors, δεν θα δουλέψουν. Στην πράξη, το 90% των mainstream loaders (SVGR, GraphQL, MDX, YAML) είναι συμβατά.

Turbopack για production builds

Το next build --turbopack είναι σε beta κατάσταση από το Next.js 15.3 και σταθεροποιείται σταδιακά προς full stable. Στα δικά μου tests, οι production builds είναι κατά 40-60% πιο γρήγοροι από τα αντίστοιχα Webpack, με μικρότερο peak memory usage. Το βασικό πλεονέκτημα δεν είναι μόνο η ταχύτητα. Είναι ότι το output είναι ντετερμινιστικό: το ίδιο codebase παράγει bit-for-bit ίδιο bundle σε κάθε machine, κάτι που κάνει το caching σε CI πραγματικά αξιόπιστο.

Πριν το ενεργοποιήσετε σε production pipeline, ελέγξτε τρία πράγματα: (1) ότι όλα τα routes σας render σωστά με ένα next build --turbopack && next start τοπικά, (2) ότι το bundle size δεν έχει αυξηθεί περισσότερο από 5% (χρησιμοποιήστε @next/bundle-analyzer) και (3) ότι τα optimized images του next/image εξακολουθούν να παράγονται σωστά. Χτύπησα αυτό το ακριβές bug σε προηγούμενο project: custom image loaders δεν εκτελούνταν σε beta version και έσπασε το LCP σε πραγματικό production traffic.

Compatibility με deployment platforms

Στο Vercel, το Turbopack build ενεργοποιείται αυτόματα αν το ανιχνεύσει στο package.json. Για self-hosted deployments (Docker, Kubernetes), βεβαιωθείτε ότι το base image σας έχει glibc 2.31+, γιατί το Rust binary του Turbopack χρειάζεται σχετικά μοντέρνο glibc. Για Alpine-based images προτείνεται node:20-alpine3.18 ή νεότερο. Αν τρέχετε το build σε ARM64 machine (π.χ. AWS Graviton), το Turbopack έχει native ARM binaries χωρίς επιπλέον setup.

Γιατί το Next.js build μου είναι αργό;

Ακόμα και με Turbopack, μερικά patterns εξακολουθούν να καθυστερούν σημαντικά το build. Οι πιο συχνοί ένοχοι που έχω δει σε code reviews είναι: (1) barrel exports που φορτώνουν ολόκληρες βιβλιοθήκες (π.χ. import { Button } from '@mui/material' αντί για import Button from '@mui/material/Button'), (2) μη-optimized SVG icons που περνούν από inline compilation, και (3) generateStaticParams functions που κάνουν εκατοντάδες API calls σε build time.

Για το πρώτο πρόβλημα, χρησιμοποιήστε το optimizePackageImports option στο next.config.ts. Αυτό λέει στο Turbopack να «σπάει» τα barrel exports σε επιμέρους chunks:

const nextConfig: NextConfig = {
  experimental: {
    optimizePackageImports: [
      '@mui/material',
      '@mui/icons-material',
      'lucide-react',
      'date-fns',
      'lodash-es',
    ],
  },
}

Για μεγαλύτερη εικόνα του τι δίνει την πιο αργή απόδοση, συνδυάστε το με τον σωστό data fetching και caching στο App Router. Συχνά η βραδύτητα δεν είναι στο bundling αλλά στο data phase του static generation. Ένα καλό benchmark είναι: αν το Compiling /page βήμα κρατάει >500ms, φταίει το bundling. Αν το Generating static pages βήμα κρατάει >5s, φταίει το data fetching.

Συχνά προβλήματα και troubleshooting

Παρακάτω τα προβλήματα που συναντώ πιο συχνά όταν βοηθώ ομάδες να μεταπηδήσουν στο Turbopack, με τη λύση καθενός.

«Module not found» σε αρχεία που δουλεύουν με Webpack

Οφείλεται σχεδόν πάντα σε custom webpack.config alias που δεν έχει μεταφερθεί στο turbopack.resolveAlias. Ελέγξτε το next.config.ts για κάθε config.resolve.alias εντολή και αντιγράψτε την στο turbopack block.

SVG imports σπάνε

Αν χρησιμοποιείτε svgr, βεβαιωθείτε ότι έχετε προσθέσει το rule που παρουσιάστηκε πιο πάνω. Ένα gotcha: το Turbopack απαιτεί το as: '*.js' ώστε να ξέρει σε τι μετατρέπεται το output. Χωρίς αυτό, βλέπετε cryptic errors του τύπου «unexpected token».

Πολύ μεγάλα HMR updates

Αν το Fast Refresh παραμένει αργό ακόμα και με Turbopack, μάλλον έχετε ένα circular dependency ή ένα shared module που καταναλώνεται από όλα τα routes. Χρησιμοποιήστε το --profile flag για να δείτε το dependency graph. Ένα κοινό pattern είναι το lib/index.ts που re-exports 200+ αρχεία. Σπάστε το σε feature-based sub-modules.

Persistent cache issues

Το Turbopack έχει το δικό του cache directory στο .next/cache/turbopack. Αν αντιμετωπίζετε παράξενα stale results μετά από upgrade του Next.js, διαγράψτε αυτόν τον φάκελο πριν κατηγορήσετε το build. Για μια λεπτομερή προσέγγιση στη διαχείριση σφαλμάτων στο App Router, το Turbopack είναι ουδέτερο, γιατί τα error boundaries και το error.tsx δουλεύουν ακριβώς όπως και με Webpack. Για ενημερωμένες οδηγίες αναβάθμισης, δείτε τον επίσημο upgrade guide του Next.js.

Συχνές ερωτήσεις

Είναι το Turbopack production ready;

Για next dev είναι stable από το Next.js 15 και χρησιμοποιείται σε production dev workflows εκατομμυρίων developers. Για next build είναι σε beta από το Next.js 15.3 και συνιστάται για μη-κρίσιμα production sites. Για high-traffic e-commerce ή financial apps καλύτερα να περιμένετε το stable release.

Χρειάζεται να αφαιρέσω το Webpack για να χρησιμοποιήσω Turbopack;

Όχι. Το Turbopack είναι απλά ένα flag και το Webpack παραμένει διαθέσιμο ως fallback. Αν αφαιρέσετε το --turbopack από το script, το Next.js επιστρέφει αυτόματα στο Webpack χωρίς να χρειάζεται καθαρισμός του project.

Ποια είναι η ελάχιστη έκδοση Next.js που υποστηρίζει σταθερό Turbopack;

Το Next.js 15.0 (Οκτώβριος 2024) σταθεροποίησε το Turbopack για next dev. Για next build --turbopack χρειάζεται τουλάχιστον η 15.3. Παλαιότερες εκδόσεις χρησιμοποιούσαν το πειραματικό --turbo flag, το οποίο έχει αντικατασταθεί.

Δουλεύει το Turbopack με το Pages Router;

Ναι, αλλά με περιορισμούς σε ορισμένα advanced Webpack features. Το Turbopack σχεδιάστηκε πρωτίστως για τον App Router, όμως όλα τα βασικά Pages Router features (getStaticProps, getServerSideProps, API routes) υποστηρίζονται πλήρως.

Πώς επιστρέφω στο Webpack αν κάτι σπάσει;

Απλά αφαιρέστε το --turbopack flag από τα scripts στο package.json και ξανατρέξτε npm install && rm -rf .next. Δεν χρειάζεται καμία άλλη αλλαγή, γιατί τα custom Webpack configs στο next.config.ts θα επανενεργοποιηθούν αυτόματα.