セッションリプレイはサイトを重くする？導入前後で負荷を確認する方法

セッションリプレイを入れたいけれど、サイトが重くならないか気になる。

タグを追加したあとに動きが遅くなり、録画が原因かを確かめたい。

そんなときは、ページを一度開いて「速い」「遅い」と判断するより、同じ条件でタグの有無を比較する方が、次の対応を決めやすくなります。

調べる対象は、利用者のブラウザで動く処理と、録画データを受け取る保存基盤の二つです。

片方が軽くても、もう片方に十分な余裕があるとは限りません。

この記事では、Chrome DevToolsを使う基本の確認手順、長い操作の測り方、運用側で見る項目を整理します。

最後に、開発担当者と共有できる「録画タグの負荷測定シート」を載せます。

製品ごとの速さを実測した比較ランキングではなく、自社のページで測るための手順です。

セッションリプレイの負荷を分けて考える

「サイトが重い」という相談には、表示が遅い、ボタンが反応しない、録画の処理が終わらないなど、異なる問題が含まれます。

症状と、処理が動く場所を先に分けましょう。

ブラウザの負荷を確認する

ブラウザ側では、スクリプトの読み込み、操作の記録、データ送信などが追加されます。

確認するのは、通信量だけでなく、CPUを使う処理時間、操作への反応、メモリの使われ方です。

ファイルが小さくても、操作するたびに重い処理が動けば、体感に影響することがあります。

一方、通信が何回か発生しただけでは、ボタンが遅くなった原因とは断定できません。

Googleの解説でも、第三者のJavaScriptを調べる際は、通信と実行時間などを分けて確認する方法が示されています（参考：第三者JavaScriptの負荷を調べる方法）。

MicrosoftもClarityの負荷について、影響を小さくする設計である一方、追加するJavaScriptが一切影響しないとは保証できないと説明しています（参考：Clarityのパフォーマンスに関する説明）。

この説明は2021年の公開資料であり、掲載された当時の測定値を、現在の自社サイトの結果として使うことはできません。

非同期で読み込むことと、処理時間がゼロであることは別です。

導入する版と実際のページで、表示中・操作中の両方を測ります。

保存基盤の負荷と混同しない

利用者が送った録画データは、受信、検証、保存、集計、再生準備などの処理へ進みます。

これらを外部のサービスが担う構成と、自社サーバーで担う構成では、運用担当者が確認できる範囲が違います。

外部サービスへ直接送る構成なら、送信先が自社のWebサーバーであるとは限りません。

自社の中継APIを通す構成なら、その受信処理も監視対象になります。

最初に通信先と処理の流れを書き出し、どこを誰が運用しているかを確認してください。

場所	確認すること	問題の例
利用者のブラウザ	処理時間・通信・メモリ	入力や画面更新が遅れる
データ受信API	応答時間・受信量・エラー	送信の失敗や再試行が増える
バックグラウンド処理	待ち時間・処理時間・再試行	録画の処理待ちがたまる
保存先・DB	書き込み・読み出し・容量	保存や検索が遅くなる
録画の再生画面	取得・展開・描画	担当者の再生画面だけ重い

AWSのECSを使う場合、Container InsightsにはCPUやメモリなどの指標があります（参考：ECSのContainer Insights指標）。

SQSを使う構成なら、待機中のメッセージ数や古い未処理メッセージの経過時間なども確認できます（参考：SQSのCloudWatch指標）。

ただし、別のキューやサーバーを使うシステムへ、同じ指標名をそのまま当てはめることはできません。

サイトの応答が遅いのか、録画の完成が遅いのかを区別して、実際に使っている基盤の担当者へ渡します。

録画導入前の基準を残す

比較の準備で大切なのは、測る条件をそろえることです。

端末や通信が変わった結果を、タグ追加の影響と取り違えないようにします。

同じ端末と回線で測る

対象URL、ページの公開版、ブラウザの版、端末、画面サイズ、回線、ログイン状態を記録します。

同意バナーの選択と、録画が実際に動く状態も合わせて残してください。

導入後だけ同意していない状態で測れば、タグを比較したつもりでも、記録処理が動いていない可能性があります。

反対に、比較のために必要な同意を飛ばすこともしません。

キャッシュの条件も分けます。

初回読み込みを調べるなら両方とも同じ初回条件にし、再訪を調べるなら両方ともキャッシュを利用した条件にそろえます。

ChromeのNetworkパネルにはキャッシュの無効化や回線速度の設定があります（参考：Chrome DevToolsのNetwork機能）。

CPUの速度を落としたシミュレーションも使えますが、PCの設定だけでスマートフォンのCPUを完全に再現できるわけではありません（参考：Performanceパネルの測定設定）。

普段の利用者に近いスマートフォンでも、主要な操作が問題なくできるかを確認します。

端末を同時に別の重い処理へ使わないなど、測定中の条件もできるだけそろえましょう。

代表的な操作を選ぶ

トップページを開くだけで、すべての負荷を確認したことにはなりません。

購入、問い合わせ、検索、管理画面など、事業上大切な操作を選びます。

次のような手順書を作ると、測定する人が変わっても比較しやすくなります。

1. 同じ商品一覧を開く
2. 同じ位置までスクロールする
3. 絞り込みを開き、同じ条件を選ぶ
4. 商品詳細へ進み、選択肢を変更する
5. テスト環境でカート追加まで行う

各操作の前後で何を待つかも決めます。

画面の読み込みが終わる前に操作した回と、十分に待った回を混ぜると、処理の重なり方が変わるためです。

入力欄にはテスト用の情報を使い、実際の注文や顧客データの変更が起きない手順にします。

まず短い代表操作で比較し、長い利用や更新の多い画面は別の試験として追加します。

「初回表示」「操作中」「長時間利用」の三つを分けて結果を残すと、どの場面が問題かを説明できます。

録画タグあり・なしを比較する

比較では、録画タグ以外の条件をできるだけ変えません。

測定用の環境で切り替えられる場合は、同じページの版で有効・無効を切り替える方法が分かりやすくなります。

他のタグ変更を止める

広告タグ、チャット、動画、A/Bテスト、画像の変更を同時に行うと、差の理由が増えます。

調査中は変更の履歴を残し、比較対象以外を固定してください。

タグ管理ツール、CMSのプラグイン、HTMLへの直接設置など、同じ録画タグが複数の場所から入っていないかも確認します。

通信が複数回あることだけを二重設置と判断せず、同じ初期化処理がどこから実行されているかを調べます。

Chrome DevToolsを使った切り分けでは、特定のリクエストだけを止める方法もあります。

Networkパネルで対象のスクリプトを確認し、右クリックからBlock requestを選ぶと、Request conditionsで条件を管理できます（参考：ChromeのRequest conditions）。

これは、調査する自分のブラウザで原因を切り分けるための方法です。

本番の訪問者全員のタグを停止する操作とは異なります。

ここで重要なのは、送信先だけを止めても、録画処理そのものが止まるとは限らないことです。

すでに読み込まれたSDKが動き続けたり、再試行が発生したりする場合があります。

何をブロックしたかを記録し、再読み込み後に対象の読み込みと実行がどう変わったかを確認します。

依存する別の機能まで壊れた場合、その結果を通常の「タグなし」の性能として扱いません。

測定後はブロック条件を解除し、通常の状態へ戻します。

繰り返し測定する

Performanceパネルでは、ページ読み込みの記録と、操作中の記録を分けて取得します。

操作中の確認なら記録を開始し、決めた操作を行い、停止して処理の時間帯を見ます（参考：Chromeの実行時パフォーマンス分析）。

同じ条件で複数回測り、タグなし、タグあり、再びタグなしのように順番も入れ替えると、時間帯や端末の状態による差に気付きやすくなります。

一番速かった一回だけを採用せず、各回の値と、極端に違った回の状況を残します。

測定回数はページの変動や目的に合わせて決め、少ない回数だけで厳密な効果を断定しません。

比較する項目の例は、次のとおりです。

目的	見る項目の例	読み違えやすい点
主要部分が見えるまで	LCP	ページ全体の完了時間ではない
操作への応答	操作の時間・INPの観察	サーバー処理の完了時間そのものではない
画面の安定	CLS	JavaScriptの重さを直接示す値ではない
処理の詰まり	Mainの処理・長いタスク	同時刻にあるだけでは原因確定ではない
通信とメモリ	送受信・メモリ推移	合計だけでは処理の場所が分からない

INPはクリック、タップ、キーボード操作などの応答性を表す指標で、通信後の処理を含むすべての完了待ちを測るものではありません（参考：INPの定義）。

少数のテスト操作の値を、実利用者全体のINPの評価へそのまま置き換えないでください。

PageSpeed Insightsの実利用データは過去28日間を対象とするため、変更直後の差を見る実験値とも区別します（参考：PageSpeed Insightsのデータの見方）。

負荷が大きい画面を調べる

初回表示の比較で問題が見えなくても、利用を続けたときだけ負荷が増える場合があります。

実際の使い方に近い画面の更新と、操作時間を確認します。

更新の多い画面を確認する

商品一覧の追加読み込み、チャット、絞り込み、頻繁に変わる数値表示など、ページ内容が繰り返し更新される箇所を選びます。

セッションリプレイの実装例であるrrwebでは、最初の画面状態と、その後の変更イベントを使って再生を組み立てます（参考：rrwebのイベント構造）。

この仕組みを理解すると、同じ閲覧時間でも、静かな記事ページと更新の多い画面では、調べる条件が違うことが分かります。

ただし、すべての製品が同じ実装や取得設定を使っているとは限りません。

録画を有効にした状態と無効にした状態で、同じ回数だけ一覧を追加し、同じ操作を繰り返します。

Performanceの記録から時間がかかる区間を選び、対象のスクリプトや描画処理の情報を確認します。

録画SDKの処理だけでなく、自社ページ側のDOM更新やレイアウト計算が増えていないかも見てください。

例えば、一覧を追加するたびに全体を作り直す処理がある場合、タグの有無にかかわらず負荷が大きい可能性があります。

タグを止めたときだけ改善するなら関与の手がかりになりますが、どの処理が影響したかは開発者の確認へつなげます。

長いセッションを確認する

管理画面や比較検討の長いページでは、数分の確認だけでは分からない問題が残ることがあります。

実際の利用時間を参考に、同じ操作の繰り返し、別画面への移動、元の画面へ戻る流れを決めます。

Chromeのメモリ調査には、タスクマネージャー、Performanceのメモリ表示、Memoryパネルなどの方法があります（参考：Chromeのメモリ問題の調べ方）。

まずは、時間がたつにつれてメモリや操作の遅れがどう変わるかを記録します。

一時的に増えたメモリが回収される場合もあるので、上がった瞬間の値だけでメモリリークとは決めません。

同じ操作を戻しても増加が続く、画面を閉じたはずの要素が保持されるなど、気になる動きがあれば開発者へ渡します。

また、ブラウザのメモリと、自社の録画処理用サーバーのメモリは別の測定です。

サーバーで圧縮データを展開するときの増加を、利用者の端末で起きた増加として報告しないようにします。

長時間のトレース自体も測定環境へ負荷を与えるため、全体の推移と、問題が起きる短い区間の詳細を分けて取得すると調べやすくなります。

テスト用のトレースやメモリ情報にもページ内容が含まれ得るので、共有前に情報の範囲を確認してください。

セッションリプレイの設定を見直す

負荷が分かったら、何を残せば調査目的を達成できるかを考えます。

単にデータを減らすだけで、見たい操作が記録されなくなっては目的を果たせません。

対象ページと取得率を検討する

最初に、調べるページと必要な操作を整理します。

例えば購入前の操作が目的なら、長時間開いたままの社内管理画面まで同じ設定で取得する必要があるかを検討できます。

対象ページ、取得率、記録するイベントの調整ができるかは、使う製品の公式仕様を確認します。

どのツールにも同じ設定があるとは限らないため、存在しない取得率のメニューを探し続ける必要はありません。

取得率を変える場合は、全体からどのように選ばれるかも確認してください。

エラーが出た訪問だけを残した記録と、無作為に選んだ記録では、発生割合を比較する前提が違います。

読み込みを遅らせる案には、初期表示の負荷を減らせる可能性と、最初の操作が欠ける可能性があります。

商品をカートへ入れる瞬間が目的なのに、その後から記録が始まる設定では、調査に使える内容が変わります。

負荷と記録の欠け方を、同じ検証で確認します。

マスキングを外して再現を優先するのではなく、必要な情報を保護したまま、目的に合う範囲を探します。

一度に一つ変更する

取得範囲、送信間隔、SDKの版を一度に変えると、どの変更が効いたかが分からなくなります。

設定を一つ変えたら、同じ測定を行い、変更内容と結果を記録します。

自社で受信・保存を運用する場合は、ブラウザ側の設定だけでなく、受信上限、処理の並列数、再試行、保存方法も調査対象です。

大量の録画データをまとめて展開する処理では、圧縮された送信サイズだけで必要なメモリを見積もらないようにします。

この点は製品共通の実測値ではなく、データ処理の構成を点検するための確認項目です。

処理担当の数を増やすと、待ち時間が減る一方、同時に使うメモリやDBへの負荷が増える構成もあります。

「ワーカーを増やせば解決」と決めず、入力の量、処理一件あたりの資源、同時実行数を合わせて見ます。

調整はテスト環境で確かめ、予想外の動作があれば戻せるように、変更前の設定を残します。

無制限の再試行や受信によって、主要な画面の処理まで圧迫しない構成かも、運用担当者と確認してください。

セッションリプレイを継続監視する

導入時の一度の測定で、将来のページ変更や利用量の増加まで確認できたことにはなりません。

見直す基準と担当を決めて、測定結果を運用へつなげます。

許容値と停止条件を決める

まずは、購入や送信などの主要操作が正常に完了することを必須条件にします。

そのうえで、処理時間、通信量、メモリ、サーバーの余力について、自社の許容範囲を決めます。

Core Web Vitalsでは、良好の目安としてLCPは2.5秒以下、INPは200ミリ秒以下、CLSは0.1以下が示され、実利用データの評価では75パーセンタイルを使います（参考：Web Vitalsの指標と評価）。

これらはページ体験の基準であり、録画タグ単体に許された処理時間の上限ではありません。

タグの追加分を判断するには、導入前の余力と、主要操作への影響も見ます。

以下は、自社の測定値を入れるためのシートで、実測結果や推奨の固定値ではありません。

記録する欄	記入内容
対象と条件	URL・ページ版・端末・ブラウザ・回線・同意状態
測定した操作	開始状態・操作順・待つ条件・測定時間
タグの状態	あり／なし・SDK版・設定・切り替え方法
ブラウザの結果	各回の処理時間・通信・メモリ・操作の成否
保存基盤の結果	受信量・待ち時間・CPU・メモリ・再試行
判断と次の対応	許容内／追加調査／停止・担当・期限

停止条件には、主要操作が繰り返し失敗する、資源の余力がなくなるなど、利用者への影響を具体的に書きます。

誰が停止を判断し、どこで止め、復旧後に何を確認するかも決めてください。

監視は録画システム自身だけに頼らず、主要ページの応答や注文・送信の成功も確認できる形にします。

録画データが来なくなったときに、「問題がなくなった」と誤解しないためです。

SDK更新後に再測定する

SDKとは、録画などの機能をサイトへ組み込むためのプログラムです。

その版が変わったときだけでなく、テーマ、フォーム、商品一覧、同意管理の仕組みを変えたときにも、代表操作を再確認します。

外部配信のスクリプトが自動更新される構成では、確認できた版やURL、更新を把握した時刻を残します。

提供元の仕様に反して独自に古いファイルへ固定するのではなく、サポートされる更新と切り戻しの方法を確認してください。

測定シートを前回と同じ形で残せば、ページ変更とタグ変更が重なった場合も調べやすくなります。

録画の再生だけがおかしい場合は、利用者側の負荷とは分け、Web録画がずれる・真っ白になる場合の確認手順を参照してください。

最初に行う作業は、代表的な一つの操作について、タグあり・なしの条件と測定結果を並べることです。

数字の差、再現した症状、記録できなくなった範囲がそろえば、導入を続けるか、設定を調整するか、実装を修正するかを判断しやすくなります。