- ニューヨーク・タイムズのある記事ページでは、422件のネットワークリクエストと49MBのデータ転送が発生し、単純に記事を読むだけでも過剰なリソースを要求する
- ページ読み込みの過程で、数十件の広告入札リクエストとトラッキングスクリプトが同時に実行され、ブラウザのCPUとバッテリーを消費する構造になっている
- このような敵対的なUX設計は、クッキーバナー、購読ポップアップ、自動再生動画、画面占有型広告などにつながり、ユーザーの読書体験を妨げる
- 広告収益最大化のための**「滞在時間」と「表示率」中心のビジネスモデル**が読者体験を犠牲にしており、エンジニアでさえこの構造に縛られている
- 記事は**テキスト中心の軽量ニュースページ（text.npr.org など）**を例に挙げ、読者とビジネスが共存できる、シンプルで敬意あるウェブ体験の回復を強調している
49MBのウェブページという現実
- ニューヨーク・タイムズのサイトにアクセスすると、422件のリクエストと49MBのデータが発生し、ページが安定するまでに2分かかる
- これは**Windows 95全体の容量（フロッピーディスク28枚分）**より大きく、MP3音楽10〜12曲分に相当する
- わずか数段落のテキストを読むために、アルバム1枚分をダウンロードしているようなものだ
- 過去に比べてハードウェア性能は飛躍的に向上したにもかかわらず、広告・トラッキング中心のウェブフレームワークがその進歩を相殺している
CPU負荷とトラッキング構造
- ニュースサイトはプログラマティック広告の入札システムをブラウザ内で実行している
- Rubicon Project、Amazon Ad Systemsなどへの非同期の入札リクエストが同時に発生する
- ブラウザは数MBのJavaScriptをダウンロード、パース、コンパイルしなければならず、これはメインスレッドの負荷につながる
- ユーザーはテキストを求めているのに、ブラウザはまず5MBのトラッキングスクリプトを処理し、その後で広告挿入が行われる
- 同時に**行動追跡ビーコン（POSTリクエスト）と見えないピクセルリダイレクト（doubleclick.net、casalemedia）**が動作し、クロスサイト識別を行う
- これらの過程はモバイル端末の発熱・バッテリー消耗を招き、ユーザーは知らないうちに高頻度データ取引市場に参加させられている
敵対的UXとインタラクションコスト
- ページに入るとGDPRクッキーバナー、ニュースレター購読モーダル、通知許可ポップアップが連続して現れる
- ユーザーはコンテンツにアクセスする前に、何度もクリックとスクロールを強いられる
- これは**NNgroupの「インタラクションコスト（Interaction Cost）」と「ミニマリズムデザイン」**の原則に反する
- Economic Timesの事例では、ユーザーは3つのモーダルを閉じ、上部バナーをやり過ごしてようやく本文にアクセスできる
- GoogleのCore Web Vitals基準でも、このような侵入型インタースティシャルはSEOの減点要因として明記されている
レイアウトの不安定さと広告挿入
- 読者が段落を読んでいる途中で広告入札が完了すると、iframe広告が挿入されてテキストが250ピクセル移動する
- これは**累積レイアウトシフト（CLS）**として測定され、離脱率の上昇に直結する
- Googleはこの問題を公式に減点対象としているが、自社の広告製品が同じ問題を引き起こしているという矛盾がある
- 自動再生動画はスクロール後も画面下部に固定されたまま再生され続け、閉じるボタンは小さくクリック領域も狭い
- これはフィッツの法則違反の事例として指摘されている
モバイル環境における空間の浪費
- 平均的なモバイルビューポート800pxのうち、ロゴ・共有バー・ブラウザUIがかなりの部分を占める
- 実際のコンテンツ表示は**Guardianのページ基準で11%**にすぎない
- **広告・モーダル89% vs コンテンツ11%**という比率は、ユーザーの視覚的疲労とスクロール頻度を増加させる
- 「X」ボタンを広告のクリック領域の近くに配置して誤タップを誘発する「fat-finger tax」戦略も存在する
- Jagranなど一部のインドのニュースサイトは、アプリインストール誘導モーダルや購読ポップアップで本文へのアクセスを妨げている
改善策の提示
- コンテンツ表示前に3〜4回の閉じる操作を強要する構造は、ユーザーの認知資源を浪費する
- ポップアップは60秒滞在または50%スクロール後にのみ表示するよう調整が必要だ
- クッキー同意とニュースレター購読は下部の非ブロッキングセクションに統合できる
- 広告スロットは固定高さのコンテナとして予約し、レイアウトシフトを防止する
- 例:
min-height: 250px; background: var(--skeleton-loader);
- 広告配信に失敗した場合は
ResizeObserverで非可視領域に限って縮小処理を行う
軽量ニュースサイトの存在
- text.npr.org、lite.cnn.com、cbc.ca/liteなどは、トラッキングもモーダルもない軽量版を提供している
- RSSフィードベースのニュース消費も依然として活発だ
- これらの事例は、シンプルでコンテンツ中心のウェブ体験への需要が今なお存在することを示している
結論: 読者の注意力は資源である
- 現在のニュースUIは読者を捕捉対象とみなすようになっており、広告表示を最大化する構造で設計されている
- しかし収益性とアクセシビリティは両立可能であり、エンジニアたちもこの構造に不満を抱いている
- 問題の根源は短期CPM中心のビジネスインセンティブにある
- 読者の注意力を抽出可能な資源として扱うシステムが形成されており、
RSS利用・タブを閉じる・離脱率の上昇がこれに対する最も強い抵抗行為として提示されている
1件のコメント
Hacker Newsの意見
サーバーが遅いというチケットが来て確認してみると、ページ内のすべての動画が一部ずつ preload されていた
オフィスがデータセンターと光ファイバーで直接つながっていたから、かろうじて持ちこたえていただけだった
Web開発者には 128kbit を超えるネットワーク速度を与えるべきではないと思う。それ以上あると全部めちゃくちゃになる
CPU 制限機能と一緒に使えば、低スペック環境でのサイト性能を点検するのに向いている
遅い開発サーバーを使うと、自然と不要なリソースを減らす訓練になる
Gopher、Gemini、IRC ベースの Bitlbee など、超低速環境でも問題なく動いていた
Electron アプリ開発者も 2GB RAM、旧式 Celeron 級PCでテストしてこそ、本当に完成したアプリと言える
それでも転送量ベースで見ると、44.47MB のうち 36.3MB は ジャーナリズム用動画 だった
つまり、過剰な広告というより、動画中心のコンテンツ構造が問題ということだ
ユーザーがクリックする前に 36MB を強制的にダウンロードさせるのは納得しがたい
広告とJavaScriptの塊のせいで、もはや読まない。代わりに見出しだけコピーして別のサイトで読む
基本的に JavaScript を無効にした状態 でブラウジングしており、広告はほとんど見ない
JS を切るとページはずっと速くなり、個人情報流出のリスクも減る
こういうやり方が非倫理的だとは思わない。先に不公正な振る舞いをしたのはサイト側だからだ
むしろ訪問しないほうが彼らにとっても得なくらいだ
コンテンツが見えて動けば、それで十分だと思っている
NYT はこうした「技術に無関心な多数」を相手にしている
新聞業界の根本的な問題は 広告ベースの経済モデルの崩壊 だ
昔は印刷費だけを読者から取り、残りは広告で賄っていた
だが今では Facebook Marketplace や Craigslist などがその広告を全部持っていった
結局ニュースは ニッチ商品 になり、読者データ販売は最後の悪あがきになっている
月 250MB 制限だったのだから、今思うと信じがたい
HN のように JS 一行一行を慎重に扱うサイトのほうが、むしろ神の贈り物のように感じる
Web はもっと肥大化しないようにすべきだ
こんな UX で金を稼げるはずがないのに、同じことを繰り返している
昔は Win95 ですら「肥大化している」と言われたのに、今のWebページはそれよりずっと大きい
広告そのものより リソースの浪費と散漫さ が問題だ
JS を有効にした瞬間に画面が騒がしくなったら、すぐ離脱する
ユーザーをいら立たせて得る数セントに、本当に価値があるのか疑問だ
たいていの人は、ただ無関心に受け入れているように見える
私は30代後半の開発者で、「自由なインターネット」世代 だから、広告に対する忍耐力がほとんどない
昔の Amadeus 端末 のようなコマンドラインベースのインターフェースが恋しい
Web が再びユーザー中心に戻るにはどうすべきか考えてしまう
フィールドラベルの誤り、切れた placeholder、中国語で表示される date picker、
座席を選んだ後の「選択不可」メッセージなど、UX が完全に崩壊していた
単純な HTML フォームだけでも十分使えるサイトは作れる
JS の濫用は洗脳された結果だ
私は Hagezi ultimate list でほぼすべての広告を遮断し、デスクトップでは uBlock で細かく調整している
Google・Adobe フォントのドメインも自分でブロックして、速度とプライバシーを改善した
ユーザーが検証していないプログラムが自分のコンピューター上で動くのは、根本的に間違った構造だ
JS を切るとサイトが壊れるのは、開発者の設計が悪いからだ
HTML と実行コードが分離されていたなら、世界はずっと良くなっていただろう
サーバー側でレンダリングして、結果だけ送れば十分だ
49MB のページは単なる 優先順位の反映 にすぎない
高速インターネットが一般化した今、ほとんどのユーザーは問題を感じていない
私は uBlock Origin ハードモード でそうしたリソースを完全に遮断している