iOS 9 のコンテンツブロックで始まる HTTP 2.0 時代の Web 広告

iOS 9 から Safari の Extension 機能としてコンテントブロックの実装が可能になった。

developer.apple.com

Web ページ内の特定の HTML 要素を見えなくしたり、特定のURLのロードをブロックする仕組みを Apple は ブラウザ Safari に提供した、それだけである。しかしこれにより Web ページの広告やトラッカーといったJavaScriptの読み込みを遮断する Safari 拡張アプリの実装が可能になることから、実質 Apple が Web 広告を潰しにきたと iOS 9 発表当時から話題になった。

実際 iOS 9 リリースとともに広告・トラッカーをブロックするアプリがストアに並び、ランキングの上位に躍り出ることになった。以前から Apple が Web 広告を蔑ろにしていることは、iOS 5Safari に追加したリーダー(Web ページの記事の文章だけにフォーカスする)機能などから伺えた。ただこれは読み込んだページに対して機能することと、ブログなど Safari が記事ページと判断したときだけ有効になるので、広告潰しとして話題になることはなかった。

少し話が逸れるがニュースアプリの SmartNews がリリースされた当初、ネットワークがオフラインでも先読みしてニュース記事の文章だけを表示するという機能が物議を醸したことがあった。その後 SmartNews はメディアと協業していく形で成功している。

ブラウザに広告ブロック機能が追加できることは目新しいことではない。PC ブラウザではアドオン・拡張機能として古くからある。昔から言われているのはこういったアドオンをインストールする人は、そもそも広告を踏むことはないので収入には影響がないという話だ。概ね正しいと思うが、厳密には広告インプレッションは減ってしまう。

これまでと状況が異なるのはブラウザのアドオンマーケットと違い、普通に iPhone を使う人がその存在を認知できる形で提供されることだ。無料アプリであればソムリエな学生の口コミで瞬く間に普及するシナリオは大いにあり得る。ユーザーからすれば広告を消すことにデメリットはない。通信量も減りブラウジングが軽くなるのは事実で、特にバッテリーで動作するスマホには恩恵が大きい。過去に Android もブロックアプリがストアに並んでいたが、広告収入がメインの Google は一斉に排除している。

もし無視できないほど広告ブロックアプリが普及したらどうなるのか。iOSSafari は今のネットにおいてトップシェアを誇るため、確実に収益減少に繋がる。その一方で、ブロック機能をオフにしないとサイトの閲覧をさせないようにする方法はある。サイトに広告が表示できたかどうか検証するスクリプトを直接ページに埋め込み、ブロックされた場合にコンテンツを隠すようにできるからだ。コンテンツに自信のあるサイトは、ブロックアプリを排除するか会員制に移行するか選択するだろう。

ちなみにトラッカーまでブロックされるとステルスアクセスになり、Google Analytics でページビューを把握してると単に訪問者が減ったように見える。Web サーバの HTTP アクセスログと照らし合わせないとわからない。

ここで立ち戻って、なぜ広告をブロックしたい状況なのか考える。以下の2点が大きい。

  • 鬱陶しく広告の載せているサイトがある。スマホでは成人向けの広告が一般サイトで表示されることも多い。
  • 広告・トラッカーのスクリプトをクライアントサイドでロード・処理しているため、ユーザー負担が大きい。

一方でサイト運営者はなぜ広告を掲載するのか大きく分けると以下の2つだ。

  • 商用 Web サイトで収益を上げるための手段として広告掲載する。
  • フリー Web サイトを維持するインフラコストを賄うため広告を掲載する。

今後望ましい状況を考えてみる。

  • 健全に広告を表示していないサイトが淘汰されること。
  • ユーザーが負担する広告配信(スクリプト)の処理が無くなる(減る)こと。
  • 維持費を広告で賄うフリーで情報提供しているサイトが残ること。

1 番目の事項は、広告配信業界が自己解決すべき問題だと思うのでこれ以上扱わない。エンジニアとして 2,3 番目の事項の解決策を考えてみたい。

基本的に Web ページは読み込み毎にスクリプトのロードと実行が走る。スクリプトの特性上、scriptタグで指定したものをトリガーに五月雨式に続くスクリプトをロードできるので、複数の外部サーバに接続しロードする構成が広告・トラッカー系には多い。それでもブロック自体が簡単にできるのは、トリガーのスクリプトさえ抑えればいいからだ。逆にその URL が特定のドメインやファイルパスを含むルールにマッチできなければブロックすることはほぼ不可能になる。

つまり Web サイト自体のサーバから(経由して)広告を配信することが、前述の答えになる。

こうすれば実質 URL がランダムにできるためにブロックできない。サイト運営者が利用する広告・トラッカーサービスはまちまちだがサーバサイドで一括で処理すればクライアントの負担も減らせる。また HTTP 2.0 時代では、従来の複数の並列なサーバ接続は確立コストが大きいため、1つの接続で複数のストリームを構築するようになる。これもプラスに働く。バックヤードでは Web サイトのサーバと広告・トラッカーのサーバは常に接続を維持できるのも接続確立コストの削減になる。

昨今はほとんどのサイトが CMS で構築されているため、この実装ハードルは低い。デメリットは Web サイトのサーバ負担が増えることだが、これは本来広告掲載するために賄うべきだったはずだ。

広告自体無くなれば良いと思う人は、GoogleGmailGoogle ドライブをフリーで提供していることを思い出してほしい。 サービス、コンテンツの対価として広告を用いることが健全に Web に存在していくことを期待したい。