この記事は Chrome ソフトウェア エンジニア、Clark Duvall による Chromium Blog の記事 “Partitioning Chrome’s Code for Faster Launch Times on Android” を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

通常、モバイル デバイスは、ノートパソコンやデスクトップよりもリソースが限られています。モバイル ユーザーが Chrome を高速に使えるようにするには、Chrome のリソース使用の最適化が欠かせません。Android 版の Chrome に機能を追加するにつれて、アプリにパッケージ化される Java コードの量は増え続けています。今回の速さと好奇心の投稿では、Isolated Splits によって Android 版 Chrome のスピードとメモリ使用量をどのように改善したのかについて説明します。この改善により、Android 版 Chrome のメモリ使用量が 5-7% 減少し、起動とページ読み込みの速度もさらに向上しました。

Reviewed by Eiji Kitamura – Developer Relations Team<!—->

この記事は Chrome ブラウザ、プロダクト マネージャー、Yana Yushkina による Chromium Blog の記事 “Searching, browsing, and shutdown Chrome performance improvements” を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

Chrome では、さまざまなプロジェクトを通じて、パフォーマンスを改善するための長期的な取り組みが行われています。今回の速さと好奇心シリーズの投稿では、スピード、メモリ、意図しないハングに関する改善について紹介します。現在、検索の 6 回に 1 回は一瞬で終わり、PartitionAlloc に関する作業によって Chrome OS でのブラウジングで最大 20% のメモリが削減され、Chrome OS と Windows のシャットダウン操作に関する厄介な問題も解消されています。

アドレスバー

Chrome のアドレスバーを使ってウェブを検索すると、文字を入力するのに合わせて検索語句の候補が表示されることに気づくはずです（Chrome の設定で [ 検索語句や URL をオートコンプリートする ] 機能をオンにしている場合）。これにより、検索語句すべてを入力する必要がなくなるので、情報の検索が迅速かつ簡単になります。求めている検索語句が提案されるまでテキストを入力すれば、すぐにそれを選択できます。

Chrome で検索すれば、さらに高速になります。提案された検索語句が選ばれる可能性が高い場合、検索結果がプリフェッチされるようになったからです。つまり、皆さんが検索語句を選択する前にウェブサーバーから結果を取得するので、検索結果が表示されるまでの時間がさらに短縮されます。実際に実験を行ったところ、検索結果が 500 ミリ秒以内に表示される可能性が 4 倍になったことがわかりました。

現在、この処理が行われるのは、Google 検索がデフォルトの検索エンジンになっている場合だけです。しかし、こちらの記事で説明しているように、提案する検索語句をサーバーから Chrome に送信する際に情報を追加することで、他の検索プロバイダもこの機能をトリガーできます。

Chrome OS の PartitionAlloc

Chrome の新しいメモリ アロケータである PartitionAlloc は、M89 で Android と Windows にロールアウトされました。その結果、メモリ使用量を「最大 22% 節約」でき、パフォーマンスについては「応答性が最大 9% 向上」しました。それ以降も、Linux には M92 で、Chrome OS には M93 で PartitionAlloc を導入しました。うれしいことに、Chrome OS の M93 のフィールド データから、合計メモリ フットプリントが 15%、ブラウザ プロセスのメモリが 20% 減少し、単一タブ、複数タブの両方で Chromebook のブラウジング体験が向上したことがわかりました。

シャットダウン時に最も頻繁に発生するハングを解消

パフォーマンスを改善するため、ソフトウェア エンジニアがシステムにキャッシュを追加するのはよくあることです。しかし、キャッシュの副作用として他の問題（コードの複雑化、安定性、メモリ消費、データの整合性）が発生することも多く、逆にパフォーマンスが悪化する可能性すらあります。今回の事例では、起動時間を短縮するため、数年前に Chrome の履歴システムにローカル キャッシュを追加していました。当時の前提は、Chrome の内部メモリに履歴インデックスをキャッシュする方が、起動のたびに履歴のインデックスを再作成するよりも速いというもので、ラボ環境でのテストでもそれが実証されていたようです。

しかし、クラッシュ データと匿名のパフォーマンス指標から実世界でのパフォーマンスを体系的に調査し続けた結果、このキャッシュによってコードが複雑になり、メモリ使用量が不必要に増加しているだけでなく、シャットダウン時にブラウザがハングする問題の一番の要因にもなっていることがわかりました。その原因は、システムの別の場所で他の I/O が起こり続けている間、バックグラウンド優先スレッドの I/O 枯渇状態が延々と続く OS があることです。さらに、フィールド データの解析結果によれば、パフォーマンス面でユーザーが受けるメリットはほとんどありませんでした。現在は、このキャッシュを削除することで、シャットダウン時に最も頻繁に発生していたハングを解消しています。これは、キャッシュは必ずしも正解ではないという原則を示す好例となりました。

今後もさまざまなパフォーマンスの改善についてお知らせしますので、ご期待ください。

すべての統計情報の出典 : Chrome クライアントから匿名で集計した実データ 

Reviewed by Eiji Kitamura – Developer Relations Team<!—->

この記事は Chrome デベロッパー、Olivier Li Shing Tat-Dupuis による Chromium Blog の記事 “Faster and more efficient phishing detection in M92” を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。

ウェブをブラウジングする Chrome ユーザーの安全を確保することは、Chrome にとって非常に重要です。実際、セキュリティは 4 つの基本原則の 1 つであり続けています。ときに、セキュリティのためにパフォーマンスが犠牲になることがあります。パフォーマンスの探求シリーズの次の投稿では、オンラインのユーザーの安全を確保するフィッシング検知アルゴリズムをどのように改善したかについてお伝えします。ここで紹介する改善によって、現在のフィッシング検知は 50 倍高速になり、電池使用量も少なくなっています。

フィッシング検知

Chrome は新しいページに移動するたびに、ページの一連のシグナルがフィッシング サイトのシグナルと一致するかどうかを評価します。これを行うため、アクセスしたページのカラー プロファイル（ページで表示される色の範囲と頻度）と、通常のページのカラー プロファイルを比較しています。たとえば以下のイメージでは、ほとんどがオレンジ色で、緑と少しばかりの紫が含まれていることがわかります。

サイトが既知のフィッシング サイトと一致した場合、Chrome は警告をし、個人情報を保護して認証情報が漏れることを防ぎます。

フィッシングの試みが検知された場合に表示される画面

プライバシーを守るため、Chrome のセーフ ブラウジング モードは、デフォルトでブラウザ外にイメージを送信することはありません。これはプライバシーにとってはよいことですが、マシンはイメージを分析する作業をすべて自力で行わなければならないことになります。

多くの場合、イメージ処理は重いワークロードになる可能性があります。イメージの分析には、一般的に「ピクセルループ」と呼ばれる処理をし、各ピクセルを評価する必要があるからです。最新のモニターの中には最大で 1400 万ピクセルを超えるものもあります。そのため、各ピクセルで単純な操作をするだけでも、積もり積もってかなりの CPU 使用量になります。フィッシング検知で各ピクセルに対してするのは、基本色を数える操作です。

この操作は、次のようになります。この数は、ハッシュマップと呼ばれる連想データ構造に格納されます。各ピクセルについて RGB のカラー値を抽出し、その数を色ごとに 1 つずつ、3 つの異なるハッシュマップのいずれかに格納します。

効率の改善

ハッシュマップに 1 つの項目を追加するのは高速ですが、この操作は何百万ものピクセルに対して行う必要があります。分析の質が損なわれないように、ピクセルの数を減らすことは避けますが、計算自体は改善できます。

次のようにパイプラインを改善します。

• このコードでは、3 つのハッシュマップで RGB チャンネルを追跡するのではなく、ハッシュマップを 1 つだけ使って色ごとにインデックスを管理します。これで、数える回数が 3 分の 1 になります。
• 連続したピクセルは、ハッシュマップで数える前に合計します。これにより、均一な背景色のサイトでは、ハッシュマップのオーバーヘッドがほぼゼロになります。

その結果、色を数える操作は次のようになります。ハッシュマップの操作が大幅に減っていることに注意してください。

高速化の成果

Chrome M92 以降のイメージベースのフィッシング分類は、50 パーセンタイルで最大 50 倍高速に、99 パーセンタイルで 2.5 倍高速に実行されます。平均で、ユーザーがフィッシング分類結果を取得するまでの時間は 1.8 秒から 100 ミリ秒に短縮されます。

これにより、Chrome を使ううえで 2 つのメリットがあります。1 つ目かつ最大のメリットは、同じ作業をするために消費する CPU 時間が減り、総合的なパフォーマンスが向上することです。CPU 時間が減れば、電池の消耗もファンが回る時間も少なくなります。
2 つ目は、結果を早く取得できるため、Chrome が警告を早く表示できることです。この最適化により、処理に 5 秒以上かかるリクエストの割合が 16.25% から 1.6% 未満に下がりました。この速度の改善により、特に悪意のあるサイトでパスワードの入力を防ぐという点で、セキュリティに大きな違いが生まれます。