「Chrome」拡張機能がブラウズに悪い影響を与える、DebugBearが調査：メモリやCPUの消費量が多いものはどれだ

Webサイト「DebugBear」は、Webブラウザ「Chrome」の拡張機能が、Chrome本体のパフォーマンスに与える影響について調査した。ダウンロード数が上位にある1000本の拡張機能が対象だ。テストの結果、CPU時間を数秒利用するものや、数百MBのメモリを消費するものがあった。これらは快適な閲覧の妨げになる可能性があり、解決するには拡張機能の設計を改善する必要がありそうだ。

[＠IT]

　フロントエンド開発者向けのWebサイトモニタリングサービスを提供するWebサイト「DebugBear」は2020年6月15日（米国時間）、Webブラウザ「Google Chrome」の拡張機能が、Chrome本体のパフォーマンスに与える影響について調査した結果を発表した。

　DebugBearは、ダウンロード回数が最も多い上位100本と、さらに上位1000本のChrome拡張機能を取り上げ、Chrome本体のパフォーマンスに与える影響を調査した。調査では、以下の4つの指標を測定した。

• ページのCPU時間　Webページのメインスレッドがどれだけの時間、拡張機能のためにビジー状態になるか
• ページレンダリングの遅延　Webページが何らかのコンテンツを表示するまでにどれだけの時間がかかるか
• バックグラウンドでのCPU時間　拡張機能がバックグラウンドでどれだけの処理を行うか
• Webブラウザのメモリ消費　Webブラウザの各種コンポーネントがどれだけのメモリを使用するか

上位100本の拡張機能がChromeのCPU時間に与える影響は意外に大きい

　拡張機能によってJavaScriptの実行やレイアウトロジックの実行が始まると、Webブラウザのメインスレッドはブロックされてしまう。Webブラウザはユーザーの操作に応答できなくなる。

　拡張機能が一切インストールされていない場合、「http://example.com/」をロードするのに必要なCPU時間は40ミリ秒程度だ。拡張機能の「Evernote Web Clipper」や「Grammarly」をインストールすると、CPU時間が500ミリ秒以上に跳ね上がる。

「example.com」ページをロードする際に必要なCPU時間（出典：DebugBear）　1番目の列は拡張機能を全くインストールしていないときのもの

　このグラフは、ダウンロード回数が最も多い上位100本の拡張機能（ダウンロード回数200万回以上）のうち、ページのCPU時間が最も長い上位20本を示している。他の80本の拡張機能は、ページCPU時間が100ミリ秒に満たない。

　CPU時間が長い拡張機能は、ユーザーが開く全てのWebページにコードを追加する。次の図に示した「Evernote Web Clipper」（以下、Evernote拡張機能）は、全てのページに約2.9MBのコンテンツスクリプトを追加する。このコードの解析とコンパイルに140ミリ秒かかる。

Evernote拡張機能のトレース結果（出典：DebugBear）　コードが解析、コンパイル、実行されることを示す

　追加後のページがロードされると、評価が必要になるため、さらに300ミリ秒かかる。

　このコードは、ユーザーがEvernote拡張機能のアイコンをクリックすると起動するイベントリスナーをセットアップする。だが、これは、JavaScriptバンドル全体をロードしなくても可能だ。

　不要なコードが大量にロードされるというEvernote拡張機能の動作パターンは、他のChrome拡張機能にも珍しくない。

拡張機能が大量のスクリプトを追加するためにCPU時間が延びている（出典：DebugBear）

　全てのWebページにコードを追加する必要がある拡張機能は多い。パスワード管理ツールはログインフォームがあるかどうかをチェックする必要があり、スペルチェッカーは、テキストフィールドを探す必要があるからだ。

　だが、関連条件をチェックするコードを拡張機能の主要機能から分離すれば、パフォーマンスは大幅に改善するはずだ。コードの大部分が、必要な場合にのみロードされるからだ。例えば、拡張機能の「Honey」は2019年にこのような変更を進めたため、パフォーマンスへの影響が大幅に減少した。

ページレンダリングが遅延する悪影響は比較的小さかった

　CPU時間が余計にかかると、Webページを一定時間、操作できなくなる。だが通常、これによってWebページのレンダリングが完全にブロックされることはない。拡張機能がレンダリングをブロックするかどうかを調べるには、Webブラウザがテキストや画像を表示し始めるときに、「First Contentful Paint」（FCP）指標を測定すればよい。FCPは、ブラウザがDOM（Document Object Model）から得たコンテンツの最初のビットをレンダリングし、Webページが読み込み中というユーザーへの最初のフィードバックがなされる時間を指す。

　ほとんどの拡張機能は、レンダリングの遅延を全く、あるいはわずかしか発生させない。だがそうではない拡張機能もある。次のグラフは、FCPへの悪影響が大きい上位20本の拡張機能を示している。

拡張機能によってどの程度Webページの表示が遅れるか（出典：DebugBear）　https://example.comをロードした場合のFCPを表す

　Chrome拡張機能は、Webページに追加されスクリプトとスタイルシートを定義できる。デフォルトでは、Webページのロードが完了し、アイドル状態のときに始めて実行される。

　だが、拡張機能の開発者は、Webページのロード開始時に、直ちにこうしたリソースをロードされるよう選択できる。例えば、拡張機能の「Dark Reader」は、Webサイトのコンテンツをダークテーマに変える。ページが最初に明るいテーマでレンダリングされた後、すぐにダークテーマに切り替わるのは、ユーザーにとって迷惑だろう。この場合、ページのレンダリングが始まる前にコードを実行することが理にかなっている。

　ただし、こうしたコードの量は、最小限に抑える必要がある。幸いなことに、上のグラフにある拡張機能の中で、100ミリ秒以上のレンダリング遅延を引き起こすものは6つしかない（「Clever」から「LastPass」まで）。

　これらの拡張機能は、Webページのレンダリングが始まる前に、大量のコードを実行する。「Clever」の場合、ページコンテンツの表示は拡張機能をインストールしていないときよりも300ミリ秒遅れる。

隠れたCPU時間、目に触れないページの処理が重い