JavaScript フレームワークの価格

Web サイトの速度を低下させるには、Web サイト上で大量の JavaScript コードを使用することより手っ取り早い方法はありません (冗談です)。 JavaScript を使用する場合、プロジェクトの XNUMX 倍以上のパフォーマンスに応じて料金を支払う必要があります。 サイトの JavaScript コードがユーザーのシステムをロードする方法は次のとおりです。

• ネットワーク経由でファイルをダウンロードする。
• ダウンロード後に解凍されたソース コードを解析してコンパイルします。
• JavaScript コードの実行。
• メモリ消費量。

この組み合わせが判明 非常に高価な.

そして、私たちはプロジェクトにますます多くの JS コードを含めます。 組織が React、Vue などのフレームワークやライブラリを利用したサイトに移行するにつれて、サイトのコア機能が JavaScript に大きく依存するようになりました。

JavaScript フレームワークを使用した非常に重いサイトをたくさん見てきました。 しかし、この問題に対する私の見方は非常に偏っています。 実際のところ、私が協力している企業は、まさにサイトのパフォーマンスの分野で複雑な問題に直面しているからこそ、私に頼ってくるのです。 その結果、私は、この問題がどの程度一般的であるか、また、特定のサイトの基盤として XNUMX つまたは別のフレームワークを選択した場合にどのような「ペナルティ」が支払われるのかについて興味を持つようになりました。

このプロジェクトは私がこれを理解するのに役立ちました。 HTTPアーカイブ.

データ

HTTP アーカイブ プロジェクトでは、通常のデスクトップ サイトへのリンクが合計 4308655 件、モバイル サイトへのリンクが 5484239 件追跡されています。 これらのリンクに関連付けられた多くの指標の中には、それぞれのサイトで見つかったテクノロジーのリストがあります。 これは、さまざまなフレームワークやライブラリを使用する何千ものサイトをサンプリングし、クライアントに送信されるコードの量と、このコードがユーザーのシステムに与える負荷の量を知ることができることを意味します。

私がアクセスできた最新のデータである 2020 年 XNUMX 月のデータを収集しました。

他のソース マテリアルを使用することも検討しましたが、すべてのサイトの集約された HTTP アーカイブ データを、React、Vue、Angular を使用して見つかったサイトのデータと比較することにしました。

さらに面白くするために、jQuery を使用するサイトをソース データ セットに追加しました。 この図書館は今でも非常に人気があります。 また、React、Vue、Angular が提供するシングル ページ アプリケーション (SPA) モデルとは異なる Web 開発アプローチも導入しています。

対象となるテクノロジーを使用していることが判明したサイトを表す HTTP アーカイブ内のリンク

フレームワークまたはライブラリ
モバイルサイトへのリンク
通常のサイトへのリンク

jQueryの
4615474
3714643

反応する
489827
241023

ヴュー
85649
43691

角度の
19423
18088

希望と夢

データ分析に入る前に、私が期待したいことについてお話したいと思います。

理想的な世界では、フレームワークは開発者のニーズを満たすだけでなく、サイトを使用する平均的なユーザーに何らかの特定の利点を提供する必要があると私は信じています。 パフォーマンスはそれらの利点の XNUMX つにすぎません。 ここでアクセシビリティとセキュリティが重要になります。 しかし、これは最も重要なことだけです。

したがって、理想的には、何らかのフレームワークを使用して、高パフォーマンスのサイトを簡単に作成できるようにする必要があります。 これは、フレームワークが開発者にプロジェクトを構築するための適切な基盤を提供するという事実、またはフレームワークが開発に制限を課し、その要件を提示して、何かを変えるものの開発を複雑にするという事実により、これを行う必要があります。遅くなるように。

最良のフレームワークは、適切なベースを提供することと、作業に制限を課すことの両方を行うことで、適切な結果を達成できるようにする必要があります。

データの中央値を分析しても、必要な情報は得られません。 そして実際、このアプローチでは私たちの注意が逸れてしまいます。 たくさんの重要な。 代わりに、私は手持ちのデータからパーセンテージを導き出しました。 これらは、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 

Angular サイト
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 

Angular サイト
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 を使用したサイトが最も見栄えが良くなります。 デスクトップ版のサイトでは、すべてのサイトに比べて 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 サイトは、同等の Vue サイトよりも 554.7 KB 多くの JS コードをデバイスに送信します。

メインスレッドでの JavaScript コードの処理にかかる時間

上記のデータは、調査対象のフレームワークとライブラリを使用しているサイトに大量の JavaScript コードが含まれていることを明確に示しています。 しかし、もちろん、それは方程式の一部にすぎません。

JavaScript コードがブラウザに到着したら、それを実行可能な状態にする必要があります。 特に多くの問題は、ブラウザのメイン スレッド内のコードを使用して実行する必要があるアクションによって発生します。 メイン スレッドは、ユーザー アクションの処理、スタイルの計算、ページ レイアウトの構築と表示を担当します。 JavaScript タスクでメインスレッドを圧倒すると、残りのタスクを時間内に完了することができなくなります。 これにより、ページの作業に遅れが生じ、「ブレーキ」がかかります。

HTTP アーカイブ データベースには、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

Angular サイト
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

Angular サイト
482.2
777.9
1365.5
2400.6
4171.8

反応サイト
508.0
1045.6
2121.1
4235.1
7444.3

デスクトップデバイスでのスクリプト処理に関連するプロセッサ時間

ここでは非常に見慣れたものを見ることができます。

まず、jQuery を使用するサイトは、他のサイトに比べてメインスレッドでの JavaScript 処理に費やす時間が大幅に少なくなります。 10 パーセンタイルでは、すべてのサイトと比較して、モバイル上の jQuery サイトはメインスレッドでの JS コードの処理に 61% 多くの時間を費やしています。 デスクトップ jQuery サイトの場合、処理時間は 37% 増加します。 90 パーセンタイルでは、jQuery サイトのスコアは集計スコアに非常に近くなります。 具体的には、モバイル デバイス上の jQuery サイトは、すべてのサイトに比べてメイン スレッドに費やす時間が 1.3% 少なく、デスクトップ デバイス上の時間が 0.7% 少なくなります。

私たちの評価の反対側にあるのは、メインスレッドの負荷が最も高いことを特徴とするフレームワークです。 これも、Angular と React です。 XNUMX つの唯一の違いは、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 で構築された Web サイトのメイン モバイル スレッドで 20.8 秒だったとします。 （この間に実際に何が起こったのかについては、別の記事に書く価値があると思います）。

ここには潜在的な複雑な問題が XNUMX つあります (ありがとう エレミヤ この特徴に私の注意を促し、この観点からデータを慎重に検討していただきました)。 実際、多くのサイトでは複数のフロントエンド ツールが使用されています。 特に、jQuery から他のフレームワークやライブラリに移行しているサイトで、React や Vue と併用して jQuery を使用しているサイトを多く見てきました。 その結果、データベースに再度アクセスし、今回は React、jQuery、Angular、または Vue のみを使用し、それらの組み合わせを使用しないサイトに対応するリンクのみを選択しました。 これが私が得たものです。

サイトが XNUMX つのフレームワークまたは XNUMX つのライブラリのみを使用する状況で、モバイル デバイスでのスクリプトの処理に関連するプロセッサ時間 (ミリ秒)

パーセンタイル
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

サイトが XNUMX つのフレームワークまたは XNUMX つのライブラリのみを使用する状況で、モバイル デバイスでのスクリプトの処理に関連するプロセッサ時間

まず、驚くべきことではありませんが、サイトで 10 つのフレームワークまたはライブラリだけを使用すると、そのようなサイトのパフォーマンスは頻繁に向上します。 各機器は 25 パーセンタイルと XNUMX パーセンタイルでより優れたパフォーマンスを発揮します。 それは理にかなっている。 XNUMX つのフレームワークを使用して作成されたサイトは、XNUMX つ以上のフレームワークまたはライブラリを使用して作成されたサイトよりもパフォーマンスが高くなります。

実際、調査した各フロントエンド ツールのパフォーマンスは、50 つの興味深い例外を除いて、すべてのケースで向上しているように見えます。 私が驚いたのは、React を使用するサイトが使用するライブラリが React だけである場合、XNUMX パーセンタイル以上でパフォーマンスが低下することです。 ちなみに、これが私がこのデータをここで紹介する理由です。

これは少し奇妙ですが、この奇妙さの説明を探してみます。

プロジェクトで React と jQuery の両方を使用している場合、そのプロジェクトは jQuery から React への移行の途中にある可能性があります。 おそらく、これらのライブラリが混在したコードベースがあると思われます。 jQuery サイトは React サイトよりもメイン スレッドに費やす時間が短いことがすでにわかっているため、jQuery にいくつかの機能を実装するとサイトのパフォーマンスが少し向上することがわかります。

しかし、プロジェクトが jQuery から React に移行し、React への依存度が高まるにつれて、状況は変わりつつあります。 サイトが本当に高品質で、サイト開発者が React を慎重に使用している場合、そのようなサイトではすべてがうまくいきます。 しかし、平均的な React サイトでは、React が広範囲に使用されるということは、メインスレッドに大きな負荷がかかることを意味します。

モバイルデバイスとデスクトップデバイスの間のギャップ

私が調査データを検討したもう XNUMX つの観点は、モバイル デバイスとデスクトップ デバイスでサイトを操作する際にどれだけの差があるかを調査することでした。 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

Angular サイト
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 プロジェクトを構築するための優れた基盤 (セキュリティ、アクセシビリティ、パフォーマンスの点で) を提供するか、制限に違反するものを構築するのを困難にする組み込みの制限を備えている必要があります。

これは、Web プロジェクトのパフォーマンスには当てはまらないようです (おそらく、Web プロジェクトのパフォーマンスにも当てはまらないでしょう) 利用可能).

React サイトや Angular サイトがコードの準備に他のサイトよりも多くの CPU 時間を費やしているからといって、必ずしも React サイトの実行中に Vue サイトよりも CPU 使用率が高いことを意味するわけではないことに注意してください。 実際、私たちが調査したデータは、フレームワークやライブラリの運用パフォーマンスについてはほとんど何も語っていません。 彼らは、意識的かどうかにかかわらず、これらのフレームワークがプログラマーを後押しできる開発アプローチについて詳しく話します。 私たちはフレームワークのドキュメント、そのエコシステム、一般的な開発手法について話しています。

また、ここでは分析しなかった点、つまり、サイトのページ間を移動するときにデバイスが JavaScript コードの実行に費やす時間についても言及する価値があります。 SPA を支持する議論は、シングル ページ アプリケーションがブラウザに読み込まれると、理論的にはユーザーはより速くサイトのページを開くことができるようになるということです。 私自身の経験から、これは事実とは程遠いことがわかります。 しかし、この問題を解明するためのデータはありません。

明らかなことは、フレームワークまたはライブラリを使用して Web サイトを作成している場合、プロジェクトを最初にロードして準備を整えるという点で妥協していることになります。 これは最も前向きなシナリオにも当てはまります。

適切な状況である程度の妥協をすることは完全に可能ですが、開発者が意識的にそのような妥協を行うことが重要です。

しかし、楽観視できる理由もあります。 私たちがレビューしたいくつかのフロントエンド ツールのパフォーマンス向上に向けて、Chrome 開発者がその開発者とどれだけ緊密に連携しているのかを見るのが楽しみです。

しかし、私は現実的な人間です。 新しいアーキテクチャは、パフォーマンスの問題を解決すると同時に、パフォーマンスの問題も引き起こします。 そしてバグ修正には時間がかかります。 期待してはいけないのと同じように、 新しいネットワーク技術 パフォーマンスの問題はすべて解決されますが、お気に入りのフレームワークの新しいバージョンにこれを期待しないでください。

この記事で説明したフロントエンド ツールのいずれかを使用したい場合は、それまでの間、プロジェクトのパフォーマンスに悪影響を及ぼさないように特別な努力をする必要があることを意味します。 新しいフレームワークを開始する前に考慮すべき考慮事項がいくつかあります。

• 常識に基づいて自分自身をテストしてください。 選択したフレームワークを本当に使用する必要がありますか? 今日の純粋な JavaScript は多くのことが可能です。
• このフレームワークの機能の 90% を提供できる、選択したフレームワーク (Preact、Svelte など) に代わる軽量の代替手段はありますか?
• すでにフレームワークを使用している場合は、より優れた、より保守的な標準オプションを提供するものがあるかどうかを検討してください (たとえば、Vue の代わりに Nuxt.js、React の代わりに Next.js など)。
• あなたは何をしますか 予算 JavaScriptのパフォーマンス?
• どのようにできますか 制限する 絶対に必要な以上の JavaScript コードをプロジェクトに挿入することを困難にする開発プロセスですか?
• 開発を容易にするためにフレームワークを使用している場合は、次の点を考慮してください。 必要ですか フレームワーク コードをクライアントに送信します。 サーバー上のすべての問題を解決できるでしょうか?

通常、フロントエンド開発に正確に何を選択したかに関係なく、これらのアイデアは検討する価値があります。 しかし、最初からパフォーマンスが不十分なプロジェクトに取り組んでいる場合、これらは特に重要です。

親愛なる読者！ 理想的な JavaScript フレームワークとはどのようなものだと思いますか?

出所： habr.com