メインコンテンツへ
短.be

TTFB

ブラウザがリクエストを送ってから最初の 1 バイトを受信するまでの時間。目安は 800 ミリ秒以下で、 CDN 配置 / キャッシュ活用 / リダイレクト削減などで短縮できる。

2026年9月8日 · 約 1 分で読めます

リダイレクト

TTFB (Time to First Byte) とは、ブラウザがそのページへの移動を開始してから、サーバーからのレスポンスの最初の 1 バイトが届き始めるまでの時間です。サーバーの応答速度を測る最も基本的な指標であり、Web パフォーマンスの出発点です。

TTFB に含まれるのは、リダイレクトに費やされた時間、Service Worker の起動時間、DNS の名前解決、接続と TLS のネゴシエーション、そしてリクエストを送ってからレスポンスの最初の 1 バイトが届くまでの時間です。サーバー内部の処理時間はこの最後の区間に含まれます。そのため TTFB が大きいときは、サーバーの処理が重いのか、それ以前の接続や名前解決の段階で待たされているのかを切り分けて見る必要があります。

Google は Core Web Vitals の補助指標として TTFB を位置づけており、良好な TTFB は 800ms 以下、800ms から 1800ms までが改善の必要な範囲、1800ms を超えると不良としています。短縮 URL のリダイレクトでは、TTFB がリダイレクトレスポンスの返却速度に直結するため、50ms 以下を目標にすべきです。

短縮 URL サービスの TTFB を最適化する手法として、CDN の活用 (ユーザーに近いエッジサーバーからレスポンスを返す)、インメモリキャッシュ (Redis で短縮 URL のマッピングをキャッシュ)、データベースの最適化 (インデックスの適切な設定)、HTTP/2 の有効化 (接続の多重化) があります。

TTFB の測定は、Chrome DevTools の Network パネルのタイミング内訳にある Waiting (TTFB)、Lighthouse のパフォーマンス監査、curl コマンド (curl -w '%{time_starttransfer}' URL)、WebPageTest で行えます。サーバー処理時間とネットワーク伝送時間を分離して測定することで、ボトルネックを正確に特定できます。

X でシェアはてブ

この記事は役に立ちましたか?

関連用語

関連記事

よくある質問

TTFB と LCP の違いは?
TTFB はサーバーの応答開始までの時間、LCP (Largest Contentful Paint) はページの最大コンテンツが表示されるまでの時間です。TTFB は LCP に先行する区間であり、TTFB にかかった時間の分だけ LCP の下限が押し上げられます。ただし Google は、サーバー側でレンダリングする構成では TTFB が大きくても FCP や LCP はかえって良い値になり得ると説明しており、TTFB だけで LCP の良否が決まるわけではありません。
TTFB の目標値は?
Google は 800ms 以下を良好としていますが、短縮 URL のリダイレクトでは 50ms 以下が理想です。CDN とキャッシュを活用すれば、10 〜 30ms 台まで詰められる構成もあります。
TTFB が遅い原因は?
サーバーの処理能力不足、データベースクエリの遅延、サーバーとユーザー間の物理的距離、SSL/TLS ハンドシェイクの遅延などが主な原因です。CDN の導入とキャッシュの最適化が最も効果的な改善策です。

知識を、実際のリンクで。

無料で URL を短縮する