Chrome の検索、ブラウズ、シャットダウン時のパフォーマンスを改善

この記事は 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 96: 条件に応じたフォーカスや優先度ヒントなどの新機能

この記事は Chromium Blog の記事 “Chrome 96 Beta: Conditional Focus, Priority Hints, and More” を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


特に記載のない限り、下記の変更は Android、Chrome OS、Linux、macOS、Windows 向けの最新の Chrome ベータ版チャンネル リリースに適用されます。ここに記載されている機能の詳細については、リンクまたは ChromeStatus.com の一覧でご確認ください。2021 年 10 月 21 日の時点で Chrome 96 はベータ版です。

3 桁のバージョン番号に対する準備

来年には、Chrome でバージョン 100 がリリースされます。つまり、Chrome のユーザー エージェント文字列で報告されるバージョン番号の桁が増えます。サイトオーナーが新しい文字列をテストしやすくするために、Chrome 96 では、Chrome のユーザー エージェント文字列として「100」が返されるようにするランタイム フラグが導入されています。chrome://flags/#force-major-version-to-100 と呼ばれるこの新しいフラグは、Chrome 96 以降で利用できます。

オリジン トライアル

このバージョンの Chrome には、以下のオリジン トライアルが導入されています。オリジン トライアルとして新機能を試せるようにすることで、ウェブ標準コミュニティにユーザビリティ、実用性、有効性についてのフィードバックを提供することができます。以下の項目を含め、現在 Chrome でサポートされているオリジン トライアルに登録するには、Chrome オリジン トライアル ダッシュボードをご覧ください。Chrome のオリジン トライアルの詳細については、ウェブ デベロッパーのためのオリジン トライアル ガイドをご覧ください。Microsoft Edge は、Chrome とは別に独自のオリジン トライアルを行っています。詳細については、Microsoft Edge オリジン トライアル デベロッパー コンソールをご覧ください。

新しいオリジン トライアル

Conditional Focus

現在、他のウィンドウやタブをキャプチャするアプリケーションには、呼び出し元のアイテムやキャプチャするアイテムにフォーカスするかどうかをコントロールする方法がありません（ビデオ会議アプリのプレゼンテーション機能を思い浮かべてください）。Chrome 96 では、新しい focus() メソッドをサポートする FocusableMediaStreamTrack と呼ばれる MediaStreamTrack のサブクラスを使用して、このコントロールを可能にしました。次のコードをご覧ください。

stream = await navigator.mediaDevices.getDisplayMedia();
let [track] = stream.getVideoTracks();

このコードでは、以前は getVideoTracks() が MediaStreamTrack オブジェクトの配列を返していましたが、FocusableMediaStreamTrack オブジェクトを返すようになります（Chrome 97 では、返されるオブジェクトが BrowserCaptureMediaStreamTrack に変更される予定です。本記事の執筆時点で、Canary 版ではすでに新しいオブジェクトが返されるようになっています）。

フォーカスするディスプレイ メディアを決定するには、このコードの次の行で "focus-captured-surface" を指定して track.focus() を呼び出し、新しくキャプチャするウィンドウやタブにフォーカスするか、"no-focus-change" を指定してこのメソッドを呼び出し、呼び出し元のウィンドウにフォーカスし続けます。Chrome 96 以降では、デモコードを試して、この機能の動作を確認できます。

Priority Hints

Priority Hints では、デベロッパーが設定する "importance" 属性が導入され、計算されるリソースの優先度を変更することができます。サポートされる importance 属性の値は、"auto"、"low"、と "high" です。Priority Hints は、リソースの相対的な重要度をブラウザに示し、リソースが読み込まれる順序をより細かくコントロールできるようにします。ブラウザでは、リソースのタイプ、可視性、プリロードのステータスなど、多くの要素がリソースの優先度に影響を及ぼします。

今回のリリースに追加されたその他の機能

プリフライトなしに単純な Range ヘッダー値を許可

プリフライト リクエストなしに、単純な Range ヘッダーを指定してリクエストを送信できるようになりました。CORS リクエストでは、プリフライト リクエストをトリガーせずに、Range ヘッダーを限定的な方法（1 つの有効な範囲のみ）で使用できます。

デスクトップのバックフォワード キャッシュ

バックフォワード キャッシュにページが格納され、クロスサイト ナビゲーションをした後でも、以前にアクセスしたページへの即時ナビゲーションが可能になります。

Cross-Origin-Embedder-Policy: credentialless

Cross-Origin-Embedder-Policy には、クロスオリジン no-cors リクエストで認証情報（Cookie やクライアント証明書など）を省略できるようにする新しい credentialless オプションが追加されます。COEP:require-corp と同じように、クロスオリジン分離も有効化できます。

SharedArrayBuffer を使い続けたいサイトでは、クロスオリジン分離をオプトインする必要があります。COEP: require-corp を使用して、クロスオリジン分離のオプトインを大規模に導入することは難しく、すべてのサブリソースで明示的にオプトインしなければならなくなります。これが問題にならないサイトもありますが、ユーザーからコンテンツを収集するサイト（Google Earth、ソーシャル メディア全般、フォーラムなど）では、依存関係の問題が発生します。

CSS

:autofill 疑似クラス

新しい autofill 疑似クラスを使用すると、自動入力されるフォーム要素のスタイルを設定できます。これは、:-webkit-autofill 疑似クラスの標準化として導入されており、WebKit ではすでにサポートされています。Firefox は、この標準バージョンをサポートします。

封じ込めが適用される場合に body スタイルからビューポートへの伝播を無効化

writing-mode、direction、background など、一部のプロパティは、body からビューポートに伝播されます。CSS コンテナクエリの無限ループを防ぐために、仕様と実装が変更され、HTML または BODY にレイアウトの封じ込めが適用される際にこれらのプロパティが伝播されなくなりました。

font-synthesis プロパティ

font-synthesis CSS プロパティは、フォント ファミリーにフェイスがない場合、ユーザー エージェントが斜体、太字、小型英大文字のフォント フェイスを合成できるようにするかどうかをコントロールします。

EME MediaKeySession が閉じられた理由

MediaKeySession.closed プロパティは、enum を使用して、MediaKeySession オブジェクトが閉じられた理由を示すようになります。この closed プロパティは、セッションが閉じたときに解決される Promise を返します。以前は Promise が解決されるだけでしたが、文字列として解決されるようになり、閉じられた理由を示します。返される文字列は、"internal-error"、"closed-by-application"、"release-acknowledged"、"hardware-context-reset"、"resource-evicted" のいずれかです。

HTTPS DNS レコードでの HTTP から HTTPS へのリダイレクト

Chrome では、DNS（ドメイン名サービス）から HTTPS レコードが利用できる場合は、常に HTTPS 経由でウェブサイトに接続します。

EventTiming の interactionID

PerformanceEventTiming インターフェースに interactiveID と呼ばれる属性が含まれるようになりました。これは、ブラウザが生成する ID であり、複数の PerformanceEventTiming エントリが同じユーザー操作に対応する場合、これらのエントリをリンクできるようにします。現在、デベロッパーは Event Timing API を使用して、関心のあるイベントのパフォーマンス データを収集できます。ただし、同じユーザー操作に対応するイベントをリンクすることは困難です。たとえば、ユーザーがタップしたときなら、pointerdown、mousedown、pointerup、mouseup、click など、多くのイベントが生成されます。

新しいメディアクエリ : prefers-contrast

Chrome は、 'prefers-contrast' と呼ばれる新しいメディアクエリをサポートします。そのため、ウェブ制作者は、オペレーティング システムで設定されたユーザーのコントラスト設定（具体的には、macOS のコントラストを強調したモードと Windows のハイ コントラスト モード）にウェブ コンテンツを合わせることができます。有効な選択肢は、'more'、'less'、'custom'、または 'no-preference' です。

デスクトップ PWA の一意の ID

ウェブアプリ マニフェストで任意の id フィールドがサポートされ、ウェブアプリをグローバルに特定できるようになりました。id フィールドがない場合、PWA は start_url にフォールバックします。現時点で、このフィールドはデスクトップのみでサポートされます。

PWA の URL プロトコル ハンドラ登録

ウェブ アプリケーションがインストール マニフェストを使用して、カスタム URL プロトコル / スキームのハンドラとして自身を登録できるようにします。多くの場合、オペレーティング システム アプリケーションは自身をプロトコル ハンドラとして登録して、見つけやすさと使用率を向上します。ウェブサイトは、すでに registerProtocolHandler() を介してスキームを処理するように登録できます。この新機能はもう一歩踏み込んで、カスタム スキーム リンクが呼び出されたときに、ウェブアプリを直接起動できるようにします。

WebAssembly

コンテンツ セキュリティ ポリシー

Chrome のコンテンツ セキュリティ ポリシーが強化され、WebAssembly との相互運用性が向上しています。wasm-unsafe-eval は、WebAssembly の実行をコントロールします（JavaScript の実行には影響しません）。また、script-src ポリシーに WebAssembly が含まれるようになりました。

参照型

WebAssembly モジュールで JavaScript オブジェクトや DOM オブジェクトへの参照を保持できるようになりました。具体的には、これらの参照は、引数として渡したり、ローカル変数やグローバル変数に格納したり、WebAssembly.Table オブジェクトに格納したりできます。

サポートの終了と機能の削除

このバージョンの Chrome では、以下のサポートの終了と機能の削除が行われます。現在サポートが終了している機能と以前に削除された機能のリストは、ChromeStatus.com をご覧ください。

PaymentRequest API の “basic-card” 支払い方法

PaymentRequest API では、“basic-card” 支払い方法が非推奨となっています。その使用率は低いうえ、低下し続けています。この支払い方法の購入手続きまでの時間や購入完了率は、他の支払い方法を下回っています。デベロッパーは、代わりとして他の支払い方法に切り替えることができます。たとえば、Google Pay、Apple Pay、Samsung Pay などの支払い方法です。

削除までのタイムライン :

  • Chrome 96: “basic-card” 支払い方法は、レポーティング API で非推奨となります。
  • Chrome 100: “basic-card” 支払い方法は削除される予定です。

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

Payment Request API で "basic-card" 支払い方法の提供が終了

この記事は Chrome チーム、デベロッパー アドボケート、Eiji Kitamura による Chromium Blog の記事 “Sunsetting the ‘basic-card’ payment method in the Payment Request API” を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。


Payment Request API は推奨が近いウェブ標準であり、ウェブ デベロッパーが手間のかからない安全な支払いフローを簡単に構築できるようにすることを目的としています。ブラウザは、販売者のウェブサイトと「支払いハンドラ」との間のフローを容易にします。支払いハンドラは、ブラウザ、ユーザーのモバイル デバイスにインストールされたネイティブ アプリ、またはプログレッシブ ウェブアプリに組み込むことができます。現在、デベロッパーは Payment Request API を使用して、ほとんどのプラットフォームの Chrome で利用できる “basic-card” や Google Pay、Safari の Apple Pay、Google Play での Digital Goods API、Chrome の Secure Payment Confirmation など、いくつかの支払い方法にアクセスできます。

Google は昨年の初めに、iOS 版 Chrome に加えて、他のプラットフォームでも “basic-card” 支払いハンドラのサポートを終了する予定であることを発表しました。通常、ブラウザに組み込まれている支払い方法である “basic-card” は、クレジット カード番号を覚えたり、手動で入力したりすることなく、その番号を簡単に入力できるようにします。この支払い方法は、フォームベースのクレジット カード支払いからアプリベースのトークン化されたカード支払いへの移行をスムーズにするために設計されました。Web Payments WG は、アプリベースの支払いを促進する（また、その他のいくつかの理由で）という目標を達成するために、“basic-card” を仕様から削除することを決定しました。

Chrome バージョン 96 以降で “basic-card” 支払い方法が使われると、DevTools コンソールに警告メッセージが表示されます（レポーティング API のレポートも作成されます）。バージョン 100 では、”basic-card” 支払い方法が利用できなくなり、他の使用可能な支払い方法が指定されていない限り、canMakePayment() は false を返します。これは、Android、macOS、Windows、Linux、Chrome OS など、すべてのプラットフォームに適用されます。

Payment Request API で “basic-card” 支払いハンドラを使用している場合は、この支払いハンドラをできるだけ早く削除して、Google Pay や Samsung Pay などの代替支払い方法を使用することをおすすめします。

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

Amazonの価格変動が分かるツール：Amazon Price Tracker – 研究職ママの子育ち日記～子どもの学び方を考える～

みなさん、Amazon Price Trackerをご存知ですか？ こんな感じで、価格の推移を示してくれるものです。 実は私は最近知りました（情弱） 娘の塾の先生のYoutubeで、先生がご自身のAmazonの画面を見せてくれて、そこにAmazon Price Trackerが入っていたのです。 なにあれ、便利そう… と、さっそく入れたら便利だったので、…

Chromeアップデート後に太字フォントの表示がおかしい（フォントが変わった、アンチエイリアスがかかる等）問題発生中

Windowsユーザーの間で、最新版Chrome（バージョン96）へのアップデート後に「アップデートしたらフォントが変わった」と困惑するユーザーが増えています。 具体的には、特に「太字（ボールド）」のフォントの表示に関す…

Google、Chrome の Windows 7 サポートをさらに 1 年間延長

Google が Google Chrome の Windows 7 サポートを 1 年間延長すると以前のブログ記事に追記する形で発表している (Google Cloud Blog の記事 [1]、 [2]、 Softpedia の記事)。

Google は Windows 7 の延長サポート終了直前の昨年 1 月、Microsoft によるサポートが終了してから少なくとも 18 か月、2021 年 7 月 15 日までは Google Chrome で Windows 7 をサポートすると発表し…