Stories

Detail Return Return

極致性能優化:前端SSR渲染利器Qwik.js | 京東雲技術團隊 - Stories Detail

引言

前端性能已成為網站和應用成功的關鍵要素之一。用户期望快速加載的頁面和流暢的交互,而前端框架的選擇對於實現這些目標至關重要。然而,傳統的前端框架在某些情況下可能面臨性能挑戰且存在技術壁壘。

在這個充滿挑戰的背景下,我們引入了 Qwik.js 框架。Qwik.js 不僅是一個前端框架,更是一種前端性能的終極解決方案。它不僅提供了卓越的性能,還以其獨特的特點和優勢脱穎而出。

讓我們一起深入探索 Qwik.js,發現它如何超越傳統,成為前端性能優化的新標杆。

一、現有框架的問題

1.傳統CSR方案

慢加載時間: CSR 技術通常要求在瀏覽器中加載和渲染整個頁面,這導致初始頁面加載時間較長。用户必須等待頁面完全加載才能進行交互。

搜索引擎優化(SEO)問題: 由於頁面內容是在客户端生成的,搜索引擎爬蟲可能無法正確解析和索引頁面內容,這影響了網站的 SEO 效果。

不利於低帶寬用户: 對於低帶寬用户或網絡條件較差的用户,CSR 頁面加載時間更長,用户體驗更差。

首屏渲染延遲: CSR 通常需要等待 JavaScript 文件的下載和執行,這導致了首屏渲染的延遲,影響了用户的第一印象。

問題分析

A. 渲染階段耗時分析

B. 請求鏈路分析

C. 瀏覽器執行渲染分析

2. 傳統SSR方案

複雜的水合過程: 涉及複雜的水合過程,包括將數據傳輸到客户端並在客户端重新渲染頁面。這增加了頁面加載時間和網絡開銷。

A. 請求鏈路分析

B. 瀏覽器執行渲染分析

什麼是水合(Hydration)?

"hydration"(水合)是指通過客户端JavaScript將靜態HTML網頁轉化為動態網頁的過程,以實現對HTML元素的事件處理。這個過程可以通過將事件處理程序附加到HTML元素上來完成

深入瞭解水合(hydration)過程 水合的難點在於知道我們需要什麼事件處理程序以及它們應該附加到哪裏。

WHAT(什麼):事件處理程序是一個封閉包,包含了事件處理程序的行為。它定義了當用户觸發此事件時應該發生什麼。

WHERE(哪裏):指的是需要將WHAT(事件處理程序)附加到的DOM元素的位置,這包括了事件類型。

更復雜的部分在於,WHAT(事件處理程序)是一個封閉包,它封閉了APP\_STATE(應用程序狀態)和FRAMEWORK\_STATE(框架內部狀態):

APP_STATE(應用程序狀態):這是應用程序的狀態。APP\_STATE通常是人們所説的狀態。沒有APP\_STATE,您的應用程序將無法向用户展示任何動態內容。

FRAMEWORK_STATE(框架內部狀態):這是框架的內部狀態。沒有FRAMEWORK_STATE,框架不知道應該更新哪些DOM節點以及何時應該更新它們。這包括組件樹和對渲染函數的引用等內容。

那麼,我們如何恢復WHAT(APP\_STATE + FRAMEWORK\_STATE)和WHERE呢?方法是通過下載並執行當前HTML中的組件。在HTML中下載和執行已渲染的組件是水合的昂貴部分。

換句話説,水合是一種通過在瀏覽器中急切地執行應用程序代碼來恢復APP\_STATE和FRAMEWORK\_STATE的方法,它涉及以下步驟:

  1. 下載組件代碼。
  2. 執行組件代碼。
  3. 恢復WHAT(事件處理程序閉包)和WHERE(DOM元素),以獲取事件處理程序閉包。
  4. 將WHAT(事件處理程序閉包)附加到WHERE(DOM元素)。

這個過程的關鍵是將APP\_STATE和FRAMEWORK\_STATE從已渲染的組件中恢復,以確保應用程序在客户端獲得正確的狀態和行為。這對於實現前端與後端的協同工作以提供動態用户體驗至關重要。

二、Qwik.js框架的特點

可恢復性(Resumability):一種無開銷的水合替代方案 那麼,如何設計一個沒有水合且沒有開銷的系統呢?

為了消除開銷,框架不僅必須避免恢復(RECOVERY),還必須避免上述所提到的第四步。第四步是將WHAT附加到WHERE,這是可以避免的成本。

要避免這種成本,您需要三樣東西:

  1. 將所有所需的信息序列化為HTML的一部分。序列化的信息需要包括WHAT、WHERE、APP\_STATE和FRAMEWORK\_STATE。
  2. 一個全局事件處理程序,依賴事件冒泡來攔截所有事件。事件處理程序需要是全局的,這樣我們就不需要急切地在特定的DOM元素上單獨註冊所有事件。
  3. 一個工廠函數,可以延遲恢復事件處理程序(WHAT)。

這種方法的關鍵是在HTML中序列化所有必需的信息,以及使用全局事件處理程序來攔截和處理事件,而不必顯式將事件處理程序附加到特定的DOM元素上。這樣可以避免昂貴的步驟四,從而提供無開銷的可恢復性,同時仍能實現前端的互動性和性能優化。

A. 渲染階段耗時分析

B. 請求鏈路分析

C. 瀏覽器執行渲染分析

四、效果和成果

五、挑戰

Qwik.js無水合方案可能會帶來一些挑戰,其中包括以下幾個方面:

  1. 新技術的學習曲線: 採用新的前端架構或技術,如Qwik.js,通常需要團隊成員學習和適應新的工作流程和最佳實踐。這可能需要一些時間和培訓來確保團隊熟練掌握新技術。
  2. 服務器開銷增加: 在無水合方案中,服務器可能需要更多的計算資源來序列化和提供所需的信息,以及處理全局事件處理程序。這可能會導致服務器開銷的增加,特別是在大量併發請求的情況下。
  3. Node.js併發挑戰: 對於Node.js服務器,處理大量併發請求可能會帶來挑戰。在無水合方案中,服務器可能需要同時處理多個請求,因此需要考慮服務器的併發性能和擴展性。

作者:京東創新零售 李健

來源:京東雲開發者社區 轉載請註明來源

user avatar feichangkudechongfengyi Avatar explinks Avatar _5bf4c360ce464 Avatar dreamlu Avatar ohaha Avatar baqidemakebei Avatar guanguans Avatar xc_xiang Avatar user_nypdl4ki Avatar longronglang Avatar code4world Avatar
Favorites 11 users favorite the story!
Favorites

Add a new Comments

Some HTML is okay.