在前不久的WWC22中， .io 的CTO 「mi?ko 」（同時也是 / 的發(fā)明者）發(fā)表了一段充滿想象力的演講。
mi?ko
在演講中，他介紹了一款全棧SSR框架 —— Qwik ，這款框架號稱 「能幫你移除項(xiàng)目中99%的JS代碼」。
他是如何辦到的，本文我們來介紹下 Qwik 。
性能差？碼農(nóng)不背鍋
先來聊聊 Qwik 誕生的背景。
對于很多 2C web 應(yīng)用（比如電商），首屏性能指標(biāo)關(guān)乎用戶留存，用戶留存關(guān)乎賺多少錢。
所以，應(yīng)用打開速度會影響賺錢。
然而頁面渲染完成后執(zhí)行js，對于前端開發(fā)者，首屏性能指標(biāo)并不容易優(yōu)化。究其原因，并不是開發(fā)者不夠努力。
讓我們來看兩個性能指標(biāo)。
如何優(yōu)化FCP
FCP （First Paint，首次內(nèi)容繪制）測量 「頁面從開始加載到頁面內(nèi)容的任何部分在屏幕上完成渲染的時間」。
當(dāng)前 web 應(yīng)用普遍采用 「前端框架」開發(fā)，這意味著會引入大量 JS 代碼（框架本身代碼、第三方依賴包的代碼......）
從 HTML 開始解析到最終頁面渲染，中間還要經(jīng)歷：
下載框架 JS 代碼
執(zhí)行框架 JS 代碼
由框架完成頁面渲染
這就導(dǎo)致 FCP 指標(biāo)的下降。
為了優(yōu)化 FCP ，框架作者提出了 SSR （ Side ，服務(wù)端渲染），在服務(wù)端生成首屏所需 HTML ，這就為 FCP 省去了上述三個步驟所需時間。
但是， TTI 指標(biāo)仍然需要優(yōu)化。
如何優(yōu)化TTI
TTI （Time to ，用戶可交互時間）測量 「頁面變得完全可交互所需時間」。
主要衡量的是從下述1到3所需時間：
首先衡量 FCP 時間
為頁面中的元素綁定事件
對元素產(chǎn)生交互后，事件響應(yīng)時間在50ms內(nèi)
使用 SSR 后，雖然 FCP 降低，但是框架 （注水，即框架使頁面能夠響應(yīng)交互）所需時間對 TTI 會有影響。
可見，性能瓶頸的源頭在 JS 代碼。
的 通過 「讓用戶交互的部分優(yōu)先」來優(yōu)化 TTI 指標(biāo)。
但是， Qwik 更極端，他的目標(biāo)是 —— 干掉所有不必要的 JS 耗時，這里的耗時包括兩部分：
超超超細(xì)粒度
如果說傳統(tǒng) SSR 的粒度是 「整個頁面」。
那么 的 的粒度是 「產(chǎn)生交互的組件」。
那么 Qwik 的粒度是 「組件中的某個方法」。
舉個例子，下面是 組件（可以發(fā)現(xiàn)， Qwik 采用類似 React 的語法）：
對應(yīng)頁面渲染效果：
打開瀏覽器 面板，這個頁面會有多少 JS 請求呢？
由于這是個靜態(tài)的組件，沒有邏輯，所以答案是：沒有 JS 請求。
再來看看經(jīng)典的計(jì)數(shù)器 組件，相比 ，增加了 「點(diǎn)擊按鈕狀態(tài)變化的邏輯」，代碼如下：
對應(yīng)頁面渲染效果：
打開瀏覽器 面板，這個頁面會有多少 JS 請求呢？
答案還是：沒有 JS 請求。
注意這兩個組件的代碼中，定義組件使用的是 $ ，有個 $ 符號。
在 中， $ 回調(diào)也有個 $ 符號。
在 Qwik 中，后綴帶 $ 的函數(shù)都是 「懶加載」的。
的粒度有多細(xì)，就取決于 $ 定義的多細(xì)。
比如在 中， $ 帶 $ 后綴，那么點(diǎn)擊回調(diào)是懶加載的，所以首屏渲染不會包含 「點(diǎn)擊后的邏輯」對應(yīng)的 JS 代碼。
在點(diǎn)擊按鈕后，會發(fā)起2個 JS 請求，第一個請求返回的是 「點(diǎn)擊后的邏輯」：
第2個 JS 請求返回的是 「組件重新的邏輯」：
這兩段代碼執(zhí)行后， 變?yōu)?。
審查元素會發(fā)現(xiàn)，點(diǎn)擊前， on:click 屬性中保存了 「邏輯所在的地址」：
點(diǎn)擊后，會從對應(yīng)地址下載 JS 代碼，執(zhí)行對應(yīng)邏輯。
從優(yōu)秀到極致
是不是覺得已經(jīng)優(yōu)化到極致了？還沒。
對于一些在頁面中長期存在的、需要 JS 驅(qū)動的模塊（比如輪播圖），在模塊展現(xiàn)前頁面渲染完成后執(zhí)行js， 「模塊對應(yīng)JS」不是必要的。
比如下面這個鐘的示例，頁面中有個長長的列表，超過一屏高度，在列表底部有個鐘。
下面是列表滾到底的樣子：
在 Clock 組件的 $ 中定義 「時鐘指針擺動的邏輯」：
Qwik 中也存在類似 React 的 ，但在 Qwik 中這個 Hook 可以在服務(wù)端/客戶端執(zhí)行。
為了區(qū)分， 是 「只在客戶端執(zhí)行的」。
加了 $ 后綴，代表他是 「懶加載的」。
具體效果是：當(dāng)頁面滾動到鐘露出之前， $ 對應(yīng) JS 代碼都不會請求。
當(dāng)鐘露出后，會發(fā)起兩個 JS 資源請求：
如果審查元素，在鐘露出前，指針對應(yīng)元素都是不動的：
當(dāng)鐘露出，加載并執(zhí)行 JS 代碼后，才開始執(zhí)行動效：
對數(shù)據(jù)
在傳統(tǒng) SSR 中，數(shù)據(jù)其實(shí)被初始化了兩次：
頁面首次渲染，此時服務(wù)端導(dǎo)出的 HTML 中已經(jīng)攜帶了首屏渲染的數(shù)據(jù)
框架 后，數(shù)據(jù)再轉(zhuǎn)化為框架內(nèi)的狀態(tài)供后續(xù)渲染
在 Qwik 中，頁面初始化時會存在 type 為 qwik/json 的 標(biāo)簽用于存儲 「當(dāng)前頁面中被激活的狀態(tài)對應(yīng)數(shù)據(jù)」：
什么叫 「被激活」呢？
比如，下面是一篇文章的評論區(qū)，這是首屏渲染后的樣子：
這些評論數(shù)據(jù)會出現(xiàn)在 qwik/json 保存的數(shù)據(jù)中么？
不會，因?yàn)闆]有交互激活他們。