Webpack против Vite в крупном проекте от скорости холодного старта и HMR до стабильности продакшн-сборки

Инструмент сборки выбирают один раз, а расхлёбывают годами. Сменить фреймворк на практике проще, чем переписать пайплайн, вокруг которого выстроены тесты, деплой и привычки двадцати человек. Оттого спор Webpack против Vite звучит не как спор об утилитах, а как спор о мировоззрении, хотя технически это всего лишь два разных ответа на один вопрос: когда собирать код. Webpack собирает всё заранее, Vite отдаёт браузеру модули на лету. Ниже разбор того, чем оборачивается эта разница для крупного проекта: в скорости холодного старта, в горячей перезагрузке и в предсказуемости продакшн-сборки.

Два разных ответа на вопрос когда собирать код

Webpack появился в 2012 году и за десятилетие стал стандартом де-факто: лоадеры, плагины, code splitting, бесконечная настройка. Пятая мажорная версия, вышедшая в октябре 2020 года, принесла персистентный кэш на файловую систему, улучшенное встряхивание дерева и Module Federation для микрофронтендов. Webpack работает как классический бандлер: перед показом хоть чего-нибудь он проходит весь граф модулей и собирает пакеты. Чем больше проект, тем дольше тишина перед первым экраном.

Vite, созданный Эваном Ю в 2020 году и закрепивший архитектуру во второй версии в феврале 2021-го, перевернул предпосылку. Браузеры к тому моменту научились нативно исполнять ES-модули, и появилась возможность отдавать исходники почти без сборки. Двухчастная схема Vite известна по его же документации: зависимости, которые меняются редко, предсобираются один раз быстрым нативным инструментом, а исходный код отдаётся по запросу, файл за файлом, в момент обращения браузера. Пока Webpack молотит весь проект до первого рендера, Vite уже отдал страницу и компилирует по пути.

Идея небандл-разработки появилась раньше Vite, у Snowpack, который и вдохновил предсборку зависимостей, но масштабную поддержку получила именно у Vite. Каденция релизов у проекта плотная: пятая версия вышла в конце 2023 года, шестая с Environment API в конце 2024-го, седьмая летом 2025-го подняла минимальную планку Node до 20.19, а сегодня живёт ветка 8.x.

Холодный старт сервера разработки и цена первой минуты

Разница между инструментами видна на первой же команде. Сервер разработки Webpack обязан собрать всё приложение до состояния "готов", и на крупном монорепозитории это минуты. Vite отвечает готовностью почти мгновенно: стартует сервер, а компиляция происходит по мере запросов браузера. Разработчик открывает страницу, Vite отдаёт модули точечно, и первая отрисовка не ждёт последнего виджета в дальнем углу приложения. Цикл старта нового проекта укладывается в четыре строчки терминала:

npm create vite@latest my-app
cd my-app
npm install
npm run dev

Эквивалентный старт на Webpack с выбором пресетов, подключением лоадеров и первыми правками конфигурации занимает заметно больше шагов, и в онбординге новичков разница ощущается в первый же час.

Второй слой скорости, предсборка зависимостей. Vite прогоняет установленные пакеты через esbuild, инструмент на Go, который в собственных бенчмарках показывает ускорение на порядок против классических транспиляторов на JavaScript. Большая библиотека компонентов предсобирается один раз и попадает в кэш внутри node_modules, повторные старты этот шаг пропускают. Если после обновления пакета что-то пошло мимо глаз, кэш сбрасывается принудительно флагом --force, и мелочь эта экономит час недоумения.

У Webpack есть контраргумент, и посильнее маркетинга. Персистентный кэш пятой версии после первого цикла сокращает холодный старт радикально, warmed-up сервер крупного проекта стартует за десятки секунд:

module.exports = {
  cache: { type: 'filesystem' },
  module: {
    rules: [
      { test: /\.tsx?$/, use: 'esbuild-loader' }
    ]
  }
};

Комбинация файлового кэша и esbuild-loader вместо ts-loader ставит ветеранский бандлер на ноги. Проблема в другом: первый запуск на чистой машине новичка и главный стенд непрерывной интеграции кэша не имеют, и именно там минуты ожидания возвращаются.

Горячая перезагрузка и её поведение при росте проекта

С горячей перезагрузкой расклад похожий. Vite обновляет отредактированный модуль по нативному протоколу ESM без пересборки, и время обновления почти не зависит от размера приложения: отредактировал кнопку в проекте на пять тысяч файлов, изменения видны через мгновение. Внутри React-приложений горячую замену в обоих лагерях обеспечивает Fast Refresh, у Vite через официальный плагин, у Webpack через react-refresh, оба сохраняют состояние компонентов при правке. Разница не в механике, а в цене: Vite отвечает на правку без пересборки, Webpack пересобирает затронутые чанки, и на большом графе задержка растёт вместе с проектом.

Правда у медали есть обратная сторона, и документация Vite признаёт её честно. Небандл-подход порождает в разработке сотни сетевых запросов: на графике вкладки Network дев-режим выглядит водопадом мелких строк, и это не поломка, а сама архитектура. На исключительно больших кодовых базах отрисовка страницы в дев-режиме замедляется именно из-за этого водопада. Ответом стала линия на полную сборку в разработке поверх Rolldown, единого бандлера на Rust, которая снимает компромисс, сохраняя скорость.

Отдельная мелочь портит нервы новичкам: обнаружив новую зависимость в коде по ходу работы, Vite обязан пересобрать предсборку, и страница сама перезагружается. Команда жмёт сохранить, страница внезапно вся обновляется, состояние формы теряется. Плата за автоматизм, о которой узнают в первый же день.

Продакшн-сборка расхождения двух конвейеров и Rolldown

Ключевой аргумент сторожей Webpack лежит не в разработке, а в релизе. Исторически Vite работал на двух разных конвейерах: esbuild в разработке и Rollup в продакшн-сборке. Две архитектуры означали два набора поведений, два набора плагинов и зазор между тем, что видит разработчик, и тем, что уезжает в прод.

Глюки из этого зазора известны: сборка падает на регулярном выражении, которое дев-сервер переваривал молча, плагин требует условия, которые на деве не воспроизводятся, минификация esbuild встречает код, который Rollup валидировал. На крупном проекте каждый такой случай это день расследования и минус к доверию к инструменту.

Практика страховки проста и независима от выбора: продакшн-сборка запускается на каждом пул-реквесте, а не вечером перед релизом. Правило "сборка упала, значит в релиз не идёт" ловит расхождения конвейеров на подступах, пока они стоят недорого.

Восьмая ветка Vite переваривает ситуацию через Rolldown, бандлер на Rust с парсером и минификатором Oxc, который унифицирует конвейеры: одна трансформация, одна система плагинов, одна семантика от запуска до релиза. Документация описывает переход осторожно, через техническое превью и слой совместимости, и это правильная осторожность, ведь Vite несёт на себе целые фреймворки, Nuxt, SvelteKit, Astro, и экосистемные инструменты вроде Vitest и Storybook.

Webpack в этом споре держит позицию зрелостью. Проект живёт и развивается, текущие релизы перевалили за 5.112, конвейер предсказуем до занудства, а редкие странности описаны в двадцатилетнем баг-трекере.

Экосистема плагинов и переносимость конфигурации между проектами

Вес категории измеряется не числом пакетов, а числом вопросов, на которые есть готовые ответы. У Webpack за плечами индустриальный массив: лоадеры под любой формат, тонкая настройка разделения чанков, и главное, Module Federation, штатный механизм микрофронтендов, которого у Vite долго не было вовсе:

new ModuleFederationPlugin({
  name: 'shop',
  remotes: { cart: 'cart@https://cdn.example.com/remoteEntry.js' }
});

У Vite экосистема моложе, но догоняет на глазах, а часть пути прошла чужими руками: интерфейс плагинов построен на соглашениях Rollup, поэтому большую часть rollup-плагинов Vite понимает напрямую. Боль миграций обычно не в сборке как таковой, а в длинном хвосте экзотики: сотни тонких специализированных лоадеров Webpack не имеют прямых аналогов, и каждая замена требует отдельного решения на ревью. Фреймворки выбирают Vite как фундамент, Laravel и Ruby on Rails встроили его в свои конвейеры ассетов, и выбор крупного проекта всё чаще предопределён выбором фреймворка.

Серверный рендер добавляет обоим сложностей по-своему. У Webpack браузерная и серверная сборки конфигурируются рядом, в одном файле. У Vite для SSR исторически существовали отдельные входы и свои правила, пока Environment API из шестой версии не превратил окружения клиента и сервера в штатную, управляемую часть конфигурации.

Конфигурация выглядит показательным контрастом. Типичный vite.config.js умещается в несколько строк:

import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';

export default defineConfig({
  plugins: [react()],
});

Эквивалентный webpack.config.js с пресетами, лоадерами и правилами разделения в реальных проектах разрастается в сотни строк и выделяется в отдельный внутренний пакет. Оба факта не приговор, но за лаконичность Vite платят вёрсткой поведения, когда проект выходит за пределы типовых сценариев.

Критерии выбора инструмента для крупного долгоживущего проекта

Сведение к одному победителю обманывает, честнее перечислить условия, при которых побеждает каждая сторона:

1. новый проект любого размера стартует на Vite быстрее и дешевле, особенно если фреймворк уже стоит на нём;
2. действующий крупный проект на Webpack 5 с настроенным кэшем не получает от переезда драматической выгоды и платит миграцией всех кастомных лоадеров;
3. микрофронтенды на Module Federation остаются территорией Webpack, хотя экосистема Vite закрывает разрыв сторонними пакетами;
4. проекты с жёсткими требованиями к продакшн-сборке ценят предсказуемость ветерана и десятилетия накопленных обходных решений;
5. команды с частыми сборками на чистых машинах интеграции теряют на холодных стартах Webpack больше, чем на чём-либо ещё;
6. монорепозитории с тысячами модулей проверяют оба инструмента на прочность, и выбор стоит делать по нагрузочному тесту, а не по демо;
7. гибридный путь легален: новые приложения на Vite соседствуют со старым ядром на Webpack за общим шлюзом.

Что опыт команд говорит о реальном раскладе между двумя инструментами

Миграция крупного проекта между бандлерами ход известный и занимает недели, а не дни: инвентаризация лоадеров и плагинов, подбор аналогов, параллельный запуск обеих сборок на стенде интеграции, переключение маршрутов по одному и только потом демонтаж старого конвейера. Команда, которая пропустила шаг инвентаризации, обнаруживает потерянные возможности уже после переезда.

Опыт больших команд за последние годы сложился в прозаическую картину. Скорость разработки решает больше, чем редкая странность продакшн-сборки, потому что разработчики платят своим временем каждый день, а сборка падает раз в квартал. Оттого новые проекты массово идут на Vite, и феномен объясняется не модой, а арифметикой: сэкономленные минуты на каждом запуске умножаются на десятки человек и сотни запусков.

Прозрения в обратную сторону тоже случаются. Проект, который переезжал на Vite ради скорости и получил на релизном стенде сюрпризы конвейеров, вспоминает Webpack добрым словом. Проект, который остался на Webpack и вложился в кэш и esbuild-loader, получает девяносто процентов той же скорости без единого риска миграции. Оба рассказа правдивы, потому что правдивы их исходные условия.

Ставка Webpack на будущее называется Turbopack, инструмент на Rust от создателя классического бандлера, и его судьба сейчас связана с Next.js. Пока Turbopack зреет, Rolldown уже унифицировал конвейеры Vite, и гонка продолжается на новом круге.

Выбор между Webpack и Vite для крупного проекта это выбор не инструмента, а меры дискомфорта, которую команда готова принять: минуты холодного старта сегодня против миграционных работ в течение месяца. Оба числа считаются на конкретном репозитории, и лучший ответ на вопрос из заголовка звучит не "Webpack" и не "Vite", а "замерьте и решите".