Leistung

Obwohl Vite standardmäßig ist, können Leistungsprobleme auftreten, wenn die Anforderungen des Projekts wachsen. Dieser Leitfaden soll Ihnen dabei helfen, gängige Leistungsprobleme zu identifizieren und zu beheben, wie beispielsweise:

Langsame Serverstarts
Langsame Seitenaufbauzeiten
Langsame Builds

Überprüfen Sie Ihre Browser-Einstellungen

Einige Browser-Erweiterungen können mit Anfragen interferieren und die Start- und Ladezeiten für große Anwendungen verlangsamen, insbesondere bei der Verwendung von Browser-Entwicklungstools. Wir empfehlen, ein reines Entwicklungsprofil ohne Erweiterungen zu erstellen oder in den Inkognito-Modus zu wechseln, während Sie den Entwicklungsserver von Vite in diesen Fällen nutzen. Der Inkognito-Modus sollte ebenfalls schneller sein als ein normales Profil ohne Erweiterungen.

Der Vite-Entwicklungsserver führt ein hartes Caching der vorgebündelten Abhängigkeiten durch und implementiert schnelle 304-Antworten für Quellcode. Das Deaktivieren des Caches bei geöffneten Browser-Entwicklungstools kann einen großen Einfluss auf die Start- und Ladezeiten von ganzen Seiten haben. Bitte stellen Sie sicher, dass „Cache deaktivieren“ nicht aktiviert ist, während Sie mit dem Vite-Server arbeiten.

Überprüfung konfigurierter Vite-Plugins

Die internen und offiziellen Plugins von Vite sind optimiert, um so wenig wie möglich zu arbeiten, während sie gleichzeitig die Kompatibilität mit dem breiteren Ökosystem sicherstellen. Zum Beispiel verwenden Code-Transformationen in der Entwicklung Regex, führen aber in der Build-Phase eine vollständige Analyse durch, um die Korrektheit sicherzustellen.

Die Leistung von Community-Plugins liegt jedoch außerhalb der Kontrolle von Vite und kann sich auf das Entwicklererlebnis auswirken. Hier sind einige Dinge, auf die Sie achten sollten, wenn Sie zusätzliche Vite-Plugins verwenden:

Große Abhängigkeiten, die nur in bestimmten Fällen verwendet werden, sollten dynamisch importiert werden, um die Startzeit von Node.js zu reduzieren. Beispiel-Refactors: vite-plugin-react#212 und vite-plugin-pwa#224.
Die buildStart, config, und configResolved Hooks sollten keine langen und umfangreichen Operationen ausführen. Diese Hooks werden während des Starts des Dev-Servers erwartet, was den Zugriff auf die Site im Browser verzögert.
Die resolveId-, load- und transform-Hooks können dazu führen, dass einige Dateien langsamer geladen werden als andere. Auch wenn dies manchmal unvermeidbar ist, lohnt es sich, nach möglichen Optimierungsbereichen zu suchen. Zum Beispiel kann man prüfen, ob der code ein bestimmtes Schlüsselwort enthält oder die id mit einer bestimmten Erweiterung übereinstimmt, bevor man die vollständige Transformation durchführt.
Je länger es dauert, eine Datei umzuwandeln, desto größer ist der Request Waterfall beim Laden der Website im Browser.
Sie können die Dauer, die für die Umwandlung einer Datei benötigt wird, mit vite --debug plugin-transform oder vite-plugin-inspect überprüfen. Da asynchrone Operationen dazu tendieren, ungenaue Zeitangaben zu liefern, sollten Sie die Zahlen eher als grobe Schätzung betrachten, aber sie sollten dennoch die teureren Operationen aufzeigen.

Profiling

Sie können vite --profile ausführen, die Website besuchen und in Ihrem Terminal p + Enter drücken, um ein .cpuprofile aufzuzeichnen. Ein Tool wie speedscope kann dann verwendet werden, um das Profil zu überprüfen und Engpässe zu identifizieren. Sie können die Profile auch mit dem Vite-Team teilen, um bei der Identifizierung von Leistungsproblemen zu helfen.

Reduzierung der Auflösungsoperationen

Das Auflösen von Importpfaden kann eine teure Operation sein, wenn sie häufig im schlimmsten Fall auftritt. Zum Beispiel unterstützt Vite das "Raten" von Importpfaden mit der Option resolve.extensions, die standardmäßig auf ['.mjs', '.js', '.mts', '.ts', '.jsx', '.tsx', '.json'] festgelegt ist.

Wenn Sie versuchen, ./Component.jsx mit import './Component' zu importieren, wird Vite die folgenden Schritte ausführen, um sie aufzulösen:

Überprüfen, ob ./Component existiert, nein.
Überprüfen, ob ./Component.mjs existiert, nein.
Überprüfen, ob ./Component.js existiert, nein.
Überprüfen, ob ./Component.mts existiert, nein.
Überprüfen, ob ./Component.ts existiert, nein.
Überprüfen, ob ./Component.jsx existiert, ja!

Wie gezeigt, sind insgesamt 6 Dateisystemüberprüfungen erforderlich, um einen Importpfad aufzulösen. Je mehr implizite Importe Sie haben, desto mehr Zeit wird für das Auflösen der Pfade benötigt.

Daher ist es in der Regel besser, bei Ihren Importpfaden explizit zu sein, z. B. import './Component.jsx'. Sie können auch die Liste für resolve.extensions einschränken, um die allgemeinen Dateisystemüberprüfungen zu reduzieren, müssen jedoch sicherstellen, dass es auch für Dateien in node_modules funktioniert.

Wenn Sie ein Plugin-Autor sind, stellen Sie sicher, dass Sie this.resolve nur aufrufen, wenn es notwendig ist, um die Anzahl der oben genannten Überprüfungen zu reduzieren.

TypeScript

Wenn Sie TypeScript verwenden, aktivieren Sie "moduleResolution": "bundler" und "allowImportingTsExtensions": true in den compilerOptions Ihrer tsconfig.json, um .ts und .tsx Erweiterungen direkt in Ihrem Code zu verwenden.

Vermeiden von Barrel-Dateien

Barrel-Dateien sind Dateien, die die APIs anderer Dateien im selben Verzeichnis erneut exportieren. Zum Beispiel:

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

Wenn Sie nur eine einzelne API importieren, z. B. import { slash } from './utils', müssen alle Dateien in dieser Barrel-Datei abgerufen und transformiert werden, da sie die slash-API enthalten können und auch Seiteneffekte enthalten können, die bei der Initialisierung ausgeführt werden. Dies bedeutet, dass beim ersten Laden der Seite mehr Dateien als erforderlich geladen werden, was zu einem langsameren Laden der Seite führt.

Wenn möglich, sollten Sie Barrel-Dateien vermeiden und die einzelnen APIs direkt importieren, z. B. import { slash } from './utils/slash.js'. Weitere Informationen finden Sie unter Issue #8237.

Häufig verwendete Dateien aufwärmen

Der Vite Entwicklungsserver transformiert Dateien nur, wenn sie vom Browser auch angefordert werden. Dadurch kann er schneller starten und wendet nur Transformationen für verwendete Dateien an. Er kann auch Dateien vorverwandeln, wenn er erwartet, dass bestimmte Dateien in Kürze angefordert werden. Dennoch kann es zu einem "Request Wassfall" kommen, wenn die Umwandlung einiger Dateien länger dauert als die von anderen. Ein Beispiel:

Bei einem Importgraphen, bei dem die linke Datei die rechte Datei importiert:

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

Die Importbeziehung kann erst nach der Transformation der Datei bekannt sein. Wenn BigComponent.vue einige Zeit für die Transformation benötigt, muss big-utils.js auf seine Ausführung warten, und so weiter. Dies führt zu einem internen Wasserfall, auch wenn eine Vor-Transformation eingebaut ist.

Vite ermöglicht es Ihnen, Dateien vorzuwärmen, von denen Sie wissen, dass sie häufig verwendet werden, z.B. big-utils.js, mithilfe der Option server.warmup. Auf diese Weise wird big-utils.js bereit und zwischengespeichert, um sofort bei Bedarf bereitgestellt zu werden.

Sie können häufig verwendete Dateien finden, indem Sie vite --debug transform ausführen und die Protokolle untersuchen:

bash

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',
      ],
    },
  },
})

Beachten Sie, dass Sie nur Dateien vorwärmen sollten, die häufig verwendet werden, um den Vite-Entwicklungsserver beim Start nicht zu überlasten. Überprüfen Sie die Option server.warmup für weitere Informationen.

Die Verwendung von --open oder server.open bietet ebenfalls eine Leistungssteigerung, da Vite automatisch den Einstiegspunkt Ihrer App oder die bereitgestellte URL vorab erwärmt.

Weniger oder natives Werkzeug verwenden

Um die Geschwindigkeit von Vite mit einer wachsenden Codebasis beizubehalten, muss man den Arbeitsaufwand für die Quelldateien (JS/TS/CSS) reduzieren.

Beispiele für weniger Arbeit:

CSS anstelle von Sass/Less/Stylus verwenden, wenn möglich (Verschachtelung kann von PostCSS gehandhabt werden).
Transformieren Sie SVGs nicht in UI-Framework-Komponenten (React, Vue usw.). Importieren Sie sie stattdessen als Strings oder URLs.
Wenn Sie @vitejs/plugin-react verwenden, vermeiden Sie es, die Babel-Optionen so zu konfigurieren, dass die Transformation während des Builds übersprungen wird (nur esbuild wird verwendet).

Beispiele für die Verwendung von nativen Werkzeugen:

Die Verwendung von nativem Werkzeug bringt oft eine größere Installation mit sich und ist daher nicht der Standard, wenn ein neues Vite-Projekt initialisiert wird. Für größere Anwendungen hingegen kann es sich aber lohnen.

Probieren Sie die experimentelle Unterstützung für LightningCSS aus.
Verwenden Sie @vitejs/plugin-react-swc anstelle von @vitejs/plugin-react.

Leistung ​

Überprüfen Sie Ihre Browser-Einstellungen ​

Überprüfung konfigurierter Vite-Plugins ​

Reduzierung der Auflösungsoperationen ​

Vermeiden von Barrel-Dateien ​

Häufig verwendete Dateien aufwärmen ​

Weniger oder natives Werkzeug verwenden ​