よくわからない機能２

Resource Timing: responseStartの変更を元に戻し、firstResponseHeadersStartを導入

概要

現在、リソースの応答時間を取得するresponseStartの動作を元に戻します。

新しくfinalResponseHeadersStartというプロパティを導入し、最終的な応答ヘッダー（例: 2xx/4xx/5xx）の時刻を取得できるようにします。

動作変更の背景

HTTP/1xxステータス（例えば、早期ヒントとしての103応答）と最終応答（例えば、200や404など）では、異なるタイムスタンプがあります。

早期ヒント（103）: 中間的な応答。

最終ヘッダー（200など）: 最終的な応答。

Chromeでは以前、responseStartを「最終ヘッダーの時刻」と定義する変更を加えましたが、これが他のブラウザやデータ解析ツール（CrUX）と整合性が取れず混乱を招きました。

変更点

responseStart: 「リダイレクト後の最初の応答の時刻」に戻します（1xx, 2xx, 4xx, 5xxのいずれか）。

finalResponseHeadersStart: 新たに導入。最終応答ヘッダー（2xx, 4xx, 5xx）の時刻を取得します。

firstInterimResponseStart: そのまま維持。1xx応答時刻、または存在しない場合は0を返します。

目的

他のブラウザとの互換性を確保。

開発者が「最終応答ヘッダーの時間」を明確に取得できる新しい手段を提供。

仕様

この変更は、現在開発中の仕様（W3C Resource Timing仕様）に基づいています。

詳細は公式仕様書（リンク）に記載。

Chrome 132での導入状況

この機能はChrome 132から正式に導入される新規機能です。既存のresponseStartの挙動が元に戻るため、影響が出る可能性があります。

ソースコードの影響確認手順

影響がある場合

既存のresponseStartを使用している箇所は、挙動変更の影響を受ける可能性があります。

影響確認のためのGrep方法

Grep対象: responseStart

理由: responseStartは既存の機能であり、挙動が変更されるため、明示的に使用されている箇所を確認する必要があります。

Grepする文言:

"responseStart": このプロパティが参照されている全ての箇所を検索します。

補足

変更の影響が懸念される場合、新しいプロパティ（finalResponseHeadersStart）の使用を検討することで、最終応答時刻を明確に取得することが推奨されます。

前回の変更点（簡潔版）

機能: Resource Timing - 中間応答時間を公開

新しいプロパティの追加

firstInterimResponseStart: 最初の中間応答（例: 103 Early Hintsや100 Continue）の時刻を取得。

responseHeadersEnd: 応答ヘッダーの読み込みが完了した時刻を取得。

responseBodyStart: 応答ボディのストリーム開始時刻を取得。

responseStartの挙動変更

responseStartが「最終応答時刻」（例: 200）を示すように戻りました（103 Early Hints導入前の動作に一致）。

背景（なぜ変更したか）

103 Early Hintsの導入で、responseStartが最初の103応答時刻を示すようになり、開発者に混乱を招きました。

この変更により、従来のresponseStart（最終応答の時刻）を明確に保ちつつ、1xx応答のタイミングを別プロパティで取得可能にしました。

目的

開発者の混乱を解消: TTFB（Time to First Byte）の期待通りの動作を維持。

タイミング情報の詳細化: より細かいリソースタイミング情報を取得できるように。

前回のリリースの要点

主な変更点:

新しいタイミングプロパティ（firstInterimResponseStartなど）の追加。

responseStartの意味を最終応答のタイミングに戻す。

1. 優先順位をつけて調査

すべてのresponseStartが影響を受けるわけではありません。次の基準で絞り込むと効率的です。

responseStartを直接使用している箇所:

performance.getEntriesByType('resource')やperformance.getEntries()の結果からresponseStartを取得し、その値を用いて計算や判定を行っているコード。

例: TTFB（Time to First Byte）を計測するコード。

responseStartが他の指標や処理に依存している箇所:

responseStartの値を他のプロパティ（例: requestStart）と比較して、特定の条件や時間差を求めるロジック。

例: レイテンシの計測。

外部ライブラリや分析ツールがresponseStartを使用している場合:

これらのツールが変更後の動作に対応していない可能性があります。

影響がある可能性の高いコード例

1. 影響があるコード例

以下のようにresponseStartを直接使っている場合、新仕様の影響を受ける可能性があります。

例1: TTFBを計測

javascript

コードをコピーする

const performanceEntries = performance.getEntriesByType('resource');

performanceEntries.forEach(entry => {

const ttfb = entry.responseStart - entry.startTime;

});

影響:

以前はresponseStartが「最終応答の時刻」だったのに対し、新仕様では「最初の応答（1xxも含む）」になる場合があるため、TTFB計算が意図しない値を返す可能性があります。

例2: レイテンシ計測

javascript

コードをコピーする

const latency = performance.timing.responseStart - performance.timing.requestStart;

影響:

中間応答が存在する場合、responseStartが中間応答を指す可能性があり、正確なレイテンシが計測できなくなる。

2. 影響が少ないコード例

次のようにresponseStartを直接参照せず、他のプロパティや処理に依存していない場合、影響は少ないです。

例: 他のプロパティを使用

javascript

コードをコピーする

const endToEndTime = performance.timing.responseEnd - performance.timing.fetchStart;

理由:

responseEndやfetchStartなどを直接使用しているため、responseStartの変更による影響を受けません。

次のステップ

Grepの次に確認すべきこと

responseStartが参照されている箇所で、TTFB計測やレイテンシ計測のようなロジックが組まれているかを確認します。

調査のポイント

中間応答（1xx）が発生する可能性があるかどうか。

使用しているブラウザで、103 Early Hintsのような中間応答が利用されているか確認。

代替案

中間応答を区別する必要がある場合は、**finalResponseHeadersStart**を使用することで最終応答のタイミングを取得できます。

既存コードの修正例（TTFB計測を修正）:

javascript

コードをコピーする

const ttfb = entry.finalResponseHeadersStart

? entry.finalResponseHeadersStart - entry.startTime

: entry.responseStart - entry.startTime;

このようにすることで、新仕様への対応が可能です。