RadeVentListener：客戶端框架性能的故事

React的受歡迎程度並非沒有批評者。該框架的相當大的尺寸（約120 kib縮小）顯著影響啟動時間，尤其是僅依靠客戶端渲染時。即使使用客戶端水合的服務器端渲染也仍然是性能密集的。儘管React在復雜的州管理中表現出色，但其資源需求通常超過更簡單的應用程序中的好處。這可以有效地排除使用功能較低的硬件的用戶。

儘管我保留了React的性能開銷，但我還是感謝其組件化模型和JSX語法。服務器端渲染（或使用preact，我首選的替代方案）仍然是寶貴的資產。但是，確定適當的客戶端用法仍然是一個挑戰。本文詳細介紹了我有關優化React性能的發現，以獲得更好的用戶體驗。

上下文：RSS提要應用程序

我的rss feed應用程序bylines.fyi在服務器和客戶端都使用JavaScript。雖然我並不固有地不喜歡客戶端框架，但我的經驗突出了兩個反復出現的問題：

1. 框架可以掩蓋基礎的網絡平台，從而阻礙對它們何時真正有益的深刻理解。
2. 框架並不總是保證最佳用戶體驗。

蒂姆·卡德克（Tim Kadlec）對Web框架性能的Httparchive研究加劇了這些問題，揭示了React的表現不佳。我的目標是在減輕其客戶端缺陷的同時利用React的服務器端優勢。

實驗：移動導航切換

我的RSS應用需要客戶端的JavaScript來進行簡單的移動導航切換，這是“簡單狀態”的經典示例。我經常看到反應組件過度用於此類簡單任務，從而導致不必要的性能開銷。該實驗雖然看似瑣碎，但它是了解框架選擇如何擴展的關鍵基準。重要的是要注意，大多數開發人員不僅會依靠這種次要功能的反應，但是結果說明了對運行時性能的架構影響。

測試條件

該實驗比較了四個設備上的三個移動導航實現：

1. 狀態反應組件：服務器渲染和客戶端熔融。
2. 狀態的預先反應組件：服務器渲染和客戶端水合。
3. 無狀態的提前部分：服務器渲染，未水合；使用標準事件聽眾。

設備包括：

1. 諾基亞2 Android電話（Chrome 83）
2. 華碩X550CC筆記本電腦（Windows 10，Chrome 83）
3. 第一代iPhone SE（Safari 13）
4. 第二代iPhone SE（Safari 13）

指標

為每個實施和設備測量了以下指標：

1. 啟動時間：包括框架加載和水合（react/preaxct），或者只是事件偵聽器代碼（EventListener）。
2. 水合時間：啟動時間的子集（僅反應/預先反應）。
3. 移動導航開放時間：在事件處理中測量框架開銷。

方法論

測試涉及遠程調試和分析，每個場景和設備的十個迭代記錄了每個度量的CPU時間。網絡性能不是一個因素。

結果

由於數據的複雜性，結果以表格格式顯示，顯示最小，最大，中值和平均CPU時間。 （詳細的表格在隨附的電子表格中可用）。關鍵發現包括：

• React的高創業和水合成本：在低端諾基亞2上尤其明顯。
• PREACT的提高性能：比React的速度要快得多，但在諾基亞2上仍超出了理想的框架預算。
• 卓越的事件聽眾的性能：始終比React和Exct都要快，尤其是對於簡單的互動。

討論：淺呼叫堆棧

性能差異源於框架加載和水合的開銷。儘管某些性能權衡是不可避免的，但對於開發人員的便利性而言，餘額通常會傾向於開發人員的體驗，而用戶則以犧牲用戶為代價。呼叫堆棧的React和PreACT Hydration突出了重大處理需求，尤其是對於簡單的任務。使用本地事件偵聽器為簡單的狀態管理提供了一種更有效的方法。

結論和建議

這種分析不是作為反應批評的，而是鼓勵批判性評估框架選擇及其性能的影響。幾種策略可以減輕績效問題：

1. 在可能的情況下，對無狀態組件的重構狀態組件。
2. 避免客戶端的JavaScript和無狀態組件的水合。
3. 使用獨立於框架的事件聽眾進行簡單的交互。
4. 懶惰的水合物組件使用相交觀察者或requestIdleCallback 。
5. 將預先反應視為反應的更快替代方法。
6. 使用navigator.deviceMemory適應低內存設備的用戶體驗。

優先考慮各種設備的性能測試，以確保具有不同硬件功能的用戶包容性。目標應該是每個人的快速訪問的網絡體驗。

特別感謝埃里克·貝利（Eric Bailey）的編輯反饋和CSS-Tricks員工發表本文。

以上是RadeVentListener：客戶端框架性能的故事的詳細內容。更多資訊請關注PHP中文網其他相關文章！