「RSSリーダーを紹介する記事」がそれ自体37MBを超え、Firefoxでは200MB以上に膨れ上がる——そんな衝撃的な事例が、Simon Willisonのブログで取り上げられ話題になっています。この記事では、その背景と技術的な実態、そして私たちWeb開発者が学べる教訓を整理します。
何が起きたのか？
2026年3月、PC GamerがRSSリーダーを特集した記事を公開しました。Stuart Breckenridgeがこれを観測し「ダウンロードが止まらない37MBの記事」として報告。Simon Willisonはさらに踏み込んで、Claude Code（Rodneyエージェント）を使ってそのページのパフォーマンス監査を実施しました。
監査結果：本当に必要なコンテンツはたった150KB
監査の結果は衝撃的でした：
- ページ本来のコンテンツ：テキスト10〜15KB ＋ 画像約150KB（合計150KB程度）
- 実際のネットワークリクエスト数：60秒以内に 431件以上
- 転送量：5.5MB（デコード後18.8MB）
- Firefoxでは：自動再生動画カルーセルにより 200MB超 に到達
- 原因の82%以上：広告テクノロジー・トラッキング・プログラマティック広告スクリプト
つまり、読者が実際に必要としているコンテンツの 100倍以上 のデータが広告・追跡目的で読み込まれていたわけです。
なぜこうなるのか：プログラマティック広告の闇
Web肥大化（Web Bloat）の主犯は現代のプログラマティック広告エコシステムです：
- リアルタイム入札（RTB）：ページロード時に数十〜数百の広告ネットワークへのリクエストが連鎖する
- 自動再生動画広告：ユーザーの操作なしに高解像度動画をダウンロードし続ける
- サードパーティトラッカー：行動追跡・指紋収集のためのスクリプトが大量に実行される
- ウォーターフォール型ロード：広告が広告を呼び、リクエストが雪だるま式に増える
今回の監査では、こうした構造的な問題が可視化されました。
Simon Willisonの手法：Claude Code + Rodneyで自動監査
注目すべきは監査の手法です。Simon WillisonはClaude Codeのウェブ対応エージェント「Rodney」を使って調査を実施。AIにページのパフォーマンス分析を委ねることで、DevToolsを手動で操作するよりも体系的なレポートを得ています。
プロンプトも公開されており、同様の調査を自分でも試せます：
# 概念的な手順
1. Claude Codeで対象URLを指定
2. ネットワークリクエストの集計・分類を指示
3. 広告/トラッキング/コンテンツ別の内訳を出力させるこのアプローチは「AIを使ったWeb監査の自動化」として応用範囲が広く、定期的なパフォーマンス監視にも転用できます。
まとめ：「速いWebを作る」責任と現実
RSSリーダーを紹介する記事が、RSSそのもの（数KB）より遥かに重いという皮肉は笑えません。Web開発者として意識すべき点：
- 自分のサイトの広告タグを棚卸しし、不要なサードパーティスクリプトを削除する
lighthouseやWebPageTestで定期的にパフォーマンス計測を習慣化する- 自動再生動画は原則無効化、ユーザー操作トリガーにする
- Core Web Vitalsだけでなく「総転送量」も指標として意識する
広告依存のメディアが抱える構造問題とはいえ、技術的には解決可能な問題です。元記事ではRodneyを使った監査の詳細なプロンプトと結果が公開されているので、ぜひ自分のサイトでも試してみてください。