大家好，我卡頌。
在前不久的WWC22中，builder.io的CTO miško hevery（同時也是Angular/AngularJS的發明者）發表了一段充滿想象力的演講。
在演講中，他介紹了一款全棧SSR框架 —— Qwik，這款框架號稱能幫你移除專案中99%的JS程式碼。
他是如何辦到的，本文我們來介紹下Qwik。
歡迎加入人類高質量前端框架群，帶飛
效能差？碼農不背鍋
先來聊聊Qwik誕生的背景。
對於很多2C web應用（比如電商），首屏效能指標關乎使用者留存，使用者留存關乎賺多少錢。
所以，應用開啟速度會影響賺錢。
然而，對於前端開發者，首屏效能指標並不容易優化。究其原因，並不是開發者不夠努力。
讓我們來看兩個效能指標。
如何優化FCP
FCP（First Contentful Paint，首次內容繪製）測量頁面從開始載入到頁面內容的任何部分在螢幕上完成渲染的時間。
當前web應用普遍採用前端框架開發，這意味著會引入大量JS程式碼（框架本身程式碼、第三方依賴包的程式碼......）
從HTML開始解析到最終頁面渲染，中間還要經歷：
- 下載框架
JS程式碼 - 執行框架
JS程式碼 - 由框架完成頁面渲染
這就導致FCP指標的下降。
為了優化FCP，框架作者提出了SSR（Server Side Render，服務端渲染），在服務端生成首屏所需HTML，這就為FCP省去了上述三個步驟所需時間。
但是，TTI指標仍然需要優化。
如何優化TTI
TTI（Time to Interactive，使用者可互動時間）測量頁面變得完全可互動所需時間。
主要衡量的是從下述1到3所需時間：
- 首先衡量
FCP時間 - 為頁面中的元素繫結事件
- 對元素產生互動後，事件響應時間在50ms內
使用SSR後，雖然FCP降低，但是框架hydrate（注水，即框架使頁面能夠響應互動）所需時間對TTI會有影響。
可見，效能瓶頸的源頭在JS程式碼。
React18的Selective Hydration通過讓使用者互動的部分優先hydrate來優化TTI指標。
但是，Qwik更極端，他的目標是 —— 幹掉所有不必要的JS耗時，這裡的耗時包括兩部分：
JS作為靜態資源載入的耗時JS執行時的耗時
超超超細粒度hydrate
如果說傳統SSR的粒度是整個頁面。
那麼React18的Selective Hydration的粒度是產生互動的元件。
那麼Qwik的粒度是元件中的某個方法。
舉個例子，下面是HelloWorld元件（可以發現，Qwik採用類似React的語法）：
對應頁面渲染效果：
開啟瀏覽器Network皮膚，這個頁面會有多少JS請求呢？
由於這是個靜態的元件，沒有邏輯，所以答案是：沒有JS請求。
再來看看經典的計數器Counter元件，相比HelloWorld，增加了點選按鈕狀態變化的邏輯，程式碼如下：
對應頁面渲染效果：
開啟瀏覽器Network皮膚，這個頁面會有多少JS請求呢？
答案還是：沒有JS請求。
注意這兩個元件的程式碼中，定義元件使用的是component$，有個$符號。
在Counter中，onClick$回撥也有個$符號。
在Qwik中，字尾帶$的函式都是懶載入的。
hydrate的粒度有多細，就取決於$定義的多細。
比如在Counter中，onClick$帶$字尾，那麼點選回撥是懶載入的，所以首屏渲染不會包含點選後的邏輯對應的JS程式碼。
在點選按鈕後，會發起2個JS請求，第一個請求返回的是點選後的邏輯：
第2個JS請求返回的是元件重新render的邏輯：
這兩段程式碼執行後，Counter變為1。
審查元素會發現，點選前，button on:click屬性中儲存了邏輯所在的地址：
點選後，會從對應地址下載JS程式碼，執行對應邏輯。
從優秀到極致
是不是覺得已經優化到極致了？還沒。
對於一些在頁面中長期存在的、需要JS驅動的模組（比如輪播圖），在模組展現前，模組對應JS不是必要的。
比如下面這個鐘的示例，頁面中有個長長的列表，超過一屏高度，在列表底部有個鍾。
下面是列表滾到底的樣子：
在Clock元件的useClientEffect$中定義時鐘指標擺動的邏輯：
Qwik中也存在類似React的useEffect，但在Qwik中這個Hook可以在服務端/客戶端執行。
為了區分，useClientEffect是只在客戶端執行的useEffect。
加了$字尾，代表他是懶載入的。
具體效果是：當頁面滾動到鍾露出之前，useClientEffect$對應JS程式碼都不會請求。
當鍾露出後，會發起兩個JS資源請求：
useClientEffect的邏輯Clock元件重新渲染的邏輯
如果審查元素，在鍾露出前，指標對應元素都是不動的：
當鍾露出，載入並執行JS程式碼後，才開始執行動效：
對資料hydrate
在傳統SSR中，資料其實被初始化了兩次：
- 頁面首次渲染，此時服務端匯出的
HTML中已經攜帶了首屏渲染的資料 - 框架
hydrate後，資料再轉化為框架內的狀態供後續渲染
在Qwik中，頁面初始化時會存在type為qwik/json的script標籤用於儲存當前頁面中被啟用的狀態對應資料：
什麼叫被啟用呢？
比如，下面是一篇文章的評論區，這是首屏渲染後的樣子：
這些評論資料會出現在qwik/json儲存的資料中麼？
不會，因為沒有互動啟用他們。
我們發現，有一條評論被摺疊了，點選後會展開這條評論：
點選這個行為會請求：
- 點選邏輯對應的
JS程式碼 - 這條評論對應元件的重新渲染邏輯
此時，評論資料才會出現在qwik/json中，因為點選互動啟用了這個資料。
所以在Qwik中，如無必要，資料不會被初始化兩次。
HTML中存在未啟用的資料，qwik/json的script標籤中儲存了啟用的資料，這個特性會帶來一個很有意思的效果：
複製除錯工具中Elements皮膚下的DOM結構後，再在新頁面中貼上，就能復現頁面當前的互動狀態（比如，輸入框內仍然保留之前輸入的內容）：
換做其他框架，只能復現頁面初始時的狀態。
互動時再請求JS不會卡麼？
有同學可能會問，如果在網路不好的情況下，互動時再請求JS程式碼不會讓互動變得卡頓麼？
Qwik允許你指定哪些元件可能是使用者大概率會操作的（比如電商應用中，購物車按鈕被點選的概率高）。
這些元件邏輯對應JS程式碼會prefetch，在不影響首屏渲染的前提下被預請求：
並且這些元件prefetch的順序是可以調整的。
這意味著可以追蹤使用者行為，以使用者互動的頻率為指標，作為元件prefetch優先順序的依據，啟發式提升應用效能。
這才是真正的以使用者為導向的效能優化，而且是全自動的。
總結
當今是個前端框架百花齊放的時代，不同框架都在尋找自己獨特的賣點。
Qwik的賣點是：將JS程式碼的拆分從常見的編譯時（比如webpack分塊）、執行時（比如dynamic import），變為互動時。
對JS程式碼的極致拆分，只為達到一個目的 —— 在首屏渲染時，移除你專案中99%的JS程式碼。
你覺得這波操作怎麼樣？