ウェブサイトは贅肉のように重くなった

Webクリップ コメントはまだありません

 
 
 
 
 

 
 
 
 
 
(これはMaciej Ceglowski の講演、"The Website Obesity Crisis"の原稿のふんいき翻訳である。Maciej Ceglowski はブックマーク共有サービス Pinboard のファウンダー兼運営者である。講演は2015年10月29日、オーストラリアのシドニーで...

 
 
 
 
 

 
 
 
 
 
(これはMaciej Ceglowski の講演、"The Website Obesity Crisis"の原稿のふんいき翻訳である。Maciej Ceglowski はブックマーク共有サービス Pinboard のファウンダー兼運営者である。講演は2015年10月29日、オーストラリアのシドニーで...
ob.001.thumb

(これはMaciej Ceglowski の講演、"The Website Obesity Crisis"の原稿のふんいき翻訳である。Maciej Ceglowski はブックマーク共有サービス Pinboard のファウンダー兼運営者である。講演は2015年10月29日、オーストラリアのシドニーで開かれた Web Directions にて行われた。講演のビデオ(53分)


ob.002.thumb

まずみなさんに申し上げますが、美しいウェブサイトというのは形も容量もさまざまです。僕は画像でいっぱいの大判なサイトが大好きです。HDの動画も大好きです。果てなく広がるjavascriptの実験や、良くできたウェブアプリも大好きです。

今日のお話はそれらについてのものではありません。今日のお話は基本的に文字中心の、何だか良く分からない理由で毎年毎年どんどん膨れあがっていくテキストベースのウェブサイトについてのお話です。

お話があまり抽象的になりすぎないように、具体的な例を挙げながら話をしていくつもりですが、特定の誰かを責めようというつもりはありません。いくつかの企業(Mediumです)を除いて……何か思い違いをしていて、わざとウェブを壊そうとしている、いくつか企業を除いての事ですが。


危機

ob.003.thumb

「ウェブサイトのぜい肉危機」とはどういう意味でしょうか。

こちらはGigaOmの「The Growing Epidemic of Page Bloat(ページ肥大化という新興流行病)」という2012年の記事です。ウェブページの平均容量が1メガバイトを超えた事について警鐘を鳴らす趣旨のものです。

このページ自体は1.8メガバイトあります。


ob.004.thumb

それから2年後、同じサイトからのほぼ同じような記事です。「The Overweight Web(ウェブの重量超過)」というタイトルで、ウェブページの平均容量が2メガバイトを超えた事に注意をうながしています。

このページ自体は3メガバイトあります。

この傾向が続いていけば、2020年ごろには、ウェブが重すぎる事を訴えるネットの記事は良い確率で5メガバイトを超えてくるでしょう。

特定の数値を尺度にしてしまう事の問題は、尺度に収まった数値については鈍感になってしまう事です。今日生意気に膨れ上がったウェブサイトは、明日には普通のよくあるウェブサイトになってますし、来年にはスリムでエレガントなデザインのウェブサイトになっているはずです。

もう少し時代を超えたものを基準に据えてみたいと思います。


ob.005.thumb

そこで、以前Twitterで提案した事の繰り返しになりますが、こう主張させてください――テキストベースのウェブサイトの容量は、ロシア文学の代表作より大きくなってはならない、と。

これは目安としては穏便なものです。何ならフランス文学(薄くて短めの作品がたくさんの)だって良かったわけですから。しかしここはあえて重々しさで知られるロシアの小説で行ってみたいと思います。

ゴンチャロフの「オブローモフ」のような、主人公がベッドから出てくるだけで最初の100ページかかるようなやつです。


ob.006.thumb

先ほどのツイートをブラウザでご覧になった場合、900キロバイトの容量のページが開きます。

これはブルガーコフの「巨匠とマルガリータ」全文よりも100キロバイト多い数値です。大粛清の時代下のモスクワにやってきた悪魔とその手下(でかい黒猫も!)たちを、ポンティオ・ピラトやイエス・キリスト、熱心ですが信頼ならぬ使徒マタイらの生涯についての奇妙な幻視を挟みながら描きだす、あの謎に満ちた楽しい小説よりもです。

ツイート一つでですよ。


ob.007.thumb

あるいは、Mediumに書かれたこの400ワード長の記事を見てみましょう。こう書いてあります。

「自分たちが誰のためにものを作っているのか、何故作っているのか、それを理解していないチームは、ぜい肉だらけのプロダクトを作りがちである。」

この金言を、Mediumのみなさんは何を思ってか、1.2メガバイトまで膨れ上がらせました。


ob.008.thumb

これは「罪と罰」よりも大きい容量です。ドストエフスキーによる、ナポレオンに取り憑かれ、金貸し老婆を殺害しようと自問自答する赤貧学生のサイコスリラーです。

金品を奪い忘れるほど自分の犯罪にうろたえ、罪悪感に苛まれてながら、ラスコリニーコフは切れ者の予審判事と抜きつ抜かれつの勝負に追われ、聖人のような娼婦の奇跡的な愛のうちに贖罪を見出します。

ドストエフスキーはこれを手書きで全部書きました。ロウソクの照明で、なんと羽ペンでですよ。


ob.009.thumb

ここに「A (Not So) Brief History of Page Bloat(ページ肥大化についての短〈くもな〉い歴史)」という最近の記事があります。

何故肥大化が良くないか、おなじみの理由を言い重ねながら、こう書いています。「重いページは遅くなり、遅いページはユーザを不幸にする」。

この一節に、かの有名なアンナ・カレーニナの冒頭を思い出す方もいるかもしれません。


ob.010.thumb

「幸福な家庭はどれも似たものだが、不幸な家庭はいずれもそれぞれに不幸なものである」


ob.011.thumb

しかし、この肥大化についてに短(くもな)い歴史は、アンナ・カレーニナよりもずっと長いです。

実はこの記事は「戦争と平和」よりも長いのです。一人一人の人間がはたして歴史のページを形づくれるのか、それとも我々みな歴史の逆らえぬ奔流にただ洗い流される他ないのかという、あのトルストイの探求よりも。


ob.012.thumb

さて、こちらはヨークシャー・イヴニング・ポストの、幾千ものよくある地方紙のウェブサイトからの記事です。個人の意志と歴史の関係については何一つ追い求めたりしないものです。

Leeds Hospital Bosses Apologise After Curry and Crumble On The Same Plate(リーズ病院の院長、カレーとクランブルを同じ皿で提供した事を謝罪)」


ob.013.thumb

病院食の皿の上で一つと触れあったこの二つの料理についての悲痛な物語は、あるいはマルセル・プルーストによって書かれたとしてもおかしくはなかったかもしれません。なんせマドレーヌの一かけらを紅茶に浸しただけで、後に9巻分3メガバイトともなる散文(手書きです)へと具現化される、鮮やかな追憶の渦巻を起こした作家ですから。その過ぎ去った時も、思い出も、それ自体は一瞬の幻に過ぎないというのに。

「失われた時を求めて」は「リーズ病院の院長、カレーとクランブルを同じ皿で提供した事を謝罪」のページに使われたjavascriptよりも短いです。


ob.015.thumb

まだまだ行けそうですね。楽しくなったきたので、どんどん行っちゃいましょう。

こちらは「Best Practices for Increasing Online performance(ウェブサイトのパフォーマンスを上げるベストプラクティス)」というハウツー記事です。3.1メガバイトあります。

Google Mapsについて取り上げています。曰く、Googleはページの重さを100キロバイトから80キロバイトに減らした事で、ユーザのエンゲージメント率を大幅に挙げることができた、との事です。

当時最も洗練されたウェブアプリであったGoogle Mapsが、今どきのニュース記事とサイズ比で35分の1だった時代を、みなさんは憶えておいででしょうか?


ob.016.thumb

ウェブの肥大化は、実に意外な場所を襲う事もあります。

例えば、Tim Kadlec氏は、ウェブのパフォーマンスについての並外れた書き手です。彼の個人サイトは単純性の理想のようなもので、無駄を削ぎ落とす事に関しては大変な知見の持ち主です。

しかし、そんな彼のパフォーマンスに関する最近の講演のスライドは、9メガバイトのウェブページか14メガバイトのPDFでしか手にする事ができません。


ob.017.thumb

最後にTechTimesのすてきな記事で締めましょう。Googleがモバイル版の検索結果ページで、重いページに対して「ロードが遅い」という専用のマークを出し始めたというものです。

何を思ってかこの記事は18メガバイトにもなります。そのうちの3メガバイトは(僕がたまたま見た時には)K-Yジェリー、「おアツいさんたちの潤滑油」と知られるセックス用ローションのビデオ広告で占められていました。

今どき広告ブロックなしでウェブをサーフィンするというのは、実に大変な量の潤滑油を必要とするようです。

いったい何がどうなってるんでしょうか?


インチキな解決策

ob.018.thumb

誰もが問題を認識しています。今とりあげたページたちは、ノートPCで見るだけでもかなりキツイ(この講演を準備した3週間もの間、僕のノートPCのファンは鳴りっぱなしでした)のですが、スマホで見た時は更に地獄です。なので大手のみなさんは対策を取り始めました。

2015年5月、Facebookが「Instant Articles」なるものを導入しました。ニュース記事をFacebookの中で瞬時にロードし表示するための専用フォーマットです。

FacebookはInstant Articlesのアナウンスを、なんか知らないおじさんの顔写真がデカデカと貼られた6.8メガバイトのウェブサイトで行いました。このおじさんはFacebookの従業員ですらありません。ナショナルジオグラフィックの写真編集者でした。

ページをスクロールすると、41メガバイトの動画があって、それ以上この技術の詳細を知る方法は無い事が分かります。動画の中ではくだんの編集者が、この新しいフォーマットの、スマホを傾けて画像をスクロールするなどのわくわくするクソ機能を熱狂的に称えていました。ニュースを読む時、スマホをしっかり握ってないと、ケン・バーンズのドキュメンタリーみたいに画像が縦横無尽に寄ったり動いたりする機能です。


ob.019.thumb

Facebookはまたinternet.orgも立ち上げました。インターネットの利用をより世界中へ広げるための活動です。開発途上国の人々の暮らしと、インターネットへのアクセスが彼らにとってどんな意味があるか、エモーショナルなホームページを通して紹介しています。

何が起きたか、だいたい予想がついてるかと思います。僕がchromeでinternet.orgを開いたまま、ランチに出かけて帰ってみると、chromeは4分の1ギガバイト以上の動画ファイルをダウンロードし終えていました。

まさか、とお思いでしょう。あらゆる人々にインターネットへのアクセスを提供しようという趣旨のウェブサイトに、でっかい動画ファイルなど背景で使うはずがない、と。


ob.020.thumb

お答えしましょう、使ったんですよ。この後ろの地球を回したいがために、Facebookは巨大な動画ファイルを使ったのです。

これがFacebookからの全世界へのメッセージです。「インターネットは遅い。くたばってしまえ」。

それに不安定なネット回線というのは何も第三世界だけの問題じゃないんです! 僕はオーストラリアをよく旅して回ったので詳しいのですが、タスマニア州やクイーンズランド州の田舎の方では、WiFiを使うのは百年ものブランデーを頂くような感じなのです。金さえ出せば好きなだけ買えはするのですが、めちゃめちゃ高い上にちょびっとしかもらえず、3回も4回も買い足すと、周りから変人を見る目で見られはじめるんです。

シドニーのような回線がよく整備された場所でも、ほんの数行の情報(レストランの住所とか)を知りたかっただけなのに巨大なページを開いてしまい、ロード待ちの間にパケットは詰まりバッテリーは死んだ、なんていう経験を、僕たちはみんな持っているのではないでしょうか。


ob.021.thumb

こういう無意味なオナニーサイトのデザイナーには極刑が与えられてしかるべきです。

彼らはプロとしての残りのキャリア中、アップルのホッケーパックマウスのみを使うよう強制されるべきです。(観客から恐怖の叫び)


ob.022.thumb

Instant Articlesへの対抗として、GoogleはAMP(Accelerated Mobile Pages)なるものをリリースしました。AMPはモバイル上で速くレンダリングされるように作られた、HTMLの特殊なサブセットです。

普通にただのHTMLでよいのでは、クソみたいな無駄アセットとか乗っけなければ済むだけの話では、という疑問には、答えはなされずじまいでした。

AMPは意識の高いオープンソースプロジェクトで、あらゆるパブリッシャーがそれに乗っかりました。モバイルインターネットへのあふれる愛のため、Googleはそのインフラを無償で、特に個人情報をトラッキングする部分を無償で提供しました。


ob.023.thumb

Jeremy Keithが教えてくれたんですが、AMPの紹介ページは技術的に見て無限のトラフィックを必要とします。Chromeでページを開くと、同じ3.4メガバイトのカルーセル動画を永遠に繰り返してダウンロードするのです。

Safariで開くとカルーセル表示は壊れるのですが、それでもページの容量は4メガバイトほどです。

ウェブを速くするという趣旨のプロジェクトにこんな滑稽なくらい重いウェブサイトを作るというのは、フィットネス用のビデオを再生してみたら講師がピザとスナックを食いながらただ単につっ立っていたというようなものです。

世界でもっとも優れたテック企業でさえ、こんな小ぶりなテキストばかりのサイトを、ウェブから無駄を無くそうという旗艦プロジェクトの趣旨説明を、軽量でパパっと見られるように作れないのです。

これ以上明らかな敗北宣言というのがありうるでしょうか。


ob.024.thumb

AMPのチーフは気さくな人物で、Twitterで僕たちと直接お話をしてくれました。彼はAMPのサイトが必要以上に重たいという事は認めながら、Googleは「リソースが足りない」ため、サイト制作を外注せざるを得なかったと付け加えたのです。

この裏話に僕は大いに心を動かされました。まさかGoogleがそこまでリソースにカツカツだとは想像もしなかったからです。ですので僕はいくつか空いた時間を使って、AMPウェブサイトの静的バージョンを作りあげました


ob.025.thumb

僕はまずカルーセルに使われた画像群を、ウィリアム・ハワード・タフトの肖像写真に差し替える事から始めました。アメリカ史上最も恰幅のすぐれた大統領です。

この差し替えは、元ページの無意味なアニメーションに比べ圧倒的な改善をもたらしました。


ob.026.thumb

午後の一時で、僕はさまざまなゴミを取り除き、ページの容量を0.5メガバイトにまで小さくする事ができました。元ページのわずか8分の1の容量です。

僕はこれを無償でGoogleに進呈しました。しかしGoogleはリソースがカツカツすぎるんでしょう、これをコピペする工数も取れてないようです。


ob.027.thumb

このプロジェクトを機に、僕はタフト・テストというものを打ち出しました。

みなさんがお作りになった記事の中の画像を、全てウィリアム・ハワード・タフトの写真に差し替えてみてください。良くなりましたか?

もしそうであれば、それらの画像は記事の質に寄与しないものだと思われます。少なくとも、差し替えたタフトの写真はそのままにしておくのをお勧めします。だって良くなったんですから。


ob.028.thumb

ここであらゆるウェブサイトのパフォーマンスを改善する2つの手順を紹介したいと思います。

  1. ページのなかで、最も重要なものを最初にダウンロードさせ、最初に表示させる。
  2. そこで止める。

他は全て要らないゴミです。勇気をもってミニマリズムしましょう。


ob.029.thumb

某有名ビジネス講演家のマネをするならば、僕は今夜にでもみなさんの現場にお邪魔して、そこにあるものだけを使って、先ほど紹介したページが全て1秒以内にロードするように作り変える事ができます。二時間もあればできます。

みなさんにはできますか? どうですか?

もちろんできるに決まってます、なんにも難しくないんですから! 僕たちは全員、自分たちがどうやって2002年ごろホームページなるものを作っていたかを覚えています。それはギリシャ爆薬やらダマスカス鋼のようなロストテクノロジーでも何でもないのです。

しかし、僕たちはページを肥大化させる圧力にさらされています。

今や、クライアント方へ出向いて、サイト作成に200キロバイト大のテンプレートなど提案したものなら、間違いなくクビにされてしまうでしょう。それがいかに見た目が良く、広告やら追跡やらSNS共有ボタンやらの要求仕様を全て満たしているとしてもです。それほど小さいサイトというのは、今やあまりにも想像のラチ外にあるものなのです。


ob.030.thumb

ダイエットに手こずった経験のある方でしたら、世の中には自分自身を痩せた気にさせる様々なトリックがある事をご存じかと思います。ベルトをきつく締めたり、細身に見えるシャツを着たり、体重計の特定のところに足を乗っけたりとかですね。

同じ事がウェブのパフォーマンステストでも行われています。糖蜜なみにゆっくりしたたり落ちるウェブサイトを素早くロードしてるように見せかけるために、さまざまなクリエイティブなメトリクスが発明されました。

GoogleのSpeedIndexなどは有名どころです(カジュアルに積分記号なんか使われている事から、Googleのものだとすぐに分かります)。

SpeedIndexの基本的な考え方は、ページ全体のうち、画面に見えてるものを速くレンダリングできれば良いというものです。見えてる範囲外で何が起ころうが関係ありません。バックグラウンドで回線が飽和しようが、スマホが握れないくらい熱くなろうが関係ありません。バッテリーが目に見えて減り出しても関係ありません。ビューポート内の見え方さえちゃんと表示できてればオールオッケーなのです。

それほど頑張ってイの一番に表示させたコンテンツが全画面広告だったとしても、もちろん何の問題もありません。または(多くのモバイルユーザがそうするように)一瞬で広告を飛ばしてスクロールしたら、ページの「最適化されていない」部分がパンツを降ろしたままなのが目に入ってしまう事になっても、何のおとがめも無いでしょう。

ウェブのパフォーマンスの正しいベンチマーク基準というのは一つしかありません。リンクをクリックしてから、全ての広告を飛ばすまでどれくらい時間がかかるか、です。

それ以外は全てカスです。


ob.031.thumb

ウェブパフォーマンス推進論者の方々と話をしていると、時としてSUV乗りと燃費の話をするヒッピーみたいな気持ちになります。

彼らはリッター何キロというのを少しでも上げるためにあらゆる変な手を使います。前輪左タイヤの空気を気持ち抜いておいたり、燃料タンクキャップに磁石を貼っつけたり、サイドミラーを畳んだり。

ウェブパフォーマンスの話題で良く挙がってくるものも、だいたい同じくらい小手先のものです。圧縮のハックだとか非同期ローディングだとか、アセットのシークェンシングだとか、多重化HTTPリクエストだとか、パイプライニングだとかミニファイだとか。


ob.032.thumb

どれもこれも、ずっと簡単な解決策から目を背けています。

角ん所のお店に買い物に行きたいだけなら、自転車に乗ればいいんです。

段落五個くらいの文章を表示したいだけなら、ただのHTMLを使えばいいんです。何なら、テキストファイルそのまま乗っけちゃってもいいんです! であれば、圧縮ハックも積分記号もデベロッパーツールのガントチャートも必要ありません。

ただのHTMLをレンダリングする事にかけては、ブラウザはものすごく、ものすごく、優れたソフトウェアです。

僕たちには技術があるのです。


ob.037.thumb

食事バランスガイドという、栄養学者のみなさんによるすばらしい仕事があります。僕たちにも同じピラミッド図が必要だと思います。健康なウェブサイトというのはどのようなものか、ひと目に分からせてくれるような。

私のお勧めする、2015年現在のバランスがとれたウェブサイトの作り方というのはこのようなものです。

  • 適正にマークアップされた、中身のあるテキスト
  • 見た目を整え、華を添えるための、少量の画像
  • CSS、小さじ1杯
  • どうしても必要な場合、ほんの少しだけ、javascript

ob.041.thumb

ところが、今僕たちが世の中で目にするウェブサイトというのはこんな感じです。

  • 基層のHTML
  • そびえたつクソ
  • 何もかもめちゃめちゃにこんがらがった個人情報監視スクリプト群

脂まみれの広告

ob.042.thumb

ウェブデザイナーのみなさん! みなさんが全部悪いわけではないのです。

みなさんが心血を注いで、ユーザーのニーズを先取りした設計過程を立て、彼らの進む道にバラの花びらを敷きつめ、最適化を施して、立派なウェブサイトを作りあげたとします。

すると、みなさんのクライアントがみなさんの作品を、みなさんの力の及ばない、ブラウザ上でロードが終わってから何が表示されるかが決まる、サイトのデザインを何もかも無視し、ユーザーが何の目的でサイトに訪れたのかも無視し、ただただユーザーの注意力を逸らす事だけが目的の、トラッキングと広告というクソで塗りたくるのです。

みなさんのウェブサイトのユーザーエクスペリエンスは、みなさんが手を出せない敵対的要素によって牛耳られてしまうのです。


ob.043.thumb

こちらはNPRによる、昨今の広告ブロッカーの隆盛について説明する記事です。普通に開いた場合、容量は12メガバイトあります。

同じ記事を普通の広告ブロッカーを有効にして開いた場合、1メガバイトになります。それでも理想からは遠い大きさですが、にしてもプラグイン一つでこれだけの違いです。

広告ブロッカーを無効にしてみましょう。ロードされるのは、バナー広告と動画だけではありません。javascriptにつぐjavascriptです。あらゆるビーコン、トラッキング、共有ボタンが、それぞれに一式のスクリプトをロードして、それぞれのスクリプトはさらにそれぞれのサードパーティーのサーバーからデータを引っぱってきます。おまけにそれぞれのリクエストにそれぞれのクッキー付きです。

ただでさえ重いところでこれ以上クッキーが要るでしょうか。

そんなスクリプトが、どこの何のサーバーかも分からない、ただマルウェアの感染ベクターとしては理想的な場所からやってくるのです。

広告業者たちに聞けば、こうするしかないんだと言うでしょう。でも、広告業者の人々とやりとりをする際には、彼らが嘘をつくプロである事を念頭に置かなければなりません。

ケンカを売りたいわけではありません。そういう仕事であると申したいのです。広告の仕事というのは、人がやらない事を、やる必要があると合点させる事です。ウェブデザイナーと議論する時の彼らの役目は、サードパーティーのトラッキングとぜい肉を山と乗っける事以外、ウェブサイトに広告を表示させる方法はないのだと納得させる事なんです。

全てのぜい肉や、パフォーマンス低下や、セキュリティのひどさは、読者たちがタダでコンテンツを楽しむために払う代償というわけです。


ob.045.thumb

ここで僕の大好きな「アドテク・エコシステム」の図をお披露目しましょう。数字だけでは分からない、広告業界のエグさを伝えてくれるものです。

これは2011年のアドテク・エコシステムを図にしたものです。この時は100社ほどの「アドテク」企業がいました。


ob.046.thumb

これが2012年になると、350社に増えます。


ob.047.thumb

2014年にはなんと947社になりました。


ob.048.thumb

2015年現在、この手の企業の数は1876社に上ります。これら全員が全員、みなさんのネット上のちょっとしたスキマ時間を取り合っているわけです。

この大成長中の業界は非常に込み入ったものです。多分わざとそうなってるんですけどね。

複雑なシステムを理解したい場合、ズームアウトして全体の流れをとらえる事が有効です。


ob.049.thumb

例えばこのドイツ語の図は、地球のエネルギー収支を表わしたものです。

太陽光が植物や水を照らす時、ありとあらゆる複雑な現象が発生しますが、そういう細かい事は全て無視して、全体のインとアウトの総量だけを計るという方法があります。

同じような感じで、このネット広告バブルをお金がどのように動き回っているのか、図解してみましょう。


ob.051.thumb

まず消費者がいます。文化的感受性の間違った発揮方法として、ここではこのカンガルーを消費者とします。

消費者は事業者から財やサービスを購入し、代価としてお金を支払います。この赤い矢印がお金――オーストラリアでは「ドル」――の流れです。


ob.052.thumb

このお金の一部は広告業者に流れます。ちょっとした消費税だと思ってください。


ob.055.thumb

このお金は世界中の中間業者の間を跳ね回り、最終的に誰かのポケットに吸い込まれるまで飛び動き続けます。

今現在、それは勝ち組アドネットワークの胴元です。FacebookやYahoo!、そしてGoogleですね。


ob.056.thumb

入っていくお金より出ていくお金の方が矢印が太い事に気がついた方もいるかと思います。

広告企業が一般の消費者から稼げる金額というのは知れています。みなさんが一日のうちに目にする広告の数と、同じく一日のうちに買い物に使うお金の量を比較してみればお分かりになるかと思います。

そこで神様仏様投資家様のお出ましです! 今のところ、この需給の差を埋めているのは彼らの資金です。最後に生き残る一握りの勝者を掴み取ろうと、この激アツ市場にどくどく金を注ぎ込んでおります。


ob.057.thumb

しかし、どこかの時点で、投資家たちは金を引き上げ、図の右側へ移っていくでしょう。その時、彼らは今まで注ぎ込んだよりも多くの金を取り戻そうとします。


ob.058.thumb

そうなった時に(というか、今まさにそうなりつつあると僕は思ってますが)何かが大きく変わらざるを得ません。

僕たちがもっと買い物をするようになるか、広告業者の取り分がもっと高くなるか……

バブルがはじけるか、です。


ob.059.thumb

バブルが崩壊した時、生き残ったスタートアップたちは破れかぶれになるでしょう。そして、いかにバレずに新時代の監視社会を担う一団となるかを探り始めるはずです。

併合と買収の波が、そしてより過激なトラッキングの波がやってくるでしょう。インターネット上のプライバシーというものは完全に破壊されてしまうでしょう。

僕が今すぐにでも彼らに対する規制が必要だと主張しているのはそのためです。

サードパーティーのトラッキングも、ターゲティングも取り締まるべきです。

広告はスマートでなくなるべきで、表示されるページの従となるべきです。


ob.063.thumb

こんにち広く行われている手法では、ウェブページの広告枠はページのロード時にオークションにかかります。実際の広告(と一緒についてきたプライバシー侵害インフラjavascriptの一群)は、広告以外の中身が揃ってからブラウザによってロードされます。

ユーザーエクスペリエンス的には、これはパーティーがとっくに始まったところでセールスマンがやってきて、音楽を止めさせ、テーブルスタンドにタッパーウェアを並べて、招待客にちょっかいを出しはじめるようなものです。雰囲気台無しです。


ob.062.thumb

サイト側で表示する広告を決定できれば、サイトがどんな見た目になるか事前に知る事ができます。アセットをまともな順序でロードする事ができます。何かのマルウェアが仕込まれる可能性を防ぐ事ができます。デザイナーにとってそれがどういう意味を持つか、想像してみてください。

サイトのロード時に画面いっぱいのGIFアニメが降って湧く事もなく、ページのレイアウトが崩壊する事もなく、ユーザがみなさんの事を憎む事もなくなるのです。


ob.061.thumb

あるいは、もっと大胆に考えてみましょう。僕は、インターネットのサイトを運営するには広告モデルに頼るしかないという風には全く思っていません。

人々はマイクロペイメント、少額課金モデルを馬鹿にします。既にうまく回っている少額課金のシステムを、みんなデフォルトに使っているにも関わらずです。

この図は、アメリカの携帯電話回線でニュースサイトを表示した時、帯域ベースで携帯会社にいくら入るのかチャートにしたものです(ニューヨークタイムズ)。例えば、Boston.comのページを表示すると、一般的なプランでおよそ30セントかかります。

この額はBoston.comが、インプレッションごといくらの広告で手にする額より間違いなく高いでしょう。これは電話会社への少額課金モデルに他なりません。

電話会社とアドネットワークだけが莫大な利益を上げ、他は全員損をしているという馬鹿げた状況下に僕たちはいるのです。


ob.065.thumb

スマートな広告モデルを取り止めさせようしたら、広告業者のみなさんは叫び声をあげてそれを退けようとするでしょう。しかし、スマートな広告の方がスマートでない広告より良いというエビデンスは、実際のところ存在しないのです。

長い長い間、まともなターゲティングひとつできてない広告たちが、テレビスタジオやラジオショー、あらゆるポピュラーエンターテインメント産業を支えきるだけの金を稼いできました。バットモービルの代金を払ってきたのはスマートではない広告なのです。

数人のジャーナリストとウェブデザイナーを雇ったところで、シットコム一編を作るよりもずっと安くつきます。であれば、誰のプライバシーも侵害しなかった、実績ある資金拠出モデルに戻ってはいけない理由など、どこにあるでしょうか?


ob.066.thumb

もちろん広告業者の方々は、あの時代のテレビ一台一台にカメラが乗っかっていれば、更にどれだけ素晴しかったか、教えてくれようとするでしょう。

そういうのってもう沢山じゃないですか。


ob.064.thumb

広告がスマートでなくなれば、その収益率は低くなります。というのも今のオンライン広告に流れている金の大半は、監視とトラッキング技術が期待させる膨大な空手形に煽られているものだからです。

しかしどっちみち、広告市場は今のバブルがはじければ深手を負います。

先に飛び出て先行利益を得るか、他のみんなと渦潮に飲み込まれるか。パブリッシャーにとっては、もうそれだけが問題なんです。


デカいアセット

ob.067.thumb

ウェブが太りすぎたまた別の理由についてお話しましょう。

デカいアセットです!

これはずっとずっとずっと前からある問題です。しかしネットワークが速くなり、コンテンツ公開のワークフローが複雑になるにつれ、意図せず巨大なファイルをウェブサイトに上げてしまう可能性は増えてしまいました。


ob.068.thumb

実例です!

ご覧のサイトは、ウェブサイトのぜい肉だなんだブチ上げて人を批判するのが好きな某独り善がりのブロガーのものです。にもかかわらず、彼の一番最近の記事には3メガもの画像がデカデカとトップに載ってるのです。

おそらく、うっかり画像をリサイズするのを忘れたのでしょう。遅い回線でページにアクセスしなければ、これに気付くのは難しいです。

ネットワークを速くする事が問題を悪化させているのです。


ob.069.thumb

これは少し前に撮られた、中国の交通渋滞の写真です。50車線もの車の列があります。車線を51に増やしたところで何一つ自体は改善しません。

同じように、帯域を太くする事は、人々に無駄にでかいものをウェブに上げないようにさせる事とは無関係なんです。


ob.071.thumb

こないだViceに載っていた、このボットネットについての記事を見てみましょう。

ページの一番上に、中身と全く無関係のイヤホンの画像(3メガバイト)があります。タフト・テスト失格ですね。

これは「ヒーローイメージ」という、ネットワークの高速化によって可能になった悲しむべきトレンドの一例です。その唯一の役割は読者にスクロールして飛ばすための何かを提供することです。

ただこのケースに関しては、ページの作者に責任はありません。サイト作成のツールチェーンのどっかが壊れて、このデカい画像の圧縮に失敗したんでしょう。

それより問題なのは、ネットワークの高速


Twitterでは幅広い情報を提供しています。お気軽にフォローをどうぞ!

関連

管理人のアンテナlive!

コメントを入力

CAPTCHA