Display Locking によるレンダリングの最適化と Async DOM

ライブラリによる最適化

React や lit-html は、この State の DOM への展開をライブラリで抽象化し、更新コストのコントロールを提供している。

実装はそれぞれ違うが、簡単にいえば既に展開されている DOM から、更新結果の DOM までの間を、最小限の操作で変化できる方法を割り出すという点では共通しているだろう。

React は Virtual DOM による差分更新、lit-html は Tagged Template Literal で割り出した Strict/Dynamic Part の識別によりこれを行なっている。

少し違うアプローチとして Worker DOM は、DOM の処理を Worker で実行しているように見せているが、実際には当然 Window にコマンドを発行し DOM API を呼ぶ。

どんなに最適化をしても、最終的にはブラウザの持つ DOM API を呼び出す必要があるため、そこがボトルネックになるのは避けられない。

そこには、標準 API によりブラウザが担保し、ベンダが実装によって最適化する余地があるだろう。

当然同じことを考える人は多く、おおよそ 4 つの異なるアプローチによる提案がなされ、それらは Async DOM という文脈でまとめられていた。

Async DOM の提案

同時期に出てきたというよりは、常に誰かが何かしら提案していた DOM API の改善提案が、3~4 年くらい前から AsyncDOM としてまとめられた。

• async-dom/current-proposals.md at master - chrishtr/async-dom

これを議論するための Mailing List ができたため、できてから 2 年くらいずっと気にかけていたのだが、特に大きな動きはなかった。

• async-dom - Google グループ

基本は、現状の DOM の持つ問題を大きく 2 つと考え、そのどちらかないし両方にアプローチしていると見るとだいたいわかる。

• DOM の操作が同期に行われる(非同期にできない)
• DOM の操作がメインループ上でしかできない(Worker に落とせない)

それを踏まえて簡単にそれぞれを解説する。

• asyncAppend
  • 非同期版 Append を生やす
  • 単体 Append だけではなく、DOM 処理の Batch 化もする
• WorkerNode
  • Worker と行き来できる DOM 更新命令をまとめたオブジェクトの提案
  • そのオブジェクトの適用には asyncAppend を使う
• DOM ChangeList
  • DOM の更新命令をまとめるオブジェクトを提案
  • それを適用すると一気に処理が走る、VirtualDOM に似てる
  • エンジンが最適化できるため
• Display Locking
  • 今回の本題なので後述

Display Locking 以外は、特に作業がされていない。

API

Display Locking が実装されると、Element に displayLock というプロパティが生える。

ここには 4 つのメソッドがあり、それぞれ以下の役割がある。

acquire()

ロックの取得

update()

getComputedStyle, offsetTop で必要な計算(forced update)などを計算する

commit()

ロックの解除(レンダリング開始)

updateAndCommit()

update + commit

それぞれが Promise を返す非同期な処理となっている。

Example

簡単な例として、すでに DOM 上にある <ul> に、複数の <li> を追加する処理を考える。

const $ul = document.querySelector("$ul")
for (const i = 0; i < 100; i ++) {
  const $li = document.createElement("li")
  $li.textContent = "deadbeef"
  $ul.appendChild($li)
}

この appendChild が毎回レンダリングを発生している。

わかりやすいように、appendChild に setTimeout を仕込んだ例は以下のように挙動する。

そこで、<ul> のロックを取得し、全ての <li> が追加されてから一気にレンダリングする場合以下のように書ける。

const $ul = document.querySelector("$ul")

// Lock
await $ul.displayLock.acquire({ timeout: Infinity })

for (let i = 0; i < 100; i ++) {
  const $li = document.createElement("li")
  $li.textContent = "deadbeef"
  $ul.appendChild($li)
}

// Unlock
await container.displayLock.updateAndCommit()

こちらも、わかりやすいように setTimeout を仕込んだ例は以下のように挙動する。

Lock 中に行われる appendChild は、メモリ上で DOM の処理を行うだけになり、commit() でレンダリングが一度に走っていることがわかるだろう。

acquire option

acquire() はオプション値をとる。

timeout

タイムアウトすると commit されるため、commit 漏れを防ぐことができる。

sizes

commit 後のサイズを指定することで、その領域を確保しておくことができる。

activatable

後述

CSS Containment

Commit された場合のレンダリング処理を最適化するために、Display Lock を取得する対象は contain: style layout が指定されている必要がある。

CSS Containment は、例えば style と layout の計算が、対象要素内に閉じていることを明示し、ブラウザの最適化にヒントを与えるものだ。

Display Lock は、その性質を利用して、事前にブラウザに style と layout が contain された要素が commit 時にレンダリングされることを示すことにした。

これは逆に Containment が指定できる設計に事前になっている箇所にしか Display Lock が使えないことを意味するため、Lock を取得する対象など、設計に影響してくるだろう。

activatable

この API が標準で提供されるメリットの 1 つが activatable だろう。

activatable は、メモリ上にあるがレンダリングされてない DOM に対して、UI からアクセスできるようにするオプションだ。

説明よりも見た方が早いので以下にデモを示す。

このデモでは、ランダムな文字列を <li> に入れ、ロックをとった <ul> に追加し commit してない状態で止めている。

ここで、CTL+F で「ページ内検索」を行い、ランダムな文字列にヒットするように検索をすると、レンダリングが走り遷移していることがわかるだろう。

ブラウザは、まだメモリ上にありレンダリングされてない要素を、検索やフォーカス移動などの対象に含み、必要に応じて commit することができるのだ。

これを利用すると、Infinite Scroll で、少しづつ裏で DOM に挿しつつレンダリングは遅延させていても、検索にはヒットするといった実装が可能になる。

そのものずばりなユースケースとして、Layered API の文脈で議論されている Virtual Scroll のニーズとも一致している。

• WICG/virtual-scroller

この Virtual Scroller のページ検索のために、もともと別ドラフトであった Searchable Invisible DOM という提案があった。

• Intent to Implement: Searchable Invisible DOM - Google グループ

これは現在 Display Locking の仕様に統合されたと記されている。

効果と Junk の回避

より効果がわかりやすい DEMO として、explainer で紹介されている動画を引用する。

(MIME が指定されていないため、<video> で埋め込むことができず、リンクしている)

ソースが公開されていないが、この DEMO では、アニメーションで円形のタイマーを回しており、通常は緑で表示される。

その背景に、複雑なレイアウトの DOM が表示されており、その表示/非表示を toggle ボタンで切り替えている模様だ。

まず display locking を利用しない場合は、背景を表示する際にかかるレンダリングコストが大きく、Junk が発生してタイマー部が赤くなっていることがわかる。

display locking を指定せず Junk が発生している例

これを、背景表示に Display Locking を適用した DEMO が以下だ。

レンダリングを一括して行なっているため、タイマー部の赤い部分が削減され Junk が最小に抑えられているように見える。

display locking を指定し Junk を抑えた例

背景のレイアウトがどの程度複雑なのかは想像でしかないが、この規模のレンダリングコストがかかるということはそれなりに大きいのだろう。

SPA などでは、DOM 変更の範囲が大きいページ遷移などが考えられそうだ。

考察

前述の通り、Display Locking は、この仕様のまま標準化されると決まっているわけではないが、今後の Async DOM を考える上でのたたき台になるだろう。

AsyncDOM の他の提案が、Append の非同期化や Worker への以降などを基本としていたことに比べると、この仕様はレンダリングのライフサイクル自体に手を入れた点が大きく異なる。

結果として、Activatable による UI のインタラクションを受け入れることができる一方、レンダリングエンジンへの影響も大きいため、実装上の懸念は少なくない。

しかし、リアルワールドでは様々なライブラリが DOM 操作の最適化を提供している以上、Chrome の Intents にある通り React/Polymer といったチームからのフィードバックも無視されることはなさそうにも思える。

今後、この仕様自体のブラッシュアップ、もしくはこれをベースとした対案の標準化も含め、何かしら作業がすすむことはありそうだ。

仮に Display Locking がそのまま改善を含めて進んだとしても、レイヤの低い API であるため、そのまま開発者が触ることは少ないだろう。

React や lit-html が提供しているのは DOM の更新だけではないため、Display Locking があればそうしたライブライが不要になるというものではない。

特に SPA では State を DOM に展開する部分のコードが、いかに抽象化されているかも Developer Experience として重要だ。

しかし、その先の DOM への展開への最適化は、現状の DOM API の限界を越えることができないため、こうしたライブラリの下回りが Display Locking をうまく取り入れることで、Developer Experience を保ちながら、実装を改善することはできるだろう。

ただし、恩恵を受けるために CSS Containment などが絡むと考慮点も増えるため、単純にライブラリが更新されるだけで改善するかというと、そうもいかないかもしれない。

それを考えると、実装そのものが隠蔽された Virtual Scroller のような Component を呼び出すだけといった抽象度の高い利用の方が、導入障壁は低いかもしれない。

いずれにせよ、今後の Mozilla や Apple の反応、それに対応した Display Locking のチームの改善や、対案の登場などを中心に、動向を注視したい。

DEMO

動作するデモを以下に用意した。

• https://labs.jxck.io/display-locking/