如何移除你項(xiàng)目中99%的JS代碼

大家好，我卡頌。

在前不久的WWC22中，builder.io的CTO 「mi?ko hevery」（同時(shí)也是Angular/AngularJS的發(fā)明者）發(fā)表了一段充滿想象力的演講。



mi?ko hevery
在演講中，他介紹了一款全棧SSR框架 —— Qwik，這款框架號(hào)稱「能幫你移除項(xiàng)目中99%的JS代碼」。








他是如何辦到的，本文我們來(lái)介紹下Qwik。

性能差？碼農(nóng)不背鍋
先來(lái)聊聊Qwik誕生的背景。

對(duì)于很多2C web應(yīng)用（比如電商），首屏性能指標(biāo)關(guān)乎用戶留存，用戶留存關(guān)乎賺多少錢(qián)。

所以，應(yīng)用打開(kāi)速度會(huì)影響賺錢(qián)。

然而，對(duì)于前端開(kāi)發(fā)者，首屏性能指標(biāo)并不容易優(yōu)化。究其原因，并不是開(kāi)發(fā)者不夠努力。

讓我們來(lái)看兩個(gè)性能指標(biāo)。

如何優(yōu)化FCP
FCP（First Contentful Paint，首次內(nèi)容繪制）測(cè)量「頁(yè)面從開(kāi)始加載到頁(yè)面內(nèi)容的任何部分在屏幕上完成渲染的時(shí)間」。

當(dāng)前web應(yīng)用普遍采用「前端框架」開(kāi)發(fā)，這意味著會(huì)引入大量JS代碼（框架本身代碼、第三方依賴包的代碼......）

從HTML開(kāi)始解析到最終頁(yè)面渲染，中間還要經(jīng)歷：

下載框架JS代碼

執(zhí)行框架JS代碼

由框架完成頁(yè)面渲染

這就導(dǎo)致FCP指標(biāo)的下降。

為了優(yōu)化FCP，框架作者提出了SSR（Server Side Render，服務(wù)端渲染），在服務(wù)端生成首屏所需HTML，這就為FCP省去了上述三個(gè)步驟所需時(shí)間。

但是，TTI指標(biāo)仍然需要優(yōu)化。

如何優(yōu)化TTI
TTI（Time to Interactive，用戶可交互時(shí)間）測(cè)量「頁(yè)面變得完全可交互所需時(shí)間」。

主要衡量的是從下述1到3所需時(shí)間：

首先衡量FCP時(shí)間

為頁(yè)面中的元素綁定事件

對(duì)元素產(chǎn)生交互后，事件響應(yīng)時(shí)間在50ms內(nèi)

使用SSR后，雖然FCP降低，但是框架hydrate（注水，即框架使頁(yè)面能夠響應(yīng)交互）所需時(shí)間對(duì)TTI會(huì)有影響。

可見(jiàn)，性能瓶頸的源頭在JS代碼。

React18的Selective Hydration通過(guò)「讓用戶交互的部分優(yōu)先hydrate」來(lái)優(yōu)化TTI指標(biāo)。

但是，Qwik更極端，他的目標(biāo)是 —— 干掉所有不必要的JS耗時(shí)，這里的耗時(shí)包括兩部分：

JS作為靜態(tài)資源加載的耗時(shí)

JS運(yùn)行時(shí)的耗時(shí)

超超超細(xì)粒度hydrate
如果說(shuō)傳統(tǒng)SSR的粒度是「整個(gè)頁(yè)面」。

那么React18的Selective Hydration的粒度是「產(chǎn)生交互的組件」。

那么Qwik的粒度是「組件中的某個(gè)方法」。

舉個(gè)例子，下面是HelloWorld組件（可以發(fā)現(xiàn)，Qwik采用類似React的語(yǔ)法）：



對(duì)應(yīng)頁(yè)面渲染效果：



打開(kāi)瀏覽器Network面板，這個(gè)頁(yè)面會(huì)有多少JS請(qǐng)求呢？

由于這是個(gè)靜態(tài)的組件，沒(méi)有邏輯，所以答案是：沒(méi)有JS請(qǐng)求。

再來(lái)看看經(jīng)典的計(jì)數(shù)器Counter組件，相比HelloWorld，增加了「點(diǎn)擊按鈕狀態(tài)變化的邏輯」，代碼如下：



對(duì)應(yīng)頁(yè)面渲染效果：







打開(kāi)瀏覽器Network面板，這個(gè)頁(yè)面會(huì)有多少JS請(qǐng)求呢？

答案還是：沒(méi)有JS請(qǐng)求。

注意這兩個(gè)組件的代碼中，定義組件使用的是component$，有個(gè)$符號(hào)。

在Counter中，onClick$回調(diào)也有個(gè)$符號(hào)。

在Qwik中，后綴帶$的函數(shù)都是「懶加載」的。

hydrate的粒度有多細(xì)，就取決于$定義的多細(xì)。

比如在Counter中，onClick$帶$后綴，那么點(diǎn)擊回調(diào)是懶加載的，所以首屏渲染不會(huì)包含「點(diǎn)擊后的邏輯」對(duì)應(yīng)的JS代碼。






在點(diǎn)擊按鈕后，會(huì)發(fā)起2個(gè)JS請(qǐng)求，第一個(gè)請(qǐng)求返回的是「點(diǎn)擊后的邏輯」：



第2個(gè)JS請(qǐng)求返回的是「組件重新render的邏輯」：



這兩段代碼執(zhí)行后，Counter變?yōu)?。







審查元素會(huì)發(fā)現(xiàn)，點(diǎn)擊前，button on:click屬性中保存了「邏輯所在的地址」：



點(diǎn)擊后，會(huì)從對(duì)應(yīng)地址下載JS代碼，執(zhí)行對(duì)應(yīng)邏輯。

從優(yōu)秀到極致
是不是覺(jué)得已經(jīng)優(yōu)化到極致了？還沒(méi)。

對(duì)于一些在頁(yè)面中長(zhǎng)期存在的、需要JS驅(qū)動(dòng)的模塊（比如輪播圖），在模塊展現(xiàn)前，「模塊對(duì)應(yīng)JS」不是必要的。

比如下面這個(gè)鐘的示例，頁(yè)面中有個(gè)長(zhǎng)長(zhǎng)的列表，超過(guò)一屏高度，在列表底部有個(gè)鐘。

下面是列表滾到底的樣子：



在Clock組件的useClientEffect$中定義「時(shí)鐘指針擺動(dòng)的邏輯」：





Qwik中也存在類似React的useEffect，但在Qwik中這個(gè)Hook可以在服務(wù)端/客戶端執(zhí)行。

為了區(qū)分，useClientEffect是「只在客戶端執(zhí)行的useEffect」。

加了$后綴，代表他是「懶加載的」。

具體效果是：當(dāng)頁(yè)面滾動(dòng)到鐘露出之前，useClientEffect$對(duì)應(yīng)JS代碼都不會(huì)請(qǐng)求。

當(dāng)鐘露出后，會(huì)發(fā)起兩個(gè)JS資源請(qǐng)求：

useClientEffect的邏輯

Clock組件重新渲染的邏輯



如果審查元素，在鐘露出前，指針對(duì)應(yīng)元素都是不動(dòng)的：



當(dāng)鐘露出，加載并執(zhí)行JS代碼后，才開(kāi)始執(zhí)行動(dòng)效：



對(duì)數(shù)據(jù)hydrate
在傳統(tǒng)SSR中，數(shù)據(jù)其實(shí)被初始化了兩次：

頁(yè)面首次渲染，此時(shí)服務(wù)端導(dǎo)出的HTML中已經(jīng)攜帶了首屏渲染的數(shù)據(jù)

框架hydrate后，數(shù)據(jù)再轉(zhuǎn)化為框架內(nèi)的狀態(tài)供后續(xù)渲染






在Qwik中，頁(yè)面初始化時(shí)會(huì)存在type為qwik/json的script標(biāo)簽用于存儲(chǔ)「當(dāng)前頁(yè)面中被激活的狀態(tài)對(duì)應(yīng)數(shù)據(jù)」：



什么叫「被激活」呢？

比如，下面是一篇文章的評(píng)論區(qū)，這是首屏渲染后的樣子：



這些評(píng)論數(shù)據(jù)會(huì)出現(xiàn)在qwik/json保存的數(shù)據(jù)中么？

不會(huì)，因?yàn)闆](méi)有交互激活他們。

我們發(fā)現(xiàn)，有一條評(píng)論被折疊了，點(diǎn)擊后會(huì)展開(kāi)這條評(píng)論：



點(diǎn)擊這個(gè)行為會(huì)請(qǐng)求：

點(diǎn)擊邏輯對(duì)應(yīng)的JS代碼

這條評(píng)論對(duì)應(yīng)組件的重新渲染邏輯

此時(shí)，評(píng)論數(shù)據(jù)才會(huì)出現(xiàn)在qwik/json中，因?yàn)辄c(diǎn)擊交互激活了這個(gè)數(shù)據(jù)。

所以在Qwik中，如無(wú)必要，數(shù)據(jù)不會(huì)被初始化兩次。

HTML中存在「未激活的數(shù)據(jù)」，qwik/json的script標(biāo)簽中保存了「激活的數(shù)據(jù)」，這個(gè)特性會(huì)帶來(lái)一個(gè)很有意思的效果：

復(fù)制調(diào)試工具中「Elements面板下的DOM結(jié)構(gòu)」后，再在新頁(yè)面中粘貼，就能復(fù)現(xiàn)「頁(yè)面當(dāng)前的交互狀態(tài)」（比如，輸入框內(nèi)仍然保留之前輸入的內(nèi)容）：



復(fù)制紅框內(nèi)的內(nèi)容
換做其他框架，只能復(fù)現(xiàn)「頁(yè)面初始時(shí)的狀態(tài)」。

交互時(shí)再請(qǐng)求JS不會(huì)卡么？
有同學(xué)可能會(huì)問(wèn)，如果在網(wǎng)絡(luò)不好的情況下，交互時(shí)再請(qǐng)求JS代碼不會(huì)讓交互變得卡頓么？

Qwik允許你指定「哪些組件可能是用戶大概率會(huì)操作的」（比如電商應(yīng)用中，購(gòu)物車(chē)按鈕被點(diǎn)擊的概率高）。

這些組件邏輯對(duì)應(yīng)JS代碼會(huì)prefetch，在不影響首屏渲染的前提下被預(yù)請(qǐng)求：



并且這些組件prefetch的順序是可以調(diào)整的。

這意味著可以追蹤用戶行為，以「用戶交互的頻率」為指標(biāo)，作為組件prefetch優(yōu)先級(jí)的依據(jù)，啟發(fā)式提升應(yīng)用性能。

這才是真正的「以用戶為導(dǎo)向」的性能優(yōu)化，而且是全自動(dòng)的。

總結(jié)
當(dāng)今是個(gè)前端框架百花齊放的時(shí)代，不同框架都在尋找自己獨(dú)特的賣(mài)點(diǎn)。

Qwik的賣(mài)點(diǎn)是：將JS代碼的拆分從常見(jiàn)的「編譯時(shí)」（比如webpack分塊）、「運(yùn)行時(shí)」（比如dynamic import），變?yōu)椤附换r(shí)」。

對(duì)JS代碼的極致拆分，只為達(dá)到一個(gè)目的 —— 在首屏渲染時(shí)，移除你項(xiàng)目中99%的JS代碼。

你覺(jué)得這波操作怎么樣？


作者：卡頌


歡迎關(guān)注微信公眾號(hào) ：魔術(shù)師卡頌