こんにちは、インフラ担当の森井康平です。
先日開催されたAWS Summit Japan 2026に、フェンリルはスポンサーとしてブースを出展しました。私もブースに立ってフェンリルのAWSビジネスについてご説明してきました。終日ブース対応をしていてセッションを見る時間はなかったのですが、イベント終了間近にぐるっと会場を見て回ったところ、「ヘッダー1行から始める！レイテンシ改善 Server-Timing × CloudFront」という展示が目に留まりました。
CloudFrontを経由するHTTPリクエストのオブザーバビリティを高められるのではと期待し、お話を聞いてきました。本記事はそこで興味を持ったServer-Timingについて、自分なりに掘り下げてみたものです。
配布されていたPDF資料はこちらです。
https://pages.awscloud.com/rs/112-TZM-766/images/AWS-Summit-Japan-2026_A142_1.pdf
Server-Timingとは
Server-Timing は、サーバーがレスポンスヘッダーを通じてクライアントにパフォーマンス計測値を渡すための仕組みで、W3Cで仕様化されています。
値は 指標名; dur=処理時間; desc="説明" という形式で表現され、1つのヘッダーに複数の指標をカンマ区切りで載せられます。クライアント側では、ブラウザの PerformanceServerTiming インターフェースや開発者ツールから読み取れます。
「バックエンドのどの処理に時間がかかっているか」をフロントエンドから可視化する用途を想定したもので、例えば db; dur=120; desc="DB query" のように、サーバー内部の区間を任意に計測して返すことができます。
CloudFrontのServer-Timing対応
CloudFront は2022年からこの Server-Timing に対応しており、レスポンスヘッダーポリシーで有効化できます。有効化時にはサンプリングレートを指定し、その割合のレスポンスにのみヘッダーが付与されます。ただし、リクエストヘッダーで Pragma: server-timing を指定するとサンプリングレートに関係なくヘッダーが付与されます。追加料金はかかりません。
CloudFront が付与する主な指標は次の通りです。
cdn-cache-hit/cdn-cache-miss：キャッシュヒットの有無cdn-cache-refresh：オリジンにキャッシュが有効であることを確認したcdn-pop：リクエストを処理したPoint of Presence (PoP)cdn-hit-layer：どの層でヒットしたか。EDGE（エッジキャッシュ） REC（リージョン別エッジキャッシュ） Origin Shield（オリジンシールド）のいずれかが指定されるcdn-upstream-dns：オリジンのDNS解決にかかった時間。0の場合はDNSキャッシュが利用されたか、既存の接続を再使用したことを示すcdn-upstream-connect：オリジンへの TCP/TLS 接続にかかった時間。0の場合は既存のTCP接続が再利用されたことを示すcdn-upstream-fbl：オリジン HTTP リクエストが完了してから、オリジンからのレスポンスで最初のバイトを受信するまでの時間cdn-downstream-fbl… エッジロケーションがリクエストの受信を終了してから、レスポンスの最初のバイトをビューワーに送信するまでの時間cdn-rid：リクエストID
キャッシュミス時には、オリジンが自前の Server-Timing を返すと、CloudFront はそれを上書きせず自分の指標を追記します。これにより、オリジン内部の区間（DB・画像処理など）まで1つのヘッダーに記録することができます。
レスポンスヘッダーポリシーを理解する - Amazon CloudFront
Server-Timingの注意事項
非常に有用そうなServer-Timingヘッダーですが注意事項もあります。
サーバーの内部情報がクライアントに露出する
Server-Timing はレスポンスヘッダーとしてクライアントに届くため、誰でもブラウザの開発者ツールから中身を見られます。CloudFront の指標で言えば、cdn-pop（着信したPoP）や cdn-hit-layer（ヒットした層）といった、CDNの内部的なルーティング・キャッシュ構成が外から観測できる状態になります。 オリジンが自前で db; dur=120 のような指標を返している場合はさらに注意が必要で、バックエンドの処理構成や、場合によってはどこが遅いかという弱点まで推測される余地が生まれます。
対策としては、本番で常時有効にするのではなく、調査時やステージングに絞る、サンプリングレートを下げる、オリジン側の Server-Timing は外向きには出さないといった運用が考えられます。
レスポンスヘッダーのサイズが増える
Server-Timing はレスポンスに付与されるヘッダーなので、そのデータ量がそのまま通信量に乗ります。CloudFrontで付与されるヘッダーのサイズは大きくありませんが、オリジン側でも値を追加している場合は処理の複雑度に応じてヘッダーサイズが肥大化する恐れがあります。
ここでも対策としてサンプリングレートを利用できます。サンプリングレートを絞れば、観測に必要な母数は確保しつつヘッダー増加の影響は最小化できます。
Server-Timingの有用性
このように Server-Timing は全リクエストで常時有効にするのが適切でない場合があります。CloudFront のアクセスログと何が違うのかを整理し、Server-Timingヘッダーの有用性を見出してみます。
| Server-Timing指標 | 内容 | アクセスログ |
|---|---|---|
cdn-cache-hit / -miss / -refresh |
キャッシュ結果 | ◯ x-edge-result-type |
cdn-pop |
処理したPoP | ◯ x-edge-location |
cdn-rid |
リクエスト一意ID | ◯ x-edge-request-id |
cdn-hit-layer |
EDGE / REC / Origin Shield | △ Origin Shieldのみ x-edge-detailed-result-type（OriginShieldHit） |
cdn-upstream-dns |
オリジンDNS解決時間 | × |
cdn-upstream-connect |
オリジンTCP+TLS接続時間 | × |
cdn-upstream-fbl |
オリジン処理→CFへ初回バイト | × |
cdn-downstream-fbl |
CF→ビューアーへ初回バイト | ◯ time-to-first-byte |
標準ログ記録リファレンス - Amazon CloudFront
こうして表にしてみると、Server-Timingだけが持っているメトリクスは少なく、粒度の差こそあれアクセスログでも取れるものが多いです。また、オリジン処理時間は CloudWatch の OriginLatency でも集計できたりします。
Server-Timing だけが持っているのは、キャッシュヒット層の特定と、オリジンへの接続区間の分解です。特にオリジンがAWS外にあったり地理的に遠い場合、CloudFront→オリジン間の接続コストがレイテンシに影響しやすいため、こうした構成であれば活用する価値は高くなるでしょう。
Server-Timingの使い所
ここまでの整理を経て、私自身は以下のようにServer-Timinigを活用していこうと思いました。
- Server-Timingを有効化する環境：サーバー内部の情報が露出するのを避けるため、本番環境では有効化は避けます。開発環境や負荷試験環境など、信頼できるユーザーが使用する環境で有効化します。
- Server-Timingのサンプリングレート：本番環境で有効化しない場合はレスポンスサイズへの影響もないため、サンプリングレートは100%を指定します。開発者がブラウザから分析したいときに常にヘッダーが付与されている状態が作れます。
- オリジン内部の処理をカスタムメトリクスとして書き込むか：書き込みません。Server-Timingはクライアントに露出する上、集計・アラート・トレース連携の仕組みがありません。オリジン内部の観測は、露出せず集計基盤に乗るX-Rayやアプリケーションログのほうが適していると考えています。
Server-Timingはリクエストを発生させたブラウザで閲覧できるのが強みです。例えば負荷試験時に稀にレスポンスが遅くなるような場合、ブラウザの開発者ツールからServer-Timingヘッダーを閲覧し、CloudFront側とオリジン側のどちらがボトルネックなのか、キャッシュはどこの層で見つかったのかなどを分析する使い方が良さそうです。リクエストIDも含まれていますから、アプリケーションログと突合してリクエスト全体の分析をすることもできそうです。
