- 実際のコンテンツよりはるかに大きい非圧縮JavaScriptをWebページが配信するケースが一般的になり、単純なランディングページから業務アプリまでブラウザの負担が増している
- 計測はFirefox on macOSで拡張機能とキャッシュを無効にし、JavaScriptのみを集計して、画像・動画・スタイルを除いたコード実行コストに焦点を当てている
- Wikipediaは0.2MBだった一方で、Linear 3MB、Zoom・Vercel 6MB、GitLab 13MBのように、単純なページでも数MBから2桁MBまで増えている
- アプリ領域ではGmail 20MBとFastMail 2MBで10倍の差があり、Jira約50MBやSlack 55MBのようにチャット・業務ツールのコード量が特に大きい
- JavaScriptはダウンロード後もパース・メモリ保持・実行のコストを発生させるため、小さなコンテンツを表示するだけなのに巨大なコードバンドルを必要とする構造は、性能とバッテリーに直接負担をかける
計測方法と比較基準
- 計測環境はFirefox on macOSで、ブラウザが違ってもおおむね似た結果になるという前提で進められている
- 条件は次の通り
- シークレットモードではない通常モード
- すべての拡張機能を無効化
- JavaScriptのみを計測
- 非圧縮サイズ基準
- Service Worker有効
- キャッシュを無効化したコールドロード
- コンテンツはサイトごとの差が大きいため比較対象から除外
- YouTubeの動画とSlackのテキストメッセージでは本質的にサイズが異なる
- JavaScriptはインタラクションの複雑さを比較するための共通指標として使われている
- 重要なのは、ブラウザがコードをパースして実行するために負担する作業量である
- 基準点として、tonsky.meのブログ自体は0.004MBと計測された
ランディングページと静的コンテンツ
- 多少のインタラクションがある一般的なページの例では、Wikipediaは0.2MB程度である
- より重いランディングページは次の通り
- Linear: 3MB
- Zoom: 6MB
- Vercel: 6MB
- GitLab: 13MB
- これらの数値は、画像・動画・スタイルを除いたJavaScriptコードのみのサイズである
- 静的テキストを表示するWebサイトでも数MBのJavaScriptを配信している
- Medium: 3MB
- Substack: 4MB
- Quora: 4.5MB
- Pinterest: 10MB
- Patreon: 11MB
- 静的ページでも実現できそうなコンテンツ表示に、大きなJavaScriptバンドルが使われている例がある
検索と単純なインタラクティブアプリ
- 検索中心のアプリはクエリ入力と結果一覧の表示が中心だが、JavaScriptサイズは小さくない
- StackOverflow: 3.5MB
- NPM: 4MB
- Airbnb: 7MB
- Booking.com: 12MB
- Google検索はテキストフィールドとリンク一覧が中心の画面であるにもかかわらず、9MBと計測された
- 単純な入力UIを持つサービスでも数MBのJavaScriptを使っている
- Google Translate: 2.5MB
- ChatGPT: 7MB
- ChatGPTの複雑さがサーバー側にあることとは別に、ブラウザには7MBのJavaScriptが配信される
メディアサービスとメール
- 動画サービスのJavaScriptサイズは次の通り
- Loom: 7MB
- YouTube: 12MB
- Pornhub: 1.4MB
- オーディオサービスではSoundCloudとSpotifyがそれぞれ12MB程度と計測された
- メールサービスでは差が大きく開く
- Google Mail: 20MB
- FastMail: 2MB
- FastMailは同じメールサービスのカテゴリでGoogle Mailより10倍少ないJavaScriptを使っている
- Google Mailの20MBは、FigmaのようにカスタムC++/OpenGLレンダリングを含むアプリと比較できるほど大きい数値である
生産性ツールと文書編集
- 生産性アプリも単純な作業に対してJavaScriptが大きい
- Todoist: 9MB
- Dropbox: 10MB
- 1Password: 13MB
- Trello: 13.5MB
- Discord: 21MB
- Dropboxはフォルダ内ファイル一覧、1Passwordはパスワード一覧、Trelloはカード表示のような作業にそれぞれ10MB以上を使っている
- 文書編集サービスは2桁MBの水準である
- Google Docs: 13.5MB
- Notion: 16MB
- 文書編集にはカーソル移動や同期のような難しい機能があるが、比較対象サービスのJavaScriptサイズは依然として大きい
ソーシャルネットワークと超大型の事例
- ソーシャルネットワークは「いいね」、フィード、メッセージングなどのため、おおむね12MB前後のJavaScriptを使っている
- Twitter: 11MB
- Facebook: 12MB
- TikTok: 12.5MB
- Instagram: 16MB
- LinkedIn: 31MB
- LinkedInはブログ、プラットフォーム、検索、メッセージング、ソーシャル機能をすべて含み、31MBと計測された
- 非常に大きいWebアプリの例は別カテゴリに近い
- Slackはユーザー一覧、メッセージ、リアクションを扱うチャットアプリだが、55MBのJavaScriptを配信している
- react.dev は最初は2MBで始まるが、スクロールを繰り返すとJavaScriptが増え続ける現象が観察された
- 例として100MBまで増やせた
- アップデートによれば、通常のユーザー体験では埋め込みコードエディタが初回ロード後にキャッシュされ、その後のネットワークトラフィックは見えない
- ただしスクロール時には100MBのJavaScriptが継続的にパース、評価、初期化されうる
10MBのコードが意味するもの
- 2015年の平均WebページサイズはDoom 1シェアウェア版の2.5MBに近づいていた
- 2024年のSlackはJavaScriptだけで、オリジナルのQuake 1全リソースサイズである55MBに達している
- 10MBのコードが一般的な水準のように見えるが、平均的なコード1行を65文字と仮定すると約15万行に相当する
- このコードはすでにminifyされているため、元のソース基準では30万行以上である可能性がある
- Google MapsはSPAの代表例として挙げられるが4.5MBと計測され、現代のWebアプリ基準ではむしろ小さい部類として比較される
- Figmaは複雑なフロントエンドアプリなのでJavaScriptのダウンロードサイズが大きいのは自然だが、GmailはFigmaと同程度で、LinkedInは1.5倍、Slackは2.5倍の水準である
ブラウザが支払うコスト
- 問題はダウンロードサイズだけでは終わらない
- JavaScriptはブラウザがパースし、メモリに保持し、実行しなければならないため、継続的なコストを生む
- コンテンツサイズはコードサイズより大きくあるべきという基準で見ると、1万文字のブログ記事を表示するために1000倍大きいJavaScriptが必要な構造は過剰である
- 良い例として挙げられたサイトは、0.1MBのJavaScriptだけで十分に動作する
- 同じWeb環境で、GitLabは静的なランディングページ表示のために13MB、約50万行以上のJavaScriptを必要とする事例として比較される
1件のコメント
Hacker Newsのコメント
10MB、12MBみたいなものと、本気でパフォーマンスを気にしている Pornhub 1.4MB を比較すればよい
ポルノサイトは昔から実際のウェブのハイテクであり、エンジニアリングもしっかりしていた。冗談みたいな「テック」大企業とは違っていた
基本的なUI/UX、コンテンツ配信、常識的な設計を台無しにした記憶はほとんどない
実際のウェブアプリケーションではページ再読み込みが望ましくない動作だという理由だけで、突然みんながウェブサイトのページ再読み込みを恐れるようになった感じがする
20年間企業向けアプリケーションを扱ってきて、生まれる前に作られたシステムも見てきたが、React はそうしたシステムでは以前のひどいクライアント/サーバーUIを置き換える最高のフロントエンドだったと思う
Angular/Vue なども同じ文脈だ。しかし一般的なウェブページでは、Gmail や Facebook のようにインタラクションやリアルタイム更新が製品の中核でない限り、ほとんど必要ない
Pornhub のようなサイトなら PHP でも十分で、たいていのウェブサイトも同様だ。いまでも HN や old.reddit.com を好む人が多いことを見れば分かるし、遅くなった新しい Facebook より old.Facebook を好む人も多いだろう
ポップアップ、ポップアンダー、偽コンテンツで似た集計サイトに飛ばす、コンテンツの代わりにアフィリエイトサイトを開く、検索結果を汚染する、といったものだ
ポルノは人々が言うほど技術を牽引する産業ではなく、Betamax 対 VHS に関する都市伝説も事実ではないし、インターネットの革新を主導したという話も誇張だ
高品質な製品を作るプレイヤーは一部にいるが、業界全体を代表してはいない。リンクファーム、ダミーコンテンツ、複製サイト、虚偽広告、検索結果の操作が多い
いま上位サイトがキビキビしているのは 競争の結果 に見える。UX が悪ければ無料ポルノはいくらでもあるので、ユーザーはすぐ別の場所へ行ってしまい、そのため継続利用率を保つために最適化しなければならない
他のウェブサイトには株主、コンテンツ提供者、独占契約、独占的地位といった別のインセンティブがあり、そこまでユーザー体験を最適化しなくても済む
動画配信、ライブ配信（昔は Flash、今は WebRTC）、ページサイズなど、あらゆるものを最適化するのに数え切れないほどの時間を費やす
なぜ 圧縮前データ を見ているのか気になる。悪い例として挙げられていたいくつかのサイトも、圧縮すれば GMaps の 1.5MB より簡単に小さくなる
Spotify や GMail のような動的アプリは、ページ読み込み後のナビゲーションが速いなら問題ないと思う
起動時の更新に数秒かかる Discord のようなもののほうが、クリックするたびに最大 2 秒待たされる GitLab よりましだ
最近のコールドスタートや静的レンダリング優先の流れは、一部のサイトではかえって体験を悪化させていると思う
試しに GitHub でファイルツリーをたどってみると、自分の端末では GitHub の他の部分よりずっとキビキビしている。偶然にも、この部分は静的レンダリングではないほぼ唯一の部分の一つだ
毎日何百もの GitHub ページをクリックしているが、パイプラインを一つ見るために毎回フッター全体を取り直させるのではなく、一度大量の JavaScript を送って、できる限り多くをキャッシュしてほしい
[1]: GMail と Spotify は例として挙げただけで、実際には使っていない
アクセシビリティの議論でこの問題はよく出てくるが、iOS と Android の CPU 性能差は大きく、大衆がよく使う低価格端末まで含めると、今日売られている新しい Android 端末が 2014 年の iPhone より遅いことすらある
開発者が最新の iPhone やフラッグシップ Android しか使っていないと、コード肥大化が一般ユーザーにどれほど大きな影響を与えるかを見落としやすい
https://infrequently.org/2024/01/performance-inequality-gap-...
キャッシュはダウンロードと展開にかかる電力・時間コストは減らせても、実際の使用コストまではなくせない
個人的な経験則では、圧縮前 JavaScript が大きいほど、マウスを動かしたりキーを押したりスクロールしたりするたびに CPU が回し続けるコードが増える
少し時間効率を犠牲にしてでも電力効率を得るほうがよく、CSS で代替できるところでは派手な動きより静的なほうを好む
あるいは本当にもっと大きな問題は、クリックで URL が別ページに移動する場合以外にも、さまざまな操作で追加ファイルをダウンロードするサイトかもしれない。これは隠れた肥大化であり、アーカイブにも非常に悪い
JavaScript でアドレスバーの URL はそのままなのに別の「ページ」が表示されるようにはしてほしくない。これもアーカイブには本当に悪い
もう一つの経験則として、圧縮前 JavaScript が大きいほど、保存されたサイトのバージョンが正しく動作する可能性は低くなる
先週インターネットが遅かったのだが、GitHub のウェブサイトでファイルをクリックするとスクリプトで読み込もうとして失敗し、ファイルツリーが文字通り使えなかった
代わりにファイルの URL をコピーしてブラウザのアドレスバーに貼り付けると、正しく読み込まれた
Spotify はネットワーク接続性の問題が大きい。アルバムをダウンロードしていても、ネットワークが変わると完全にパニック状態になる。オンライン状態を維持しようとし続けるより、単にオフラインモードのほうがよい
それを見てそのアーキテクチャ全体を判断するのは難しく、とてもひどい SPA を一つ指して、すべての SPA がよくないと言うのと似ている
あらゆるソフトウェアは、それを作った組織のあり方を反映する
転送されるデータの大半は、ページの動作に実際に必要なJavaScriptではなく、分析ツールや各種サードパーティ製スクリプトである可能性が高い
「elephant」カテゴリだけが、Reactのような遅延読み込みモジュールに当てはまる
こうしたものの多くは、この問題を知らないか気にしていないマーケティングチームが主導している
開発者はGoogle Tag Managerや他のスクリプト挿入サービスをページに付けただけ、という場合が多い。場合によっては開発者ですらそれを行っておらず、運用インフラのプロキシがページを改変している
より重要な懸念は、実際に仕事をする人たちよりもマーケティングのほうが成果物に対して大きな統制権を持っていることかもしれない
「elephant」ページの場合、肥大化は組織そのものにある。何人かの愚か者ではなく、スケールした愚かさの問題だ
前職では非技術部門がGoogle Tag Managerを握っていて、本番ページに注入されるゴミを監視し続けなければならなかった
排除しようと本気で戦った
検索のGoogleはYahooよりそうだったし、Chromeも登場当時はIE/Firefoxよりそうだった
Chrome自体はUIがほとんどなく、それが機能だった
最近ニュージーランドのロードトリップから帰ってきたが、地方のかなりの地域では携帯の電波がほとんどないか、まったくない
ローミングまで重なるとさらに一段遅くなる感じで、多くのWebを使うのが本当につらかった
SpotifyのPMがいるなら、オフラインUXを見直してほしい。オフラインはプレミアムの中核機能の一つなのに、実際にアプリをオフラインで使おうとするといろいろな面でひどすぎる
Spotifyはインターネットがあると判断すると、すべてのコンテキストメニュー内容をサーバーに問い合わせ、数秒間応答を待った末、あるときはメニュー表示を諦め、あるときはオフラインモードなら即座にできた操作へ戻る
このプレイヤーは本当に嫌いだ
レイテンシが非常に高い、あるいは損失が多い中間状態では、実際にはオフラインのように振る舞うべきなのに、Spotifyはオンラインだと思っている
ただ、こういう問題は非常によくあり、Spotifyだけが失敗しているわけではなく、適切なしきい値を決めるのは難しいのだろう
Spotifyはなぜ、電波がないときにアプリが何かを読み込むのを30秒も待たせるのかわからない。ダウンロード済みのポッドキャストをそのまま聴き続けたいだけなのに
どんなエンジニアリング上の判断のせいで、この種のシナリオの重み付けがそこまで複雑になったのか気になる
この記事は特に、実際のWebアプリケーションでJavaScriptファイルがなぜそこまで大きいのかを分解して見ていない、という点を完全に見落としている
たとえばGoogle Translateは、よく見れば一度やり取りして終わるだけのアプリではない。辞書、代替候補、音訳、発音、複数の入力方式などがある
そうした点を考慮しても2.5MBは大きすぎるし、一部の選択的機能は遅延読み込みできるし、そうすべきだと思うが、今の文章は怠惰すぎて、より深い議論の助けにはあまりならない
if data.transliteration show icon with audio embedにどれだけのJavaScriptが必要だというのか？画像が大きくて数も多かったのだろうし理解はできるが、少し皮肉ではあった
ここでの含意が「JavaScriptが多すぎる」だというのはわかるが、そのうちどれだけが純粋な追跡用のゴミなのかも語るべきだ
さらに悪いのは、その一部がホストコードに束ねられておらず外部から読み込まれるため、レイテンシと潜在的なセキュリティリスクを増やしていることだ
開発者の介入なしに、マーケターがWebアプリケーションにどんなゴミでも注入できるようにするツールだった
人間関係もちょっと壊れたし、勝てもしなかったし、性能はいまだにひどいままだ
その次に性能問題を引き起こすのは、地図やチャートのような重いライブラリで、たいていは賢い遅延読み込みで解決できる
実際に経験したものでは、ごく小さな機能なのに起動時にQRコードスキャンライブラリと地図ライブラリを読み込んでいたケース、すべての国際化文字列を起動時にウォーターフォールで取得してどのJSも実行される前に詰まっていたケース、Zendeskがページ性能を完全に壊していたが上からの指示で遅延読み込みしかできなかったケースがある
その次は、DOM要素や再レンダリング、ウォーターフォールリクエストを多発させる設計の悪いコードだ
最後にアプリレベルのコードサイズが来るが、これも遅延読み込みで直せるとはいえ、アプリケーションが非常に巨大になるまでは通常そこまで必要ない
たとえばGitLabのランディングページは、追跡スクリプトを止めると13MBから「たった」6MBになる
マーケティング部門はいつだってソフトウェアの肥大化を倍にする
人気サイトがコールドロード時にどれだけ多くのJavaScriptを読み込むかを比較した内容。主なポイントは次のとおり
PornHub は YouTube より約 10倍少ない JS を読み込む（1.4MB 対 12MB）
Gmail は理解しがたいほど footprint が大きい（20MB）。Fastmail は 10分の1の 2MB と軽く、Figma はさらに複雑なアプリなのに同じくらいの 20MB  Jira は 58MB もあって途方もない
Jira は一度ダウンロードされた後は、更新までオフラインアプリのようにローカルから読み込まれるはず
Pornhub はシークレットモードで実行される可能性が高く、キャッシュが役に立たない
Jira もひどくて遅い
https://wordsandbuttons.online/ のすべてのページは、アニメーションやインタラクションがあってもなお 64KB 未満
たとえばこのページ https://wordsandbuttons.online/trippy_polynomials_in_arctang... は 51KB
コードもまったく経済的ではない。80% は少しずつ違うコピペで、賢く減らそうとする試みもない。すべて古いバニラ JS で、圧縮も minify もされていない
“View page source” で開くと、コードは完全に読める状態
秘訣は 依存性ゼロ方針。サードパーティも内部依存もない。必要なコードは HTML ファイルと一緒にすべて受け取る
逆説的だが、長期的にはコピペは肥大化の原因ではなく防止策になっている
モバイルでは端が文字どおり見えない
依存関係そのものが原因ではなく症状だ。Web サイトや企業がもはや肥大化を減らすインセンティブを持っていないので、重複した依存関係がほとんど整理されないのだ
2015年の The Website Obesity Crisis の記事 [1] を思い出す。その後 [2] 状況はさらに悪化し、もうほぼ10年が経った
この先10年後には、2015年ごろの PC では Web 閲覧が不可能になっていると言うのは愚かだろうか？ 何も変わらなければそう見える
2013年の古い MacBook に最新の Firefox を入れても、https://civitai.com の 23.98MB の JavaScript をさばけず、この惨事のような Web フロントエンドをレンダリングしようとして 30 秒ほど固まる
Web だけの問題ではない。モバイルのオールインワンアプリも大きくなりすぎていて、2013年のスマートフォンでは同様に読み込めず、その半分は Web 技術スタックの上に作られている
予算の大きい企業がなぜネイティブアプリケーションを使う余裕がないのかわからない
[1] https://idlewords.com/talks/website_obesity.htm
[2] https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
Web の状態はとても悲しい
光ファイバー接続を使っている大半の人は、Web がどれほど遅くなったかすら感じていない
だがまだ 2Mbps 接続 だと本当にひどい。自分がまさにそうで、つらい
だから広告・トラッカー遮断を使わないという選択肢はまったくない
Ublock Origin を有効にした状態でこのテストを見てみたい
このコードの大半はユーザー追跡と広告管理用だと思う
より良くより速いコンピュータとネットワーク速度が手に入ったのに、アプリや Web サイトをより小さくし続けることに集中すべきだと考えるのが理解できない
ムーアの法則のおかげで、開発者は最適性を犠牲にしてより多くを押し込み、速く動けるようになり、こういうケースが多くなった