Webサイトの読み込み時間に関して検索大手のGoogleは敏感になっている。Googleの検索サービスの検索速度は速い。Google Chromeの表示までの速度の追求には恐れ入る。そして今年4月には、site speedを検索順位に反映すると発表している。
これらの事象から推測するに、Webサイトをいかに高速に表示するかは、多くのサイトにとって課題になるだろう。
Webサイトの表示速度を高速にするためには、いくつかの方法があると考えられる。
- 動的コンテンツではなく静的なコンテンツとして扱う（MovableTypeやWordPressのキャッシュのような）
- 多くの画像を1つの画像にまとめる（CSS Sprite）
- 先読みを行う
- 遅延読み込みを行う
多くのサイトにとって、画像を利用しないという選択肢は存在しない。時にモバイルでサイトを閲覧しようものなら、画像の読み込みに多くの時間を費やすこととなる。
以前にもページ分けについてニュースサイトが記事のページを分ける理由を考えてみたことがある。Googleが100件ではなく10件しか結果を表示しないことについて、
一度に全内容を送ると読めるまでに時間がかかる
という意見は、今になって振り返れば、テキスト情報を送信するという意味において、それほど問題のあることだと思えない。これはユーザから何のクエリが来るか分からないため、事前にキャッシュを行うことができず、常に動的生成しなければならないために生じる制限であり、10件を100件にすると単純に10倍の時間がかかるということが関連しているのだろうと思うようになった。
検索試行の8,9割は1〜10件までの検索結果しか見ない。そういった数字がどこかにあるのだろうと仮定する。そうしたときに、残りの90件あまりの計算は無駄になる。そして検索時間が10倍になることによってユーザー離れが起きる。そのことから、10件程度が妥当だ、という考えに至ったのだろうではないか、と推測している。
しかし、このような問題がニュースサイトやショップサイトに当たるのか？、と考えた場合、否である。ニュースサイトやショップサイトは、自身が持つ情報を全て把握しており、動的コンテンツからキャッシュした静的コンテンツで問題ないはずである。そうした方が、常に動的に生成するよりも何倍も高速になる。その方が有利なはずだ。
課題は、その製品の現在の状況（価格や在庫）がどうなっているかなどの情報や、各個人に個別に合わせた商品の見せ方をしたい場合、そして画像が多い場合である。
例えば、在庫の状況などを逐一変更できるシステムを作成した場合、その変更ごとにページのキャッシュの更新が行われることになる。そのときの問題は、”キャッシュを生成してから誰にも閲覧されていないのに再度キャッシュを更新したときにかかる負荷”であると考えられる。これは、閲覧：更新の割合に関連しており、常に閲覧されている状況であればキャッシュ生成は効果的に働くと考えられるが、更新が多いシステムの場合は事前キャッシュ生成に時間がとられてしまい、その間システムの負荷は高くなってしまう。
その真ん中の案しては、”更新が合った場合には関連するキャッシュを削除し、アクセスがあったときにキャッシュを生成する”というものだが、キャッシュが削除されている間にアクセスする人は待ち時間を感じてしまう。更新が多いシステムの場合、常にキャッシュ生成を訪問者が行うことになるので、結局は読み込み時間のかかるサービスに見えてしまう。
この状況を打破するべく、少し前に流行ったものがAjaxである。更新される情報というものは一部であり、他の多くの固定の情報はキャッシュしてしまう。更新される情報は、後から読み込みしよう、というものである。こうすることで、固定の情報にかかる生成時間は削減され、動的な情報のみを引き出すことができる。一例を出せば、RSSやTwitterの更新情報を引き出すブログパーツというものも、ブログシステムに負荷を与えずに表示することができる。この負荷の分散という考え方がマッシュアップ近辺で行ったもので、提供する側も提供される側もお互いに得になるという話だ。
ページ送り、ページ分けの話に戻ると、こうした遅延処理をしっかり行えるのであれば、ページ送りなどというものは必要ないのではないか、という考えがある。しかしながら、遅延処理を行っても、1ページ100件の要求を1ブラウザがサーバに送りつけるのだから、たまったものじゃない。せいぜい1ブラウザが表示できるのは10〜20件程度じゃないか、と。画像についても同様であるが、例えば100件の画像を一気にブラウザが読み込みという状況は望ましくない。
これに対してTwitterでは、ボタンを人の手で押させることで遅延読み込みを実現している。だが、この作業は非常に面倒だ。
昨今では、ブラウザのスクロールにあわせて情報を追加していく、という流れが出てきている。ブラウザの画面に表示されるので、画像を取得する・情報を取得する、ということが必要なのであって、見られないのであれば情報を取得する必要も無い。見られる可能性というものは、ブラウザのスクロール位置に強く関連している。つまり、スクロール位置とコンテンツの位置から、割り出し、表示されそうだということがわかってはじめて遅延読み込みを行う。
この1例が例えばAppleの商品ページに見られる。98件の商品をページ送りすることなく表示している。ページをスクロールしていくと、画像がフェードしながら表示されるが、これは遅延読み込みをうまくごまかしている。
その他の例として、AutoPagerizeというGoogleの検索ページの下に来ると勝手に次の検索結果のページを読み込んでページをつなげてくれるプラグインがあるが、これも遅延読み込みである。
楽天の商品ページを見ていると、売れ筋商品のページは、ものすごく縦に長い。カルチャーショックを受けるが、そこにはページ送りをさせない（というよりできない仕様？）という形が存在している。それでも物が売れるのであれば、ページ送りとは何だったのだろうか、と最近は思うに至る。
# ちなみに先読みに関してはWebStorageが熱いと感じた次第であります