沒有比在網站上使用一堆 JavaScript 代碼更能降低網站速度（雙關語意）的方法了。 使用 JavaScript 時，你要為它付出不少於四倍於項目性能的代價。 以下是網站的 JavaScript 代碼加載用戶系統的方式：
- 通過網絡下載文件。
- 下載後解析和編譯解壓的源代碼。
- 執行 JavaScript 代碼。
- 內存消耗。
這個組合結果 .
我們的項目中包含越來越多的 JS 代碼。 隨著組織轉向由 React、Vue 等框架和庫支持的網站，我們正在使網站的核心功能嚴重依賴 JavaScript。
我見過很多使用 JavaScript 框架的非常繁重的網站。 但是我對這個問題的看法是非常有偏見的。 事實上，與我合作的公司之所以轉向我，正是因為他們在網站性能領域面臨著複雜的問題。 結果，我開始好奇這個問題有多普遍，以及當我們選擇一個或另一個框架作為某個站點的基礎時，我們付出了什麼樣的“懲罰”。
該項目幫助我解決了這個問題。 .
數據
HTTP Archive 項目總共跟踪了 4308655 個指向常規桌面站點的鏈接和 5484239 個指向移動站點的鏈接。 在與這些鏈接相關的眾多指標中，有一個在各個站點上找到的技術列表。 這意味著我們可以對使用各種框架和庫的數千個站點進行採樣，並了解它們向客戶端發送了多少代碼以及這些代碼在用戶系統上產生了多少負載。
我收集了 2020 年 XNUMX 月的數據，這是我可以訪問的最新數據。
我決定將所有站點的聚合 HTTP 存檔數據與來自使用 React、Vue 和 Angular 的站點的數據進行比較，儘管我也考慮過使用其他源材料。
為了讓它更有趣，我還在源數據集中添加了使用 jQuery 的站點。 這個圖書館仍然很受歡迎。 它還引入了一種不同於 React、Vue 和 Angular 提供的單頁應用程序 (SPA) 模型的 Web 開發方法。
HTTP 檔案中的鏈接表示已被發現使用感興趣的技術的站點
框架或庫
移動網站鏈接
鏈接到常規站點
jQuery的
4615474
3714643
應對
489827
241023
Vue公司
85649
43691
角
19423
18088
希望和夢想
在我們繼續進行數據分析之前，我想談談我希望得到的東西。
我相信在一個理想的世界中，框架應該超越滿足開發人員的需求，並為使用我們網站的普通用戶提供一些特定的好處。 性能只是這些好處之一。 這就是可訪問性和安全性發揮作用的地方。 但這只是最重要的。
因此，在理想情況下，某種框架應該可以輕鬆創建高性能站點。 這樣做應該是因為該框架為開發人員提供了構建項目的良好基礎，或者由於它對開發施加了限制，提出了一些要求，使某些東西的開髮變得複雜出來要慢。
最好的框架應該做到這兩點：提供良好的基礎，並對工作施加限制，讓您獲得不錯的結果。
分析數據的中值不會給我們提供我們需要的信息。 而且，事實上，這種方法沒有引起我們的注意 . 相反，我從我擁有的數據中得出百分比。 這些是 10、25、50（中位數）、75、90 個百分位數。
我對第 10 個和第 90 個百分位數特別感興趣。 第 10 個百分位代表特定框架的最佳性能（或至少或多或少接近最佳）。 換句話說，這意味著只有 10% 使用特定框架的站點達到了這個級別或更高級別。 另一方面，第 90 個百分位數是硬幣的另一面 - 它向我們展示了事情會變得多麼糟糕。 第 90 個百分位是落後的網站——那些擁有最多 JS 代碼或在主線程上處理代碼的時間最長的 10% 的網站。
大量的 JavaScript 代碼
首先，分析不同站點通過網絡傳輸的 JavaScript 代碼的大小是有意義的。
傳輸到移動設備的 JavaScript 代碼量 (Kb)
百分位數
10
25
50
75
90
所有網站
93.4
196.6
413.5
746.8
1201.6
jQuery 網站
110.3
219.8
430.4
748.6
1162.3
Vue 網站
244.7
409.3
692.1
1065.5
1570.7
角度站點
445.1
675.6
1066.4
1761.5
2893.2
反應網站
345.8
441.6
690.3
1238.5
1893.6
發送到移動設備的 JavaScript 代碼量
傳輸到桌面設備的 JavaScript 代碼量 (Kb)
百分位數
10
25
50
75
90
所有網站
105.5
226.6
450.4
808.8
1267.3
jQuery 網站
121.7
242.2
458.3
803.4
1235.3
Vue 網站
248.0
420.1
718.0
1122.5
1643.1
角度站點
468.8
716.9
1144.2
1930.0
3283.1
反應網站
308.6
469.0
841.9
1472.2
2197.8
發送到桌面設備的 JavaScript 代碼量
如果我們只討論站點發送到設備的 JS 代碼的大小，那麼一切看起來都如您所料。 也就是說，如果使用其中一個框架，這意味著即使在理想情況下，網站的 JavaScript 代碼量也會增加。 這並不奇怪——您不能將 JavaScript 框架作為站點的基礎，並期望項目的 JS 代碼量會非常低。
該數據的顯著之處在於，某些框架和庫可以被認為是比其他框架和庫更好的項目起點。 使用 jQuery 的網站看起來最好。 在桌面版本的網站上，它們包含的 JavaScript 比所有網站多 15%，而在移動設備上，它們包含的 JavaScript 多 18%。 （不可否認，這裡有一些數據損壞。事實是 jQuery 出現在許多網站上，所以這些網站比其他網站與網站總數的關聯更緊密是很自然的。但是，這並不影響原始的程度為每個框架輸出數據。）
雖然代碼量增加 15-18% 是一個值得注意的數字，但與其他框架和庫相比，可以得出結論，jQuery 徵收的“稅”非常低。 排名第 10 個百分位的 Angular 站點向桌面發送的數據比所有站點多 344%，向移動設備發送的數據多 377%。 React 站點緊隨其後，向桌面發送的代碼比所有站點多 193%，向移動設備發送的代碼多 270%。
前面我提到，雖然使用框架意味著項目中會包含一定數量的代碼，但在開始工作時，我希望框架能夠以某種方式限制開發人員。 特別是，我們正在討論限制最大代碼量。
有趣的是，jQuery 站點遵循這個想法。 雖然它們比第 10 個百分位的所有網站略重（15-18%），但它們在第 90 個百分位的桌面和移動設備上略輕，約為 3%。 這並不是說這是一個非常重要的好處，但可以說 jQuery 站點至少沒有巨大的 JavaScript 代碼大小，即使是在其最大的版本中也是如此。
但是對於其他框架就不能這樣說了。
就像第 10 個百分位的情況一樣，Angular 和 React 上第 90 個百分位的網站與其他網站不同，但不幸的是，它們的差異更糟。
在第 90 個百分位，Angular 站點向移動設備發送的數據比所有站點多 141%，向桌面發送的數據多 159%。 React 站點向桌面發送的郵件比所有站點多 73%，向移動設備發送的郵件多 58%。 第 90 個百分位數的 React 站點的代碼大小為 2197.8 KB。 這意味著此類站點向移動設備發送的數據比基於 Vue 的最接近的競爭對手多 322.9 KB。 基於 Angular 和 React 的桌面站點與其他站點的差距更大。 例如，桌面 React 站點向設備發送的 JS 代碼比同等的 Vue 站點多 554.7 KB。
在主線程中處理 JavaScript 代碼所花費的時間
上述數據清楚地表明，使用所研究的框架和庫的站點包含大量的 JavaScript 代碼。 但當然，這只是我們等式的一部分。
JavaScript 代碼到達瀏覽器後，需要使其進入可工作狀態。 特別是許多問題是由那些必須在主瀏覽器線程中執行代碼的操作引起的。 主線程負責處理用戶操作、計算樣式、構建和顯示頁面佈局。 如果你用 JavaScript 任務壓垮了主線程，它就沒有機會及時完成剩下的任務。 這會導致頁面工作的延遲和“中斷”。
HTTP Archive 數據庫包含有關在 V8 引擎的主線程中處理 JavaScript 代碼需要多長時間的信息。 這意味著我們可以收集這些數據並找出主線程處理各個站點的 JavaScript 所花費的時間。
與移動設備上的腳本處理相關的處理器時間（以毫秒為單位）
百分位數
10
25
50
75
90
所有網站
356.4
959.7
2372.1
5367.3
10485.8
jQuery 網站
575.3
1147.4
2555.9
5511.0
10349.4
Vue 網站
1130.0
2087.9
4100.4
7676.1
12849.4
角度站點
1471.3
2380.1
4118.6
7450.8
13296.4
反應網站
2700.1
5090.3
9287.6
14509.6
20813.3
與移動設備上的腳本處理相關的處理器時間
與桌面設備上的腳本處理相關的處理器時間（以毫秒為單位）
百分位數
10
25
50
75
90
所有網站
146.0
351.8
831.0
1739.8
3236.8
jQuery 網站
199.6
399.2
877.5
1779.9
3215.5
Vue 網站
350.4
650.8
1280.7
2388.5
4010.8
角度站點
482.2
777.9
1365.5
2400.6
4171.8
反應網站
508.0
1045.6
2121.1
4235.1
7444.3
與桌面設備上的腳本處理相關的處理器時間
在這裡你可以看到一些非常熟悉的東西。
對於初學者來說，與其他網站相比，使用 jQuery 的網站在主線程上花費的 JavaScript 處理要少得多。 在第 10 個百分位，與所有網站相比，移動 jQuery 網站在主線程上花費的時間多 61% 來處理 JS 代碼。 對於桌面 jQuery 站點，處理時間增加了 37%。 在第 90 個百分位，jQuery 站點的得分非常接近總分。 具體來說，移動設備上的 jQuery 站點在主線程上花費的時間比所有站點少 1.3%，在桌面設備上花費的時間少 0.7%。
在我們評級的另一邊是主線程負載最高的框架。 這又是 Angular 和 React。 兩者之間的唯一區別是，雖然 Angular 站點向瀏覽器發送的代碼比 React 站點多，但 Angular 站點處理代碼所需的 CPU 時間更少。 遠不及。
在第 10 個百分位，桌面 Angular 站點在主線程處理 JS 代碼上花費的時間比所有站點多 230%。 對於移動網站，這個數字是 313%。 React 網站是表現最差的。 在桌面上，他們處理代碼的時間比所有網站多 248%，在移動設備上多 658%。 658% 不是錯字。 在第 10 個百分位，React 站點花費 2.7 秒的主線程時間來處理它們的代碼。
與這些龐大的數字相比，第 90 個百分位數看起來至少要好一些。 與所有站點相比，Angular 項目在主線程中在桌面設備上花費的時間多 29%，在移動設備上花費的時間多 27%。 在 React 站點的情況下，相同的數字看起來分別是 130% 和 98%。
第 90 個百分位數的百分比偏差看起來比第 10 個百分位數的相似值更好。 但在這裡值得記住的是，指示時間的數字似乎相當可怕。 假設使用 React 構建的網站的主移動線程上有 20.8 秒。 （我認為這段時間實際發生的故事值得單獨寫一篇文章）。
這裡有一個潛在的並發症（感謝 提醒我注意這個特徵，並從這個角度仔細考慮數據）。 事實上，許多網站使用多種前端工具。 特別是，我看到很多網站將 jQuery 與 React 或 Vue 一起使用，因為這些網站正在從 jQuery 遷移到其他框架或庫。 結果，我再次訪問了數據庫，這次只選擇那些與僅使用 React、jQuery、Angular 或 Vue 的站點相對應的鏈接，而不是它們的任何組合。 這是我得到的。
在站點僅使用一個框架或僅一個庫的情況下，與在移動設備上處理腳本相關的處理器時間（以毫秒為單位）
百分位數
10
25
50
75
90
只使用 jQuery 的網站
542.9
1062.2
2297.4
4769.7
8718.2
只使用 Vue 的網站
944.0
1716.3
3194.7
5959.6
9843.8
僅使用 Angular 的網站
1328.9
2151.9
3695.3
6629.3
11607.7
只使用 React 的網站
2443.2
4620.5
10061.4
17074.3
24956.3
在站點僅使用一個框架或僅使用一個庫的情況下，與在移動設備上處理腳本相關的處理器時間
首先，這並不奇怪：當一個網站只使用一個框架或一個庫時，這樣的網站的性能往往會提高。 每個儀器在第 10 個和第 25 個百分位數上表現更好。 這說得通。 使用一個框架製作的網站應該比使用兩個或更多框架或庫製作的網站表現更好。
事實上，所研究的每一種前端工具的性能在所有情況下看起來都更好，除了一個奇怪的例外。 令我驚訝的是，在第 50 個百分位及以上，使用 React 的網站在 React 是他們唯一使用的庫時表現更差。 順便說一下，這就是我在這裡展示這些數據的原因。
這有點奇怪，但我仍然會嘗試為這種奇怪現象尋找解釋。
如果一個項目同時使用 React 和 jQuery，那麼該項目可能處於從 jQuery 到 React 的過渡過程中。 也許它有一個代碼庫，其中混合了這些庫。 由於我們已經看到 jQuery 站點在主線程上花費的時間比 React 站點少，這可能告訴我們在 jQuery 中實現某些功能有助於站點性能更好一些。
但隨著項目從 jQuery 過渡到 React 並更多地依賴 React，事情正在發生變化。 如果網站質量真的很高，並且網站開發人員用心使用 React，那麼這樣的網站就萬事大吉了。 但對於一般的 React 站點來說，大量使用 React 意味著主線程負載過重。
移動設備和桌面設備之間的差距
我查看研究數據的另一個角度是研究在移動和桌面設備上使用網站之間的差距有多大。 如果我們談論比較 JavaScript 代碼量，那麼這樣的比較並沒有揭示出任何可怕的東西。 當然，如果能看到可下載的代碼量更小就好了，但移動端和桌面端的代碼量差別不大。
但如果我們分析處理代碼所需的時間，移動設備和桌面設備之間的巨大差距就會變得顯而易見。
與桌面相比，在移動設備上處理腳本相關的時間（百分比）有所增加
百分位數
10
25
50
75
90
所有網站
144.1
172.8
185.5
208.5
224.0
jQuery 網站
188.2
187.4
191.3
209.6
221.9
Vue 網站
222.5
220.8
220.2
221.4
220.4
角度站點
205.1
206.0
201.6
210.4
218.7
反應網站
431.5
386.8
337.9
242.6
179.6
雖然手機和筆記本電腦之間的代碼處理速度存在一些差異是意料之中的，但如此大的數字告訴我，現代框架並沒有充分針對低功率設備，並且他們正在努力縮小他們發現的差距。 即使在第 10 個百分位，React 站點在移動主線程上花費的時間也比桌面主線程多 431.5%。 jQuery 的差距最小，但即使在這裡，相應的數字也是 188.2%。 當網站開發人員以這樣的方式製作他們的項目時，他們的處理需要更多的處理器時間（這種情況確實發生了，而且隨著時間的推移只會變得更糟），低功率設備的所有者必須為此付出代價。
結果
好的框架應該為開發人員構建 Web 項目提供良好的基礎（在安全性、可訪問性、性能方面），或者它們應該有內置的限制，使得構建違反這些限制的東西變得困難。
這似乎不適用於 Web 項目的性能（並且可能不適用於他們的 ).
值得注意的是，僅僅因為 React 或 Angular 站點比其他站點花費更多的 CPU 時間來準備代碼並不一定意味著 React 站點在運行時比 Vue 站點佔用更多的 CPU。 事實上，我們審查的數據很少說明框架和庫的運行性能。 他們更多地談論這些框架有意或無意地推動程序員的開發方法。 我們正在談論框架的文檔、它們的生態系統、通用的開發技術。
還值得一提的是我們沒有在這里分析的東西，即設備在站點頁面之間導航時執行 JavaScript 代碼所花費的時間。 支持 SPA 的論點是，一旦將單頁應用程序加載到瀏覽器中，理論上用戶將能夠更快地打開網站頁面。 我自己的經驗告訴我，這遠非事實。 但我們沒有數據來澄清這個問題。
顯而易見的是，如果您使用框架或庫來創建網站，那麼您在初始加載項目和準備運行方面做出了妥協。 這甚至適用於最積極的情況。
在適當的情況下完全可以做出一些妥協，但重要的是開發人員有意識地做出這樣的妥協。
但我們也有樂觀的理由。 我很高興看到 Chrome 開發人員與我們審查過的一些前端工具的開發人員密切合作，以幫助提高這些工具的性能。
然而，我是一個務實的人。 新架構產生性能問題的頻率與解決性能問題的頻率一樣高。 修復錯誤需要時間。 正如我們不應該期望的那樣 將解決所有性能問題，你不應該期望我們最喜歡的框架的新版本。
如果您想使用本文中討論的前端工具之一，這意味著您將不得不付出額外的努力，同時不損害項目的性能。 以下是開始新框架之前需要考慮的一些注意事項：
- 用常識測試自己。 您真的需要使用所選的框架嗎？ 今天的純 JavaScript 可以做很多事情。
- 是否有比所選框架更輕巧的替代方案（如 Preact、Svelte 或其他）可以為您提供該框架 90% 的功能？
- 如果您已經在使用框架，請考慮是否有提供更好、更保守、標準選項的東西（例如，Nuxt.js 代替 Vue，Next.js 代替 React，等等）。
- 你會怎樣 JavaScript 性能？
- 你怎麼 一個開發過程使得向項目中註入比絕對必要更多的 JavaScript 代碼變得更加困難？
- 如果您使用易於開發的框架，請考慮 將框架代碼發送給客戶。 也許您可以解決服務器上的所有問題？
通常這些想法都值得一看，不管你為前端開發選擇了什麼。 但是，當您從事的項目從一開始就缺乏績效時，它們尤其重要。
親愛的讀者！ 您如何看待理想的 JavaScript 框架？
來源： www.habr.com