Vue 在大多數(shù)常見場景下性能都是很優(yōu)秀的，通常不需要手動優(yōu)化。然而，總會有一些具有挑戰(zhàn)性的場景需要進行針對性的微調。
數(shù)字化管理平臺
Vue3+Vite+VueRouter+Pinia+Axios+ElementPlus教程
權限系統(tǒng)-商城
個人博客地址
Web 性能優(yōu)化主要有兩個方面：
-
頁面加載性能
首次訪問時，應用展示出內容與達到可交互狀態(tài)的速度。這通常會用 Google 所定義的一系列 Web 指標 (Web Vitals) 來進行衡量，如最大內容繪制 (Largest Contentful Paint，縮寫為 LCP) 和首次輸入延遲 (First Input Delay，縮寫為 FID)。 -
更新性能
應用響應用戶輸入更新的速度。比如當用戶在搜索框中輸入時結果列表的更新速度，或者用戶在一個單頁面應用 (SPA) 中點擊鏈接跳轉頁面時的切換速度。
一、頁面加載優(yōu)化
1.1 選用正確的架構
如果你的用例對頁面加載性能很敏感，請避免將其部署為純客戶端的 SPA，而是讓服務器直接發(fā)送包含用戶想要查看的內容的 HTML 代碼。純客戶端渲染存在首屏加載緩慢的問題，這可以通過服務器端渲染 (SSR) 或靜態(tài)站點生成 (SSG) 來緩解。
1.2 包體積與 Tree-shaking 優(yōu)化
一個最有效的提升頁面加載速度的方法就是壓縮 JavaScript 打包產(chǎn)物的體積。當使用 Vue 時有下面一些辦法來減小打包產(chǎn)物體積：
-
盡可能地采用構建步驟
- 如果使用的是相對現(xiàn)代的打包工具，許多 Vue 的 API 都是可以被 tree-shake 的。舉例來說，如果你根本沒有使用到內置的 組件，它將不會被打包進入最終的產(chǎn)物里。Tree-shaking 也可以移除你源代碼中其他未使用到的模塊。
- 當使用了構建步驟時，模板會被預編譯，因此我們無須在瀏覽器中載入 Vue 編譯器。這在同樣最小化加上 gzip 優(yōu)化下會相對縮小 14kb 并避免運行時的編譯開銷。
-
在引入新的依賴項時要小心包體積膨脹
- 如果使用了構建步驟，應當盡量選擇提供 ES 模塊格式的依賴，它們對 tree-shaking 更友好。舉例來說，選擇 lodash-es 比 lodash 更好。
- 查看依賴的體積，并評估與其所提供的功能之間的性價比。如果依賴對 tree-shaking 友好，實際增加的體積大小將取決于你從它之中導入的 API。像 bundlejs.com 這樣的工具可以用來做快速的檢查，但是根據(jù)實際的構建設置來評估總是最準確的。
- 如果你只在漸進式增強的場景下使用 Vue，并想要避免使用構建步驟，請考慮使用 petite-vue (只有 6kb) 來代替。
1.3 代碼分割
代碼分割是指構建工具將構建后的 JavaScript 包拆分為多個較小的，可以按需或并行加載的文件。通過適當?shù)拇a分割，頁面加載時需要的功能可以立即下載，而額外的塊只在需要時才加載，從而提高性能。
像 Rollup (Vite 就是基于它之上開發(fā)的) 或者 webpack 這樣的打包工具可以通過分析 ESM 動態(tài)導入的語法來自動進行代碼分割：
// lazy.js 及其依賴會被拆分到一個單獨的文件中
// 并只在 `loadLazy()` 調用時才加載
function loadLazy() {
return import('./lazy.js')
}
懶加載對于頁面初次加載時的優(yōu)化幫助極大，它幫助應用暫時略過了那些不是立即需要的功能。在 Vue 應用中，這可以與 Vue 的異步組件搭配使用，為組件樹創(chuàng)建分離的代碼塊：
import { defineAsyncComponent } from 'vue'
// 會為 Foo.vue 及其依賴創(chuàng)建單獨的一個塊
// 它只會按需加載
//（即該異步組件在頁面中被渲染時）
const Foo = defineAsyncComponent(() => import('./Foo.vue'))
對于使用了 Vue Router 的應用，強烈建議使用異步組件作為路由組件。Vue Router 已經(jīng)顯性地支持了獨立于 defineAsyncComponent 的懶加載。
二、更新優(yōu)化
2.1 Props 穩(wěn)定性
在 Vue 之中，一個子組件只會在其至少一個 props 改變時才會更新。
<ListItem
v-for="item in list"
:id="item.id"
:active-id="activeId" />
在 組件中，它使用了 id 和 activeId 兩個 props 來確定它是否是當前活躍的那一項。雖然這是可行的，但問題是每當 activeId 更新時，列表中的每一個 都會跟著更新！
理想情況下，只有活躍狀態(tài)發(fā)生改變的項才應該更新。我們可以將活躍狀態(tài)比對的邏輯移入父組件來實現(xiàn)這一點，然后讓 改為接收一個 active prop：
<ListItem
v-for="item in list"
:id="item.id"
:active="item.id === activeId" />
現(xiàn)在，對于大多數(shù)的組件來說，activeId 改變時，它們的 active prop 都會保持不變，因此它們無需再更新?？偨Y一下，這個技巧的核心思想就是讓傳給子組件的 props 盡量保持穩(wěn)定。
2.2 v-once
v-once 是一個內置的指令，可以用來渲染依賴運行時數(shù)據(jù)但無需再更新的內容。
在隨后的重新渲染，元素/組件及其所有子項將被當作靜態(tài)內容并跳過渲染。這可以用來優(yōu)化更新時的性能。
<!-- 單個元素 -->
<span v-once>This will never change: {{msg}}</span>
<!-- 帶有子元素的元素 -->
<div v-once>
<h1>comment</h1>
<p>{{msg}}</p>
</div>
<!-- 組件 -->
<MyComponent v-once :comment="msg" />
<!-- `v-for` 指令 -->
<ul>
<li v-for="i in list" v-once>{{i}}</li>
</ul>
從 3.2 起，你也可以搭配 v-memo 的無效條件來緩存部分模板
2.3 v-memo
v-memo 是一個內置指令，可以用來有條件地跳過某些大型子樹或者 v-for 列表的更新。
為了實現(xiàn)緩存，該指令需要傳入一個固定長度的依賴值數(shù)組進行比較。如果數(shù)組里的每個值都與最后一次的渲染相同，那么整個子樹的更新將被跳過
<div v-memo="[valueA, valueB]">
...
</div>
當組件重新渲染，如果 valueA 和 valueB 都保持不變，這個
正確指定緩存數(shù)組很重要，否則應該生效的更新可能被跳過。v-memo 傳入空依賴數(shù)組 (v-memo=“[]”) 將與 v-once 效果相同。
v-memo 僅用于性能至上場景中的微小優(yōu)化，應該很少需要。最常見的情況可能是有助于渲染海量 v-for 列表 (長度超過 1000 的情況)：
<div v-for="item in list" :key="item.id" v-memo="[item.id === selected]">
<p>ID: {{ item.id }} - selected: {{ item.id === selected }}</p>
<p>...more child nodes</p>
</div>
當組件的 selected 狀態(tài)改變，默認會重新創(chuàng)建大量的 vnode，盡管絕大部分都跟之前是一模一樣的。v-memo 用在這里本質上是在說“只有當該項的被選中狀態(tài)改變時才需要更新”。這使得每個選中狀態(tài)沒有變的項能完全重用之前的 vnode 并跳過差異比較。注意這里 memo 依賴數(shù)組中并不需要包含 item.id，因為 Vue 也會根據(jù) item 的 :key 進行判斷。
三、通用優(yōu)化
以下技巧能同時改善頁面加載和更新性能。
3.1 大型虛擬列表
所有的前端應用中最常見的性能問題就是渲染大型列表。無論一個框架性能有多好，渲染成千上萬個列表項都會變得很慢，因為瀏覽器需要處理大量的 DOM 節(jié)點。
但是，我們并不需要立刻渲染出全部的列表。在大多數(shù)場景中，用戶的屏幕尺寸只會展示這個巨大列表中的一小部分。我們可以通過列表虛擬化來提升性能，這項技術使我們只需要渲染用戶視口中能看到的部分。
要實現(xiàn)列表虛擬化并不簡單，幸運的是，你可以直接使用現(xiàn)有的社區(qū)庫：
- vue-virtual-scroller
- vue-virtual-scroll-grid
- vueuc/VVirtualList
3.2 減少大型不可變數(shù)據(jù)的響應性開銷
Vue 的響應性系統(tǒng)默認是深度的。雖然這讓狀態(tài)管理變得更直觀，但在數(shù)據(jù)量巨大時，深度響應性也會導致不小的性能負擔，因為每個屬性訪問都將觸發(fā)代理的依賴追蹤。好在這種性能負擔通常這只有在處理超大型數(shù)組或層級很深的對象時，例如一次渲染需要訪問 100,000+ 個屬性時，才會變得比較明顯。因此，它只會影響少數(shù)特定的場景。
Vue 確實也為此提供了一種解決方案，通過使用 shallowRef() 和 shallowReactive() 來繞開深度響應。淺層式 API 創(chuàng)建的狀態(tài)只在其頂層是響應式的，對所有深層的對象不會做任何處理。這使得對深層級屬性的訪問變得更快，但代價是，我們現(xiàn)在必須將所有深層級對象視為不可變的，并且只能通過替換整個根狀態(tài)來觸發(fā)更新：
const shallowArray = shallowRef([
/* 巨大的列表，里面包含深層的對象 */
])
// 這不會觸發(fā)更新...
shallowArray.value.push(newObject)
// 這才會觸發(fā)更新
shallowArray.value = [...shallowArray.value, newObject]
// 這不會觸發(fā)更新...
shallowArray.value[0].foo = 1
// 這才會觸發(fā)更新
shallowArray.value = [
{
...shallowArray.value[0],
foo: 1
},
...shallowArray.value.slice(1)
]
3.3 避免不必要的組件抽象
有些時候我們會去創(chuàng)建無渲染組件或高階組件 (用來渲染具有額外 props 的其他組件) 來實現(xiàn)更好的抽象或代碼組織。雖然這并沒有什么問題，但請記住，組件實例比普通 DOM 節(jié)點要昂貴得多，而且為了邏輯抽象創(chuàng)建太多組件實例將會導致性能損失。
需要提醒的是，只減少幾個組件實例對于性能不會有明顯的改善，所以如果一個用于抽象的組件在應用中只會渲染幾次，就不用操心去優(yōu)化它了。考慮這種優(yōu)化的最佳場景還是在大型列表中。想象一下一個有 100 項的列表，每項的組件都包含許多子組件。在這里去掉一個不必要的組件抽象，可能會減少數(shù)百個組件實例的無謂性能消耗。
附錄： Vue 組織架構
Vue 被設計成一個靈活的、可以漸進式集成的框架。根據(jù)使用場景的不同需要，相應地有多種不同的方式來使用 Vue，以此在技術棧復雜度、開發(fā)體驗和性能表現(xiàn)間取得最佳平衡。
-
獨立腳本
Vue 可以以一個單獨 JS 文件的形式使用，無需構建步驟！如果你的后端框架已經(jīng)渲染了大部分的 HTML，或者你的前端邏輯并不復雜，不需要構建步驟，這是最簡單的使用 Vue 的方式。在這些場景中你可以將 Vue 看作一個更加聲明式的 jQuery 替代品。
Vue 也提供了另一個更適用于此類無構建步驟場景的版本 petite-vue。它為漸進式增強已有的 HTML 作了特別的優(yōu)化，功能更加精簡，十分輕量。 -
作為 Web Component 嵌入
你可以用 Vue 來構建標準的 Web Component，這些 Web Component 可以嵌入到任何 HTML 頁面中，無論它們是如何被渲染的。這個方式讓你能夠在不需要顧慮最終使用場景的情況下使用 Vue：因為生成的 Web Component 可以嵌入到舊應用、靜態(tài) HTML，甚至用其他框架構建的應用中。 -
單頁面應用 (SPA)
一些應用在前端需要具有豐富的交互性、較深的會話和復雜的狀態(tài)邏輯。構建這類應用的最佳方法是使用這樣一種架構：Vue 不僅控制整個頁面，還負責處理抓取新數(shù)據(jù)，并在無需重新加載的前提下處理頁面切換。這種類型的應用通常稱為單頁應用 (Single-Page application，縮寫為 SPA)。
Vue 提供了核心功能庫和全面的工具鏈支持，為現(xiàn)代 SPA 提供了極佳的開發(fā)體驗，覆蓋以下方面：- 客戶端路由
- 極其快速的構建工具
- IDE 支持
- 瀏覽器開發(fā)工具
- TypeScript 支持
- 測試工具
SPA 一般要求后端提供 API 數(shù)據(jù)接口，但你也可以將 Vue 和如 Inertia.js 之類的解決方案搭配使用，在保留側重服務端的開發(fā)模型的同時獲得 SPA 的益處。
-
全棧 / SSR
純客戶端的 SPA 在首屏加載和 SEO 方面有顯著的問題，因為瀏覽器會收到一個巨大的 HTML 空頁面，只有等到 JavaScript 加載完畢才會渲染出內容。
Vue 提供了一系列 API，支持將一個 Vue 應用在服務端渲染成 HTML 字符串。這能讓服務器直接返回渲染好的 HTML，讓用戶在 JavaScript 下載完畢前就看到頁面內容。Vue 之后會在客戶端對應用進行“激活 (hydrate)”使其重獲可交互性。這被稱為服務端渲染 (SSR)，它能夠極大地改善應用在 Web 核心指標上的性能表現(xiàn)，如最大內容繪制 (LCP)。
Vue 生態(tài)中有一些針對此類場景的、基于 Vue 的上層框架，比如 NuxtJS，能讓你用 Vue 和 JavaScript 開發(fā)一個全棧應用。 -
JAMStack / SSG
如果所需的數(shù)據(jù)是靜態(tài)的，那么服務端渲染可以提前完成。這意味著我們可以將整個應用預渲染為 HTML，并將其作為靜態(tài)文件部署。這增強了站點的性能表現(xiàn)，也使部署變得更容易，因為我們無需根據(jù)請求動態(tài)地渲染頁面。Vue 仍可通過激活在客戶端提供交互。這一技術通常被稱為靜態(tài)站點生成 (SSG)，也被稱為 JAMStack。
SSG 有兩種風格：單頁和多頁。這兩種風格都能將站點預渲染為靜態(tài) HTML，區(qū)別在于：- 單頁 SSG 在初始頁面加載后將其“激活”為 SPA。這需要更多的前期 JS 加載和激活成本，但后續(xù)的導航將更快，因為它只需要部分地更新頁面內容，而無需重新加載整個頁面。
- 多頁 SSG 每次導航都會加載一個新頁面。好處是它可以僅需最少的 JS——或者如果頁面無需交互則根本不需要 JS！一些多頁面 SSG 框架，如 Astro 也支持“部分激活”——它允許你通過 Vue 組件在靜態(tài) HTML 中創(chuàng)建交互式的“孤島”。
單頁 SSG 更適合于重交互、深會話的場景，或需要在導航之間持久化元素或狀態(tài)。否則，多頁 SSG 將是更好的選擇。
Vue 團隊也維護了一個名為 VitePress 的靜態(tài)站點生成器，你正在閱讀的文檔就是基于它構建的！VitePress 支持兩種形式的 SSG。另外，NuxtJS 也支持 SSG。你甚至可以在同一個 Nuxt 應用中通過不同的路由提供 SSR 和 SSG。文章來源：http://www.zghlxwxcb.cn/news/detail-624336.html -
Web 之外…
盡管 Vue 主要是為構建 Web 應用而設計的，但它絕不僅僅局限于瀏覽器。你還可以：文章來源地址http://www.zghlxwxcb.cn/news/detail-624336.html- 配合 Electron 或 Tauri 構建桌面應用
- 配合 Ionic Vue 構建移動端應用
- 使用 Quasar 用同一套代碼同時開發(fā)桌面端和移動端應用
- 使用 Vue 的自定義渲染 API 來構建不同目標的渲染器，比如 WebGL 甚至是終端命令行！
到了這里，關于【 Vue3 性能優(yōu)化】頁面加載性能 與 更新性能的文章就介紹完了。如果您還想了解更多內容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！
