Timing-Allow-Origin: Resource Timing API でアナリティクスが見ているもの

誰も意図的には設定しないヘッダー

ほとんどのチームが Timing-Allow-Origin（TAO）に出会うのは、監視ツールのグラフに不審なゼロが表示されたときくらいでしょう。クロスオリジンのリソース——フォント、CDN 上の画像、サードパーティのスクリプトなど——は Resource Timing API に現れますが、応答するサーバーが明示的にオプトインしない限り、その詳細なサブタイミングは 0 として読み取られてしまいます。そのオプトインこそが TAO ヘッダーであり、これを理解することは、侵襲的なトラッキングに頼らずに正直なパフォーマンスデータを得たいなら不可欠です。

Resource Timing 標準は、ページが行うすべてのフェッチについて PerformanceResourceTiming エントリを公開します。同一オリジンのリソースについては、DNS ルックアップ、TCP 接続、TLS ネゴシエーション、リクエスト開始、レスポンスのタイミングといった完全な内訳が得られます。クロスオリジンのリソースについては、仕様上、ドキュメントが読み取れる内容が意図的に制限されています。これらの細かなタイミングは、ユーザーのネットワーク状態、キャッシュの内容、あるいは別のオリジンの内部的な挙動に関する情報を漏らしうるからです。

ゼロにされるもの

一致する TAO ヘッダーがない場合、クロスオリジンの PerformanceResourceTiming エントリの次の属性はゼロに固定されます: redirectStart、redirectEnd、domainLookupStart、domainLookupEnd、connectStart、connectEnd、secureConnectionStart、requestStart、responseStart、transferSize、encodedBodySize、そして decodedBodySize。一方で startTime、duration、responseEnd、およびリソースの name と initiatorType は引き続き取得できます。実際のところ、これはリソースが読み込まれたことと全体としてどれだけ時間がかかったかは分かるものの、その時間がどこで費やされたのか、あるいは何バイトが回線を通過したのかは分からない、ということを意味します。

このチェックは、Resource Timing 仕様における timing allow check アルゴリズムによって定義されています。リソースは、そのレスポンスがリクエスト元ドキュメントのオリジンと等しい値、あるいはワイルドカード * を持つ Timing-Allow-Origin を伴っている場合にチェックを通過します。

Timing-Allow-Origin: https://example.com
# or, to allow any origin
Timing-Allow-Origin: *

これがプライバシーファーストなアナリティクスにとって重要な理由

Monoid はフィールドから——実際の訪問者による実際のナビゲーションから——パフォーマンスを計測します。クッキーも localStorage も、フィンガープリンティングも使いません。Resource Timing と Navigation Timing の API は、それを実現する標準ベースの手段であり、TAO はプラットフォームがクロスオリジンのタイミングデータをデフォルトで機密に保つために利用しているメカニズムです。

そのデフォルトは、障害物ではなくプライバシー機能です。この固定化（クランプ）は、ページがサードパーティのオリジンをタイミングのサイドチャネルとして探るのをまさに防ぐために存在します。私たちが、あなた自身の静的アセットや CDN に Timing-Allow-Origin を設定することを推奨するとき、私たちがお願いしているのは、あなた自身の 計測のために あなた自身の インフラを可視化へオプトインすることであって、誰かの保護を弱めることではありません。

Core Web Vitals はこの点を裏付けます。Largest Contentful Paint はしばしばクロスオリジンの画像や Web フォントです。それらのレスポンスに TAO ヘッダーがなければ、Largest Contentful Paint API を通じて LCP 要素を観測することは依然として可能ですが、遅延の原因が遅い DNS なのか、コールドな TLS ハンドシェイクなのか、あるいは大きな転送量なのかを教えてくれるはずのリクエストとレスポンスのサブタイミングは失われます。アセットのオリジンにこのヘッダーを追加すれば、不透明な数値が実用的な数値に変わります。

正しく設定する

いくつか実務的な注意点があります。第一に、transferSize がゼロでないことにより、キャッシュヒット（小さな転送サイズ）とネットワークフェッチを区別できます。これは再訪時のパフォーマンスを診断する際に非常に有用です。第二に、フォントをクロスオリジンで配信している場合、CSS の crossorigin 属性と CORS は TAO とは別の問題です——両方が必要になることもあります。第三に、可能な限り * よりも特定のオリジンを名指しで指定し、正当にそのデータを必要とするドキュメントだけが受け取れるようにしましょう。

Cloudflare では、Transform Rule または Worker のレスポンスを使ってエッジでこのヘッダーを追加し、アセットのパスに適用できます。Monoid は同じエッジ上で動作するため、訪問者のブラウザが収集するタイミングデータは、そのまま集約された識別子不要のメトリクスへと流れ込みます——ヒーロー画像が TLS に 400ms 費やしていることを知るのに、ユーザーごとのプロファイルは一切不要です。

まとめ

Timing-Allow-Origin は小さなヘッダーながら、フィールドのパフォーマンスデータからどれだけを学べるかに不釣り合いなほど大きな影響を持ちます。ブラウザのデフォルト——クロスオリジンのサブタイミングをゼロにすること——は意図的なプライバシー保護であり、プライバシーファーストなアナリティクスが本来あるべき姿ときれいに合致します。すなわち、標準 API から集約値を計測し、あなた自身のオリジンを明示的に詳細へオプトインさせ、ユーザーのネットワークフィンガープリントを収穫すべき対象として扱わない、ということです。アセットに TAO を設定すれば、いかなるトラッキングもなしに Web Vitals のデバッグがより鋭くなります。

Sources

• Resource Timing (W3C Working Draft) — Timing Allow Check
• MDN — Timing-Allow-Origin header
• MDN — PerformanceResourceTiming
• web.dev — Largest Contentful Paint (LCP)