Dev-сервер vs Production-сборка: почему нельзя деплоить dev-версию
Dev-сервер Vite предназначен для локальной разработки: быстро обрабатывает модули и поддерживает Hot Module Replacement. Количество запросов зависит от приложения, кэша и оптимизации зависимостей; фиксированных «52 запросов» у Vite нет. Публичный production-сайт должен раздавать подготовленную сборку через подходящий сервер или платформу.
Для обычного клиентского React-приложения production-сборка создаёт оптимизированные статические файлы, обычно в dist. Их состав и число запросов определяет проект. Бандлинг и минификация могут уменьшить объём загрузки, но не гарантируют конкретные Core Web Vitals или четырёхкратное ускорение. При HTTP/2 и повторном использовании соединений каждый запрос не означает новое DNS/TCP-соединение.
Не используйте dev-сервер и vite preview как production-серверы. Сборка сама по себе не исправляет тяжёлые изображения, медленный API, ошибки кэширования или доступности. Измеряйте LCP и другие показатели на опубликованном сайте.
Создание production-сборки: команда npm run build и что внутри
Проверьте scripts в package.json: build должен запускать сборку, а preview — vite preview. В шаблонах React с TypeScript build также может включать проверку типов. Установите зависимости по lock-файлу через npm ci, выполните npm run build и проверьте dist либо настроенный build.outDir. Команды предполагают уже существующий Vite-проект с согласованным package-lock.json.
Инструменты зависят от версии Vite. В Vite 8 используются Rolldown и инструменты на базе Oxc вместо связки Rollup/esbuild предыдущих версий. Сборка анализирует импорты, формирует чанки и оптимизирует код в пределах настроек и возможностей анализа. Неиспользуемый код с побочными эффектами нельзя гарантированно удалить. При миграции проверяйте плагины и параметры по документации своей версии.
Хеши в именах файлов - критический механизм для кеширования. Файл main.a3f8b2c1.js содержит хеш, вычисленный из содержимого. При изменении кода хеш меняется, браузер загружает новую версию. Без хешей пользователи получали бы устаревший код из кеша. Папка dist содержит index.html и директорию assets с JS- и CSS-файлами. Эту структуру можно загружать на любой статический хостинг.
В vite.config.js можно задать build.outDir и base. Для Vite 8 настройка разбиения чанков описана в build.rolldownOptions.output.codeSplitting; старые примеры build.rollupOptions.output.manualChunks требуют проверки при миграции. Для размещения в подкаталоге задайте нужный base и отдельно согласуйте базовый путь клиентского роутера.
Бандлинг и минификация: что измерять в своём проекте
В dev-режиме браузер получает модули по мере необходимости; зависимости могут предварительно объединяться. В production чанки формируются сборщиком. Сравнивайте переданные байты, число запросов и критический путь загрузки при одинаковых условиях кэша, а не количество исходных файлов.
Отдельный vendor-чанк для всех node_modules не является обязательным результатом по умолчанию. Чанки зависят от импортов, динамической загрузки, общих зависимостей и конфигурации. Не вводите ручное разбиение только ради числа файлов: проверьте начальную загрузку, повторные переходы и кэш.
Минификация сокращает код, но не задаёт фиксированного процента уменьшения или времени загрузки. Сравните размеры ресурсов до и после HTTP-сжатия и проверьте результат на целевых устройствах.
Запустите dev-сервер и изучите Network в DevTools. Затем выполните npm run build и npm run preview, повторите проверку с теми же условиями. Зафиксируйте свои результаты: ни числа 52/13, ни постоянная пропорция между ними не гарантированы.
Готовый dist можно разместить на статической платформе или самостоятельно обслуживаемом веб-сервере. Если нужен собственный сервер и контроль настроек, при выборе инфраструктуры можно сравнить Timeweb Cloud с другими провайдерами. Это партнёрская ссылка. Сопоставьте стоимость, HTTPS, SPA-маршрутизацию, резервные копии и сопровождение; минимальный тариф не гарантирует нужную производительность. Для чисто статического сайта отдельный VPS не обязателен, а пример CI ниже остаётся для Netlify.
Локальное тестирование production-сборки: npm run preview
При соответствующем script команда npm run preview локально показывает собранные файлы из dist. Это удобная предварительная проверка, но не точная копия DNS, HTTPS, заголовков, CDN, API и маршрутизации реального хостинга. Vite прямо не рекомендует preview для production.
Перед деплоем проверьте пути ассетов, прямой переход и обновление вложенного SPA-маршрута, загрузку lazy-компонентов и адрес API. При BrowserRouter только маршруты приложения должны получать index.html; API и отсутствующие статические файлы не должны маскироваться HTML-ответом. Значения VITE_* встраиваются при сборке и доступны пользователю браузера. В них допустимы публичные параметры вроде URL API, но не пароли, приватные ключи или токены сервисов.
После preview выполните smoke-тест на целевом хостинге: HTTPS, заголовки, API/CORS, клиентские маршруты и корректность кэша. Успех локального preview не доказывает успешность деплоя. Source maps и доступ к ним определяются конфигурацией; проверьте, не раскрывают ли опубликованные артефакты лишние данные.
Роль Claude Desktop в процессе сборки: автоматизация и помощь
Claude Desktop - AI-инструмент, который ускоряет рутинные операции при подготовке к деплою. Он анализирует конфигурацию Vite, находит узкие места и предлагает конкретные улучшения. Запрос «проанализируй мой vite.config.js и предложи оптимизации для production-сборки» возвращает список проблем: отсутствие ручного code splitting для тяжёлых библиотек, неоптимальные настройки chunkSizeWarningLimit, пропущенные переменные окружения.
Практический сценарий: вы собрали бандл и видите в логах предупреждение о большом размере чанка. Копируете лог в Claude Desktop, описываете структуру проекта. Инструмент предлагает разбить чанк через dynamic import или подобрать настройки разбиения чанков для установленной версии Vite. Генерирует готовый фрагмент конфига с пояснениями.
Claude Desktop помогает генерировать скрипты для CI/CD. Запрос «напиши GitHub Actions workflow для сборки React-приложения на Vite и деплоя на Netlify» выдаёт готовый YAML с шагами checkout, setup-node, npm ci, npm run build и деплоем. Разработчик проверяет и адаптирует под свой проект - время зависит от проекта и объёма проверки. Инструмент не заменяет инженера, но снимает с него типовые задачи. Подобный подход к автоматизации через AI-агентов детально разобран в статье про Pre2Prod - превращение вайбкод-прототипа в production-ready MVP, где AI-агенты выполняют 41 специализированное ревью за 9 стадий.
Типичные ошибки при подготовке к деплою и как их избежать
Неправильный base path. Симптом: после деплоя в поддиректорию /app/ все ассеты загружаются с корня, получаете 404. Решение: установите base: '/app/' в vite.config.js. Vite подставит этот префикс ко всем путям в index.html и сгенерированных ссылках.
Переменные окружения и секреты. Для публичного адреса API можно задать VITE_API_URL в .env.production или окружении build. Vite build по умолчанию использует production mode, но --mode может его изменить. Переменные окружения процесса имеют приоритет над env-файлами. Не добавляйте VITE_ ко всем переменным: секреты должны оставаться на backend. GitHub Secrets не делает VITE_* секретным после сборки. Если ключ уже попал в клиентский bundle, удалите его из frontend, отзовите/замените и пересоберите приложение.
CORS и API. Ошибка возникает при ограничениях межсайтового доступа, а не просто из-за абсолютного URL. Либо backend должен разрешать нужный origin и необходимые credentials, либо запросы проходят через настроенный same-origin proxy. Относительный /api без серверного маршрута API ничего не исправляет. Dev proxy Vite не встраивается в dist.
Клиентский роутинг. Для SPA настройте fallback только для известных маршрутов приложения и проверьте прямой переход по /about. Например, если приложение действительно имеет маршрут /about и раздел /dashboard, в public/_redirects для Netlify можно записать отдельными строками /about /index.html 200 и /dashboard/* /index.html 200; Vite скопирует файл в dist. Подставьте реальные маршруты своего приложения, а не копируйте эти пути вслепую. Не добавляйте общий catch-all /* /index.html 200: он может вернуть HTML вместо отсутствующего JS/CSS. Оставьте /assets/* и /api/* вне SPA rewrite, а необходимые правила API разместите раньше. Проверьте, что отсутствующий /assets/missing.js возвращает 404, а не index.html. Для Nginx аналогично разделите обработку маршрутов приложения, API и статических ассетов; конкретные location, root и try_files зависят от схемы URL.
Большие чанки. Симптом: один JS-файл весит больше 500 КБ, пользователи на мобильных сетях ждут загрузки. Решение: используйте динамические импорты. Замените статический импорт тяжёлого компонента на const HeavyComponent = lazy(() => import('./HeavyComponent')). Vite автоматически выделит его в отдельный чанк, который загрузится только при необходимости.
Интеграция сборки в CI/CD: автоматический деплой
Сборку удобно выполнять в CI из проверенного commit и lock-файла. Зафиксируйте совместимые версии Node.js, пакетного менеджера и зависимостей; npm ci проверяет согласованность lock-файла и устанавливает зависимости заново. CI повышает воспроизводимость, но внешние загрузки, переменные и изменяемые теги actions тоже могут менять результат.
Пример ниже сохраняет деплой на Netlify. Нужны существующий сайт, доступные только доверенному workflow Netlify credentials и проверенные scripts проекта. Перед production защитите main и настройте GitHub Environment production с требуемыми проверками/подтверждениями. Само имя environment не включает защиту автоматически. Actions в примере указаны тегами для читаемости; для production закрепите проверенные commit SHA.
name: Deploy to Production
on:
push:
branches: [main]
permissions:
contents: read
concurrency:
group: production
cancel-in-progress: false
jobs:
build-and-deploy:
runs-on: ubuntu-latest
environment: production
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: '24'
cache: 'npm'
- run: npm ci
- run: npm run build
env:
VITE_API_URL: ${{ vars.VITE_API_URL }}
- name: Deploy to Netlify
uses: nwtgck/actions-netlify@v3
with:
publish-dir: './dist'
production-branch: main
enable-pull-request-comment: false
enable-commit-comment: false
enable-commit-status: false
enable-github-deployment: false
fails-without-credentials: true
env:
NETLIFY_AUTH_TOKEN: ${{ secrets.NETLIFY_AUTH_TOKEN }}
NETLIFY_SITE_ID: ${{ secrets.NETLIFY_SITE_ID }}
Параметр cache в setup-node кэширует данные пакетного менеджера, не node_modules; npm ci остаётся необходимым. Задайте публичную GitHub Variable VITE_API_URL для build, если приложение её использует. Токен Netlify передаётся только шагу деплоя через GitHub Secrets; он не должен попадать в VITE_* или dist. Для команд, которые хотят глубже автоматизировать процесс, статья про DevSecOps с семью сканерами в едином пайплайне рассматривает проверки безопасности.
Этот workflow запускается при push в main; доступность деплоя также зависит от credentials и правил environment. После публикации проверьте сайт и API. Revert может восстановить код, но не откатывает автоматически внешние данные и настройки. Для предсказуемого отката храните артефакты релизов и проверяйте механизм восстановления платформы.
Перед релизом соберите приложение, проверьте dist локально и на целевом хостинге, убедитесь в отсутствии секретов в клиентском коде и протестируйте маршруты/API. AI может помочь подготовить конфигурацию и CI, но результат нужно сверять с версией инструментов и реальными условиями размещения.