次世代のウェブ コンテンツに対応
Chris Harrelson です。Blink のレンダリング(HTML と CSS の変換)のエンジニアリング リードです。私は 8 年以上にわたり、ウェブでのレンダリング パフォーマンスの分野に深く関わってきました。個人的な目標は、優れた UX をより速く、簡単かつ安全に提供できるように、できることなら何でも行うことです。新しい最先端の Chromium レンダリング エンジン アーキテクチャを構築するために、当時行った Google の取り組みをご紹介します。 これは大変な努力によるものでした
2021 年には、このアーキテクチャの設計、構築、出荷のプロセスの大部分が完了します。今は「RenderingNG」としますRenderingNG は少なくとも 8 年にわたって開発が進められており、多くの Chromium デベロッパーが集まって取り組んでいるものです。高速で滑らかで信頼性が高く、レスポンシブでインタラクティブなウェブ コンテンツの次世代の可能性を秘めています。また、デベロッパーが信頼できるすべてのウェブ レンダリング エンジンの新しい最低基準を定義するベースラインでもあります。
このブログ投稿はシリーズの第 1 回目です。Google が構築したもの、目的、仕組みについて説明します。最初の投稿では、まず以下のことから始めます。
- Google の目標。
- 「成功のピラミッド」: Google の取り組みの指針となる原則と、その原則の実践例。
- RenderingNG によって可能になる特徴と機能
- RenderingNG の主なプロジェクト コンポーネントの概要
北極星
RenderingNG の明確な指針は、ブラウザ エンジンの実装とそのレンダリング API の豊富さが、ウェブ上の UX を制限する要因にならないようにすることです。
ブラウザのバグによって機能の信頼性が低下したり、サイトのレンダリングが壊れたりすることを心配する必要はありません。
パフォーマンスの急激な変化があってはなりません。 また、不足している組み込みの機能を回避する必要もありません。
正常に動作するはずです。
RenderingNG は、この目標に向けた大きな一歩になると考えています。 RenderingNG の導入前は、レンダリング機能を追加してパフォーマンスを改善できましたが、これらの機能をデベロッパーにとって信頼性のあるものにすることができず、パフォーマンスが大幅に低下しました。現在では、これらの問題の多くを体系的に解消し、これまで実現不可能だと考えられていた高度な機能を解消するアーキテクチャができました。つまり、
- さまざまなプラットフォーム、デバイス、オペレーティング システムの組み合わせにわたって、確固たるコア機能を備えています。
- 予測可能で信頼性の高いパフォーマンスがある。
- ハードウェア機能(コア、GPU、画面解像度、リフレッシュ レート、低レベル ラスター API)の使用率を最大化します。
- 可視コンテンツを表示するために必要な処理のみを実行します。
- 一般的なビジュアル デザイン、アニメーション、インタラクション デザイン パターンのサポートが組み込まれています。
- レンダリング コストを簡単に管理できるデベロッパー API を提供します。
- デベロッパー アドインのレンダリング パイプラインの拡張ポイントを提供します。
- HTML、CSS、2D キャンバス、3D キャンバス、画像、動画、フォントなど、すべてのコンテンツを最適化します。
他のブラウザ レンダリング エンジンとの比較
Gecko と Webkit は、これらのブログ投稿で説明したアーキテクチャ機能のほとんどを実装しており、場合によっては Chromium よりも前に実装されています。これは素晴らしいですね! どのブラウザも高速で信頼性が向上すれば、大きな影響があります。しかし、最終的な目標は、すべてのブラウザのベースラインを進化させ、デベロッパーが安心して利用できるようにすることです。
成功のピラミッド
私の理念は、成功は最初に信頼性を達成し、次にスケーラブルなパフォーマンスを達成し、最終的には拡張性を達成した結果であるということです。
実際のピラミッドと同様に、各レベルは、その上のレベルの基礎を固く構築します。
信頼性
豊かで複雑なユーザー エクスペリエンスを実現するには、まず堅牢なプラットフォームが必要です。コア機能と基盤は正しく機能し、時間が経過しても動作し続ける必要があります。同様に、それらの特徴量が適切に構成され、奇妙なエッジケースの動作やバグがないことも重要です。
このため、信頼性は RenderingNG の最も重要な要素の一つです。信頼性は優れたテスト、品質フィードバック ループ、指標、ソフトウェア設計パターンによって得られます。
信頼性の重要性を実感していただくために 私たちはこの 8 年間の大半をこの部分に 取り組んできましたまず、システムに関する深い知識を築きました。具体的には、バグレポートから弱点のある箇所を調べて修正し、包括的なテストをブートストラップし、サイトのパフォーマンス ニーズと Chromium のパフォーマンスの制限を把握しました。その後、主要な設計パターンとデータ構造を注意深く段階的に設計し、ロールアウトしました。ようやく、レスポンシブ デザイン、スケーラビリティ、レンダリングのカスタマイズのための真に次世代のプリミティブを追加する準備が整いました。
その期間中に Chromium で改善された点はないというわけではありません。 実は、その逆も真実です。 この数年は、Google がリファクタリングを一つずつ進め、改善を段階的に展開する中で、信頼性とパフォーマンスが着実かつ持続的に向上しました。
テストと指標
過去 8 年間にわたり、単体テスト、パフォーマンス テスト、統合テストを数万件追加してきました。さらに、ローカルテスト、パフォーマンス ベンチマーク、および実際のユーザーとデバイスでの実際の環境で、Chromium のレンダリングがどのように動作するかについて、さまざまな側面を測定する包括的な指標を開発しました。
しかし、RenderingNG(あるいは、別のブラウザのレンダリング エンジン)がどれほど優れていても、ブラウザ間で多くのバグや動作の違いがある場合、ウェブ向けの開発は容易ではありません。また、この問題に対処するため、Google ではウェブ プラットフォーム テストを最大限に活用しています。それぞれのテストでは、すべてのブラウザが合格を目指すウェブ プラットフォームの使用パターンを検証します。また、時間の経過とともにより多くのテストに合格することや、コア互換性を向上させるための指標を綿密にモニタリングしています。
ウェブ プラットフォーム テストは協力して実施されます。たとえば、Chromium のエンジニアが追加した CSS の機能は、WPT テスト全体の約 10% にすぎず、他のブラウザ ベンダー、独立したコントリビューター、仕様作成者が貢献しています。ウェブの相互運用性を高めるには、人の協力が必要です。
優れたソフトウェア設計パターン
一方、コードが理解しやすく、バグの可能性を最小限に抑えるように設計されていれば、高品質のソフトウェアを確実に提供しやすくなります。RenderingNG のソフトウェア設計については、今後のブログ投稿で詳しくお伝えします。
スケーラブルなパフォーマンス
速度、メモリ、電力使用量の面で優れたパフォーマンスを達成することは、RenderingNG の次に最も重要な側面です。Google は、デバイスの安定性を犠牲にすることなく、すべてのウェブサイトとのやり取りをスムーズでレスポンシブにしたいと考えています。
しかし、私たちが求めているのはパフォーマンスだけではありません。スケーラブルなパフォーマンス、つまり、ローエンド、ハイエンドのマシン、OS プラットフォームを問わず確実に動作するアーキテクチャも求めています。私はこれをスケールアップと呼んでいます。これは、ハードウェア デバイスが実現できるすべてのことを活用してスケールダウンすることで、効率を最大化し、必要に応じてシステムへの要求を減らすことです。
そのためには、キャッシュ保存、パフォーマンス分離、GPU ハードウェア アクセラレーションを最大限に活用する必要がありました。順番に見ていきましょう具体的には、ウェブページで非常に重要な操作であるスクロールのパフォーマンスに、それぞれの要素がどのように貢献しているのかを考えてみましょう。
キャッシュ
ウェブなどの動的でインタラクティブな UI プラットフォームでは、パフォーマンスを劇的に改善する最も重要な方法はキャッシュ保存です。ブラウザで最もよく知られているキャッシュは HTTP キャッシュですが、レンダリングにも多くのキャッシュがあります。スクロールで最も重要なキャッシュは、キャッシュされた GPU テクスチャとディスプレイ リストです。これにより、バッテリーの消耗を最小限に抑えながら、さまざまなデバイスで適切に動作しながら、スクロールを非常に高速にできます。
キャッシュ保存は、スクロールのバッテリー駆動時間とアニメーション フレームレートに役立ちますが、さらに重要なことは、メインスレッドからパフォーマンスを分離できることです。
パフォーマンスの分離
最新のデスクトップ パソコンでは、バックグラウンド アプリケーションによって作業中のアプリケーションの速度が低下することを心配する必要はありません。これは、プリエンプティブ マルチタスクによるものです。プリエンプティブ マルチタスクは、ひいてはパフォーマンス分離の一種であり、独立したタスクが互いに速度を低下させないようにします。
ウェブでのパフォーマンス分離の最適な例は、スクロールです。低速な JavaScript を大量に含むウェブサイトでも、スクロールは JavaScript やレイアウト スレッドに依存しない別のスレッドで実行されるため、非常にスムーズに処理できます。Google は RenderingNG に多大な労力を注いでおり、単なるディスプレイ リストにとどまらない複雑な状況でも、可能なすべてのスクロールがスレッド化されるようにしています。たとえば、固定位置と固定位置の要素を表すコード、パッシブなイベント リスナー、高品質のテキスト レンダリングなどがこれに該当します。
GPU アクセラレーション
GPU を使用すると、ピクセルの生成と画面への描画が飛躍的に速くなります。多くの場合、すべてのピクセルを他のピクセルと並行して描画できるため、速度が大幅に向上します。RenderingNG の主要なコンポーネントは、GPU ラスターとあらゆる場所に描画する機能です。すべてのプラットフォーム、すべてのデバイスで GPU を使用して、ウェブ コンテンツのレンダリングとアニメーション化を高速化します。これは、多くの場合、デバイスの他の部分よりもはるかに高性能な GPU を搭載したローエンド デバイスや超ハイエンド デバイスで特に重要です。
拡張性: ジョブに適したツール
信頼性と拡張性に優れたパフォーマンスが得られたら、HTML、CSS、Canvas の組み込み部分を拡張し、苦労して得たパフォーマンスと信頼性を犠牲にすることなく、デベロッパーが拡張できる多数のツールを利用する準備が整います。
この API には、レスポンシブ デザイン、プログレッシブ レンダリング、スムーズさと応答性、スレッド レンダリングなどの高度なユースケース向けの JavaScript 公開 API が組み込まれています。
Chromium が支持する以下のオープン ウェブ API は、RenderingNG によって実現したものであり、以前は実現不可能と考えられていました。
これらはすべて、オープンな仕様と、オープンウェブ パートナー(他のブラウザのエンジニア、エキスパート、ウェブ デベロッパー)と共同で開発されました。以降のブログ投稿では、それぞれについて詳しく見ていき、RenderingNG によってそれらがどのように実現されるかを説明します。
- content-visibility: サイトは画面外コンテンツのレンダリング処理を簡単に回避でき、現在表示されていない単一ページ アプリケーション ビューのキャッシュ レンダリングも簡単に行えます。
- OffscreenCanvas: キャンバス レンダリング(2D キャンバス API と WebGL の両方)を独自のスレッドで実行できるため、優れたパフォーマンスを確実に実現できます。このプロジェクトは、ウェブにおけるもう一つの大きなマイルストーンで、JavaScript(または WebAssembly)で複数のスレッドから 1 つのウェブページ ドキュメントをレンダリングできるようにする初めてのウェブ API です。
- コンテナクエリ: 単一のコンポーネントがレスポンシブに自身をレイアウトし、プラグアンドプレイ コンポーネント全体のブロックを解除します(現在は試験運用版の実装です)。
- オリジンの分離: サイトで iframe 間でパフォーマンスの分離を強化できます。
- メインスレッド外のペイント ワークレット: デベロッパーは、コンポジタ スレッドで実行されるコードを使用して、要素のペイント方法を拡張できます。
明示的なウェブ API に加え、RenderingNG により、すべてのサイトにメリットをもたらす重要な「自動機能」をいくつかリリースできるようになりました。
- サイト分離: クロスオリジンの iframe を異なる CPU プロセスに配置して、セキュリティとパフォーマンスの分離を強化します。
- Vulkan、D3D12、Metal: OpenGL よりも効率的に GPU を使用する低レベル API を利用します。
- アニメーションの合成: SVG、背景色。
RenderingNG によってブロックされる今後の追加機能には、次のようなものがあります。
- スクロールリンク アニメーション。
- 非表示ながらも検索とアクセスの容易な DOM。
- 共有要素遷移。
- カスタム レイアウト。
- メインスレッド外の合成、スレッド化と合成の分離。
RenderingNG を構成する主なプロジェクト
以下に、RenderingNG の主なプロジェクトを示します。次回以降のブログ投稿で、それぞれを詳しく見ていきます。
CompositeAfterPaint
スタイル、レイアウト、ペイントから合成を切り離すことで、信頼性と予測可能なパフォーマンスが大幅に向上し、スループットが向上し、パフォーマンスを犠牲にすることなくメモリの使用量を削減できます。2014 年に始まり、今年で終了します。
年 | Progress |
---|---|
2015 | ディスプレイ リストを発送する。 |
2017 | 新しい無効化を発行します。 |
2018 年 | 船の特性ツリー(パート 1) |
2019 年 | 船の特性ツリー(パート 2) |
2021 | プロジェクトの出荷を完了しました。 |
LayoutNG
すべてのレイアウト アルゴリズムを一から書き直したことで、信頼性が大幅に向上し、パフォーマンスの予測可能性が向上しました。2016 年に開始され 今年中に終了する予定です
年 | Progress |
---|---|
2019 年 | ブロックのフロー。 |
2020 年 | 柔軟な編集、 |
2021 | その他はすべて発送します。 |
BlinkNG
Blink レンダリング エンジンのクリーンアップとリファクタリングを行い、明確に分離されたパイプライン フェーズにします。これにより、キャッシュ保存が向上し、信頼性が向上し、コンテンツの可視性やコンテナクエリなどのリエントラントまたは遅延レンダリングが可能になります。この取り組みは 2014 年に始まり、その後も段階的に改善され、現在も続いています。2021 年に完了します。
あらゆる場所での GPU アクセラレーション
すべてのプラットフォームで GPU のラスタライズ、描画、アニメーションを常にロールアウトする長期的な取り組み。 GPU アクセラレーションは、すべてのピクセルを並列処理できるため、ほとんどのコンテンツで速度が大幅に向上します。また、GPU を搭載している傾向があるローエンド デバイスでパフォーマンスを向上させるのにも効果的です。2014 年に始まり、2020 年に完了しました。
年 | Progress |
---|---|
2014 | Canvas のサポート。Android のオプトイン コンテンツで配信されます。 |
2016 | Mac で出荷。 |
2017 | GPU は Android のページビューの 60% 以上で使用されます。 |
2018 年 | Windows、ChromeOS、Android Go でリリースします。 |
2019 年 | スレッド GPU のラスタライズ。 |
2020 年 | 残っている Android コンテンツを発送する。 |
スレッド形式のスクロール、アニメーション、デコード
スクロール、レイアウト非誘導のアニメーション、画像のデコードをすべてメインスレッドから移行するための長期的な取り組み。2011 年に始まり、今も進行中です。
年 | Progress |
---|---|
2011 | スレッド形式のスクロールとアニメーションを初期サポートしました。 |
2015 | レイヤの圧縮。 |
2016 | ユニバーサル オーバーフロー スクロール。 |
2017 | コンポジタ スレッドで画像がデコードされる。 |
2018 年 | コンポジタ スレッドの画像アニメーション。 |
2020 年 | 常に固定位置を合成します。 |
2021 | パーセンテージ変換アニメーション、SVG アニメーション。 |
ビジュアリゼーション
Chromium のラスターおよび描画プロセスを一元化して、スループットを向上させ、メモリを最適化し、ハードウェア機能の最適な利用を実現します。また、サイト分離のブロックを解除する、レンダリング パイプラインをブラウザの UI レンダリングから切り離すなど、ウェブ デベロッパーには目立たないものの、ユーザーにとっては目に見えるメリットもあります。2016 年に開始され、2021 年に完了する予定です。
年 | Progress |
---|---|
2018 年 | OOP-R は Android、Mac、Windows でリリースされています。 |
2019 年 | OOP-D を発送しました。OOP-R はどこにでも発送されます(Canvas を除く)。SkiaRenderer は Linux でリリースされました。 |
2020 年 | SkiaRenderer は Windows と Android に搭載されました。Vulkan は Android に搭載されています。 |
2021 | SkiaRenderer は Mac にリリース済み(ChromeOS も近日中にリリース予定)。 |
上の表で使われる用語の定義:
- サポート範囲外(OOP-D)
- プロセス外のディスプレイ コンポジタ。 ディスプレイ合成は、OS コンポジタと同じ種類のアクティビティです。プロセス外とは、ウェブページのレンダリング プロセスやブラウザ UI プロセスではなく、Viz プロセスで行うことを意味します。
- OOP-R
- プロセス外のラスター。ラスターがディスプレイ リストをピクセルに変換している。プロセス外とは、ウェブページのレンダリング プロセスではなく Viz プロセスで行うことです。
- SkiaRenderer
- Vulkan、D3D12、Metal など、さまざまな基盤となる GPU API での実行をサポートできる新しいディスプレイ コンポジタの実装。
スレッド形式のキャンバス レンダリングとアクセラレーテッド キャンバス レンダリング
このプロジェクトは、OffscreenCanvas を可能にした建築要素を配置したプロジェクトです。2015 年に開始し、2021 年に終了する予定です。
年 | Progress |
---|---|
2018 年 | OffscreenCanvas を出荷する。 |
2019 年 | ImageBitmapRenderingContext を送信します。 |
2021 | OOP-R を発送します。 |
VideoNG
ウェブ上での効率的で信頼性が高く、高品質な動画再生を提供するための長期的な取り組みです。
年 | Progress |
---|---|
2014 | Mojo ベースのレンダリング フレームワークを導入しました。 |
2015 | よりスムーズな動画レンダリングのために、Project Butter と動画オーバーレイを出荷しました。 |
2016 | Android とデスクトップのデコードとレンダリングの統合パイプラインを出荷。 |
2017 | HDR と色補正済み動画レンダリングを出荷しました。 |
2018 年 | Mojo ベースの動画デコード パイプラインを出荷しました。 |
2019 年 | サーフェスベースの動画レンダリング パイプラインを出荷しました。 |
2021 | ChromeOS で 4K の保護コンテンツ レンダリング サポートを出荷しました。 |
上の表で使われる用語の定義:
- モホ
- Chromium 用の次世代 IPC サブシステム。
- 画面
- Viz プロジェクトの設計に含まれるコンセプトです。
おわりに
ウェブと Chromium におけるレンダリングの進歩には目を見張るものがあります。 RenderingNG の確固たる基盤の上に構築できるようになるため、今後そのペースは加速し続けるでしょう。
今後の投稿では、新しいアーキテクチャ、誕生の経緯、仕組みについてさらに詳しく説明します。どうぞご期待ください。
デバイスの写真: Eirik Solheim Unsplash
イラスト: Una Kravets