Vue 性能指標(biāo)逐漸開始反超 React 了！

在之前的全球網(wǎng)站統(tǒng)計(jì)中，利用 React 構(gòu)建的網(wǎng)站比例遠(yuǎn)大于 Vue，而隨著 Vue 的飛速發(fā)展，尤其是去年發(fā)布了 Vue3 后，越來越多的人開始使用了。

那么在這種情況下，用 Vue 構(gòu)建的網(wǎng)站比例如何了呢？除了 Vue 和 React，其它框架的占比如何？每個(gè)網(wǎng)站的性能又如何？

所有數(shù)據(jù)無法證明這些框架孰優(yōu)孰劣，畢竟框架只是提供能力，所以比較結(jié)果僅供參考

本文數(shù)據(jù)來自于 Google Chrome User Experience Report，這是用戶在使用 Chrome 瀏覽器訪問網(wǎng)頁時(shí)自動(dòng)上報(bào)并記錄的，應(yīng)該還比較有權(quán)威性

前言

Chrome 所統(tǒng)計(jì)的網(wǎng)站性能指標(biāo)主要來源于三個(gè)維度：

• LCP^[1]（Largest Contentful Paint）
• FID^[2]（First Input Delay）
• CLS^[3]（Cumulative Layout Shift）

這些也是在 Google Search 中統(tǒng)計(jì)權(quán)重的重要指標(biāo)

在 Chrome 的用戶體驗(yàn)報(bào)告里主要統(tǒng)計(jì)到的前端開發(fā)框架有：Vue、React、Angular JS、Angular、Preact、Svelte、Next.js、Nuxt.js、SvelteKit ...

各大框架性能如何？

結(jié)合這三個(gè)指標(biāo)，綜合數(shù)據(jù)如下：

這里有個(gè)有意思的點(diǎn)，Preact 只有 4kb 左右，而 React 有 32kb 左右，都知道前者是后者的輕量級(jí)的替代方案，從圖中數(shù)據(jù)可以看出，這兩者性能差不多，甚至在 PC 端的圖表數(shù)據(jù)上來看 Preact 還優(yōu)于 React

再把這三個(gè)指標(biāo)拆開來看看各大框架的表現(xiàn)情況

這個(gè)指標(biāo)沒什么好看的，所有的框架幾乎都很完美

在業(yè)界流傳著一句話：大型應(yīng)用選React，小型應(yīng)用選Vue

剛才看的都是統(tǒng)計(jì)的所有網(wǎng)站的數(shù)據(jù)，我們來看下網(wǎng)站排名前 100萬 的網(wǎng)站數(shù)據(jù)

看這兩張圖表，Vue 構(gòu)建的網(wǎng)站似乎性能都超過了 React ？

恰巧最近也看了 Vue3 的框架設(shè)計(jì)的書，真的是驚嘆 Vue 框架設(shè)計(jì)的 ???? 之處

資源大小

用戶報(bào)告其實(shí)也統(tǒng)計(jì)了各個(gè)網(wǎng)站 JS 資源下載情況，這也是跟網(wǎng)站性能有所關(guān)聯(lián)的，畢竟資源過大或多或少也會(huì)減慢頁面的渲染速度，尤其是 JS 文件，需要下載再解析

可以看到基本上每個(gè)框架構(gòu)建的網(wǎng)站所需要下載的 JS 資源大小都達(dá)到了 1000kb 甚至以上，畢竟 SPA 應(yīng)用會(huì)一次性把所有的文件都下載下來，這都很正常

從圖中看 Svelte 好像是最優(yōu)的？這是意料之中的，畢竟跟每個(gè)框架的設(shè)計(jì)有關(guān)，Svelte 選擇了純編譯時(shí)（官方所說的無 runtime），也就是最終編譯成直接操作原生 DOM 的代碼，那么所需要下載的 JS 資源肯定相較于其它框架是少一些的

又看到個(gè)有意思的點(diǎn)，想拋出一個(gè)疑問，Preact 明明是 React 輕量替代方案，圖中展現(xiàn)的數(shù)據(jù)來看，Preact 確實(shí)最"重"的？這是為什么？

再來看一個(gè)跟框架本身無關(guān)的數(shù)據(jù)吧，那就是各大網(wǎng)站的圖片下載量

SSR & SSG

大家都知道 SSR 和 SSG 的出現(xiàn)就是為了解決 SPA 應(yīng)用帶來的一些性能問題，目的是為了使網(wǎng)站能更快的展現(xiàn)在用戶面前，以此來提升網(wǎng)站的性能指標(biāo)（本文所說的 Core Web Vitals ）

用戶使用報(bào)告里同樣也收集了使用了這些技術(shù)的網(wǎng)站的相關(guān)數(shù)據(jù)，一起來看一下

最吸引人眼球的就是 SvelteKit 了，它的數(shù)據(jù)指標(biāo)似乎比其它的框架高出了將近一倍，不過可惜的是統(tǒng)計(jì)到的數(shù)據(jù)只有 33 個(gè)，相較于其它框架的數(shù)量差距太大了，留個(gè)懸念吧，不知道等它量級(jí)起來后，是否還能保持這樣的性能

對(duì)于 CLS、FID、LCP 這三個(gè)指標(biāo)來說，大家最關(guān)心的應(yīng)該是 LCP，畢竟這是最影響用戶體驗(yàn)的指標(biāo)，那么在使用和沒使用服務(wù)端渲染框架的網(wǎng)站在 LCP 這項(xiàng)指標(biāo)上的表現(xiàn)又如何呢？

發(fā)現(xiàn)了特別特別有意思的點(diǎn)：

• Next.js 的 LCP 指標(biāo)遠(yuǎn) 低 于 React
• Nuxt.js 的 LCP 指標(biāo)遠(yuǎn) 高 于 Vue

同樣是服務(wù)端渲染框架為何差別這么大？

回到 LCP 指標(biāo)本身，其目前并不會(huì)計(jì)算所有元素，因?yàn)檫@樣會(huì)使這個(gè)指標(biāo)變得非常復(fù)雜，它現(xiàn)在只關(guān)注下面的元素：

• 元素

• 元素

• 元素

• 通過 url() 函數(shù)加載背景圖片的元素

• 包含文本節(jié)點(diǎn)或其他內(nèi)聯(lián)文本元素子級(jí)的塊級(jí)元素。

大部分網(wǎng)站都是以圖片為主導(dǎo)元素的，有沒有可能是圖片影響的？了解 Next.js 的人都知道，該框架自己封裝了一個(gè) image 組件，該組件內(nèi)部對(duì)圖片做了很多處理，例如：利用內(nèi)置的代理服務(wù)器對(duì)圖片進(jìn)行 格式轉(zhuǎn)換、壓縮、懶加載，利用 srcset^[4] 屬性對(duì)圖片進(jìn)行優(yōu)化

我在想這些雖然看起來是 Next.js 的優(yōu)點(diǎn)，但其實(shí)也是它的缺點(diǎn)，在對(duì)圖片進(jìn)行處理時(shí)肯定會(huì)有一些耗時(shí)，影響渲染速度

再找一張數(shù)據(jù)表來看看我的猜想是否符合：

我們看了這幾個(gè)框架構(gòu)建的網(wǎng)站中圖片下載情況，盡管 Next.js 應(yīng)用圖片下載量很小，但它的 LCP 指標(biāo)仍然墊底？？？反而 Nuxt.js 的數(shù)據(jù)令人驚嘆，圖片下載量將近是 Next.js 的三倍，LCP 指標(biāo)還遠(yuǎn)遠(yuǎn)高于它

我倒不是驚嘆于為什么 Nuxt.js 遠(yuǎn)超于 Next.js，疑惑的是 Next.js 的這個(gè)指標(biāo)為什么這么差，我翻閱了很多資料都沒有結(jié)論，也許是過渡優(yōu)化或優(yōu)化不當(dāng)帶來的弊端？（如果你們有什么想法，可以評(píng)論區(qū)留言）

參考資料