Project Note

Googleから検索結果の順位決定の条件にページの読み込み速度を考慮することが発表されています。
新しいランキングアルゴリズムから対応するとか、ページの関連性に比べて比重が小さいとかありますけど、表示の速度は早い方が良いよ。遅いとイライラするだけですし。

Googleウェブマスターツールでサイトの情報を見ていると、検索キーワード(上位のキーワード、ランキング、何ページ目からジャンプしてきたか)とか、クロールの統計情報(1 日あたりのクロールされたページ数、ダウンロード量、時間)だとかデータとして表示されます。
最近「実験的な機能」のところに「サイトのパフォーマンス」が加わりました。

これが将来的に順位決定で考慮されるものであることは明らか。気に入らないのは「全体の 97% にあたるサイトよりも遅い読み込み時間です。」と表示されちゃうところです。今のページだと平均読み込み時間は 12.5 秒らしいのです。HTMLだけならもっと早く表示されているけど、完全に読み込まれるだけ待つと結構掛かるらしいです。

それに平均だからな。ブログのトップ画面は遅い方です。高速なのは管理者用のログイン画面です。特に遅いのは検索結果ですね。
ブログのトップが遅いのはAmazonやTwitter、写真などのブログパーツがあるからかと思います。他のサイトを見に行ってくるので少し待つ感じです。
検索結果は1ページで返してくるから、ヒット数が多いとそれだけページが伸びて、写真も動画も読み込まれるのです。これは複数ページに分けて表示したいところですね。

---

タイトルの「サーバのレスポンスを上げる方法について」は今後どのようにするべきだろうか？
一つ目は「サーバ機のリプレース」、
二つ目は「ブログパーツの利用中止」、
三つ目は「CGIの改修」

今のサーバ機は中古のパソコンで動いているので、これを最新のパーツで作ったら物理的に早くなります。
HDDをSSHにするべき。OSのサーバ用とか64bitにしてしまうとかね。64bitならメモリも多く積めます。

遅い機能は外してしまえば早くなる。しかし機能的に使えなくなるのは困るので、キャッシュしてしまうとか？
1日1回くらいでブログパーツの状態をキャプチャして画像ファイルにしてしまう。クリックされたら本来の機能にジャンプとか。アクティブなブログパーツでは良さがまったく失われてしまうので、この方法は欠点が多いな。

遅いプログラムは作り方を変えれば早くなります。単純にPHPでテンプレートエンジンを使えば動的に出力したページでもキャッシュが自動的に行われて早くなるとか。
テキストベースで処理しているページの作成も、ログをＤＢに入れてSQLで取得する。MySQLを使うと取得するレコードを範囲指定できるのでページ単位で検索結果を表示するのも楽になります。

---

■Using site speed in web search ranking