2024年のJavaScript肥大化

JavaScriptの肥大化問題

• 現代のフロントエンド開発にはやや疎く、ウェブページのサイズが数MBに達するウェブの肥大化に関する記事を覚えていた。
• 平均的なウェブページのサイズが3MBなら、JavaScriptバンドルはおよそ1MB程度だろうという印象を持っていた。
• 実際にどのくらいなのか確認するため、実験を行った。

方法

• macOSでFirefoxを使用（他のブラウザでも同じはず）
• シークレットモードではなく通常モード（アプリ内の数値を見たく、実際の体験により近いと考えたため）
• すべての拡張機能を無効化
• JavaScriptのみを測定
• 非圧縮の状態
• サービスワーカーを有効化（より現実的な状況のため）
• すべてのキャッシュを無効化（最初から読み込み）

ランディングページ

• 一般的な、多少のインタラクションがあるページの例: Wikipedia、0.2MB
• やや肥大化したページの例: Linear、3MB
• ひどいランディングページの例: Zoom、6MB; Vercel、6MB; Gitlab、13MB

主に静的なウェブサイト

• 静的なテキストの壁を表示するより単純なものはない。
• Mediumはそれだけのために3MBが必要。
• Substackは4MB、Quoraは4.5MB、Pinterestは10MB、Patreonは11MBが必要。

検索

• アプリのインタラクションは主に検索に限定される。
• StackOverflowは3.5MB、NPMは4MB、Airbnbは7MB、Booking.comは12MBが必要。
• Googleは単純なテキストフィールドとリンク一覧を表示するのに9MBが必要。

単一インタラクションのアプリ

• Google Translateは2つのテキストボックスのために2.5MBが必要。
• ChatGPTは1つのテキストボックスのために7MBが必要。

動画

• Loomは7MB、YouTubeは12MBが必要。
• Pornhubはパフォーマンスを気にするサイトで、1.4MBしか必要としない。

オーディオ

• SoundCloudとSpotifyはどちらも12MBが必要。

メール

• Google Mailは20MBが必要。
• FastMailは同じ機能を提供しながら、2MBしか必要としない。

生産性

• Todoistは9MB、Dropboxは10MB、1Passwordは13MB、Trelloは13.5MBが必要。
• Discordはチャットのために21MBが必要。

文書編集

• Google Docsは13.5MB、Notionは16MBが必要。

ソーシャルネットワーク

• Twitterは11MB、Facebookは12MB、TikTokは12.5MB、Instagramは16MB、LinkedInは31MBが必要。

巨大カテゴリー

• Jiraはほぼ50MB、Slackは55MBが必要。
• react.devは最初は2MBで始まるが、スクロールすると無限に大きくなりうる。

ますます急速に悪化しているのか？

• 2015年の平均的なウェブページサイズは、Doom 1のシェアウェア版（2.5MB）に近かった。
• 2024年にはSlackが55MBを占め、これはJavaScriptだけでオリジナルのQuake 1と同じサイズである。

10MBはどれほど大きいのか？

• 10MBはもはやそれほど大きくも特別にも感じられない。
• 平均して1行65文字と仮定すると、各ウェブサイトごとに約15万行のコードを送信していることになる。
• Google Mapsは現代の基準では比較的控えめな4.5MBである。

結論

• 問題はダウンロードサイズだけではない。
• JavaScriptはブラウザがパースし、メモリに保持し、実行しなければならない。
• コンテンツはコードサイズを上回るべきだと考えている。
• Gitlabは静的なランディングページを表示するために13MBのコード、50万行超のJSを必要とする。

GN⁺の意見:

1. ウェブ開発の現状に対する現実的な診断であり、ウェブサイトのJavaScriptサイズがユーザー体験とパフォーマンスに与える影響を理解する助けになる。
2. フロントエンド開発者に最適化の重要性を思い出させ、必要以上のリソースを使わないよう注意を促す。
3. ウェブサイトのパフォーマンスに関して、開発者コミュニティ内で議論を促進しうる興味深いデータを提供している.

[GN⁺]

Hacker Newsの意見

• アダルトサイトは実際にパフォーマンスを気にしている例で、Pornhubはわずか1.4MBのデータしか読み込まない。これは一部の巨大テック企業が見せるパフォーマンスよりはるかに優れている。Pornhubは基本的なUI/UXやコンテンツ配信で失敗することがほとんどない。
• ニュージーランドの地方でローミングサービスを使っていた際、Webの利用体験は非常に不快だった。Spotifyのオフライン時のユーザー体験（UX）も改善が必要だ。
• なぜ圧縮されていないデータを見ているのかという疑問がある。SpotifyやGmailのような動的アプリは、ページ読み込み後に高速に操作できるのであれば許容できる。一部のサイトは初期読み込みばかりに注力し、ユーザー体験を損ねている。
• ソフトウェアはそれを作った組織を反映する。データ転送の大半は、実際にページを動作させるために必要なJavaScriptではなく、分析用やサードパーティ製スクリプトだ。マーケティングチームはこうした点に無知であるか、関心がない。
• WebアプリケーションのJavaScriptファイルサイズに関する分析が欠けていた。たとえばGoogle Translateは単純なインタラクティブアプリではなく、多くの機能を含んでいるにもかかわらず、2.5MBは依然として過大だ。
• Wordsandbuttons.onlineのすべてのページは、アニメーションやインタラクションがあるにもかかわらず64KB未満だ。これはサードパーティ依存を持たない方針のおかげだ。
• JavaScriptの過剰使用だけでなく、トラッキングスクリプトの量についても議論する必要がある。
• 人気サイトが読み込むJavaScriptの量を比較している。たとえばPornhubはYouTubeより約10倍少ないJavaScriptしか読み込まない。
• 現在のWebの状態は非常に悲しい。高速なインターネット接続を使っている人たちは、Webがどれほど遅くなったかを認識していない。広告・トラッカーのブロッカーを使わないという選択は考えられない。
• 複雑なフレームワークや抽象化を作って保守を容易にしようとしているが、多くの開発者はJavaScriptの基礎すら分かっていない。Webアプリケーションを過剰にエンジニアリングし、実際の言語を隠すレイヤーを作りすぎている。JavaScriptそのものを学び、フレームワークではなく素のJavaScriptを使えば、JavaScriptコードベースを大幅に減らせる。