ブラウザが読み込むものから単一のインベントリを作る
代表的なページで始める：ホーム、ランディング、詳細、検索、カート、チェックアウト、アカウント、キャンペーン。Chrome DevToolsで新規と再訪問を記録する。ブラウザの証拠をタグマネージャ、CMSプラグイン、コード依存と比較する。挿入されたスクリプトは1つのビューでは見落とされることがある。
ベンダーや統合ごとに1行にする（URLごとではない）。接続するドメインとタグ追加権限の有無を記録する。目的を擁護し削除を承認できるビジネスオーナーを付与する。キャンペーン、ベンダー変更、テンプレートリリース、改修のあとに再確認する。
ページ、経路、ベンダードメイン、リクエスト、転送サイズ（バイト）、メインスレッド作業、テスト条件を保存する。ラボトレースは診断用の証拠であり、すべての訪問者の保証ではない。
目的、オーナー、同意カテゴリ、トリガー、公開されるデータ、依存順序、フォールバック、レビュー日を含める。
保持・削除・予算判断を可視化する
各オーナーに統合が消えたときに何が最悪かを尋ねる。答えが曖昧なら無効化または削除する。web.devは予算の設定、重複機能の回避、冗長スクリプトのクリーンアップを推奨している。
予算はチームのガードレールであり普遍的な閾値ではない。バイト、リクエスト、メインスレッド時間、読み込みタイミングについてベンダーとページごとの許容量を設定する。ベースラインと変更を比較する。オーナーに許容量内に収めるか、別のコストを削除するか、期限付きの例外を取得するよう要求する。比較可能な経路とユーザー中心の指標を使う。
現行の目的があり、オーナーがコストとデータ使用を受け入れ、許容できる障害時の経路がある依存関係のみを保持する。
期限切れのピクセル、重複分析、非アクティブなチャット、未使用の実験、放置されたプラグインを段階的リリースで退役させる。
理由、コスト、承認者、補償措置、レビュー日を記録する。
遅延読み込みは安全な場合のみ選ぶ
読み込み動作を意図的に選ぶ。classicな外部スクリプト（async/defer/module指定なし）は取得・実行が行われるまでHTML解析が停止する。asyncではダウンロードは並列で行われるが、準備でき次第実行され順序は保証されない。deferではclassic外部スクリプトは解析後にドキュメント順で実行され、DOMContentLoadedの前に動く。deferは順序が必要なスクリプトに適しており万能ではない。
任意のチャット、ソーシャル、マップ、ビデオ、レコメンドインターフェイスには軽量のプレースホルダを描画し、クリックや関連時にベンダーを読み込む。ファサード（外観）パターンは完全な埋め込みではなくあなたの制御から開始する。キーボード操作を維持し、領域を確保する。価格計算、サインイン、支払い処理、必須のアクセシビリティ、または確定した義務を満たすコードを、レビュー済みの代替がない状態で遅延しないこと。
ファーストタスクの依存性のみ即時読み込みとし、順序が必要なコードは解析後に、任意の埋め込みは操作や可視性で読み込む。
相互依存するスクリプトをasyncにして順序が保たれると期待しない。公開されるチェーンを文書化しテストする。
重要なUIをwindow loadに結び付けないこと。サードパーティ埋め込みはasyncやdeferを使っていてもそれを遅らせる可能性がある。
同意（コンセント）を門（ゲート）にする、後回しにしない
各ベンダーを法務・プライバシーステークホルダーと分類し、管轄とデータフローを把握する。同意が必要な統合では、タグが関連データを送る前に同意状態を確立する。Googleはデフォルトの同意コマンドが測定コマンドより前に実行され、選択変更後に更新が続くべきだとしている。この製品ガイダンスは法的助言ではない。
初回訪問で選択なし、受諾、拒否、撤回のそれぞれをテストする。インターフェイスとネットワークを確認する：ウィジェットが非表示でもリクエストや識別子が送られていないことを証明しない。コンセントプラットフォームが非同期で読み込まれる場合はタイミングをテストする。選択を適切に永続化し、現在のページと次回訪問に反映させる。
ベンダーのラベルだけに頼らない。タグがある地域や経路で必須・任意・禁止のいずれかである理由を記録し、承認を得る。
撤回後、設定された非必須タグが読み込まれないかデータを送信しないことを確認し、テスト証拠を保持する。
あなたが制御しないコードの影響範囲を小さくする
OWASPはクライアント側での制御喪失、ブラウザでの任意コード実行、機密データの露出を中心リスクとして挙げている。タグ公開権限を制限し、カスタムHTMLや任意コード機能をレビューし、許可するデータレイヤーのフィールドを文書化する。ハイリスク統合にはベンダー契約と専門的なセキュリティレビューが有用だが、それらはテストを代替しない。
Subresource Integrity（SRI）はブラウザがスクリプトを暗号ハッシュで検証する方法を提供する。ピン留めでき、クロスオリジン配信がCORSをサポートする場合にのみ有効だ；W3CはCORSなしでSRIを使うのは論理的な誤りだと述べている。多くの変化するベンダーURLには適していない。iframeのsandboxはホストのDOMやクッキーへの直接アクセスを減らせるが、専門的レビューが必要だ。支払いやセキュリティに敏感なフローは資格あるレビューに値する。
目的に必要な文書化されたフィールドだけを渡す。シークレット、支払いデータ、不要な顧客属性を公開しない。
SRIはバイト列を検証するだけで、データ使用や後続のリクエストが適切かどうかを評価しない。分離（Isolation）はそのまま万能解ではない。
顧客に遭遇させる前にベンダー障害を実地で練習する
保持する各ベンダーについて、テスト環境やブラウザのリクエストブロッカーでドメインをブロックし、経路を実行する。遅い応答やタグマネージャの設定で統合がない場合もテストする。主要コンテンツ、ナビゲーション、フォーム、チェックアウト、アカウントアクセスが想定どおり動作するか確認する。これによりリリース前に前提を露出できる。
インシデント発生前に修復手順を定義する：誰がタグを無効化できるか、フラグやタグマネジャー公開が必要か、どうロールバックするか、どう検証するか。SIUはプロアクティブな稼働率最適化と修復の枠組みであり、インベントリ、予算、プレフライト、ロールバック演習を使って依存リスクを減らす。SIUはベンダーインフラを制御したり可用性を保証したりレビューに取って代わることはできない。
ベンダーなしで何が使えるか、何が劣化し得るか、フォールバック、無効化までの最大遅延を明記する。
変更記録にビフォー・アフタートレース、同意結果、ベンダーブロック結果、ロールバック担当者を添付する。