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
