googleさまの記事によるとページ表示は最悪でも２秒以内、理想は１秒以内。amazonに関する記事だと表示が0.1秒遅くなると売上が1%落ちるし、googleの記事だと表示が0.5秒遅くなると検索数が20%落ちる。らしい。

かたやECサイトだし、もう一方は検索で広告商売なので、こうしたデータからすると、表示速度は売上直結死活問題。コミュニティサイトやブログ、ニュース系サイトなどはそこまでシビアじゃないと思うけど、待たされるのはストレス、に違いはない。

情報設計とか、ユーザビリティとか、機能面とか、デザインとか、いろいろ言われて、サイト作りに盛られていく。この過程で、組織内の大きな声の人間や、正論クンの言うとおりになってしまって、表示速度のことに気づくのが、ほぼサイトが完成する公開直前のテストだったりして仰け反ることになる。

そりゃ、そんな機能あったらいいよね。キャッチーで人目をひくよ、このデザイン。動線確保のためにショートカットリンクは常に表示だよ、やっぱり。

なんてことやってると、表示速度は、確実にコンマ何秒かずつでも遅くなっていく。サーバーの設定で頑張って、プログラムで頑張ってるのに、わざわざ遅くなる要因をつけ足してることに変わりない。

どんな魅力的なサイトでも使ってもらってなんぼ。アクセスしてページが開くのに、ひと呼吸もふた呼吸も待たされたんじゃ、面倒で離脱する。リピータになってくれてるのに、いつも使ってるうちにイライラがたまって、そのうちアクセスしなくなる。

てことで、この雑記帖みたいな辺境も、twitterやamazonからデータを取得するコンテナが増えてくると、その分表示速度が落ちてくる。なので、ごそごそいじって、ajaxでの取得に切り替えた。ページ全体の表示とはまた別扱いなのが、ajaxのいいところ。今まで4秒ぐらいかかってた表示がぎりぎり2秒台まで短縮できた、かな（前職のダウンロード配信サイトでは、ストップウォッチを片手に表示速度をチェックして、速度が出ないので公開延期になったりもした）

てな細工を先日やったこともあって、表示速度について、電子書籍検索サイト「電子書籍を探すなら hon.jp」のAPIをちょっといじってみて気になった。ここは、電子書籍を総ざらいで検索できるのでかなり便利なサイト。perlでごそごそいじってウチに組み込もうとしたところ、速度が出ない。RESTのURIをそのままブラウザに入れても、レスポンスがかなり遅い。6秒程度かかるケースもある。

↓たとえばこんな検索

キーワード：山田風太郎・ジャンル：国内文学・ハードウエア：iphone

ユーザーページも、本を起点にユーザーを結びつけたり、ajaxで画面遷移なく直観的に使えるようにしたり、機能豊富でやろうとしてることは大賛成だし、かなり面白い。でも、ここも速度が出てない。一度公開してしまってる機能を引っ込めるのはちょっとアレだけど、整理して速度を見直すか、速度が出てなくて待たされてる感を少しでも軽減できるような効果を検討するとか、お願いしたいところ。

文句ばかりつけたけど、電子書籍検索に関して、このサイトは本当にオススメ！

あと、やっぱりなんちゅーか。電子書籍に統一のコードがないのが（？）困る。

『続・ハイパフォーマンスWebサイト ―ウェブ高速化のベストプラクティス』

スティ-ブ・サウダ-ズ