Webサイトを運用していると、レスポンスが追い付かなくなってくることがある。それを追究して対策を打つのもSEの仕事だ。サーバ側のCPU・メモリ・ネットワーク・ディスクなど、ボトルネックを探すことが重要だが、まずはお客様側（ブラウザ側）で何が重くなっているのかを知ることも重要。
そんな時役に立つのが「Page Test」だ。見つけてくれた社員のＹ野リーダー、ありがとう。
■PageTest Web Page Optimization and Performance Test
▼ステップ１
測定したいページのURLやURIを入力。
▼ステップ２
そのURLに接続してクライアントPCをシミュレートする回線帯域を選択。ダラスから繋げてくれているようだ。一番目はファイバー回線、二番目はADSL回線、三番目はダイアルアップ回線をシミュレートしてくれている。
▼ステップ３
何回実行するか、などのオプションを選択。
▼ステップ４
実行
すると、しばらくテスト中ページが出てから、こんな結果が表示される。
先頭の数字だけの表は、１行目がキャッシュなしでの測定、２行目がキャッシュありでの測定と見なしてよさそう。
その後の表は、左側がページを読みこんでいくシーケンスを表したもの、右側は各オブジェクトがどんな状態であり何を改善すべきかアドバイスしてくれている。それぞれの画像をクリックすると、詳細に表示してくれる。
分かりやすいViewですね。1.4秒でページは見えてくる(レンダリングが開始される)が、全画像なども読み込むには11秒近くかかっているということが分かる。この中で遅いのがi2iのアクセスカウントのためのphp。緑が長いというのはサーバへの接続が待たされているということ。そこで待たされているので、その後の他のブログパーツ群読み込みも待たされている。なるほど。
ということは、i2iのアクセスカウントパーツは、なるべくページの後ろに置く方が良いということが分かる。で、実験してみる。思い切ってi2iアクセスカウンターパーツをフッターの一番最後に置いてみる。
i2iが一番後ろになった。今回はたまたま早かったけど、そもそもViewにはi2iは影響ないことなのでこうすべきですね。
ということで、Webサイトのレスポンスにお悩みの皆さん、お試しください。
なお、自分のクライアント環境からテストできるツールはIBMから「Page Detailer」というソフトがあります。こちらは、米IBMサイトにアカウント登録するとフリーでダウンロードできるソフトで、同じようにサイトレスポンスの解析が出来ます。手元の環境ならではの問題を追究するには、こちらがオススメです。
■alphaWorks : IBM Page Detailer : Overview
コメント