BLaDE: Braveの新たな性能評価基盤
BLaDEはBraveのオープンソース自動性能評価基盤です。このシステムは、ユーザーの行動をシミュレートしながらデバイスのメトリクスを正確に測定し、モバイルアプリの評価、診断を向上させます。
この記事を読む →
この記事は、Braveのパフォーマンスを評価する継続的なシリーズです。シニア機械学習リサーチャーのKleomenis KatevasとシニアモバイルセキュリティエンジニアのArtem Chaikinによって行われた研究を紹介します。
2019年後半、ブラウザバージョン1.0のリリースと併せて、私たちはBraveのパフォーマンスを測定するため一連のテストを実施しました。これらのテストでは、他のブラウザのデフォルト体験と比較して、特に拡張機能ベースの広告ブロッカーを使用するブラウザと比較して、ページ読み込み速度、データ使用量、バッテリー消費量、その他の指標においてBraveの明確な優位性が示されました。
先日、BraveはAndroid専用にこれらのテストの更新と再実行を行いました。その目的は、Braveブラウザが進化する中で、Brave 1.0当時におけるパフォーマンス上の利点が現在も維持されているかどうかを検証することでした。結論を先にお伝えすると、Android版Braveは引き続き現在も高速で、バッテリーとCPUの使用量が少なく、モバイルデータやWi-Fi帯域幅の消費も少ないままです。具体的には、BraveはテストされたAndroidブラウザの中で、平均してバッテリーを4%、CPUを9%少なく使用し、Webページの読み込みが21%高速で、帯域幅の使用量が14%少なくなっています。これらのパフォーマンスの優位性は、広告、トラッカー、フィンガープリンティング、バウンストラッキングをデフォルトでブロックするBraveの高度なプライバシーとセキュリティ機能によるものです。これらの保護機能は、ユーザーのプライバシーを向上させるとともに、不要なネットワークリクエストと処理オーバーヘッドを削減し、日常的なブラウジングにおいてより高速な読み込み時間とより低いエネルギー消費を実現しています。
この投稿では、Androidデバイスでのテスト環境、方法論、およびパフォーマンス結果について詳細に説明します。今後、デスクトップおよびiOSデバイスについても同様に一連の結果をお知らせする予定です。
私たちのテスト環境で使用されたハードウェアは、人気のAndroidデバイスであるGoogle Pixel 6a(2022年)で、Android 13(ビルドTQ3A.230605.010)を使用しています。このデバイスは、オクタコアプロセッサー(2×2.80 GHz Cortex-X1、2×2.25 GHz Cortex-A76、4×1.80 GHz Cortex-A55)と6GBのRAMを搭載しています。
テストでは、2025年7月1日時点で利用可能な最新版である以下のブラウザバージョンを使用しました。
すべてのテストは、ロンドンの専用50Mbpsインターネット接続で実施され、Androidデバイスは内部5GHz WiFiネットワーク(Wi-Fi 6、802.11ax)を使用しました。
私たちのパフォーマンス評価は、ブラウザパフォーマンスの以下の属性に焦点を当てています。
loadEventEnd
を通じて評価され、初期リクエストからページが完全にインタラクティブになるまでの時間を表します。実際の使用ケースとして、(Brave Search統計によってランク付けされた)最も人気のある50のWebサイトをテストしました。それぞれにランダムに選択されたサブページを組み合わせ、合計100のシャッフルされたURLを使用し、読み込まれたコンテンツとのユーザーインタラクションをシミュレートしました。各実験は10回繰り返され、実行ごとにブラウジングアプリの順序をランダム化しました。
Androidの分析では、まず各ブラウザを開いた後にアプリプロファイルを保存し、オンボーディング画面をスキップし、デフォルト設定を選択し、すべてのコンポーネントが最新であることを確認するために60秒待機しました。同じプロファイルがすべての10回のテスト実行で使用され、各実験の実際のワークロードは以下の通りでした。
Androidでのブラウザパフォーマンスを評価するために、Google Pixel 6aでオープンソースのBLaDEインフラストラクチャ(v0.3)を使用しました。これにはバッテリーの取り外し、内部コントローラーの分離、外部電源端子の配線を含むバッテリーバイパス設定を実装しました。このハードウェア改造により精密な電力測定が可能になり、他のソフトウェアベースの方法よりも高い精度での検証が可能になりました。
ページ読み込み時間の指標の計測には、プロキシサーバー(mitmproxy v8.1.1)を使用し、ページ読み込み関連の指標をローカルWebサーバーに送信するJavaScriptスニペットを動的に注入しました。
CPU使用率は、デバイスの /proc/stat
を3秒ごとにサンプリングすることで監視しました。URL毎のメモリオーバーヘッドを測定するために、各タブを閉じる前に dumpsys meminfo
を使用して、関連するブラウザプロセスの比例セットサイズ(PSS)を収集しました。
測定ノイズを最小限に抑えるために、確立されたベストプラクティスを使用してデバイスを準備しました。
まず、5つのモバイルWebブラウザにおいてURL毎のリソース消費量(具体的にはエネルギー、CPU、メモリ消費量)を分析しました。図1は各ブラウザ毎のタスクに必要な総電力放電量(mAh)を表した棒グラフを示しています。エラーバーは10回の実行における95%信頼区間を示し、電力使用量の一貫性を表しています。
図1: 総電力消費量(mAh)
テストされたブラウザの中で、Braveが最もエネルギー効率が良く、総電力使用量は557.68 mAhでした。これはChrome、Edge、Firefoxと比較して平均約3.9%少なく、DuckDuckGoと比較して23.7%少ない結果でした。CPU使用率をテストした際も同様の傾向が見られ(図2)、BraveはChrome、Edge、Firefoxと比較して平均5.5%少ないCPUを使用し、DuckDuckGoと比較して17.6%少ない使用量でした。
図2: CPU使用率(%)
DuckDuckGoブラウザは、すべてのテストにおいて一貫して著しく高いエネルギー消費を示したことに注意してください。調査の結果、リソース管理の問題を特定しました:タブが閉じられた際に、アプリが関連するWebViewを適切に終了できていませんでした。その結果、バックグラウンドプロセスが実行し続け、エネルギー使用量の増加とパフォーマンス指標の膨張、特に受信帯域幅の面で問題が生じていました。この問題はebay.comで特に顕著で、タブが閉じられた後も数分間にわたってライブストリーミングコンテンツが受信・処理され続けていました。これらの調査結果はDuckDuckGo開発チームに提出し、さらなる調査を依頼しました。
異なるブラウザ間でのメモリ使用量を評価するために、関連するブラウザプロセスのPSS(プロセスが実際に使用しているメモリ量を正確に測定する指標)を監視しました。オペレーティングシステムのWebViewに依存するDuckDuckGoについては、WebViewのメモリオーバーヘッドも考慮しました。図3は、各ブラウザのメモリ消費量の累積分布関数(CDF)プロットを示しています。
図3: メモリ(MB)
Braveは合計でChromeよりメモリ使用率が4.6%高いのですが、この差は主にBraveの内蔵機能、特にChromeにはないネイティブ広告・トラッカーブロッカーによるものと説明できます。この小さなトレードオフにより、外部拡張機能を必要とせずに、より良いプライバシーと速度を実現しています。Braveは現在、ネイティブ広告・トラッカーブロッカーのメモリ使用量削減に積極的に取り組んでおり、今後数ヶ月でこの差を大幅に縮小する予定です。重要なことは、Braveは追加機能があるにもかかわらず、平均してDuckDuckGoより31.1%、Edgeより9.8%、Firefoxより40.1%少ないメモリを使用しており、その効率性を強調していることです。
Webブラウザを使用する際に生じるユーザーにとって最も大きな差は、Webサイトの読み込み速度です。前述のとおり、ローカルWebサーバーでmitmproxyを活用し、読み込まれた各WebサイトにJavaScriptを動的に注入し、 loadEventEnd
イベントまでの時間を測定しました。これらの測定値はURL毎に収集され、異なるWebサイト間での変動を捉えました。図4は、各ブラウザのこれらの読み込み時間の累積分布関数(CDF)プロットを示しています。Braveは一貫して他のブラウザを上回る性能を示し、最も高速な全体的読み込み時間分布を持ち、ページの80%以上が2.5秒未満で読み込まれています。
図4: ページ読み込み時間(秒)
帯域幅の消費量を評価するために、私たちは2つの主要な指標を分析しました。ネットワーク経由で受信したデータの総量を捉えるネットワークRx(図5a)と、送信されたデータの総量を反映するネットワークTx(図5b)です。両方の図のエラーバーは、10回の実行における95%信頼区間を示しています。これらの測定値は adb shell dumpsys netstats
を使用して収集し、アプリごとのネットワーク使用量を正確に追跡することができました。
テストしたブラウザの中で、Braveは最も効率的なネットワーク使用量を示し、359.6 MBを受信し、わずか13.6 MBを送信しました。これはDuckDuckGoと比較して受信データが最大34%少なく、送信データが55%少なく、その他の競合ブラウザと比較しても受信データが最大16%少なく、送信データが51%少ないという結果でした。これらの結果は、不要なリクエストをブロックすることで、受信と送信の両方のデータ使用量を最小限に抑えるBraveの明確な優位性を浮き彫りにしています。
図5a: ネットワークRx(MB)
図5b: ネットワークTx(MB)
Speedometer、JetStream、MotionMarkなどの合成ベンチマークはブラウザのパフォーマンスを評価するために一般的に使用されていますが、これらは主にブラウザ機能の特定の部分に焦点を当てています。
Speedometer 3.1は、タイピングやUI要素の更新などのユーザーインタラクションをシミュレートして、ブラウザがJavaScriptベースのWebアプリケーションをどれだけ迅速に実行できるかを測定します。
JetStream 2.2は、JavaScriptの実行速度とWebAssemblyのパフォーマンスを評価し、ブラウザが計算集約的なタスクをどれだけうまく処理できるかを評価します。
MotionMark 1.3.1は、グラフィックスパフォーマンスに焦点を当て、ブラウザが複雑なアニメーションや視覚効果を毎秒60フレームでどれだけ効率的にレンダリングできるかをテストします。
これらのテストはエンジンパフォーマンスについて有用な洞察を提供しますが、プライバシー保護、広告ブロック、ネットワーク最適化など、実際のブラウジングに影響する重要な要因を省いています。さらに、Brave、Chrome、Edgeなどのブラウザは同じChromiumエンジンを共有しているため、実際のパフォーマンスに大きな違いがあるにもかかわらず、ベンチマークスコアは似たような傾向になります。
完全な全体像を提供するため、私たちはこれらの合成ベンチマークの結果(図6a、6b、6c)を含めており、各テストは最新のブラウザバージョンで10回実行されました。エラーバーは10回の実行における95%信頼区間を示しています。これらの制御された条件下で、Braveは一貫して良好なパフォーマンスを示し、一部のケース(例:JetStream 2.2)では競合他社を上回る性能を発揮する一方で、全体的なブラウジング体験を向上させる強化されたプライバシーと効率性も提供しています。
Figure 6a: Speedometer 3.1(高い方が高性能)
Figure 6b: JetStream 2.2(高い方が高性能)
図6c: MotionMark 1.3.1(高い方が高性能)
上記で示されたように、BraveはAndroidデバイスにおいて最も高速で、最もリソース効率が良く、最もネットワーク負荷の少ないブラウザであり続けています。これは部分的に、Braveにネイティブに統合された広範囲なプライバシーおよび最適化機能によるものです。将来的には、デスクトップおよびiOSモバイルデバイスで同様のテストセットを実行し、すべてのオペレーティングシステムでこれらのテストを定期的に再実行して、Braveが利用可能な主要ブラウザの中で最もパフォーマンスの高いブラウザであり続けることを明確にする予定です。
この投稿の結果に関するご質問やコメントについては、Brave Research チーム(blade-project@brave.com)にお問い合わせください。
BLaDEはBraveのオープンソース自動性能評価基盤です。このシステムは、ユーザーの行動をシミュレートしながらデバイスのメトリクスを正確に測定し、モバイルアプリの評価、診断を向上させます。
この記事を読む →ユーザが節約できた時間について、これまでBraveはかなり控えめに推定値を出してきました。推定方法は、ブロックした広告とトラッカーの総数に50ミリ秒を乗じるというものですが、いくぶん単純すぎるところがあります。なぜ50ミリ秒なのでしょうか。50ミリ秒は、サードパーティがJavaScriptを実行するためのオーバーヘッドとして他で推定されている値の最小値に相当します。
この記事を読む →