Webサイトパフォーマンスの可視化でボトルネックを改善／読者のサイトをプロが診断 [単発記事] | Web担当者Forum

Webサイトパフォーマンスの可視化でボトルネックを改善／読者のサイトをプロが診断 [単発記事] | Web担当者Forum: "

Web担3周年を記念した読者プレゼント企画の中でも、Web担ならではのプレゼントだった、各分野のプロによるあなたのサイト診断レポート。まずは、株式会社サムライズ提供のプレゼント「あなたのサイトのWebサイトパフォーマンス診断 Experience First」から、当選者の発表と結果レポートをお届けします。



申し込みサイトのなかから当選してパフォーマンス測定&アドバイスをゲットしたのは、次の3サイトです。



  • アルネットホーム

  • ビートップス

  • 鍵のハイパーレスキュー



当選、おめでとうございます！ では、1サイトずつ、株式会社サムライズ提供のWebサイトパフォーマンス測定ツール「Experience First」を用いて解析を行った3サイトの診断結果とアドバイスをお届けしていきましょう。



当選サイトのWeb担当者さんにはもちろん、それ以外の方にも参考になる情報が満載ですよ。





パフォーマンス測定に関する調査概要やレポート内で解説している数多くの専門用語、またExperience Firstの製品情報は記事末尾でまとめて紹介しているのでそちらも参考にしていただきたい。



本診断では、国内のさまざまな拠点・接続環境に設置されたパソコンから対象サイトへのアクセスを試み、応答時間や通信状態を定点調査した。接続の過程で得られるサイトのさまざまな情報をもとに、通信状況をウォーターフロー図で可視化することで、サイトのボトルネックを割り出しパフォーマンス改善がねらえるポイントをピックアップして解説している。





ケーススタディ1：アルネットホーム





アルネットホームのトップページ
アルネットホームのトップページ




アルネットホームのトップページ（www.alnethome.com/）は、ページ総容量433KB、HTTPリクエスト数52（※測定時点の数値）の、今回測定した3サイトの中では2番目の容量を持つページとなる。3サイト中では、ちょっと手を入れることでパフォーマンスが改善される可能性を一番持っているサイトであった。




初めに、バックボーンテスト※1の結果から得られた、応答時間の平均値（4時間ごと）を示した折れ線グラフを確認していこう。





時系列でみた平均応答時間の変化（アルネットホーム）
時系列でみた平均応答時間の変化（アルネットホーム）




  • 平均応答時間：0.608秒

  • 最小応答時間：0.458秒

  • 可用性：100％

  • 標準偏差：0.2秒






9月14日に一度だけ応答時間が3秒を超えた以外は、測定結果の約95％が1秒以内に収まっている（平均応答時間：0.608秒）非常に安定したページだといえる。さらなる施策を講じるのであれば、応答時間にしきい値を設けて、応答時間が1秒以上になったらサイト担当者に、3秒以上ならチーム全員に自動でアラートメールを送信するといった運用監視を行うことでトラブル時に速やかに対応できる（この機能はExperienceFirstにも搭載されている）。




実際のユーザーはどう感じているのか



続いて、ラストマイルテスト※2でユーザーが実際に体験している応答時間を測定したのが次のグラフだ。バックボーンテストに比べて、さまざまなユーザー環境の違いが反映されたデータになっている。それぞれテストに使用されたパソコンの回線速度は以下の通り。




  • ダイアルアップ接続（Dial Up）：56kbps未満の低速回線

  • 低速ブロードバンド接続（Low Broadband）：56kbps以上512kbps以下の中速回線

  • 高速ブロードバンド接続（High Broadband）：512kbpsを超える高速回線




時系列でみた接続回線別の平均応答時間の変化（アルネットホーム）
時系列でみた接続回線別の平均応答時間の変化（アルネットホーム）





































接続回線 平均応答時間 可用性 エラー数 テスト回数
ダイアルアップ接続 59.184秒 75.00％ 6 24回
低速ブロードバンド接続 25.525秒 94.29％ 6 105回
高速ブロードバンド接続 4.198秒 99.47％ 1 189回



ダイアルアップ回線の平均応答時間は59.184秒で、可用性が75％と、当然だが回線速度の低下を受けて応答時間が長くなり、ユーザーエクスペリエンスの劣化を招いていることが確認できる。さらに、この応答時間の内訳を通信フェーズ毎に分けたのが以下の表だ。





接続回線別通信フェーズ毎の応答時間（アルネットホーム）










































通信フェーズ ダイアルアップ接続 低速ブロードバンド接続 高速ブロードバンド接続
応答速度※3 59.184秒 25.525秒 4.198秒
DNS Time※4 0.926秒 0.394秒 0.199秒
Connect Time※5 26.412秒 15.311秒 2.062秒
1st Byte Time※6 28.848秒 14.049秒 2.811秒
Content Time※7 56.604秒 17.796秒 2.687秒




回線速度が遅くなるにしたがって応答速度に対するContent Timeの比率が高まっている。つまり、中低速回線でのパフォーマンス低下を回避するためには、ページ容量をさらに小さくする必要があるのだ。さらに、Connect Timeの比率も回線速度の低下に比例して上昇しているが、後述するHTTP Keep Aliveという手法を用いることでこの問題は改善可能である。






アルネットホームへのプロのパフォーマンス改善ポイント




バックボーンテストの結果から代表的なデータを1つ選び、ウォータフォールグラフにしてさらに深い分析を行った結果が次ぎのとおりだ。








通信フェーズ別の接続状況のウォーターフロー図（アルネットホーム）


































通信フェーズ 所要時間
応答時間 0.608秒
DNS Time 0.018秒
Connect Time 0.268秒
1st Byte Time 0.413秒
Content Time 0.473秒







HTTP Keep Alive手法を用いた接続数の削減




このページを表示する過程で合計51個のHTTP接続が行われているが、HTTP Keep Alive※8が使用されていない。HTTP Keep Aliveとは、Webサーバーとの間で確立した接続をデータ転送終了後も維持することで、2回目以降のリクエストの接続処理を省略するためのテクニックだ。



HTTP Keep Aliveを活用することで、現状オブジェクトごとに開閉しているTCP接続の時間（グラフ上、オレンジ色で示されているConnect Time）を節約できる。接続合計51個の内、外部サイトへの接続（google-analytics.comの2つとengross.info）を除いたアルネットホーム（211.133.244.78）への接続が48個。その内、最初の2回以降である46回のTCP接続を回避できる。Connect Time 0.268秒の実に9割以上を削減できるだろう。




複数オブジェクトの組み合わせによるHTTPリクエスト数の削減



次に、このページ内のHTTPリクエストの数自体を減らせばページの表示に掛かる時間が短縮できる。このページでは以下のオブジェクトが読み込まれている。




  • 画像：35個

  • JavaScript：10個

  • CSS：4個



画像はCSSスプライト※9やイメージマップ※10と呼ばれる手法を用いて画像を1枚に組み合わせれば、HTTPリクエスト数を減らすことが可能だ。また、10個のCSSと4個のJavaScriptはそれぞれ1個にまとめてファイル数を減らせば、さらにHTTPリクエストの数が削減できるため、表示速度の高速化を実現できる。




@importの使用回避でオブジェクト読み込みの適正化



グラフから、Google Analyticsへのデータ送信が、ページの読み込み開始直後に行われているのが確認できる（10行目）。Google Analyticsのトラッキング コードが</body>の直前に配置されているにもかかわらず、データが正しいタイミングで送信されていないのは、import.css内で@importが使われているからだと推測される。



Webページを上部から徐々に表示させることで、ユーザーエクスペリエンスを向上するためには、CSSファイルをソースの上方に記述する必要がある。import.cssは<head>タグ内に存在するが、import.cssを分析してみると@importを使用してさらに4つのCSSファイルをダウンロードしている。Internet Explorerは、CSSの読み込みが@importで指定されている場合には、それがHTMLの先頭部分にあったとしても、<link>タグをページの最後に記述してCSSを読み込んむ場合と同様の動きをするために、CSSファイルの読み込みが最後に実行され、ページ表示が遅れる可能性がある。また、Google Analyticsのページビュー数集計への影響も考えられる。




ファイル容量の圧縮で転送時間の短縮を



Content Timeを短縮するためには、フブラウザが読み込むァイルのサイズを小さくするのが良い。画像ファイルにはしっかりと圧縮をかけ、JavaScriptやCSSはコード内のコメントや改行を省くことで容量を縮小できる。コメントや適切な改行は開発者にとって必要不可欠だが、Webサイトパフォーマンスの観点では通信量を増加させる要因の1つとなってしまう。



また、HTTPレスポンスにgzip圧縮※11が実装されていない。HTMLファイル、10個のCSS、4つのJavaScriptの合計約72KBを圧縮することで、HTTPレスポンスの容量を小さくし、転送に必要な時間を短縮することが可能できる。これは、特に回線速度が遅いユーザーへには効果的だ。




404エラーによる不要なリクエスト・レスポンスの回避



ページオブジェクト読み込みの最初の方で、404エラーが発生している（グラフ上の赤線：Connection 6に対するレスポンス）。リンク先にファイルがないというエラー（HTTPレスポンス404）を受信するためだけに、HTTPリクエストを送信しているのだから、不要なリンクであれば削除したほうがいい。




他にも、オブジェクトに対するExpiresヘッダー※12を設定してブラウザキャッシュを活用する施策なども考えられる。






  • ケーススタディ2：ビートップス

  • ケーススタディ3：鍵のハイパーレスキュー

  • 調査概要や専門用語の一覧、製品紹介





ケーススタディ2：ビートップス





ビートップスのトップページ
ビートップスのトップページ



テレビ通販・テレビショッピングサイトであるビートップスのトップページ（www.b-tops.com）は、ページ総容量が平均1.1MB、HTTPリクエスト数130（※測定時点の数値）の、今回計測した3サイトの中で最も容量が大きなページである。



初めに、バックボーンテスト※1の結果から得られた、応答時間の平均値（4時間ごと）を示した折れ線グラフを確認していこう。






時系列でみた平均応答時間の変化（ビートップス）
時系列でみた平均応答時間の変化（ビートップス）




  • 平均応答時間：2.001秒

  • 最小応答時間：1.137秒

  • 可用性：100％

  • 標準偏差：1.94秒




バックボーンテストの測定期間中、ほとんどの時間帯で約2秒の応答時間と安定（平均応答時間：2.001秒）しているものの、5秒前後の急な増加を数回記録している。この結果が何の影響によるものか、サーバー監視やアクセス解析との併用で調査を行うべきだといえる。



続いて、ラストマイルテスト※2でユーザーが実際に体験している応答時間を測定したのが次のグラフだ。バックボーンテストに比べて、さまざまなユーザー環境の違いが反映されたデータになっている。





時系列でみた接続回線別の平均応答時間の変化（ビートップス）
時系列でみた接続回線別の平均応答時間の変化（ビートップス）





































接続回線 平均応答時間 可用性 エラー数 テスト回数
ダイアルアップ接続 50.765秒 32.14％ 19 28回
低速ブロードバンド接続 36.715秒 90.53％ 9 95回
高速ブロードバンド接続 8.401秒 98.96％ 2 193回



512kbps以下の中低速回線では応答時間が急激に増加していることが確認できる。さらにダイアルアップ接続（56kbps以下）では、可用性が32.14％に激減、これは28テスト中19テストにおいて2分以内にページ表示が正常に行われなかったことを示している。





接続回線別通信フェーズ毎の応答時間（ビートップス）










































通信フェーズ ダイアルアップ接続 低速ブロードバンド接続 高速ブロードバンド接続
応答時間 50.765秒 36.715秒 8.401秒
DNS Time 0.853秒 0.747秒 0.296秒
Connect Time 1.858秒 1.748秒 0.265秒
1st Byte Time 41.365秒 24.541秒 8.153秒
Content Time 61.584秒 45.892秒 7.030秒



通信フェーズごとの数値を確認すると、特に回線速度が遅い場合には応答時間に占める1st Byte TimeとContent Timeの比率が高く、オブジェクトの容量とHTTPリクエスト数が影響していることが想定できる。




ビートップスへのプロのパフォーマンス改善ポイント



バックボーンテストの結果から代表的なデータを1つ選び、ウォータフォールグラフにしてさらに深い分析を行った。






通信フェーズ別の接続状況のウォーターフロー図（ビートップス）




JavaScriptの記述場所によるダウンロードの効率化



グラフから、Google Analyticsへのデータ送信が、ページの読み込み開始直後に行われているのが確認できる（7行目）。HTTP Keep Aliveを使用していても、JavaScriptの読み込み後にキューに入力されたオブジェクトは、そのJavaScriptが実行されるまではダウンロードが中断されるため、JavaScriptはできるだけソースの下のほうに記述するのが望ましい。また、パフォーマンスの観点からだけでなく、ページ表示が完了する遥か前にGoogle Analyticsへのデータ送信が行われると、ページビュー数の集計に影響が及ぶ可能性も考えられる（Google Analyticsのトラッキングコードは、ページの</body>タグ直前への設置が推奨されている）。



ホスト追加による並列ダウンロード数の増加



すべての画像が1つのホスト（125.29.37.197）からダウンロードされている。HTTP Keep Aliveを使用することで同時に2ファイルを並列ダウンロードできるが、さらにホストを追加することで3ファイル以上の並列ダウンロードが可能になる。ホストへの接続時間（DNS TimeとConnection Time）を差し引いても全体的なパフォーマンス向上が達成できるかもしれない。



CSSスプライトやイメージマップを活用したHTTPリクエストの削減、画像を除くオブジェクトファイルのgzip圧縮など、ケーススタディ1で述べた内容は説明を割愛しているので、そちらも参照してほしい。






  • ケーススタディ3：鍵のハイパーレスキュー

  • 調査概要や専門用語の一覧、製品紹介






ケーススタディ3：鍵のハイパーレスキュー




鍵のハイパーレスキューのトップページ
鍵のハイパーレスキューのトップページ



鍵のハイパーレスキューのトップページ（www.key-hyper-rescue.jp/）は、ページ総容量が平均207KB、HTTPリクエスト数73（※測定時点の数値）の、今回測定した3サイトの中で最も容量が小さいページだ。



初めに、バックボーンテスト※1の結果から得られた、応答時間の平均値（4時間ごと）を示した折れ線グラフを確認していこう。




時系列でみた平均応答時間の変化（鍵のハイパーレスキュー）
時系列でみた平均応答時間の変化（鍵のハイパーレスキュー）




  • 平均応答時間：1.051秒

  • 最小応答時間：0.543秒

  • 可用性：100％

  • 標準偏差：0.335秒（3秒以上の測定結果2つを除外）




2週間の平均応答時間は約1秒。3秒を超える応答時間が2度計測されているが、定常性は見当たらず、ばらつきが少ない安定したサイトだといえる。



続いて、ラストマイルテスト※2でユーザーが実際に体験している応答時間を測定したのが次のグラフだ。バックボーンテストに比べて、さまざまなユーザー環境の違いが反映されたデータになっている。




時系列でみた接続回線別の平均応答時間の変化（鍵のハイパーレスキュー）
時系列でみた接続回線別の平均応答時間の変化（鍵のハイパーレスキュー）





































接続回線 平均応答時間 可用性 エラー数 テスト回数
ダイアルアップ接続 31.759秒 83.33％ 5 30
低速ブロードバンド接続 10.427秒 93.16％ 8 117
高速ブロードバンド接続 2.830秒 100.00％ 0 193



これまで診断してきた2サイトに比べると、ダイアルアップ接続でも83.33％の可用性があり、中低速回線においても応答時間に大きな劣化がみられない。ページ容量の小ささが貢献していると考えらる。





鍵のハイパーレスキューへのプロのパフォーマンス改善ポイント



バックボーンテストの結果から代表的なデータを1つ選び、ウォータフォールグラフにしてさらに深い分析を行った。








通信フェーズ別の接続状況のウォーターフロー図（鍵のハイパーレスキュー）









Expiresヘッダーを用いたキャッシュの有効利用



各オブジェクトにExpiresヘッダーが付いていない。頻繁に入れ替わる画像などでなければ、遠い未来の日付のExpiresヘッダーを設定しておくことで、サイト内でのページ遷移時やページの更新時にブラウザにキャッシュされたオブジェクトが利用される。結果、不必要なHTTPリクエストを回避できる。






  • 調査概要や専門用語の一覧、製品紹介







調査概要





  • 調査対象


    Web担3周年記念プレゼント「あなたのサイトのWebサイトパフォーマンス診」にご応募いただいた中から編集部・サービス提供者によって選定した以下の3サイト


    • アルネットホーム様

    • ビートップス様

    • 鍵のハイパーレスキュー様





  • 調査手法・期間


    • バックボーンテスト


      • 調査手法：東京都内の通信事業者データセンター内から診断対象サイトへのアクセスを1時間間隔で測定。日本国内の最良のユーザーエクスペリエンスを再現できる測定方法。


      • 調査期間：2009年9月2日午前0時～9月16日午前0時（2週間）




    • ラストマイルテスト


      • 調査手法：米国Gomez, Inc.社が全世界で契約している約12万台の一般ユーザーのパソコンの中から、日本国内のパソコン15台を選出。実際のユーザーエクスペリエンスを測定。


      • 調査期間：2009年9月16日午前0時～9月18日午前0時（2日間）








  • 調査項目


    • バックボーンテスト

      • 平均応答時間

      • 最小応答時間




    • ラストマイルテスト

      • 接続回線別応答時間




    • 各応答時間に関してはさらに細かく測定

      • DNS Time

      • Connect Time

      • 1st Byte Time

      • Content Time





  • 調査実施機関

    株式会社サムライズ


  • 測定ツール

    ExperienceFirst





Webサイトパフォーマンスに関する専門用語




  • HTTP Keep Alive

    HTTPの持続接続。それぞれのHTTPリクエストが新しい接続を開くのではなく、複数のHTTPリクエスト・レスポンスが同一のTCP接続を使用する。ネットワーク通信量を抑えることができるので、サイトのパフォーマンス向上に非常に重要である。


  • CSSスプライト

    複数の画像を1枚の画像としてまとめ、CSSで範囲を指定することでそれぞれの個別の画像ように表示させる手法。


    サンプル：Web担の右サイドバーにある「連載／特集コーナー一覧」では、各連載・特集のアイコンを一枚絵にしたものを利用している。


  • イメージマップ

    1つの画像内に複数のURLを関連付ける手法。


    TAG indexの「画像内に複数リンクを設定する」に詳細な解説がある。



  • gzip圧縮

    クライアントへのHTTPレスポンスを圧縮することで転送量を小さくする手法。データ圧縮方法としてgzipを用いている。転送時間の短縮に繋がるが、サーバー側での圧縮、クライアント側での解凍処理が発生するため、ファイルサイズで判断する必要がある。


  • Expiresヘッダー

    キャッシュの有効期限。ブラウザがオブジェクトをキャッシュする際には、HTTPレスポンスに含まれるExpiresヘッダーも保存する。有効期限が切れていない間はキャッシュされたファイルが使用されるため、HTTPリクエストは発行されず、ページの表示時間が短縮できる。






ExperieceFirstに関する専門用語




  • 応答時間

    HTTP通信が開始されて、HTMLページ内の全てのオブジェクトの受信が完了するまでの時間。本測定では、フラッシュ内から二次的に呼ばれているオブジェクトは含んでいない。


  • DNS Time

    あるドメイン名からそれに対応するIPアドレスを引き出す「名前解決」に要する時間。たとえば、「www.samuraiz.co.jp」と送信されたURLの場合は「192.168.1.102」に変換される。


  • Connect Time

    名前解決（DNS参照）が完了した後、ブラウザがウェブサーバーとのTCP接続に要するまでの時間。



  • 1st Byte Time

    ブラウザからウェブサーバーへHTTPリクエストの最後のパケットが送信されてから、ブラウザがウェブサーバーから最初のパケット（最初のバイト=1st Byte）を受信するまでの時間。


  • Content Time

    HTMLページや画像ファイルなどのオブジェクトの最初のバイト（1st Byte）を受信してから、そのオブジェクトのダウンロードが完了するまでの時間。







ExperienceFirst - Active XF







米国 Gomez, Inc.社が契約している全世界で約12万の測定ポイントを利用し、ユーザー視点からあなたのウェブサイトのパフォーマンス監視を行えるソリューション。アラート機能やさまざまな切り口での分析を可能とする豊富なレポート群が、安定した運用とパフォーマンス改善のお手伝いをします。



上記は、米国Gomez, Inc.社製品「ExperieceFirst」を使用して解析した結果です。詳しい製品情報は下記サイトからお問い合わせください。





本レポートは、Steve Souders著『High Performance Web Sites（日本語訳：ハイパフォーマンスWebサイト）』で説明されているルールを基にしています。






関連リンク




この記事に関連する他の記事を見る




※このコンテンツはWebサイト「Web担当者Forum - 企業ホームページとネットマーケティングの実践情報サイト - SEO/SEM アクセス解析 CMS ユーザビリティなど」で公開されている記事のフィードに含まれているものです。
オリジナル記事：Webサイトパフォーマンスの可視化でボトルネックを改善／読者のサイトをプロが診断 [単発記事] | Web担当者Forum
Copyright (C) IMPRESS BUSINESS MEDIA CORPORATION, an Impress Group company. All rights reserved.



"
Posted by da-i at 0:49 | 0 comments read on

Recently

Archives

2009/08/16 2009/08/17 2009/08/18 2009/08/19 2009/08/20 2009/08/21 2009/08/23 2009/08/25 2009/08/26 2009/08/27 2009/08/28 2009/08/29 2009/08/30 2009/09/01 2009/09/02 2009/09/03 2009/09/05 2009/09/06 2009/09/07 2009/09/08 2009/09/09 2009/09/10 2009/09/12 2009/09/15 2009/09/17 2009/09/19 2009/09/20 2009/09/23 2009/09/24 2009/09/25 2009/09/26 2009/09/27 2009/09/29 2009/09/30 2009/10/02 2009/10/05 2009/10/08 2009/10/10 2009/10/18 2009/10/24 2009/10/28 2009/11/01 2009/11/04 2009/11/07 2009/11/10 2009/11/11 2009/11/21 2009/11/23 2009/11/24 2009/11/25 2009/11/30 2009/12/01 2009/12/07 2009/12/16 2009/12/23 2010/01/03 2010/01/06 2010/01/12 2010/01/15 2010/01/19 2010/01/27 2010/02/09 2010/02/14 2010/04/28


Links