今回の「速さと好奇心」の投稿では、Chrome がどのようにして Speedometer 3.0 の史上最高スコアをたたき出したのかについて紹介します。Speedometer 3.0 は、アップグレードされた新しいブラウザ ベンチマーク ツールで、ウェブ アプリケーションのパフォーマンス最適化に役立ちます。今すぐ Chrome をお試しください。 

先日公開された Speedometer 3.0 は、ブラウザのパフォーマンスを測定するためのベンチマークで、企業を超えた業界全体のコラボレーションとして、Google、Apple、Mozilla、Intel、Microsoft などが作成したものです。Chrome を最適化し、すべてのユーザーのブラウザ エクスペリエンスを高速化できる領域を特定する際に役立ったのが、このベンチマークでした。

この更新版のベンチマークが開発されている間に、最新の Chrome のパフォーマンス情報をじっくりと慎重に追跡し、さらに最適化を進めることで、Speedometer 3 の史上最高のスコアをたたき出すことができました。ここでは、その手法について詳しく説明します。2022 年 5 月に Speedometer 3 が構想されてから、Chrome の Speedometer スコアは 72% 増加しました。これは、ユーザーのパフォーマンスが向上したと言い換えることができます。



ワークロードを最適化する

Speedometer のワークロードと Chrome で特に時間がかかっている関数を調べることで、最適化の対象を絞りこむことができ、それによって、Chrome のスコアが向上しています。たとえば、SpaceSplitString は頻繁に使われる関数で、"class='foo bar' " のようなスペース区切り文字列をリスト表現に変換します。この関数で、いくつかの不要な境界チェックを削除しました。重複するスタイルシートが存在することがわかった場合は、重複を排除し、1 つのスタイルシート インスタンスを参照するようにしています。また、メモリ割り当てを調整することで、パスや円弧の描画コストを削減する最適化を行いました。フォーム エディタの作成時には、フォーム要素を作成する際に不要な処理があったことがわかりました。querySelector でよく使われるセレクタを検出し、そのためのホットパスを作成しました。

以前にお知らせしたように、解析に特化した高速パスを使って innerHTML を最適化しましたが、この実装は WebKit にも採用されました。Speedometer 3 のワークロードには DOMParser を使っているものもあるため、同じ最適化を拡張することで、さらに 1% 向上させることができました。

また、Harfbuzz のメンテナンス担当者と協力し、Apple の Mac OS システム フォントで使われているような AAT フォントのレンダリング方法を最適化しました。テキストは、処理済みの Unicode 文字のストリームとして始まり、グリフのストリームに変換されてから、AAT フォントで定義されたステートマシンで実行されます。この最適化により、グリフが実際にステートマシンのルールの一部であるかどうかを高速に判断できるようになり、AAT によるテキスト処理のスピードアップにつながります。

注目すべき適切なコードを選ぶ

高いパフォーマンスを実現するために重要な戦略は、コードのティアリングです。これは、エンジンでさらに最適化できるコードを適切に選択することを指します。Intel は、V8 にプロファイルによるティアリングを提供しました。これは、過去のティアリングの決定を記憶する機能で、ある関数が過去に確実にティアリングされていれば、将来の実行時に積極的にティアリングするようにします。

ガベージ コレクションを改善する

Speedometer 3 で約 3% の向上につながったもう 1 つの変更領域がありました。それは、ガベージ コレクションの改善です。V8 のガベージ コレクタは、かなり以前からレンダラのアイドル時間を利用しています。これは、実際のアプリケーション コードに干渉しないようにするためです。最近の変更も、この考え方に則っています。つまり、レンダラは通常、非常に活発に動作していますが、可能な限り、そのアイドル時間にガベージ コレクションを行うように、既存のメカニズムを拡張します。具体的には、オブジェクトの再利用時に実行される DOM のファイナライズのコードもアイドル時間で実行されるようになっています。これまでこのような操作は、CPU リソースをめぐって通常のアプリケーション コードと競合していました。さらに V8 は、DOM 要素をラップするオブジェクト、つまり JavaScript フレームワークに公開されるすべてのオブジェクトで、はるかにコンパクトなレイアウトをサポートするようになっています。このコンパクトなレイアウトのおかげで、メモリ負荷が軽減され、ガベージ コレクションにかかる時間が短くなっています。


Reviewed by Eiji Kitamura - Developer Relations Team

今後、ChromeOS が Android スタックの大部分をベースとしたものになり、Google AI、イノベーション、機能をいち早くユーザーにお届けできるようになります。

私たちは、過去 13 年間にわたって ChromeOS を進化させ、安全かつ高速でさまざまな機能を持つ Chromebook エクスペリエンスを、世界中の何百万人もの生徒や教師、家族、ゲーマー、企業に提供してきました。最近では、Google AI と Gemini を使った新機能も発表され、Chromebook は日常のタスクを支援するツールを多くの人々に届けています。

今後も新しい Google AI 機能をたくさんのユーザーにすばやく展開できるように、ChromeOS の基盤の一部として、Android Linux カーネルや Android フレームワークなど、Android スタックの一部を採用いたします。この 2 つには、すでに充実したコラボレーションの歴史があります。すなわち、ChromeOS で Android アプリが利用できるようになっており、Bluetooth スタックの統合は ChromeOS 122 の時点で始まっています。

Android ベースの技術スタックを ChromeOS に導入することで、ChromeOS の中核である AI イノベーションのペースを上げ、エンジニアリング作業を簡略化し、スマートフォンやアクセサリなどのさまざまなデバイスと Chromebook との連携を強化できます。同時に、ChromeOS ユーザーや企業、学校に愛される比類のないセキュリティ、一貫したルック アンド フィール、幅広い管理機能を今後も提供し続けます。

このような技術スタックの改善は始まっていますが、一般消費者向けに準備が整うのは少し先になります。その際には、シームレスに更新版のエクスペリエンスに移行します。楽しみなことに、それまでの間も ChromeOS は進歩し続けます。定期的なソフトウェア アップデートや新しいイノベーションに変更はありません。

Chromebook は、世界中の何百万人ものお客様、ユーザー、デベロッパー、パートナーにすばらしい体験を提供し続けます。ChromeOS の未来をこれほど楽しみに思ったことはありません。

Reviewed by Eiji Kitamura - Developer Relations Team


使ってみるには

この変更はブラウザレベルで行われるので、Chrome のカスタムタブを使用するデベロッパーは、Chrome バージョン M124 以降に自動的に適用された変更を確認することができます。エンドユーザーから見ると、Chrome カスタムタブ ツールバーに最小化アイコンが表示されます。

これは Chrome で行われる変更ですが、ほかのブラウザにも同様の機能が採用されることを願っています。


Posted by Eiji Kitamura - Developer Relations Team

Share on Twitter Share on Facebook

私たちは、常にセキュリティとユーザビリティのバランスを取ることを最優先し、絶えず進化する脅威の状況を把握しながら、使いやすいプロダクトを構築するよう努めています。これを実現するために、Chrome と Google セーフ ブラウジングの連携方法にいくつかの変更を加え、スムーズで中断のないウェブ ブラウジングを最適化しつつ、オンラインの安全性を確保できるようにしました。



非同期チェック


現在のセーフ ブラウジング チェックは、Chrome のページ読み込みのブロッキング パスで行われています。つまり、ユーザーは、チェックが完了するまでページを見ることができません。これは、セーフ ブラウジング API v4 で行われるようなローカル ファーストのチェックでは問題ありませんが、セーフ ブラウジング サーバーで直接行われるチェックでは、遅延が発生する可能性があります。そこで、Chrome 122 より非同期メカニズムの導入を開始します。これにより、セーフ ブラウジング サーバーでリアルタイム チェックが進行中でも、サイトを読み込めるようになるので、ページ読み込み時間が短縮され、ユーザー エクスペリエンスが向上することが期待されます。リアルタイムのサーバー側チェックでページ読み込みがブロックされることはなくなりますが、ページ読み込み後にサイトが危険であることが判明すると、警告が表示されます。


この変更によって向上するのは、パフォーマンスだけではありません。時間の経過とともに保護の質も向上します。リモート検索がページ読み込みのブロッキング パスの外側で行われるようになったため、AI や ML ベースの新たなアルゴリズムを実験して展開することで、より多くのフィッシング攻撃やソーシャル エンジニアリング攻撃を検出してブロックできるようになります。これまでは、ページ読み込みが遅くなる可能性があったので、このような実験は困難でした。


潜在的なリスクに関しては、次の点を評価し、十分な緩和策が講じられていると判断しました。


  • フィッシング攻撃とソーシャル エンジニアリング攻撃 : 非同期チェックに移行すると、サーバー側のセーフ ブラウジング チェックが進行中に、そのようなサイトの読み込みが開始される可能性があります。タイミングに関するデータを精査した結果、警告が表示される前にユーザーがそのようなサイトと重要なやり取りを行う（パスワード入力など）可能性は、極めて低いものと判断しました。

  • ブラウザに対するエクスプロイト : Chrome では、ブラウザのエクスプロイトを提供していることがわかっている一部のサイトを、ローカルのセーフ ブラウジング リストとして保持しており、これを同期的に確認する処理は今後も継続されます。また、オンラインの保護を維持するために、アップデートが利用可能になったらすぐに Chrome をアップデートすることを常にお勧めしています。



サブリソースのチェック


私たちが閲覧するほとんどのサイトには、さまざまなサブリソースが含まれており、それを使ってコンテンツがレンダリングされています。こういったサブリソースには、画像やスクリプトなどがあります。これまで、Chrome では、セーフ ブラウジングでトップレベルの URL とサブリソースの両方を確認し、害を及ぼす可能性があるサイトについて警告してきました。サブリソースの大部分は安全ですが、かつては、悪意のあるアクターによってサイトが不正使用され、大規模にマルウェアを配布したり、ブラウザを悪用したりするサブリソースが埋め込まれることもよくありました。


近年、攻撃者のそのような傾向は減少しています。サブリソースを悪用する大規模攻撃はもはや一般的ではなく、サブリソースのチェックはそれほど重要でなくなっています。さらに、インテリジェンス収集、脅威検出、セーフ ブラウジング API の進化により、サブリソース チェックを行わずに、他の方法でユーザーをリアルタイム保護することもできるようになっています。たとえば、Chrome のクライアント側ビジュアル ML モデルは、サブリソースの有無に関係なく、フィッシング ページの作成に使われる画像を特定できます。


以上を踏まえて、今後、Chrome はセーフ ブラウジングでサブリソースの URL を確認しなくなります。これにより、Chrome クライアントが Google に接続する頻度が減るので、ユーザーにとって不要なネットワーク帯域幅のコストが削減されます。セーフ ブラウジング側では、この変更によって検出ロジックと API を大幅に簡素化できるため、インフラストラクチャの信頼性と警告精度が向上し、全体的なリスクが軽減されます。



PDF ダウンロード チェック


最後に、Chrome が PDF ダウンロードを確認するためにセーフ ブラウジングにアクセスする頻度を大幅に減らしました。


かつて、PDF は人気が高く、広く使われていたファイル形式でした。時間とともに PDF ビューアが継続的に強化された（Chrome の PDF ビューアのサンドボックス化など）こともあり、PDF が広く悪用されるケースはなくなり、業界から危険なファイル形式であると報告されることもなくなっています。悪意のある PDF を閲覧してしまった場合でも、そこにはユーザーを Chrome にリダイレクトするリンクが含まれているため、ユーザーを保護する機会がもう一度得られます。


この変更の結果、Chrome のセーフ ブラウジングへのアクセス回数が毎週数十億回減少しています。



今後に向けて


以上の変更は、主に内部処理の変更です。これによって Chrome ユーザーのウェブ ブラウジング エクスペリエンスは快適になるはずですが、セキュリティが低下することはありません。私たちは、今後も脅威の状況をモニタリングし、オンラインの安全性を確保するための態勢を維持していきます。
Posted by Eiji Kitamura - Developer Relations Team
Share on Twitter Share on Facebook

Share on Twitter Share on Facebook

Chromium の問題追跡システムの移行が完了したことをお知らせします！Issue Tracker とサポート ドキュメントにはこちらからアクセスできます。


移行を実施した理由

問題追跡システムを Monorail から Chromium Issue Tracker（Google Issue Tracker を利用しています）に移行することで、Chromium エコシステムに豊富な機能と充実したサポートを備えた問題トラッカーを導入しました。Chromium は、このツールに関連する他のオープンソース プロジェクト（Git、Gerrit）に参加します。

今後の流れ

既存の Monorail への問題のリンクは、移行された新しい問題トラッカーの問題にリダイレクトされます。今後も、フィードバックを重視して問題トラッカーのエクスペリエンスを改善していく予定です。

ヘルプとフィードバック

質問や懸念事項などがありましたら、いつでも [email protected] までお問い合わせください。


Posted by Eiji Kitamura - Developer Relations Team

Share on Twitter Share on Facebook

Share on Twitter Share on Facebook

Chrome はすべてのプラットフォームで優れた機能を発揮するように設計されているので、自宅から PC でウェブをブラウジングするときも、外出先からスマートフォンでブラウジングするときも簡単に使えるようになっています。例えば、Chrome sync のようなツールによって、すべてのデバイスを切り替えてもブックマークやパスワードにアクセスできるようになりました。

今後数週間で iOS 版 Chrome に変更を加え、特に重要な情報をすぐ利用できるようにします。デバイスで Chrome 同期を設定する必要がなくなり、Chrome にログインするだけで、新しい情報を Google アカウントに保存したり、既存の情報にアクセスしたりできるようになります。iOS ですでに動作している Google アプリの数が多いため、これに慣れ親しんでいるように感じるかもしれません。Chrome にサインインすると、ブックマーク、リーディングリスト、パスワード、支払い情報、住所、設定など、重要な情報をアカウントに保存できます。また、タブと閲覧履歴を iOS の Chrome から Google アカウントに別々に同期させることもできます。これにより、別のデバイスで中断した閲覧を再開できます。




以上のアップデートは、データ管理にも役立つように設計されています。Chrome にログインすると、すでにデバイスに保存されている閲覧データは、デバイスのローカルデータとして別に保管されます。ローカルデータとアカウント データは、設定で簡単に区別できます。また、他のデバイスでローカルデータを利用できるようにしたい場合は、設定に移動してアカウントに保存することもできます。

iOS での Chrome へのログインは、今後とも完全に任意です。ログインしなくても、ブックマークやパスワードなどは保存できますが、保存したデバイスでのみ利用できます。また今後も、Chrome にログインしないまま、Gmail などの Google のウェブサービスにログインすることができます。

これらの変更により、求められるあらゆる柔軟性を提供するとともに、さらに簡単に Chrome を活用できるようになることを期待しています。


Posted by Eiji Kitamura - Developer Relations Team
Share on Twitter Share on Facebook

Google のチームは、ウェブを量子耐性暗号に移行する準備を整えることに注力しています。この大きな変革に対応するための戦略を継続しながら、技術標準を更新し、新しい量子耐性アルゴリズムをテストおよび展開しているほか、この取り組みを成功させるために幅広いエコシステムと連携しています。

この移行に向けた第一歩として、Chrome 116 から TLS での対称シークレットの確立に X25519Kyber768 がサポートされるようになり、Chrome 115 ではフラグを設定することで利用できるようになります。このハイブリッド メカニズムは、2 つの暗号アルゴリズムの出力を組み合わせて、TLS 接続の大部分を暗号化するために使用されるセッション鍵を生成します。

Google は、この変更に伴うエコシステムの非互換性を洗い出すために、このアルゴリズムを TCP と QUIC の両方で Chrome と Google サーバーに展開し、潜在的な互換性の問題をモニタリングしています。Cloudflare などのサードパーティ サーバー オペレーターがこのセッション鍵のサポートを追加した場合、Chrome は、当該サードパーティ サーバーに接続する際に、この更新された鍵合意を使用することもあります。この変更によって引き起こされたと思われる問題に遭遇したデベロッパーまたは管理者の方は、バグについてご報告ください。ここからは、この変更とその理由を理解するのに役立つ重要な背景情報について記載します。

ポスト量子暗号化へと向かう理由

TLS などの最新のネットワーク プロトコルは、情報の保護（機密性）やウェブサイトの ID 検証（認証）など、さまざまな目的で暗号を使用します。この暗号の強さは、攻撃者がこうした特性の 1 つ以上を侵害するのがどれほど難しいかという観点から評価されます。暗号化の分野では、攻撃はより強力になることはあっても弱くなることは決してない、とよく言われます。これは、攻撃が進化し、時間が経つほど手ごわくなるため、より強力なアルゴリズムへの移行が重要になることを強調しています。

そのような進化の一例として、既存のコンピューティング方式では不可能な特定の計算を効率的に実行できる量子コンピュータの開発が挙げられます。現在使用されている多くのタイプの非対称暗号化は、既存の技術を使用した攻撃に対して強いと考えられていますが、十分な能力の量子コンピュータを使用する攻撃者には対抗できません。

量子耐性のある暗号は、量子暗号解読技術と古典的暗号解読技術の両方に対しても安全でなければなりません。これは理論上の話ではありません。2022 年と 2023 年には、量子耐性暗号アルゴリズムの主要な候補のいくつかが、市販されている安価なハードウェア上で破られました。X25519Kyber768 などのハイブリッド メカニズムは、接続が既存の安全なアルゴリズムによって保護されることを保証しながら、新しい量子耐性アルゴリズムを展開およびテストする柔軟性を提供する必要があります。

こうした要求事項に加えて、このアルゴリズムは、市販のハードウェアでもパフォーマンスを発揮する必要があるため、問題がさらに複雑になります。


なぜ転送中のデータを保護することが、今重要なのか

現代の古典的な暗号を破ることができる量子コンピュータは、今から 5 年、10 年、おそらく 50 年後にも登場しないと考えられています。それでは、なぜ今、トラフィックの保護を始めることが重要なのでしょうか？その答えは、特定の用途の暗号は、今収集して後で解読（Harvest Now, Decrypt Later）と呼ばれる攻撃に対して脆弱だからです。この攻撃では、データは即座に収集されて保存されますが、解読は、暗号解読技術が改良された後で行われます。

TLS では、転送中のデータを保護する対称暗号化アルゴリズムは量子暗号解読に対して安全であると考えられていますが、対称鍵の生成方法はそうではありません。つまり、Chrome では、量子耐性のあるセッション鍵を使用するために TLS を更新するのが早ければ早いほど、将来の量子暗号解読からユーザー ネットワーク トラフィックをより早く保護することができます。

展開に関する考慮事項

X25519Kyber768 を使用すると、Kyber によりカプセル化された鍵素材が追加されるため、TLS ClientHello メッセージに 1 キロバイト以上の追加データが生じます。Google が以前行った、CECPQ 2 を用いた実験では、TLS 実装の大部分がこのサイズの増加に対応できることが実証されましたが、一部の特定のケースでは、メッセージ サイズに対する不適切なハードコード制限のために TLS ミドルボックスで動作不良が起きました。

これらの新しいアルゴリズムが展開される際に、ネットワーク アプライアンスの非互換性に対処しなければならない企業を支援するために、Chrome の管理者は Chrome 116 から利用可能な PostQuantumKeyAgreementEnabled エンタープライズ ポリシーを使用して、X25519Kyber768 を無効にすることができます。このポリシーは一時的な措置としてのみ提供されます。管理者は、影響を受けるプロダクトのベンダーと協力して、非互換性を引き起こすバグをできるだけ早く修正するよう強くお勧めします。

最終的なデプロイのための考慮事項として、X25519Kyber768 と Kyber の仕様はどちらもドラフト段階のものであり、最終的な決定の前に変更される可能性があり、Chrome の実装も変更される可能性があることに注意してください。


Posted by Eiji Kitamura - Developer Relations Team
Share on Twitter Share on Facebook




一歩下がってすでにある機能に手を加えることで、パフォーマンスを大きく向上させることができる場合があります。今回の 速さと好奇心の投稿では、どのように Android 版 Chrome のスクロール操作を改善し、遅いスクロールによるジャンクを最終的に半分に減らすことができたかについて説明します。どのように問題を発見して評価したか、そしてそれがどのように今後のブラウザ エクスペリエンス設計の向上に役立ったかについて、お読みください。


ブラウザのパフォーマンスを測定するときは、ページ読み込み速度やウェブに関する指標を考えるのが一般的です。折りたたみ式などの新しいフォーム ファクタを含め、タッチ操作が一般的なモバイルでは、常にスムーズで応答性が高くなるようにするため、Chrome とのインタラクションも重視しています。特に最近力を入れているのが、スクロール時のジャンクを減らすことです。


先日は、ノイズをフィルタリングして、画面に表示されるコンテンツが瞬間的に移動するように見える現象を減らすことで、Android 版 Chrome のスクロール操作の指標を 2 倍に向上しました。この結果を得るためには、一歩下がって、Android 版 Chrome が iOS 版 Chrome に遅れをとっている理由を理解する必要がありました。 


プラットフォーム間で Chrome を比較したところ、あることがわかりました。iOS 版 Chrome のスクロールは一貫してスムーズでしたが、Android 版の Chrome のスクロールは、そこまで指に追従する感じではありませんでした。しかし、指標を確認したところ、ジャンクは時々起こるものの、iOS 版 Chrome と比較したときに感じたほど頻繁に発生するものではありませんでした。つまり、調査が求められる謎の現象が発生したということです。


入出力レートの調査

この指標が示していたのは、入力を受け取るレートが一貫していない場合が多いということです。しかし、入力レートはディスプレイのフレームレートよりも大きいため、通常は少なくとも 1 つの入力イベントで、表示するフレームの生成がトリガーされていました。ただし、このフレームが受け取る入力イベントが少なかったり多かったりすると、たとえ一定の速度でスクロールしていたとしても、画面のコンテンツが一貫性のない形で移動してしまう場合があります。


入力レートとフレームレートが異なるというこの問題は、以前に Chrome で対処しなければならなかった問題です。内部的には、入力を再サンプリングして、生成するフレームに対して相対的な一貫したポイントにおいて指があった場所を予測および推定しています。そのため、各フレームが一定の時間を表すようになり、スクロールは入力イベントのノイズに関係なくスムーズになるはずです。理想的なシナリオを次の図に示します。青い点は実際の入力イベント、緑は再サンプリング後の入力イベントです。再サンプリングしたものではなく、実際の入力イベントを使った場合、画面がスクロールする差分量は変動します。





すでに再サンプリングを行っているのに、問題が発生するのはなぜでしょうか？


苦難と再実装のストーリー

Chrome（と Android）に入力の再サンプリングが追加されたのは、90 Hz デバイスが登場し、上記の問題が目立ち始めた 2019 年です（フレームあたりの入力イベントが 2 つと 1 つで振動します。60 Hz デバイスでは、フレームあたり常に 2 つの入力イベントが一般的です）。Android には複数の再サンプリング アルゴリズム（カルマン、線形など）が実装されていますが、今回のユースケースには、線形再サンプリング（2 点間を線で結んで速度を計算し、指定されたタイムスタンプを補完する）で十分であるという結論に達しました。これにより、ほとんどの Android アプリの問題は修正されましたが、Chrome の問題には対処できませんでした。


これまでの経緯や未加工の入力に対するウェブ仕様の要件の関係で、Chrome ではバッファリングされていない入力が使われています。そのため、入力に適合しないサンプリング レートのデバイスが登場し始めたときに、Chrome になんらかのバージョンの再サンプリングを実装する必要が生じました。下の図から、各フレーム（入力から表示までの時間を測定したもの）が受け取る入力イベントの数は異なることがわかります（最初のフレームは 2 つ、2 番目のフレームは 3 つ、3 番目のフレームは 1 つ）。入力が一貫して到着し、それぞれが正確に 30 ピクセルの変位であれば、次に示すように、1 フレームあたり 60 ピクセルに平滑化するのが理想です。





しかし、もともとの謎を調査している間にわかったのは、現実は上の理想的な状況とは大きく異なることでした。実際の画面の入力の動きは急激で（予想以上に）一貫性がなく、予測によって多少は改善されているものの、期待したほどではありませんでした。左は画面上の実際の指の変位（各点は入力イベント）、右は平滑化後の実際のコンテンツのオフセットの予測結果（各点はフレーム）です。





右側ではフレームは一貫して表示されていますが、互いの変位スパイクのレートは一貫していません（最も激しいのは、-50、-40、-52 の部分です）。人間の指は、（フレームレベルの精度で）このような不連続な動きにはなりません。むしろ、徐々に加速したり減速したりしながら、少しずつ移動したり方向を変えたりします。そのため、ここに問題があると考えました。Chrome の実装を詳しく調べたところ、そこに根本的な違いがあることがわかりました（Android の実装をコピーしたものだと思われます）。


1. Android ではネイティブの C++ MotionEvent タイムスタンプ（ナノ秒精度）が使われていますが、Chrome では Java の MotionEvent.getEventTime と MotionEvent.getHistoricalEventTime（ミリ秒精度）が使われています。残念ながら、ナノ秒精度の機能は、パブリック API には含まれていませんでした。しかし、ミリ秒に丸めてしまうと、イベントのタイムスタンプ間の速度を計算するときにうまく予測ができなくなる可能性があります。 

2. Android の実装では、2 つの入力イベントを慎重に選択しています。そのため、再サンプリングには最も関連性の高いイベントが使われています。一方の Chrome は、入力イベントの単純な FIFO キューを使っています。そのため、高リフレッシュレート デバイスでは、まれに未来のイベントを使用して過去の速度を予測するという奇妙なケースが発生する可能性があります。


Android の再サンプリングを使って Chrome のプロトタイプを作成しましたが、それはまだ Chrome のアーキテクチャとして完璧ではなく、ジャンクが起きることがわかりました。これを改善するため、自動化を活用して同じ入力を何度も繰り返し再生し、画面の変位曲線を評価するさまざまなアルゴリズムを実験しました。チューニングの結果、1€ フィルタの実装が最適であることがわかり、スクロール操作が目に見える形で大幅に改善しました。このフィルタを使うことで、画面が指を細かくトラッキングできるようになり、ウェブサイトのスクロールがスムーズになって、一貫性のない入力イベントによるジャンクを防止できるようになりました。手動で検証しても、トップエンド デバイスとローエンド デバイスの両方で、この改善の成果を明確に確認できます（redmi 9A の動画サンプルはこちら）。


今後に向けて

Android 14 では、SDK で Java の MotionEvents 用のナノ秒 API が公開されるため、Chrome（や入力をバッファリングしていない他のアプリ）から呼び出せるようになります。スクロール予測フレームの品質を追跡する新しい指標も作成しました。これは、ピクセルレベルのフレームの違い（その他の形態のジャンクは含めていません）を作り出すテストアプリを作成し、気づいたことを確認する実験をもとにしています。この分析の詳細は、こちらから確認できます。今後、さらに効果的なパフォーマンスの改善や、目に見える形でのリグレッションの追跡に活用する予定です。最終的にチューニングをし 1€ フィルタを有効にした結果、ゆっくりスクロールしているときの目に見えるジャンクは、指標上半分に減少しました。この改善はデフォルトとして M116 で公開されますが、M110 までさかのぼってリリースされます。これにより、Android 版 Chrome が iOS 版 Chrome と同等になります。


このストーリーから、次の教訓を得ることになりました。指標はすべてのケースをカバーしていない場合があります。一歩下がって徹底的に調査して状況を理解することで、ユーザーにとって優れたスクロール操作を実現できます。



Posted by Eiji Kitamura - Developer Relations Team
Share on Twitter Share on Facebook

ブログ投稿のメインイメージ。アドレスバーの右側にある Chrome の新しいダウンロード エクスペリエンスを紹介しています。


デスクトップ版 Chrome の最新リリースで、Chrome のダウンロード エクスペリエンスを刷新し、最近のダウンロードに対する操作をさらに簡単に行えるようにしました。Chrome シニア プロダクト マネージャーの Jasika Bawa から、今回の刷新の舞台裏について詳しい話を聞いてみましょう。

Chrome のダウンロードを刷新するという判断をしたのはなぜですか？

ダウンロードは日々のウェブ ブラウジングに欠かせない操作です。猫をテーマにした完璧な背景をパソコン用に入手することから、納税申告書のコピーを保存することまで、その用途はさまざまです。私たちは、Chrome の以前のダウンロード エクスペリエンスについてのフィードバックを長年にわたって受け取ってきました。中核的なダウンロード操作のサポートや潜在的に有害なファイルに対する組み込みの保護など、優れた機能がたくさんあることはわかっていますが、問題点もありました。たとえば、次のようなことです。

  • 画面下部の貴重なピクセルを占有するため、ウェブ コンテンツ領域が狭くなり、画面の幅によって一度に表示できるファイルの数が制限されていた
  • 自動で消えることがなく、固定のオーバーフロー メニューで提供されていたアクションは、一時停止や再開、フォルダを開くなどだけだった
  • モダンでインタラクティブなものでなく、他のブラウザの UI やブラウザのエコシステム全体の外観との整合性がなくなっていた

こういったすべての点について考えれば、ダウンロード エクスペリエンスをさらに直感的なものにするために、Chrome を改善する余地があったのは明らかでした。

今回の刷新によって提供すべきものは何ですか？

画面下部にあった以前のダウンロード エクスペリエンスに代わり、Chrome のアドレスバーの右側に新しいダウンロード トレイが表示されます。ダウンロードが進行中の場合、アニメーションするリングから一目で進行状況を確認できます。ファイルのダウンロードが終わると、トレイが開き、自動的に非表示になります。そのため、すばやく簡単にアクセスできるだけでなく、閲覧が中断することもありません。

Chrome ブラウザの GIF イメージ。カーソルが、ウェブファイルの「保存」オプションをクリックしています。ダウンロードが進行中であることを示すアイコンがあり、その周りに進行状況を表すリングが表示されます。ファイルのダウンロードが終わると、ダウンロード トレイが自動的に開きます。


ダウンロード トレイでは、過去 24 時間のすべてのダウンロードのリストを確認できます。このトレイは、ダウンロードを始めたブラウザ ウィンドウだけでなく、すべてのウィンドウから確認できます。トレイにはインライン オプションも用意されており、ダウンロードしたフォルダを開く、ダウンロードをキャンセルする、なんらかの理由で失敗したダウンロードを再試行する、ダウンロードの一時停止や再開を行うといった操作が可能です。


Chrome ブラウザの GIF イメージ。カーソルが、Chrome アドレスバーの右側にあるダウンロード トレイを開いています。ダウンロード トレイには、進行中のファイルのダウンロードが表示されています。ダウンロードを一時停止するインライン オプションも提供されています。カーソルが一時停止ボタンをクリックすると、ボタンが再生ボタンに変わります。カーソルが再生ボタンをクリックすると、ダウンロードが再開されます。


新しいダウンロード エクスペリエンスは、オンラインで人々の安全を保つことにどう貢献しますか？

私たちがいつも重視しているのは、ファイルをダウンロードする際の安全性です。マルウェアやウィルスの可能性がある場合、Chrome は今後も明確な警告を表示し続け、デバイスやアカウントを守ります。実際に、Chrome の新しいダウンロード エクスペリエンスでは、スペースが広くなり、UI も柔軟になっているので、悪意のある可能性のあるファイルからユーザーを保護するために提供できる情報が増え、高度なディープ スキャン オプションも実現できるようになっています。これは、以前にはできなかったことです。詳しくは、近日公開予定の Google セキュリティ ブログをご覧ください。

ダウンロードの警告だけではありません。ダウンロード トレイは、Chrome のアドレスバーの横の決まった位置に表示されるので、信頼できるブラウザの UI とウェブ コンテンツを明確に分離するうえで役立ちます。これは、今回の刷新でどうしても実現したかった点でした。


ダウンロード トレイを拡大した Chrome ブラウザのイメージ アセット。危険なファイルのダウンロードがブロックされたことを示す通知が表示されています。


新しいダウンロード エクスペリエンスに簡単に移行できるようにする方法として、どのようなことを考えましたか？

重要なことは、Chrome の新しいダウンロード エクスペリエンスで、以前の機能をすべて利用できるようにすることでした。 たとえば、今後も新しいダウンロード トレイから、ダウンロードしたファイルを別のフォルダやプログラム、ウェブサイトにドラッグしたり、「常に開く」などのアクションを行ったりできます。ダウンロードのさらに詳しい表示も、引き続き可能になっています。ダウンロード トレイの [ すべてのダウンロードを表示 ] オプションを選択するか、Chrome のその他メニューから [ ダウンロード ] をクリックするか、Chrome のアドレスバーに chrome://downloads と入力します。

また、初期の試験運用でのフィードバックを真摯に受け止め、ダウンロード トレイを開く頻度を調整するなどの変更を加えています。Chrome の設定から、自動でトレイを開かないようにすることもできます。


Chrome ブラウザの [ダウンロード] 設定メニューのイメージ。ダウンロードが完了したときに、ダウンロードの表示を無効にするオプションを選択できます。



デベロッパーの対応が必要になることはありますか？

デベロッパーの皆さんにぜひお願いしたいのは、ユーザーのダウンロード操作をサポートするためにガイドやビジュアルを作成している場合、それを更新することです。まずは、Google Chrome ヘルプセンターのトピック、ファイルをダウンロードするを参照することを検討できるでしょう。

拡張機能デベロッパーの皆さんは、chrome.downloads 拡張機能 API の変更に注意してください。拡張機能の更新が必要になるかもしれません。具体的には、setShelfEnabled が setUiOptions に置き換えられ、新しいダウンロード エクスペリエンスの表示、非表示を切り替えられるようになっています。

公開されたばかりの新機能ですが、ぜひ使ってみてください！今後のリリースでは、ウェブからファイルをダウンロードする際の安全性を保ちながら、Chrome の生産性を維持できるように、引き続きこの機能を強化していきます。
Posted by Eiji Kitamura - Developer Relations Team
Share on Twitter Share on Facebook

速さと好奇心シリーズのヒーロー イメージ


Chrome が誕生したときから、ベンチマークは、ユーザーのメリットになるパフォーマンス最適化を促進する重要な手段でした。現在、最も重要なウェブ ベンチマークは、Speedometer、MotionMark、Jetstream です。この 1 年を通じて、Chrome はこれらのベンチマークに対して最適化することに取り組み、3 つすべてで最高スコアを達成しました。こうした成果は、大規模なプロジェクトと細かな改善の組み合わせによって達成されました。今日の速さと好奇心の投稿では、Chrome でこうした改善を促進した方法のほんの一部をご紹介します。

まったく新しい中間層コンパイラの発表 : Maglev

Chrome 用の新しい中間層コンパイラをご用意しました。Maglev は、最初の 100 分の 1 秒以内に、関連するすべての関数向けにパフォーマンスの高いマシンコードを迅速に生成できる実行時コンパイラです。電池寿命を節約しながら、コードをコンパイルするための総 CPU 時間を短縮します。Google の測定値では、Maglev が Jetstream で 7.5%、Speedometer で 5% の改善をもたらしたことが示されました。Maglev は、6 月 5 日からリリースされる Chrome バージョン 114 でロールアウトを開始します。

Speedometer

Speedometer は、さまざまな JavaScript UI フレームワークをテストすることで、ウェブサイトの応答性を測定します。ちょうど 1 年前に、Chrome バージョン 40 からバージョン 101 にかけてスコアを 100 から 300 に向上させた方法の詳細をご紹介しました。その後、13 回の Chrome リリースを経て、Speedometer で最新の最高スコア 491 を達成しました。V8 チームは、Maglev に加えて、最適化した関数呼び出しなどの細かな調整と、複数四半期にわたる大規模なプロジェクトの両方によって、このスコアを実現しました。

速度計のビジュアルは、Speedometer ブラウザ ベンチマークのスコア 491 を示しています。これは、ウェブサイトの応答性を測定したものです。これは、Chrome の昨年のスコア 330 より向上しています。
Maglev が有効になっている M2 Macbook Air で実行中の Chrome 116.0.5803.2


MotionMark


MotionMark は、ブラウザのグラフィック システムが高いフレームレートでどれだけレンダリングできるかをテストするように設計されています。Chrome のグラフィックとレンダリングのチームは、年初より 20 を超える最適化を追跡しており、その半数以上が現在利用できます。こうした最適化の組み合わせにより、パフォーマンスが 3 倍近く向上しました。主な改善点は、Canvas のパフォーマンス、プロファイルに基づいた最適化、GPU タスクのスケジューリング、レイヤの合成などです。また、動的マルチサンプル アンチエイリアス用の斬新なアルゴリズムや、並列化の改善のためのプロセス外 2D キャンバス ラスタライゼーションも作成しました。


速度計のビジュアルは、MotionMark ブラウザ ベンチマークのスコア 4821.30 を示しています。これは、ブラウザのグラフィック システムをテストしたものです。これは、Chrome の昨年のスコアより 3 倍近く向上しています。
13 インチの M2 Macbook Pro で実行中の Chrome M115.0.5773.4


Jetstream

JetStream は、高度なウェブ アプリケーションに特化した JavaScript および WebAssembly ベンチマーク スイートです。Speedometer 向けに多数のアップデートを加えたことにより、V8 エンジンを最適化して、Jetstream のスコアも大幅に向上させることができました。これらの機能強化に加えて、Maglev はこのベンチマークで最大の成果を発揮しました。


スピードメーターのビジュアルは、Jetstream2 ブラウザ ベンチマークのスコア 330.939 を示しています。このベンチマークは、高度なウェブ アプリケーションに特化したものです。この改善には、Chrome の新しい実行時コンパイラである Maglev が多大に貢献してします。
Maglev が有効になっている M2 Macbook Air で実行中の Chrome 116.0.5803.2


今後の予定

私たちは、これらのベンチマークに対して最適化を行っているため、これらの改善をユーザーの実際のメリットに変える必要があります。そのため、他のブラウザと連携しながら次世代のベンチマークの作成に取り組んでいます。これは継続中のコラボレーションであり、今後の 1 年間は、この新しい目標に向かって努力していきたいと考えています。

より高速になった Chrome を皆さん全員に楽しんでいただけることを願っています！


Posted by Eiji Kitamura - Developer Relations Team
Share on Twitter Share on Facebook

最近の監査により、Google 専用の機能として想定されていた Chrome の同期や Click to Call などの Google 機能が、一部のサードパーティ製の Chromium ベースのブラウザに組み込める状態だったことがわかりました。これは、ごく一部のユーザーが Google アカウントにログインし、ブックマークなどの個人の Chrome 同期データを、Google Chrome だけでなく、一部のサードパーティ製の Chromium ベースのブラウザに保存できていたことを意味します。この対策として、2021 年 3 月 15 日より、プライベートな Chrome API へのアクセスを制限します。


サードパーティ製の Chromium ベースのブラウザから Google 機能（Chrome 同期など）にアクセスしていたユーザーのデータは、Google アカウントで引き続き利用でき、ローカルに保存したデータは引き続きローカルで利用できます。ユーザーは、My Google Activity ページで通常どおりにデータの表示や管理ができます。また、Google Takeout ページからデータをダウンロードしたり、こちらからデータを削除したりできます。 

サードパーティ製の Chromium ベースの製品ベンダー向けのガイドは、Chromium Wiki で公開しています。

Reviewed by Eiji Kitamura - Developer Relations Team
Share on Twitter Share on Facebook



先週、私のカレンダーは、多くの皆さんが Google I/O に集まってくるだろうというアラートを常に表示していました。それを見ると、今は直接集まることはできないという悲しい気持ちになります。この厳しい時期、ウェブ デベロッパーの皆さんは、必要なことに集中する、重要な情報を利用できるようにする、オンラインでの取引を可能にする、在宅での仕事や教育を可能にするといったことに貢献しています。ウェブ デベロッパーが果たしている役割にはとても感銘を受けます。皆さんに称賛を送ります。

私たちも、そのお手伝いをしたいと考えています。

そこで、3 日間のデジタル イベント web.dev LIVE を計画しています。ウェブ デベロッパーの皆さんが自宅から気軽に参加して、プラットフォームの最新アップデートについて話を聞いたり、最新のウェブ技術を学んだり、他のデベロッパーと交流したりできるイベントです。COVID 関連の作業の最前線に立ってコミュニティを前進させているデベロッパーも集まります。

このイベントは、6 月 30 日から 7 月 2 日にかけて行われ、web.dev/live から 3 時間の短いコンテンツ（英語）がストリーミングされます。

皆さんのタイムゾーンに合わせてお届け

デジタルのみのイベントを計画するのは、おもしろい挑戦です。物理的に集まることはできなくても、皆さんのソファやキッチン、裏庭のハンモックなどにすばらしいコンテンツを直接お届けできます。デジタル イベントは、物理的な制約を超えるチャンスでもあります。会場の広さという制限はなくなり、ボタンをクリックするだけで、文字通り世界中の誰もが「参加」できます。（私たちは、ウェブ コミュニティの一員として、これを実現できたことを日々誇りに思っています！）

実際にすべての地域を対象にしたイベントになるように、私たちは 3 つのタイムゾーンに「出張」します。そのため、皆さんが活動している時間帯にリアルタイムで質問にお答えすることができます。毎日その日だけのコンテンツがあるので、3 日間すべてに参加することもできます。後ほどオンデマンドでご覧いただくこともできますが、どのタイムゾーンのデベロッパーも、少なくとも 1 回は直接質問に回答してもらえる機会があります。

ライブイベントの開催時間

このイベントを、Google カレンダーに設定するリンクはこちらです。（英語でインビテーションが届きます）

たくさんのすばらしいコンテンツやお楽しみを準備していますので、イベント関連のお知らせを受け取れるように、ぜひ web.dev/live でサインアップしてください。


Posted by Eiji Kitamura - Developer Relations Team

Share on Twitter Share on Facebook

私たちは今後数か月で、TurboFan をより多くの JavaScript で使用できるようにし、最終的には既存の CrankShaft コンパイラーから完全に移行することを目標としています。TurboFan が展開されると、デベロッパーのコードが自動的に高速化されます。コストはかからず、変更の必要もありません。今後の進捗にご期待ください。

Posted by Eiji Kitamura - Developer Relations Team
Share on Twitter Share on Facebook

Chrome 41 から、「Blink」レンダリング エンジンに統合するタスク スケジューラを作成しました。スケジューラは処理待ちのタスクを検証し、ユーザー アクションに対するアニメーションや応答などの優先度の高いタスクを先に表示する機能を備えます。使用されていないメモリの解放など優先度の低いタスクは、プロセッサに余裕ができるまで処理を遅らせられます。実際これによって、Chrome でフレームの描画を集中的に処理している際のユーザー入力への応答が 40% 早まるという結果が生じています。
ただし、どんなに高度なスケジューラでも、その後に何が発生するか不明なものについては、適切に優先順位を付けることはできません。この問題に対処するため、「Blink」スケジューラは Chrome のグラフィック エンジンにも統合されます。このエンジンではグラフィックを画面に描画するため、Chrome で他のタスクの優先順位を下げる必要があるタイミングを正確に認識します。これによってスケジューラは、Chrome で次のフレームを描画する必要が生じる前の「アイドル」タイムを有効に活用して、優先度の低いタスクを処理できるようになります。優先度の低いタスクは原則的に、毎秒 60 フレームのアニメーションに何の影響も与えずに処理されます。
最新の Chrome で負荷の高いウェブサイトをスクロールした様子。
スケジューラが有効（左）、無効（右）。
この変更で示しているのは、パフォーマンスとは単に物事を早く行うことだけでなく、よりスマートに、適切な順序で、適切なタイミングで行う、ということを意味するということです。Chrome のスケジューラを使ってさらにパフォーマンスを向上させる試みについて、今後もご期待ください。

Posted by Eiji Kitamura - Developer Relations Team
Share on Twitter Share on Facebook

QUIC ではさらに、輻輳制御と切断回復機能の向上という多大な利点があります。パケットの再送信時に、パケット シーケンス番号が再利用されることはありません。これによって不明瞭なパケット受信が発生せず、再通信タイムアウトを回避できます。結果として、接続状況が良好でない状況において QUIC は TCP よりも優れた接続を行うことができます。最も遅い 1% の接続状況においても、Google 検索ページの読み込みを大幅に削減できます。 こうしたメリットは、Youtube などの動画サービスではより顕著になります。QUIC 接続での動画視聴の際に、再バッファ時間が 30% 削減されるという報告もなされており、視聴時間が短縮されることで、繰り返し、より多くの動画を視聴できるようになっています。

現在、Chrome から Google サーバーへのおよそ半数のリクエストが QUIC で行われており、今後も QUIC のトラフィックを増やしていく方針です。最終的には QUIC を、Chrome とモバイルアプリの双方で、Google のクライアントから Google のサーバーへの通信規格のデフォルトにする予定です。インターネット標準として IETF に QUIC を正式に提案する予定ですが、その前にワイヤーフォーマットを変更したり、リファレンス実装を SPDY - QUIC から HTTP2 - QUIC に更新したりするなど、いくつかの解決すべき点があります。今後数か月で、応答確認時のオーバーヘッドを低減しサーバー側での拡張性を高め、前方誤り訂正や輻輳制御の向上、マルチパス接続のサポートの追加などに取り組む予定です。

状況を確認したり実際に試すには、コードやこちらのページをご確認ください。また、[email protected]にもご参加ください。一歩ずつ、インターネットを改良し続けます。

Posted by Eiji Kitamura - Developer Relations Team
Share on Twitter Share on Facebook