عملکرد

در حالی که Vite به‌صورت پیش‌فرض سریع است، با گسترش نیازهای پروژه، مشکلات عملکردی (Performance) ممکن است به وجود بیایند. این راهنما به شما کمک می‌کند تا مشکلات رایج عملکردی (Performance) را شناسایی و برطرف کنید، از جمله:

• شروع کند سرور
• بارگذاری کند صفحات
• بیلدهای کند (Slow builds)

تنظیمات مرورگر خود را بررسی کنید

برخی از اکستنشن‌های مرورگر ممکن است با درخواست‌ها تداخل داشته باشند و زمان شروع و بارگذاری مجدد برنامه‌های بزرگ را کند کنند، به‌ویژه زمانی که از ابزارهای توسعه‌دهنده مرورگر استفاده می‌کنید. پیشنهاد می‌کنیم در این موارد، یک پروفایل مخصوص توسعه (dev-only) بدون اکستنشن‌ها ایجاد کنید یا به حالت ناشناس (Incognito mode) بروید، در حالی که از سرور توسعه Vite استفاده می‌کنید. حالت ناشناس (Incognito mode) همچنین باید سریع‌تر از پروفایل معمولی بدون اکستنشن‌ها باشد.

سرور توسعه‌ی Vite از کش سخت‌افزاری (hard caching) برای وابستگی‌های از پیش بسته‌بندی‌شده (pre-bundled) استفاده می‌کند و پاسخ‌های سریع 304 برای کد سورس پیاده‌سازی می‌کند. غیرفعال‌کردن کش در حالی که ابزارهای توسعه‌ی مرورگر (Dev Tools) باز هستند، می‌تواند تأثیر زیادی روی زمان راه‌اندازی و بارگذاری مجدد کامل صفحه داشته باشد. لطفاً بررسی کنید که گزینه‌ی "غیرفعال‌کردن کش" (Disable Cache) در هنگام کار با سرور Vite فعال نباشد.

بررسی پلاگین‌های تنظیم‌شده‌ی Vite

پلاگین‌های داخلی و رسمی Vite به‌گونه‌ای بهینه‌سازی شده‌اند که کمترین میزان کار ممکن را انجام دهند و در عین حال سازگاری با اکوسیستم گسترده‌تر را فراهم کنند. به عنوان مثال، تبدیل‌های کد (code transformations) در محیط توسعه (dev) از regex استفاده می‌کنند، اما در مرحله‌ی ساخت (build)، یک تجزیه‌ی کامل (complete parse) انجام می‌شود تا صحت کد تضمین شود.

با این حال، عملکرد پلاگین‌های جامعه (community plugins) خارج از کنترل Vite است و این ممکن است بر تجربه‌ی توسعه‌دهنده تأثیر بگذارد. در اینجا چند نکته وجود دارد که می‌توانید هنگام استفاده از پلاگین‌های اضافی Vite به آن‌ها توجه کنید:

1. وابستگی‌های بزرگ که فقط در موارد خاص استفاده می‌شوند، باید به صورتdynamic ایمپورت شوند تا زمان راه‌اندازی Node.js کاهش یابد. مثال‌هایی از بازنویسی کد (refactors): vite-plugin-react#212 و vite-plugin-pwa#224.

2. هوک‌های buildStart، config و configResolved نباید عملیات‌های طولانی و گسترده اجرا کنند. این هوک‌ها در زمان راه‌اندازی dev server منتظر می‌مانند، که این موضوع دسترسی به سایت در مرورگر را به تأخیر می‌اندازد.

3. هوک‌های resolveId، load و transform ممکن است باعث شوند برخی فایل‌ها کندتر از بقیه بارگذاری شوند. اگرچه گاهی اوقات این موضوع اجتناب‌ناپذیر است، اما همچنان ارزش دارد که بخش‌های ممکن برای بهینه‌سازی بررسی شوند. به عنوان مثال، بررسی اینکه آیا code شامل یک کلمه‌کلیدی خاص است یا id با یک پسوند خاص مطابقت دارد، قبل از انجام تبدیل کامل (full transformation).

   هرچه تبدیل یک فایل (transform) زمان بیشتری طول بکشد، آبشاری از درخواست‌ها (request waterfall) هنگام بارگذاری سایت در مرورگر قابل‌توجه‌تر خواهد بود.

   شما می‌توانید مدت زمان تبدیل یک فایل (transform) را با استفاده از دستور vite --debug plugin-transform یا vite-plugin-inspect بررسی کنید. توجه داشته باشید که از آنجایی که عملیات ناهمزمان (asynchronous operations) تمایل به ارائه زمان‌بندی‌های نادرست دارند، باید اعداد را به عنوان یک تخمین تقریبی در نظر بگیرید، اما همچنان عملیات‌های پرهزینه‌تر را نشان می‌دهد.

Profiling

شما می‌توانید دستور vite --profile را اجرا کنید، از سایت بازدید کنید و در ترمینال خود p + enter را فشار دهید تا یک فایل ‎.cpuprofile ثبت شود. سپس می‌توانید از ابزاری مانند speedscope برای بررسی پروفایل و شناسایی bottlenecks استفاده کنید. همچنین می‌توانید پروفایل ها را به اشتراک بگذارید و به تیم Vite کمک کنید تا مسائل مربوط به عملکرد (performance issues) را شناسایی کنند.

کاهش عملیات حل و فصل (resolve)

حل و فصل مسیرهای ایمپورت می‌تواند یک عملیات پرهزینه باشد، به‌ویژه زمانی که اغلب به بدترین حالت خود برخورد می‌کند. به عنوان مثال، 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 وجود دارد؟ بله!

همان‌طور که مشاهده می‌شود، برای حل و فصل یک مسیر ایمپورت، در مجموع ۶ بررسی فایل سیستم لازم است. هرچه تعداد ایمپورت‌های ضمنی (implicit imports) بیشتر باشد، زمان بیشتری برای حل و فصل مسیرها صرف خواهد شد.

بنابراین، معمولاً بهتر است که مسیرهای ایمپورت را به‌صورت صریح مشخص کنید، مانند عبارت import './Component.jsx'. همچنین می‌توانید لیست resolve.extensions را محدود کنید تا تعداد بررسی‌های فایل سیستم کاهش یابد، اما باید مطمئن شوید که این تغییر برای فایل‌های موجود در node_modules نیز به درستی کار می‌کند.

اگر یک نویسنده‌ی پلاگین هستید، اطمینان حاصل کنید که فقط در مواقع ضروری this.resolve را فراخوانی کنید تا تعداد بررسی‌های ذکرشده در بالا کاهش یابد.

TypeScript

اگر از TypeScript استفاده می‌کنید، مقدار "moduleResolution": "bundler" و ‎"allowImportingTsExtensions": true را در بخش compilerOptions فایل tsconfig.json فعال کنید تا بتوانید مستقیماً از پسوندهای ‎.ts و ‎.tsx در کد خود استفاده کنید.

از استفاده از فایل‌های Barrel خودداری کنید

فایل‌های Barrel فایل‌هایی هستند که APIهای سایر فایل‌های موجود در همان دایرکتوری را re-export می‌کنند. به عنوان مثال:

src/utils/index.js

export * from './color.js'
export * from './dom.js'
export * from './slash.js'

وقتی که تنها یک API خاص را ایمپورت می‌کنید، مانند import { slash } from './utils'، تمامی فایل‌های موجود در آن فایل Barrel باید واکشی (fetched) و تبدیل (transformed) شوند، زیرا ممکن است API slash را در خود داشته باشند و همچنین ممکن است دارای side-effects باشند که در زمان بارگذاری اولیه اجرا می‌شوند. این بدین معناست که فایل‌های بیشتری نسبت به آنچه که نیاز است، در هنگام بارگذاری صفحه‌ی اولیه بارگذاری می‌شوند و این باعث کندتر شدن زمان بارگذاری صفحه می‌شود.

در صورت امکان باید از فایل‌های Barrel خودداری کرده و APIهای فردی را به‌طور مستقیم ایمپورت کنید، مانند import { slash } from './utils/slash.js'‎. برای اطلاعات بیشتر، می‌توانید issue #8237 را مطالعه کنید.

فایل‌های پر استفاده را پیش‌بارگذاری کنید

سرور توسعه‌ی Vite فقط فایل‌هایی را تبدیل (transform) می‌کند که توسط مرورگر درخواست شده‌اند. این امکان باعث می‌شود تا سرور به سرعت راه‌اندازی شود و تنها تبدیل (transform)ها را روی فایل‌های استفاده‌شده اعمال کند. همچنین می‌تواند فایل‌هایی را پیش‌تبدیل (pre-transform) کند اگر پیش‌بینی کند که برخی فایل‌ها به زودی درخواست خواهند شد. با این حال، آبشاری از درخواست‌ها (request waterfalls) ممکن است اتفاق بیفتد اگر برخی فایل‌ها زمان بیشتری برای تبدیل (transform) نسبت به بقیه نیاز داشته باشند.

با توجه به یک گراف ایمپورت که در فایل سمت چپ، فایل سمت راست را ایمپورت می‌کند:

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

رابطه‌ی ایمپورت (import relationship) فقط پس از تبدیل فایل قابل تشخیص است. اگر BigComponent.vue زمان‌بر باشد، big-utils.js باید منتظر نوبت خود بماند و به همین ترتیب ادامه می‌یابد. این موضوع حتی با وجود قابلیت پیش‌تبدیل (pre-transformation) داخلی، باعث ایجاد یک آبشار درونی (internal waterfall) می‌شود.

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

vite.config.js

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

توجه داشته باشید که فقط باید فایل‌هایی را از قبل بارگذاری کنید که به طور مکرر استفاده می‌شوند تا سرور توسعه Vite در هنگام راه‌اندازی بیش‌ازحد بارگیری نشود. برای اطلاعات بیشتر، گزینه server.warmup را بررسی کنید.

استفاده از ‎--open یا server.open نیز باعث بهبود عملکرد می‌شود، زیرا Vite به‌طور خودکار entry point برنامه شما یا URL ارائه‌شده برای باز کردن را از قبل بارگذاری می‌کند.

از ابزارهای ساده‌تر یا بومی استفاده کنید.

برای حفظ سرعت Vite در یک پایگاه کد در حال رشد، باید حجم کاری فایل‌های منبع (مانند JS/TS/CSS) را کاهش دهید.

نمونه‌هایی از کاهش کارها:

• در صورت امکان از CSS به جای Sass/Less/Stylus استفاده کنید (قابلیت‌هایی مانند تودرتو بودن (nesting) می‌تواند توسط PostCSS مدیریت شود).
• SVGها را به کامپوننت‌های فریمورک‌های UI (مثل React، Vue و غیره) transform نکنید. در عوض، آن‌ها را به‌صورت رشته یا URL ایمپورت کنید.
• هنگام استفاده از ‎@vitejs/plugin-react، از پیکربندی گزینه‌های Babel خودداری کنید تا در طول build از transform شدن صرف‌نظر شود (تنها esbuild استفاده خواهد شد).

نمونه‌هایی از استفاده از ابزارهای بومی:

استفاده از ابزارهای بومی اغلب باعث افزایش حجم نصب می‌شود و به همین دلیل به‌طور پیش‌فرض هنگام شروع یک پروژه جدید با Vite فعال نیست. اما ممکن است برای برنامه‌های بزرگتر، این هزینه ارزش داشته باشد.

• از Rolldown به‌جای Rollup و esbuild استفاده کنید تا بیلد سریع‌تر باشد و بین توسعه و بیلد تجربه‌ای هماهنگ‌تر داشته باشید.
• پشتیبانی آزمایشی از LightningCSS را امتحان کنید.
• به‌جای ‎@vitejs/plugin-react از ‎@vitejs/plugin-react-swc استفاده کنید.