サードパーティスクリプトは、静かに負荷テストにおけるノイズ、歪み、誤検知の最大の原因のひとつになっています。あらゆるマーケティングツール、アナリティクスピクセル、最適化フレームワーク、ウィジェットが、あなたのアプリケーションが制御できないリモート依存をさらに追加します。本番トラフィック下ではそれらの多くは「十分に動く」ことが多いですが、合成負荷では地雷のように振る舞い、その失敗をしばしば「あなたの」失敗として報告します。
この記事では、ブラウザ内部で実際に何が起きているのか、なぜ合成トラフィックがこれらの影響を誇張するのか、そしてサードパーティコードに結果を乗っ取られない賢い負荷テストの方法を解説します。LoadViewを使うチーム向けに書かれていますが、ブラウザベースの負荷テストを行う全ての環境に当てはまる原則です。
サードパーティコードの隠れた重み
現代のページは HTML と自分の JavaScript だけではありません。次のような要素の寄せ集めです：
- アナリティクスエンジン
- A/B テストフレームワーク
- セッションリプレイトラッカー
- タグマネージャー
- チャットウィジェット
- CDN 配信のライブラリ
- 同意バナー
- 広告ビーコン
- フィーチャーフラグローダー
これらのスクリプトはそれぞれ独自のタイムラインで動作し、独自にネットワーク呼び出しを行い、バックエンドチームが見ていない方法でページを停止させることがあります。
負荷テストでは、あなたのシステムだけをテストしているわけではありません。所有も制御もできない 15〜30 の外部サービスのグローバル可用性をテストしているのです。速いものもあれば遅いものもあります。数千のほぼ同一の「訪問」を毎分発生させるとパニックを起こすものもあります。
だからチームは次のようなパターンをよく目にします：
- アプリケーションサーバの指標：安定
- データベースレイテンシ：変わらず
- 合成負荷テスト：「ページが遅い」「ウォーターフォールがブロックされている」「JS 実行が止まっている」
- これらが相関しない場合、多くはサードパーティコードが原因です。
負荷テスト中にサードパーティスクリプトが実行されると実際に何が起きるか
テスト結果が汚染される理由を理解するには、ブラウザがしなければならない作業を見てください：
- HTML をパースする。
- CSS と自分の JS を取得する。
- 外部スクリプトを見つけ、DNS → TCP → TLS → GET を発行する。
- リモートプロバイダーの応答を待つ。
- 返ってきたコードを実行する。
- そのコードがさらに 別のスクリプトを読み込むことがよくある。
- それらのスクリプトがさらに 別のリクエストを発生させることが多い。
これは仮説ではありません。DevTools のウォーターフォールを開けばそれが見えます：タグマネージャーがさらに多数のスクリプトを生成し、トラッカーが設定を取得し、リプレイツールが録画資産を読み込み、アナリティクスがバッチエンドポイントにコールを行います。
負荷がかかると、これらの外部チェーンは速くなるどころか遅くなります。場合によっては大幅に遅くなります。
最も重要なのは、ブラウザはこれが負荷テストであることを知らないという点です。実際のユーザーと同じように全てを実行します。サードパーティプロバイダーが応答を遅延させれば、ブラウザは待たされます。
サードパーティスクリプトが結果を膨らませ、誤導する仕組み
合成ブラウザテストはユーザーが感じるものを測定します：LCP、DOMContentLoaded、load イベント、TTI、その他のランタイム指標。サードパーティスクリプトは次のような方法でそれらを歪めます：
ブロッキングスクリプトがパースを停止させる
もしスクリプトタグが async や defer でない場合、ブラウザはリモートプロバイダーが応答するまで HTML のパースを止めます。そのプロバイダーが遅い、あるいはトラフィックに対してレート制限をかけていると、テスト時間が爆発します。
ロングテールレイテンシがパーセンタイルを変動させる
サードパーティのパフォーマンスは本質的にばらつきがあります。あるリクエストは 50ms、あるものは 800ms かかります。フルの負荷テストを実行すると、これらの外れ値が 95th や 99th のパーセンタイルに累積し、実際には安定しているアプリケーションを不安定に見せてしまいます。
非同期コードでも CPU やイベントループ時間を消費する
非同期に読み込まれても、重いアナリティクスやリプレイスクリプトは JS 実行の負担を増やします。負荷下ではこの影響が増幅されます。
ウォーターフォールの拡散が本当のボトルネックを隠す
サードパーティスクリプトがさらに 5 個のリクエストを生むと、あなたのコードと外部コードを区別するのが難しくなります。多くのチームは「バックエンドのレイテンシ問題」を追いかけて何時間も浪費しますが、実際はスタックしたタグマネージャーが原因であることがよくあります。
結論：あなたのシステムは健全かもしれませんが、負荷テストの結果は健全に見えません。
合成負荷下での CDN の変動と連鎖的レイテンシ
サードパーティスクリプトはあなたのインフラから実行されるのではなく、世界中に散らばった CDN から配信されます。これらの CDN は地理、混雑、ピアリング、ロールするメンテナンス、あるいはその時点で動いている動的な負荷分散ロジックに基づいてトラフィックをルーティングします。合成負荷のように複数の地域から同時にリクエストを発生させると、その変動は増幅されます。
同一の外部スクリプトに何百ものブラウザが同時にアクセスすると、まったく異なる POP にルーティングされることがあります。ある地域は温まった応答の良いエッジノードに当たり即座に返るかもしれません。別の地域は混雑した、あるいはコールドな POP に当たり数百ミリ秒止まるかもしれません。第三の地域は一時的に悪化や再ルーティングを経験し、さらに予測不能さを加えます。これらはあなたのアプリケーションの健全性を反映するものではありませんが、すべてテスト結果に反映されてしまいます。
結果は予測可能です：レポートで遅いと見えるロードゾーンは実際にはあなたのサーバと戦っているのではなく、マーケティングピクセルやアナリティクスタグ、あるいは近隣 POP の調子の悪い CDN 上のリプレイスクリプトと格闘しているのです。一方でインフラ指標は別の話を伝えます：CPU は安定、メモリは安定、データベースレイテンシも変化なし。あなた側はクリーンに見えます。
しかしウォーターフォールは外部の長いバーで吹き飛び、スクリプト実行が遅れ、タイミング指標が膨らみます。このミスマッチが、合成負荷下でのサードパーティコードの典型的な兆候です。
サードパーティプロバイダーは負荷テストが嫌い（レート制限問題）
ブラウザベースの負荷テストで欺瞞的な失敗パターンのひとつは、サードパーティサービスが自らを保護し始めることにあります。アナリティクス、タグマネージャー、リプレイツール、マーケティングピクセルは、通常は分散した不規則な正規トラフィックを処理するように設計されています。彼らが処理するのに向いていないのは、何千ものほぼ同一の合成セッションが短時間に集中して同じエンドポイントを叩くことです。プロバイダーの検出システムにとって、それは「テスト」ではなく「攻撃」に見えます。
起きることは次のとおりです：
- 負荷テストが始まる。
- すべてのブラウザがあなたのページにアクセスする。
- サードパーティのターゲットが異様に反復的なフラッドを観測する。
- プロバイダーがこれはスクレイピングや DDoS に見えると判断する。
- リクエストが遅くなるかエラーを返すようになる。
- ブラウザがレスポンスを待って停止する。
- テストのメトリクスが崩れる。
結果はあなたのアプリケーションが崩壊したように見えますが、実際にはインフラに何も変化はありません。CPU はフラット、メモリは安定、データベースレイテンシに変化なし。遅延はあなたのものではなく、サードパーティサービスがテストトラフィックを悪意あるものと判断してレート制限しているのです。HAR ファイルや外部ウォーターフォールを詳しく調べなければ、これを内部パフォーマンス問題と誤診断するのは簡単です。修正はサーバーチューニングではなく、外部依存がテストトラフィックに対して自己防衛をしていることを認識することです。
なぜ実際のユーザーは同じ遅延を見ないのか（広告ブロッカーと同意）
合成の結果と実世界のパフォーマンスの差の大きな理由のひとつは、実際のユーザーはテスト環境がロードするすべてを読み込まないという単純な事実です。ユーザーのかなりの割合が広告ブロッカーやプライバシー拡張を使用しており、これらがアナリティクスやトラッキングピクセル、マーケティングスクリプトの実行を阻止します。拡張がなくても、多くのサイトはユーザーの同意を得るまでスクリプトをロードしません。
対照的に合成ユーザーは、ブロッキングや拡張、同意ゲートがない「クリーンな」ブラウザとしてすべての依存を読み込みます。つまり、追跡タグ、リプレイツール、最適化フレームワークなどが全ての合成セッションで実行される一方、多くの実ユーザーはそれらを一切トリガーしないことが多いのです。
結果として予測可能なミスマッチが生じます：本番は安定して見えるのに、負荷テストではタイミングが膨らみウォーターフォールが重くなる。テストは間違っているわけではありません—完全にサードパーティの重みが均一に適用されるシナリオを測っているのです。しかしそれは実際のユーザー行動の分布を反映しておらず、こうした不一致が頻出する理由になります。
サードパーティスクリプトを負荷テストに含めるべき場合とブロックすべき場合
正しいアプローチは一つではありません。何を測りたいかによります。
以下を重視するならサードパーティスクリプトを含める：
- 実際のユーザーエクスペリエンス
- UX タイミング（LCP、FID、TTI）
- ピークトラフィック下でのページレンダリング
- マーケティングの要素もすべて有効な状態での挙動
以下を重視するなら除外またはブロックする：
- バックエンドのスケーラビリティ
- API パフォーマンス
- データベースのスループット
- インフラのボトルネック特定
- ネットワークやロードバランサのチューニング
- スループットやエラーレートの SLA
賢いアプローチは—多くの成熟したチームが行っている通り—両方を実行することです：
- クリーンラン（外部依存をブロックまたはスタブする）。
- フルラン（ブラウザがすべてを読み込む）。
この二つの差分が、サードパーティプロバイダーが実際のユーザー体験にどれだけの重みを与えているかを正確に教えてくれます。
LoadView ならこれが簡単にできます：ブロックリスト／許可リスト機能を使って、スクリプトを書き直すことなく両方のシナリオを実行できます。
サードパーティスクリプトはフロントエンドだけの話ではない
負荷テストでの誤解の一つに、サードパーティスクリプトは外部プロバイダーとだけやり取りするため自分のインフラに影響を与えない、というものがあります。実際にはそれは稀です。多くのスクリプトがデータ取得やイベント送信、構成取得のためにあなたのバックエンドを呼び出し、見落とされがちな追加トラフィックを生みます。
例：
- A/B テストフレームワークが実験構成を取得するためにあなたの API を問い合わせる。
- パーソナライゼーションスクリプトがログインユーザー属性を要求する。
- アトリビューションスクリプトがページ遷移やセッションマーカーをポストする。
- チャットウィジェットが稼働状況やロスターのエンドポイントを呼ぶ。
- アナリティクスツールがクロスサイトブロッキングを避けるためにあなたのドメインにイベントをバッチ送信する。
その結果は静かな増幅効果です：1 つのサードパーティスクリプトがページロードごとに追加のバックエンド呼び出しを何件も生成するかもしれません。負荷下ではこれが劇的に乗算されます—フロントエンドだけのテストだと思っていたものが実は意味のあるバックエンドトラフィックを生んでいることがあります。UI 中心のシナリオでインフラ指標に予期しない API スパイクやデータベース負荷が出る場合、この相互作用パターンが原因であることが多いです。
こうした隠れたバックエンドタッチポイントを認識することは、負荷テスト結果を正しく解釈するうえで不可欠です。これを考慮しないと、システムの別の部分を誤って責めたり、本番で直面する実際の需要を過小評価したりしてしまいます。
より賢いテスト：スタブ、モック、オーバーライド、制御された外部挙動
クリーンで信頼できる負荷テストの目的は、現実を捏造することではなく、測定対象のシステムを分離することです。サードパーティ依存はノイズ、不確実性、そしてレート制限の挙動を持ち込み、あなたのインフラとは無関係にテストを汚染します。これらの変数を制御することで、外部サービスの不安定さを引き継がないあなた自身のパフォーマンスを測定できます。
一つの手段は DNS オーバーライドです。既知のサードパーティドメインをローカルのモックエンドポイントにルーティングし、即時応答を返すようにします。これによりブラウザは期待されるリクエストシーケンスを完了できます。スクリプトブロッキングはより少ない設定で同じ結果を得られます：LoadView では googletagmanager.com、hotjar.com、optimizely.com のようなドメインを単にブロックするだけで、テスト中にブラウザがそれらの取得や実行に時間を費やさないようにできます。
モックエンドポイントは最小限で予測可能なペイロードを返すことでさらに制御を強化します。これによりスクリプト実行はランごとに一貫性を保ち、タイミングのロングテールを取り除けます。場合によっては外部ライブラリのフォールバックコピーをローカルにホストし、可用性と応答時間の両方を管理することでアプリケーションロジックを変えずに制御するチームもいます。
これらの方法は、ブラウザの振る舞いを現実的に保ちながら、第三者サービスが負荷下で引き起こすランダムな遅延や障害を排除します。その結果、あなたのアプリケーションのパフォーマンスを反映するテストが得られます—他人の CDN の健康状態ではなく、あなたが運営するシステムの性能です。
LoadView がサードパーティスクリプトのノイズを扱う方法
LoadView のブラウザベース負荷テストは、「あなたのコードが遅い」のか「他人のサービスが詰まった」のかを切り分ける可視性を提供します。
主な利点：
- ウォーターフォールレベルの可視性：ページをブロックした正確なサードパーティリクエストを確認できます。
- 外部ドメインのブロック/許可：スクリプトバージョンを複数管理することなく、クリーン対フルの比較テストを実行できます。
- ブラウザレベルの実行：マーケティングスクリプトがパフォーマンスを引きずっているかなど、ユーザーが実際に経験する内容を測定できます。
- ロードゾーン：ジオロケーション特有の外部遅延を特定できます。
- スクリプト制御（Selenium）：外部呼び出しを防いだり予測可能なモックに置き換えたりする条件を注入できます。
これが現代の負荷テストに求められる、ノイズに対する精緻なコントロールです。
結果の読み方：サードパーティの幽霊を追うな
テストが暴走したとき、チームが誤った根本原因を追わないための簡単なトリアージパターンを示します。
サーバー指標が安定しているのにブラウザ結果がひどい場合：
ほとんどの場合サードパーティスクリプトかクライアント側の実行オーバーヘッドです。
95th/99th パーセンタイルが膨らむが平均はクリーンな場合：
それは典型的なサードパーティのロングテール挙動です。
一つの地理的ロードゾーンだけが遅い場合：
外部 CDN の POP がその時間帯に不調です。
外部ドメインで DNS や TLS エラーが出る場合：
レート制限やブロックを受けています。
「フロントエンド」テストでバックエンドトラフィックが予期せず増えている場合：
あるクライアント側スクリプトが秘密裏にあなたの API を呼び出しています。
結果を正しく解釈することは単なるスキルではなく、有効なテストの必須条件です。
まとめ
サードパーティスクリプトは無くなりません。あらゆるマーケティングチーム、アナリティクスベンダー、パーソナライゼーションプロダクトがページに依存関係を追加します。それが現代のウェブの現実です。
しかし、他人の遅いサーバのせいであなたのインフラが故障していると誤認すべきではありません。
現実的なテストとは：
- いつサードパーティコードを含めるべきかを知ること
- いつブロックすべきかを知ること
- 差分をどう解釈するかを知ること
- クリーンとフルのシナリオを実行すること
- CDN ノイズやレート制限されたアナリティクスプロバイダーに SLA を歪めさせないこと
LoadView はチームがまさにそれを行えるよう、可視性と制御を提供します—あなたが実際に運用しているシステムをテストし、ページに取り付けられた外部スクリプトの山ではなく、あなたのシステムの性能を評価してください。