ブラウザでウィンドウを複数開くと動作が重い？実行速度を高めるシステム最適化ガイド

同時に十数個のブラウザウィンドウを開いて使っていると、ページを切り替えるたびにローディングが回り、ファンはどんどんうるさくなり、タイピングも手の速さについていかなくなり、ひどいときはOSごと固まったように感じる。こうしたとき、まずブラウザを「性能が悪い」と決めつけてはいけない。各ウィンドウの背後では、複数のレンダラプロセス、拡張機能、スクリプト、動画、ネットワークタスクが同時に動いている可能性がある。CPU、メモリ、ディスク、VRAMのどれかひとつでも上限に近づけば、カクつきは何倍にも増幅される。

効果的な高速化も、手当たり次第にキャッシュを消したり、何度も再起動したり、セキュリティ機能をすべてオフにしたりすることではない。より確実なのは、先にボトルネックの場所を特定し、業務上の価値のない負荷を取り除くことだ。この方法は主に、複数のショップと複数のSNSアカウントを同時に運用する越境EC、海外オペレーション、カスタマーサポート、広告運用のシーンを想定しているが、タブを多用する一般ユーザーにもそのまま当てはまる。

なぜウィンドウを複数開くとタブを複数開くよりリソースを消費するのか

現代のChromium系ブラウザはマルチプロセスアーキテクチャを採用している。メインプロセスはウィンドウとディスク・ネットワークのやり取りを担当し、レンダラプロセスはWebページの内容を処理し、GPUプロセスはグラフィック描画を担う。一部の拡張機能もそれぞれ独立したプロセスを持つ。これは分離と安定性のためだが、その代償として複数の独立した環境が同時に動くと、リソース消費はそのまま積み重なっていく。

Googleのエンタープライズ版パフォーマンス調査ガイドでは、よくあるボトルネックがいくつかのタイプに整理されている。メモリ不足やディスクの読み書きの遅さはメインプロセスを重くし、非効率なWebページは特定のレンダラプロセスを長期間CPUフル稼働に追い込む。グラフィックドライバの問題や3D・動画ページは、GPUプロセスを遅くするかもしれない。「ウィンドウを多く開いている」のはあくまで表面に過ぎず、本当のボトルネックはまったく別のところにある可能性がある。

リソースを押し上げやすい要因としては、次のようなものがよくある。

• どのアカウントでも動画、ライブ配信、データダッシュボード、複雑なエディタを開いている
• 複数のウィンドウで同じ重量級の拡張機能を重複して実行している
• ページ通知、自動更新、ダウンロード、音声・動画があるせいで、バックグラウンドのタブが休止状態に入れない
• 物理メモリを使い切った後、システムがスワップファイルを頻繁に使い、ディスク使用率も上昇する
• 自動化タスクが同時に起動して同時にページを読み込むため、一瞬でCPUとネットワークが飽和する
• ブラウザやPCを何日も連続稼働させて、暴走したタブや異常なプロセスが蓄積する

ステップ1：ボトルネックがCPU・メモリ・ディスクのどこにあるのかを先に確認する

システムのタスクマネージャーを確認する

WindowsではCtrl + Shift + Escでタスクマネージャーを開ける。Microsoftはこれを、CPU・メモリ・ディスク・ネットワークの消費量を確認してアプリを管理するWindowsのシステム構成ツールと位置づけており、入口や説明はここで確認できる。

一瞬の値だけで判断せず、動作が重いときに2〜3分観察してから見極めるのがおすすめだ。

• CPUが長期間ほぼフル稼働: 同時に起動するウィンドウを減らし、動画と自動化を一時停止してから、高負荷のWebページを特定する
• メモリがほぼ枯渇: 使っていない環境やタブを閉じ、拡張機能を減らし、タスクを小さなバッチに分けて実行する
• ディスクが100%のまま: メモリ不足で頻繁にページングが起きていないか、ダウンロード・ウイルススキャン・キャッシュ書き込みが原因でないか確認する
• GPUが異常に上昇したり画面がちらついたりする: グラフィックドライバを更新し、ハードウェアアクセラレーションをオン／オフして対照テストする
• ネットワークが飽和: アップロード、ライブ配信、素材のダウンロード、自動化によるアクセスを時間帯でずらす

ブラウザ内蔵のタスクマネージャーも見る

ChromeではWindowsとLinuxでShift + Escを押すとブラウザのタスクマネージャーを開ける。ショートカットの出典はChrome公式のショートカットキー一覧ドキュメント。CPUやメモリ順に並べ替えると、特定のWebページや拡張機能、サブフレームが異常にリソースを消費しているのを素早く見つけられることが多い。

使用率が高いからといって、すぐにプロセスを終了しないこと。プロセス名と対応するページを記録し、それが動画の再生中なのか、ファイル転送やスクリプト実行中なのか、必要な業務を担っているのかを判断しよう。うかつに終了すると、保存していない内容を失う恐れがある。

さらに特定のWebページを詳しく調べたい開発者は、Chrome DevToolsのPerformance MonitorでCPU、JavaScriptヒープ、DOMノード、イベントリスナー、フレームレートをリアルタイムに観察できる。一般の運用担当者はフレームグラフまで読み解く必要はなく、「特定のページを開く前と後」のリソース変化を比べるだけで、異常はたいてい見つけられる。

ステップ2：抑えるべきは「同時にアクティブな数」であり、ウィンドウの総数ではない

同じ20個のウィンドウでも、すべて静的なページにとどまっている場合と、すべてが同時に動画を再生したりレポートを読み込んだりする場合とでは、負荷が桁違いに違う。最適化で本当に注視すべき指標は、「同じ時間に実際にアクティブになっている環境がいくつあるか」だ。

作業を3つの層に分けて管理するとよい。

1. 常駐層: 現在、メッセージにすぐ返信したり注文を処理したり異常を見張ったりしなければならないアカウント群
2. ポーリング層: 一定時間ごとに確認すれば足りるアカウント。小分けに開いて処理し終わったら閉じる
3. アーカイブ層: 当面タスクのないアカウントは閉じたままにして、必要な資料と操作ログだけ残す

たとえば30のショップを毎日チェックする必要があるなら、早朝にすべてを同時起動しなくてよい。1バッチ5つずつ開き、確認が終わったら閉じて次のバッチへ。バッチとバッチの間には少し間隔を空ける。こうすれば起動時のリソースピークを抑えられるうえ、カクつきが出たときも、どの環境がシステムを遅くしているのか特定しやすくなる。

ステップ3：タブ、動画、バックグラウンドの活動を整理する

ChromeのMemory Saver（メモリセーバー）は、使っていないタブを一時的に停止し、次にアクセスしたときに再読み込みする。Chromeのパフォーマンス設定に関する公式ドキュメントには、タブの休止を妨げるケースも列挙されている。音声・動画の再生、画面共有、ページ通知、ダウンロード中、未送信のフォーム、固定タブ、接続中のデバイスなどだ。

複数ウィンドウ運用の場面では、次のように調整しよう。

• Memory Saverをオンにして、まずはバランスレベルから始め、最も積極的なモードを最初から狙わない
• 本当に常駐させたいサイトだけを「常時アクティブに保つ」リストに入れる
• ミュートなのに再生され続ける動画、ライブ配信のプレビュー、延々と自動更新される広告ページを閉じる
• ダウンロード、アップロード、フォームの入力が終わってからウィンドウを閉じ、途中で離脱しない
• データダッシュボードが手動更新に対応しているなら、全ウィンドウが高頻度で自動更新するのは避ける
• 本当に長時間オンラインでいる必要があるサポートや会議のページは個別に例外を設定し、休止で業務が途切れないようにする

ひとつ注意しておくと、「より積極的にすればするほどメモリを節約できる」とは限らない。タブの休止と復帰が頻繁に繰り返されると、再読み込みやログイン認証も何度も発生する。自分の操作頻度に合ったバランス点を選べばよい。

ステップ4：拡張機能を厳選し、本当に使っているものだけ残す

拡張機能は、Webページの監視、リクエストの書き換え、ストレージの読み取り、バックグラウンドでの定期実行などを行うことがある。1つだけなら負荷は小さくても、同じ拡張機能一式が数十の独立した環境で繰り返し有効になれば、積み上がる負荷はかなりのものになる。

月に1回、拡張機能の棚卸しをするのがおすすめだ。

• 使わなくなったもの、出所が不明なもの、機能が重複するものを削除する
• たまにしか使わないものは先に無効化しておき、必要なときだけ有効にする
• 「全サイトでデータの読み取りと変更」の権限を、指定サイトのみ、またはクリックしたときだけに絞り込む
• 拡張機能をオフにする前後のCPU、メモリ、起動時間を比較して、データで判断する
• 「リソース節約」をうたう出所不明のクリーナー系拡張機能を新たに追加しない

Chromeの拡張機能の管理に関するドキュメントには、有効化、無効化、削除、サイトアクセス権限の調整方法が説明されている。チームで運用しているなら、統一の拡張機能ホワイトリストを整え、メンバーが機能重複や出所不明のツールを各自で入れないようにするとよい。

ステップ5：ハードウェアアクセラレーションは一括オフにせず、テストで判断する

ハードウェアアクセラレーションはグラフィック処理の一部をGPUに任せる仕組みで、動画、アニメーション、複雑なページには通常プラスに働くため、既定でオフにするのはおすすめしない。グラフィックドライバの異常、リモートデスクトップで十分なGPUサポートが得られない場合、一部のページで頻繁にちらつきやクラッシュが起きる場合にこそ、A/B対照テストをする価値がある。

1. まず現在のウィンドウ数、ページの種類、リソース使用率を記録する
2. ハードウェアアクセラレーションの設定を切り替えてブラウザを再起動する
3. 同じウィンドウと操作で同じ作業を再度実行する
4. より安定した方の設定を残し、ついでにグラフィックドライバも更新する

複数のシステムパラメータを同時に変更してはいけない。同時に変えると、たとえ性能が改善しても、どの項目が効いたのかを説明できなくなる。

ステップ6：自動化タスクに同時実行数の上限を設ける

自動化は「ウィンドウを一度に多く開けば開くほど速く回る」ということではない。同時実行数がマシンの許容範囲を超えると、ページの読み込みが遅くなり、タイムアウトや失敗時のリトライが増えるだけで、実際のスループットはむしろ下がる。

確実なのは段階的な負荷テストだ。まず同時実行数を2から始め、1バッチのタスクについて完了時間、失敗率、CPUピーク、メモリピークを記録し、その後4、6、8と順に上げていく。失敗率が上がり始める、あるいはタスク1件あたりの所要時間が伸びる変曲点を見つけたら、1段階戻して余裕を残す。

あわせて次のような仕組みも用意しておこう。

• 起動間隔を設け、全ウィンドウが同じ瞬間に一斉に読み込まれないようにする
• タスクごとのタイムアウトと、回数制限付きのリトライ
• キューの優先順位を設定し、サポートや注文といったリアルタイム性の高いタスクを先に実行する
• 処理が終わったらすぐウィンドウを閉じ、プロセスとメモリを解放する
• ログを残し、どのアカウントのどの段階でカクついたのかを特定できるようにする

独立した環境ではグループごとにずらして起動するほうが、一度に全部開くよりリソースを抑えられる

数十のプラットフォームアカウントを、普段は独立したブラウザ環境で区切って運用しているなら、高速化の重点は並列ウィンドウを増やすことではない。「このバッチではどの環境を先に回すか」をきちんと管理することだ。PurpleMarkのWeb版を例にすると、環境をプラットフォーム、地域、クライアントごとにグループ化しておき、毎朝その日に処理するグループだけを起動して、終わったら閉じる。実際に同時に開くべき数は、ページの複雑さ、拡張機能、ネットワーク、そしてそのマシンのハードウェア水準が一緒に決める。一度に全ウィンドウを並べるより、バッチ単位でタイミングをずらして起動するほうが安定しやすい。まず日常のバッチ運用のリズムを安定させてから、他の場所で同時実行数を増やすかを判断しよう。最初からすべての環境を同時に開く必要はない。

今日からすぐ実践できる高速化チェックリスト

いますぐ取りかかりたいなら、次の順序でひととおり確認しよう。

1. カクついたらシステムのタスクマネージャーを開き、CPU、メモリ、ディスク、GPU、ネットワークを記録する
2. ブラウザのタスクマネージャーで使用率の高いWebページと拡張機能を見つける
3. 業務上の価値のない動画、ライブ配信、ダウンロード、自動更新ページを閉じる
4. メモリ節約機能をオンにし、必要なサイトだけ常駐の例外として設定する
5. 不要な拡張機能を削除または無効化し、拡張機能のサイト権限を制限する
6. アカウントを小さなバッチに分け、起動と終了のタイミングをずらす
7. 自動化に同時実行数の上限、起動間隔、タイムアウト、ログを設定する
8. ハードウェアアクセラレーションとグラフィックドライバは個別にテストし、一度に複数変更しない
9. 一度に1つの変数だけを変え、変更前後のデータを保持する
10. それでもリソースが長期間上限に張り付くなら、メモリ増設やCPUのアップグレード、複数デバイスへのタスク分散を検討する

よくある質問

キャッシュの削除で、複数ウィンドウ運用はずっと速くなるのか？

そうとは限らない。キャッシュは本来、重複したダウンロードを減らすためのものだ。異常なキャッシュやディスク容量不足が原因のときは削除が役立つが、頻繁に全量削除するとページがリソースを取り直すことになり、再ログインのコストも増える。キャッシュ削除は原因切り分けの手段として使い、日常的な高速化の中心には据えないほうがよい。

メモリが大きければ、開けるウィンドウも必ず増えるのか？

そうではない。メモリは要素の1つに過ぎず、CPU、GPU、ディスク、ネットワーク、Webスクリプト、拡張機能が先にボトルネックになることもある。アップグレードする前に、数日観察して本当の制約がどこにあるのかを確認しよう。

なぜウィンドウを開いた直後がいちばん重いのか？

起動時は、環境データの読み込み、拡張機能のロード、ネットワーク接続の確立、ページの描画を同時に行う。複数のウィンドウが一緒に起動するとリソースのピークが生じるため、後からプロセスを終了するより、起動間隔を空けるほうが効果的だ。

ハードウェアアクセラレーションはずっとオフにすべきか？

一概には言えない。ドライバとGPUが正常な状態では、ハードウェアアクセラレーションは通常価値がある。画面の異常、クラッシュ、特定のリモート環境との非互換があるときだけ、対照テストを検討すればよい。

まとめ

ブラウザの複数ウィンドウ高速化に、一発で効く万能スイッチはない。より確実な道筋はこうだ。まずシステムとブラウザの2つのタスクマネージャーでボトルネックを確認し、次に同時にアクティブなウィンドウ、バックグラウンドのメディア、重複した拡張機能を減らす。最後に、バッチ起動、同時実行数の上限、ログの仕組みでワークフロー全体を安定させる。

調整のたびに前後のデータを比べていれば、最適化すべき対象がページなのか、拡張機能なのか、タスクの編成なのか、それともハードウェアなのかが徐々にわかるようになる。あれこれの「高速化テクニック」を試行錯誤で渡り歩く必要もなくなる。