ブログに掲載された調査によると、Chromeのネットワークへのリクエストが広告ブロッカーによって行われたとき、ミリ秒未満の影響がありました。
昨年10月、ChromeはGhosteryが調査を行ったマニフェストV3と呼ばれる拡張機能を開発するための基準を発表しました。ベンチマークの結果と一緒に研究が投稿された直後に、Chromeは修正計画を取り戻しました。
By Chrome には、拡張機能の開発に使用する Chrome 関数と API のルールが設定されていました。これには、拡張機能がネットワーク要求を傍受して処理する必要があることを含みます。WebRequest API を使用する代わりに、拡張機能は、新しい を使用するように求められました。ユーザーとエクステンション開発者の両方が、独自の広告ブロッカーが組み込まれているため、サードパーティの広告ブロッカーを弱体化させようとしていた Chrome を非難しました。
Chromeの防衛では、エンジニアは、拡張に対するネットワーク要求の定義された数を持たないと、そのパフォーマンスにどのような影響を与えるかを示しました。Ghosteryチームは、彼らの研究は、拡張機能が任意のJavascriptを実行できることを述べているマニフェストV3提案の主張の1つに基づいているという声明に反対しました, すべてのネットワーク要求にアクセスするためにコンテンツブロッカーをアブリング.
彼らは、最も一般的なコンテンツブロッカーは非常に効率的であり、ユーザーにとって顕著なスローダウンは存在しないとの見解でした。この調査には、Adblock Plus、Bravo、DuckDuckGoなどの一般的な広告ブロッカーのパフォーマンス分析が含まれており、リクエストごとにかかったサブミリ秒の決定時間が示され、Chromeチームの主張に明らかに反対しました。
数時間後、調査が発表されてから、GoogleのエンジニアはマニフェストV3で行われたリラクゼーションについて発表しました。Chrome エンジニアの 1 人は、マニフェスト V3 で webRequest API が完全に排除されないと言いました。
“webRequest API は、マニフェスト V3 の一部として完全に削除される予定ではありません。特に、現在のところ、webRequest の観測機能に対する計画的な変更はありません (つまり、要求を変更しないもの)。また、受け取っているフィードバックを継続的に聞き、評価しており、webRequest APIに対する変更案を絞り込んでいます」と、Googleグループ投稿でDevlin Cronin氏は説明しました。
Cronin氏は、顧客がニーズに応じて Chrome をカスタマイズするために拡張機能が重要な役割を果たしていることを明らかにし、拡張機能エコシステムを維持する予定です。Chrome は、コンテンツブロック、開発者ツール、その他の機能に関連する拡張機能を引き続きサポートします。
ユーザーは拡張機能に慣れていて、使用に参加しています。様々な研究によると、すべての拡張速度が低下するわけではないため、ページを速く読み込むことがよくあります。CPUの消費量とページのダウンロードサイズを増加させるものがあります。
関連：
画像: APフォト/マーク・レニハン
