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

盡管我保留了React的性能開銷，但我還是感謝其組件化模型和JSX語法。服務(wù)器端渲染（或使用preact，我首選的替代方案）仍然是寶貴的資產(chǎn)。但是，確定適當?shù)目蛻舳擞梅ㄈ匀皇且粋€挑戰(zhàn)。本文詳細介紹了我有關(guān)優(yōu)化React性能的發(fā)現(xiàn)，以獲得更好的用戶體驗。

上下文：RSS提要應(yīng)用程序

我的rss feed應(yīng)用程序bylines.fyi在服務(wù)器和客戶端都使用JavaScript。雖然我并不固有地不喜歡客戶端框架，但我的經(jīng)驗突出了兩個反復(fù)出現(xiàn)的問題：

1. 框架可以掩蓋基礎(chǔ)的網(wǎng)絡(luò)平臺，從而阻礙對它們何時真正有益的深刻理解。
2. 框架并不總是保證最佳用戶體驗。

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

實驗：移動導(dǎo)航切換

我的RSS應(yīng)用需要客戶端的JavaScript來進行簡單的移動導(dǎo)航切換，這是“簡單狀態(tài)”的經(jīng)典示例。我經(jīng)?？吹椒磻?yīng)組件過度用于此類簡單任務(wù)，從而導(dǎo)致不必要的性能開銷。該實驗雖然看似瑣碎，但它是了解框架選擇如何擴展的關(guān)鍵基準。重要的是要注意，大多數(shù)開發(fā)人員不僅會依靠這種次要功能的反應(yīng)，但是結(jié)果說明了對運行時性能的架構(gòu)影響。

測試條件

該實驗比較了四個設(shè)備上的三個移動導(dǎo)航實現(xiàn)：

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

設(shè)備包括：

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

指標

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

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

方法論

測試涉及遠程調(diào)試和分析，每個場景和設(shè)備的十個迭代記錄了每個度量的CPU時間。網(wǎng)絡(luò)性能不是一個因素。

結(jié)果

由于數(shù)據(jù)的復(fù)雜性，結(jié)果以表格格式顯示，顯示最小，最大，中值和平均CPU時間。 （詳細的表格在隨附的電子表格中可用）。關(guān)鍵發(fā)現(xiàn)包括：

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

討論：淺呼叫堆棧

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

結(jié)論和建議

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

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

優(yōu)先考慮各種設(shè)備的性能測試，以確保具有不同硬件功能的用戶包容性。目標應(yīng)該是每個人的快速訪問的網(wǎng)絡(luò)體驗。

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

以上是RadeVentListener：客戶端框架性能的故事的詳細內(nèi)容。更多信息請關(guān)注PHP中文網(wǎng)其他相關(guān)文章！