Производительность

Хотя Vite по умолчанию быстрый, проблемы с производительностью могут возникнуть по мере роста требований проекта. Это руководство направлено на то, чтобы помочь вам выявить и исправить распространённые проблемы с производительностью, такие как:

• Медленный старт сервера
• Медленная загрузка страниц
• Медленные сборки

Проверьте настройки браузера

Некоторые расширения браузера могут мешать запросам и замедлять время запуска и перезагрузки для крупных приложений, особенно при использовании инструментов разработчика браузера. В подобных случаях мы рекомендуем создать профиль только для разработки без расширений или переключиться в режим инкогнито, используя dev-сервер Vite. Режим инкогнито также должен быть быстрее, чем обычный профиль без расширений.

Сервер разработки Vite выполняет жёсткое кэширование предварительно собранных зависимостей и реализует быстрые ответы 304 для исходного кода. Отключение кэша, пока открыты инструменты разработчика браузера, может значительно повлиять на время запуска и полных перезагрузок страниц. Пожалуйста, убедитесь, что опция «Отключить кэш» в инструментах разработчика не включена, пока вы работаете с сервером Vite.

Аудит настроенных плагинов Vite

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

Однако производительность плагинов сообщества находится вне контроля Vite, что может повлиять на опыт разработчика. Вот несколько моментов, на которые стоит обратить внимание при использовании дополнительных плагинов Vite:

1. Большие зависимости, которые используются только в определённых случаях, следует динамически импортировать, чтобы сократить время запуска Node.js. Примеры рефакторинга: vite-plugin-react#212 и vite-plugin-pwa#224.

2. Хуки buildStart, config и configResolved не должны выполнять длительные и обширные операции. Эти хуки ожидаются во время запуска dev-сервера, что задерживает доступ к сайту в браузере.

3. Хуки resolveId, load и transform могут вызывать более медленную загрузку некоторых файлов по сравнению с другими. Хотя иногда это неизбежно, всё же стоит проверить возможные области для оптимизации. Например, проверьте, содержит ли code определённое ключевое слово или соответствует ли id определённому расширению, прежде чем выполнять полное преобразование.

   Чем больше времени требуется для преобразования файла, тем значительнее будет водопад запросов при загрузке сайта в браузере.

   Вы можете проверить время, необходимое для преобразования файла, используя команду vite --debug plugin-transform или vite-plugin-inspect. Обратите внимание, что асинхронные операции, как правило, предоставляют неточные временные показатели, поэтому следует рассматривать эти цифры как приблизительные, но они всё же должны выявить более затратные операции.

Профилирование

Вы можете запустить vite --profile, посетить сайт и нажать p + enter в вашем терминале, чтобы записать файл .cpuprofile. Затем вы можете использовать инструмент, такой как speedscope, чтобы проанализировать профиль и выявить узкие места. Вы также можете поделиться профилями с командой Vite, чтобы помочь нам выявить проблемы с производительностью.

Сокращение операций разрешения

Разрешение путей импорта может быть дорогостоящей операцией, особенно в худших случаях. Например, Vite поддерживает «угадывание» путей импорта с помощью опции resolve.extensions, которая по умолчанию равна ['.mjs', '.js', '.mts', '.ts', '.jsx', '.tsx', '.json'].

Когда вы пытаетесь импортировать ./Component.jsx с помощью import './Component', Vite выполнит следующие шаги для его разрешения:

1. Проверит, существует ли ./Component
2. Проверит, существует ли ./Component.mjs
3. Проверит, существует ли ./Component.js
4. Проверит, существует ли ./Component.mts
5. Проверит, существует ли ./Component.ts
6. Проверит, существует ли ./Component.jsx

Как показано, для разрешения пути импорта требуется в общей сложности 6 проверок файловой системы. Чем больше неявных импортов у вас есть, тем больше времени требуется для разрешения путей.

Поэтому обычно лучше указывать имена файлов с расширениями, например, import './Component.jsx'. Вы также можете сузить список для resolve.extensions, чтобы уменьшить общее количество проверок файловой системы, но вам нужно убедиться, что это работает и для файлов в node_modules.

Если вы автор плагина, убедитесь, что вызываете this.resolve только при необходимости, чтобы сократить количество проверок выше.

TypeScript

Если вы используете TypeScript, включите "moduleResolution": "bundler" и "allowImportingTsExtensions": true в секции compilerOptions вашего tsconfig.json, чтобы использовать расширения .ts и .tsx напрямую в вашем коде.

Избегайте файлов-агрегаторов

Файлы-агрегаторы — это файлы, которые повторно экспортируют API других файлов в той же директории. Например:

// src/utils/index.js
export * from './color.js'
export * from './dom.js'
export * from './slash.js'

Когда вы импортируете только отдельный API, например, import { slash } from './utils', все файлы в этом файле-агрегаторе должны быть загружены и преобразованы, так как они могут содержать API slash и также могут содержать побочные эффекты, которые выполняются при инициализации. Это означает, что вы загружаете больше файлов, чем необходимо, при первоначальной загрузке страницы, что приводит к более медленной загрузке.

Если возможно, следует избегать подобных файлов и импортировать отдельные API напрямую, например, import { slash } from './utils/slash.js'. Вы можете прочитать issue #8237 для получения дополнительной информации.

Подготовка часто используемых файлов

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

Учитывая график импорта, где левый файл импортирует правый:

main.js -> BigComponent.vue -> big-utils.js -> large-data.json

Отношение импорта может быть известно только после преобразования файла. Если BigComponent.vue требует времени для преобразования, big-utils.js должен ждать своей очереди и так далее. Это вызывает внутренний водопад запросов, даже с учётом встроенного предварительного преобразования.

Vite позволяет вам подготавливать файлы, про которые вы знаете, что они часто используются, например, big-utils.js, с помощью опции server.warmup. Таким образом, big-utils.js будет готов и кэширован для немедленного обслуживания по запросу.

Вы можете найти файлы, которые часто используются, запустив vite --debug transform и проверив логи:

vite:transform 28.72ms /@vite/client +1ms
vite:transform 62.95ms /src/components/BigComponent.vue +1ms
vite:transform 102.54ms /src/utils/big-utils.js +1ms

export default defineConfig({
  server: {
    warmup: {
      clientFiles: [
        './src/components/BigComponent.vue',
        './src/utils/big-utils.js',
      ],
    },
  },
})

Обратите внимание, что вы должны подготавливать только те файлы, которые часто используются, чтобы не перегружать dev-сервер Vite при запуске. Ознакомьтесь с опцией server.warmup для получения дополнительной информации.

Использование --open или server.open также обеспечивает прирост производительности, так как Vite автоматически готовит точку входа вашего приложения или предоставленный URL для открытия.

Используйте менее сложные или встроенные инструменты

Сохранение скорости Vite с растущей кодовой базой связано с уменьшением объёма работы для исходных файлов (JS/TS/CSS).

Примеры уменьшения объема работы:

• Используйте CSS вместо Sass/Less/Stylus, когда это возможно (вложенность можно обрабатывать с помощью PostCSS).
• Не преобразовывайте SVG в компоненты UI-фреймворков (React, Vue и т. д.). Импортируйте их как строки или URL.
• При использовании @vitejs/plugin-react избегайте настройки параметров Babel, чтобы пропустить преобразование во время сборки (будет использоваться только esbuild).

Примеры использования встроенных инструментов:

Использование встроенных инструментов часто приводит к увеличению размера пакета и поэтому не является стандартным при создании нового проекта Vite. Но это может оправдать затраты для более крупных приложений.

• Попробуйте экспериментальную поддержку Lightning CSS.
• Используйте @vitejs/plugin-react-swc вместо @vitejs/plugin-react.