Webレスポンス時間

計算式と考え方

応答時間は「DNS + 接続確立 + サーバー処理 + データベース + 転送」の合計です。DNS20ms、接続90ms、サーバー処理120ms、データベースは8回×6msで48msとなり、最初のバイトまでは278msです。転送は450KBを8倍して3,600Kb、実効帯域20Mbpsで割ると180msになり、合計458msです。基準の200msを258ms超えており、100msあたり1%の低下とすると2.58%です。月20万訪問・CV率2.5%では約129件に相当します。

応答時間の内訳と改善手段

Webレスポンス時間の詳しい解説

応答時間の議論では最初のバイトまでの時間が注目されがちですが、利用者が感じる待ち時間はそこに転送時間が加わったものです。この試算では最初のバイトまでが278ms、転送が180msで、転送が全体の4割を占めています。転送時間は転送量と実効帯域の割り算で決まるため、サーバーをいくら速くしても、画像や JavaScript が重ければ体感は改善しません。450KBを20Mbpsで送れば180msかかり、これが900KBになれば360msになります。改善の順序としては、まず転送量の削減が費用対効果に優れます。画像の形式変更と適切なサイズ指定、使っていないコードの削除、圧縮の有効化といった手当ては、サーバー構成を変えずに実施できます。サーバー処理の中では、データベースへの問い合わせ回数が支配的になることが多くあります。1回6msの問い合わせでも8回行えば48msです。一覧表示で件数分の問い合わせが発生する構造になっていると、20件で120ms、100件で600msという形で件数に比例して悪化します。この構造は開発時のデータ量では顕在化せず、本番でデータが増えてから問題になります。問い合わせをまとめる、必要な列だけを取得する、索引を適切に張るといった対応で、回数と1回あたりの時間の両方を下げられます。地理的な距離も無視できません。接続確立には往復が必要で、物理的な距離が遠いほど1往復の時間が伸びます。国内から海外のサーバーへ接続すると、それだけで100ms以上が加算されることがあります。コンテンツ配信網を使って利用者に近い拠点から配信すれば、DNS、接続、転送のすべてが短くなります。静的なファイルだけでも配信網に載せる価値があります。遅延と成果の関係については、応答時間が伸びるほど離脱率が上がり、コンバージョン率が下がるという報告が複数の事業者から公表されています。100msの遅延が売上に影響したという事例が知られていますが、影響の大きさは業種と利用状況で異なります。この試算では100msあたり1%という単純な近似を使っており、実際の値は自社で計測しないとわかりません。判断が分かれるのは、どこまで速くするかです。200msを下回ると、それ以上の短縮による体感の改善は小さくなり、投資対効果は落ちます。一方で1秒を超える領域では、100msの改善が明確な差になります。現在地がどこにあるかで、優先度は変わります。あわせて、平均値ではなく上位の遅い部分を見ることが必要です。平均が速くても、一部の利用者が数秒待たされている状態は、平均値では見えません。

業界・現場での使い方

よくある間違い・注意点

• 最初のバイトまでの時間だけを見る — 転送時間が全体の4割を占めることがあります。合計で評価してください。
• 平均値だけで判断する — 平均が速くても一部の利用者が数秒待っている場合があります。遅い側の分布を見てください。
• 開発環境のデータ量で性能を確認する — 件数に比例して問い合わせが増える構造は、本番でデータが増えてから顕在化します。

関連する規格・法規

• 業界標準
• ISO/IEC規格

※本ツールは公的基準に基づく参考計算です。実際の設計・施工・法令適用は最新の告示・規格および所轄官庁の判断に従ってください。

よくある質問（FAQ）

関連計算ツール