Vite, esbuild или webpack: чем платишь за скорость сборки

Проект на webpack 5 холодно стартует dev-сервер за 20–40 секунд на среднем ноутбуке, а после каждого сохранения ждёт пересборки бандла. Проект на Vite 5 отдаёт первую страницу почти мгновенно и обновляет модуль без пересборки всего дерева. Разница не в магии, а в том, что эти инструменты решают задачу принципиально по-разному. Ниже — какой из трёх выбрать под конкретную ситуацию и чем вы платите за каждый вариант.

Три инструмента — три модели работы

Сначала стоит развести понятия, потому что сравнивают часто несравнимое.

• webpack — классический бандлер. Строит полный граф зависимостей и собирает бандл целиком, и в dev, и в prod. Написан на JavaScript.
• esbuild — сверхбыстрый бандлер и трансформер, написанный на Go. Используется как самостоятельный инструмент и как движок трансформации внутри других.
• Vite — не бандлер в том же смысле. В dev он раздаёт исходники через нативные ES-модули браузера и трансформирует их по запросу через esbuild. В prod собирает бандл через Rollup.

Отсюда следует главное: Vite в разработке почти ничего не собирает заранее, а webpack собирает всё. Это и объясняет разницу в скорости старта.

Vite быстрый в dev не потому, что "оптимизирован", а потому, что переложил работу на браузер: тот сам подтягивает нужные ES-модули по мере навигации, вместо того чтобы держать готовый бандл.

Почему это разные модели, а не "кто быстрее"

webpack пересобирает граф — при старте он должен разобрать все точки входа, прогнать loader'ы (babel-loader, ts-loader, css-loader) и склеить результат. Чем больше проект, тем дольше холодный старт и тем ощутимее пауза после правки, даже с HMR и persistent cache.

Vite при старте прогоняет только предбандлинг зависимостей из node_modules через esbuild (это разовая операция, кешируется в node_modules/.vite), а собственный код приложения не трогает до запроса из браузера. Поэтому размер приложения почти не влияет на время старта dev-сервера.

Таблица: чем платишь за каждый выбор

За что платит webpack

webpack медленный по сравнению с остальными, и это цена его зрелости. Взамен вы получаете экосистему, где почти под любой формат ассета уже есть loader или плагин, и глубокий контроль над сплиттингом чанков через optimization.splitChunks. Крупные приложения с нестандартными требованиями к бандлу до сих пор живут на webpack именно из-за этого.

С версии 5 у webpack есть persistent cache на файловой системе — он заметно ускоряет повторные сборки:

// webpack.config.js — webpack 5.x
module.exports = {
  mode: 'production',
  cache: {
    type: 'filesystem', // кеш между запусками на диске
  },
  optimization: {
    splitChunks: {
      chunks: 'all', // выносим общие модули в отдельный чанк
    },
  },
};

Кеш решает проблему повторных сборок, но не холодного старта на чистой машине или в CI без сохранённого кеша — там webpack всё равно собирает с нуля.

За что платит Vite

Главная неочевидная цена Vite — разные движки в dev и prod. В разработке ваш код трансформирует esbuild и раздаёт нативный ESM, а прод собирает Rollup. Это два разных пайплайна, и иногда код, который работал в dev, ведёт себя иначе в prod-сборке: другой порядок инициализации модулей, иное поведение динамических импортов, различия в обработке CSS.

Практический вывод: не полагайтесь только на vite (dev). Перед деплоем гоняйте vite build и vite preview — так вы увидите прод-поведение до продакшена.

Минимальный конфиг под React выглядит так:

// vite.config.js — Vite 5.x
import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';

export default defineConfig({
  plugins: [react()],
  build: {
    // Vite сам поднимает браузерную поддержку через esbuild target;
    // для старых браузеров подключайте @vitejs/plugin-legacy отдельно
    target: 'es2020',
  },
});

За что платит esbuild напрямую

esbuild собирает бандл в разы быстрее двух других инструментов, потому что написан на Go и распараллеливает работу. Но взять его как единственный инструмент сборки приложения — значит остаться без развитого dev-сервера, без богатого сплиттинга и с узкой экосистемой плагинов. Его API плагинов проще и покрывает не все сценарии, которые есть у webpack.

Поэтому чаще esbuild используют не напрямую как "замену webpack", а как движок трансформации внутри Vite и других сборщиков, либо для сборки библиотек и утилит, где не нужен богатый dev-опыт. Простая сборка через API:

// build.mjs — esbuild 0.2x, запуск: node build.mjs
import { build } from 'esbuild';

await build({
  entryPoints: ['src/index.ts'],
  bundle: true,
  minify: true,
  outfile: 'dist/bundle.js',
  target: ['es2020'],
});

console.log('Сборка завершена');

Точные имена флагов и опций проверяйте в документации вашей версии esbuild — API до стабильного 1.0 меняется между минорными версиями.

Когда что выбирать

• Новое SPA или сайт, стандартный стек (React/Vue/Svelte) — Vite. Быстрый старт, разумные умолчания, минимум конфигурации.
• Большое legacy-приложение с кастомными loader'ами и сложным сплиттингом — webpack. Миграция дороже, чем выигрыш в скорости, если всё уже работает.
• Сборка библиотеки, CLI-утилиты или serverless-функции — esbuild напрямую. Не нужен dev-сервер, важна скорость и простой выход.
• Нужна поддержка старых браузеров с точным контролем полифилов — webpack + babel даёт больше контроля, чем target у esbuild.

Критерий простой: если дорог опыт разработки и стек стандартный — Vite. Если дорог контроль над бандлом и проект уже сложный — webpack. Если сборка не приложение, а артефакт для запуска — esbuild.

Что ломается на практике

• Vite: работало в dev, сломалось в prod. Причина — разные движки. Всегда проверяйте vite build + vite preview перед релизом.
• Vite: тяжёлые CommonJS-зависимости. Пакеты без ESM-сборки Vite прогоняет через предбандлинг; иногда приходится добавлять их в optimizeDeps.include, если импорты не находятся автоматически.
• webpack: CI пересобирает медленно. Persistent cache помогает, только если директория кеша сохраняется между запусками пайплайна — иначе каждый прогон холодный.
• esbuild: слабее tree-shaking на сложных случаях. Для библиотек, где размер бандла критичен, сравните вес выхода с Rollup, прежде чем закладывать esbuild в релизную сборку.

Что делать дальше

Померьте свою реальную боль, а не чужие бенчмарки. Замерьте холодный старт dev-сервера и время prod-сборки на вашем проекте и вашем железе — командой time перед сборкой или встроенными профилировщиками. Если старт dev-сервера — узкое место и стек стандартный, соберите прототип на Vite и сравните цифры. Если проект уже на webpack и собирается за приемлемое время, включите filesystem cache и не трогайте рабочее решение ради моды. Отдельная тема — миграция крупного webpack-проекта на Vite: она требует ревизии всех loader'ов и плагинов, здесь мы её не разворачиваем.