如何移除你項(xiàng)目中99%的JS代碼
作者：卡頌
簡(jiǎn)介：《React技術(shù)揭秘》作者
來(lái)源：SegmentFault 思否社區(qū)
大家好，我卡頌。
在前不久的WWC22中，builder.io的CTO mi?ko hevery（同時(shí)也是Angular/AngularJS的發(fā)明者）發(fā)表了一段充滿想象力的演講。
在演講中，他介紹了一款全棧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ù)現(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)?strong>交互時(shí)。
對(duì)JS代碼的極致拆分，只為達(dá)到一個(gè)目的 —— 在首屏渲染時(shí)，移除你項(xiàng)目中99%的JS代碼。
你覺(jué)得這波操作怎么樣？
