サイトの速さの話をするとき、話題はどうしてもページ全体の評価に寄っていきます。表示速度の指標が良いか悪いか、という会話は、1枚のページを丸ごと1つの数字にまとめた見方です。ただ、実際に手を動かしていて困るのは、もっと部分的なところではないでしょうか。商品の価格や在庫の表示だけが後から差し替わる、同意バナーが本文より遅れて覆いかぶさる、問い合わせフォームの中身だけがしばらく空白のまま残る。ページ全体としては速いのに、利用者が待っているその一角だけが遅い、という状況です。
この「部品ごとにいつ見えたのか」をブラウザ側で数えてもらう仕組みが、試験提供の段階に入りました。Container Timingと呼ばれるもので、Bloombergが提案し、Igaliaの手でChromiumに実装されたものです。Chromeの開発者向けブログでは、Chrome 148からオリジントライアル、つまり本番のサイトで期間限定で試せる段階に入ったことが案内されています。
ページ全体の指標では届かない場所
いま広く使われている表示速度の指標は、いずれもページを単位にしています。最初に何かが描画された時点、いちばん大きな内容が描画された時点。どちらも利用者の体感を大づかみに表すには便利ですが、面積が大きいことと、その部品が大事であることは別の話です。
商品ページを思い浮かべると、写真、価格と在庫、レビュー、おすすめ商品、決済のウィジェット、同意バナー、外部のチャットといった部品が同居しています。サーバー側で組み立てられるものもあれば、読み込み後にブラウザ側で描かれるもの、外部との通信を待ってから出てくるものもあります。この中で最大の面積を占めるのはたいてい写真ですが、購入の判断を止めているのは価格や在庫の表示だったりします。
さらに、いちばん大きな内容の描画時間は、利用者が操作した時点で計測が打ち切られます。気にしている部品がスクロールやクリックのあとに現れるなら、その部品は指標に載らないまま終わります。実際の訪問者から集めた計測データを扱っている事業者の記事では、同じページ、同じ機種でもこの数値は訪問者ごとに揺れる、と説明されています。画面の広さの違いもありますが、操作で計測が止まることも理由の1つです。
囲んで名前をつけるだけの計測
Container Timingのやることは、拍子抜けするほど単純です。測りたいひとかたまりの外側の要素に containertiming という属性を書き、値として自分でつけた名前を入れる。それだけです。
あとは PerformanceObserver で container という種類の記録を購読すると、その内側に内容が描かれるたびに通知が届きます。届く記録には、自分でつけた名前、最初に描画された時刻、最新の描画の時刻、これまでに描かれた面積の合計、最後に描画のきっかけになった要素などが入っています。描画がコンポジタに渡された時刻と、画面に出た時刻を分けて受け取ることもできます。
逆に、数に入れたくない部分には containertiming-ignore という属性を書きます。同意バナーの中のボタン、読み込み中の骨組み表示、装飾目的の要素、計測のために差し込んだ表示など、数えると面積が水増しされてしまうものを外せます。囲みの中に大きな別部品がある場合、これを外しておくとDOMをたどる処理も軽くなる、という副次的な効きもあるようです。
要素単位の計測と何が違うのか
これまでも elementtiming という属性で、個々の要素の描画時刻を測ることはできました。ただ、これは1つの要素につき1回きりの合図です。ウィジェット全体がいつ揃ったのかを知りたければ、中身の要素すべてに印をつけて回る必要があり、しかも後から差し込まれる要素には印がついていません。自社で書いていない部品には、そもそも手を入れられません。
提案の説明文書では、この不足を埋めるために書かれたJavaScriptの補助実装が引き合いに出されています。描画が始まる前にすべての子要素へ印をつけ、DOMの変化を監視して新しく入ってきた要素にも印をつけ、描かれた矩形を自前で管理する。動きはするものの、そのために描画をせき止めることになり、計測したい速さを計測が損なうという本末転倒に近い形になっていました。この補助実装は現在保守を終えており、正確な値が必要ならブラウザ側の実装を使うよう案内されています。
もう1つの違いは、記録が一度で終わらないことです。ひとかたまりの中身は、文字が先に出て、画像が後から届き、遅れて読み込まれるアイコンがさらに後から乗る、という順に埋まっていきます。そのため記録は候補として複数回届き、どの時点をその部品の揃った時刻と見なすかは書き手が決めます。面積の増加が止まったところを採る、最初の1件だけを採る、利用者の操作が起きるまでを採る。そうした選び方が想定されています。
ブラウザの内側でどう数えているか
実装を担当したIgaliaの技術記事では、既存の仕組みを組み替えて作った経緯が説明されています。Blinkの描画処理には、いちばん大きな内容の描画時間や要素単位の計測のために、文字と画像の描画を検出する部分がすでにあります。新しく描画の追跡を作るのではなく、そこで拾った情報を集約する道を足した、という説明です。
DOMが組み立てられる段階で、containertiming が書かれた要素とその子孫には内部的な目印が立てられます。containertiming-ignore があれば、そこで目印の伝播が止まります。おかげで描画が起きたときに、それが計測対象かどうかを即座に判断でき、対象でない場合の負担はほとんど生じません。対象だった場合は、描かれた要素からDOMを上にたどり、印のついた祖先へ報告が上がっていきます。
面積の集計には、描かれた矩形を重複なく足し合わせる領域計算が使われています。Skiaの領域オブジェクトを流用して、新しい描画のたびに既存の領域との和を取る形です。面積が増えない描画は記録として送られないので、通知の数も抑えられます。計測そのものが重くなっては意味がない、という割り切りが、この辺りの設計に表れているように見えます。
現時点の制約もはっきり書かれています。追跡できるのは文字と画像の描画で、動画やcanvas、SVGはまだ対象外です。Shadow DOMの扱いも初版では見送られており、要素単位の計測での方針が固まってからの検討とされています。深い階層を上にたどる処理の重さも、今後の最適化課題として挙げられています。
どこに印をつけると意味があるか
あらゆる部品に印をつけて回るのは、おそらく得策ではありません。実際の訪問者から計測データを集めている事業者の記事では、利用者の目に入り、かつ商売として意味のある部分から始めるのがよい、という考え方が示されています。売上や離脱に効く場所、先に進めなくなる場所、遅いと苦情の原因になる場所です。
具体例として挙がっているのは、冒頭の主役となる領域、商品のバリエーション選択、購入内容の確認、検索結果の一覧、同意バナー、外部から読み込まれるウィジェットあたりです。とくに同意バナーは、外部の仕組みがブラウザ側で組み立てることが多く、画像も見出しも持たない作りだと要素単位の計測では捉えにくいという事情があります。画面を覆って操作を止めるものなのに、既存の指標には載りにくいわけです。
地方の中小企業のサイトに置き換えるなら、規模は小さくても構図は同じです。トップの主役画像、料金表、予約や問い合わせのフォーム、地図の埋め込み、外部のカレンダー。このうちどれかが遅れて出てくることに心当たりがあるなら、名前をつけて測ってみる価値があります。名前は人間が読んで分かるもので、かつ商品IDのように変動する値は避けるべきだ、とも助言されています。集計したときに散らばってしまうからです。
注意したい点もいくつかあります。印は描画より前に存在していなければならず、後からJavaScriptで属性を足すと、それまでの描画は取りこぼされます。画面の外にある部分は記録されず、後からスクロールして見えても新しい記録が出るとは限らないので、表示領域に入ったかどうかを知る仕組みの代わりにはなりません。読み込み中の骨組み表示を囲みの中に入れたままにすると、その骨組みも描画として数えられます。最終的な中身の側に印をつけ直すか、骨組みを除外するか、集め方を調整するかの判断が要ります。
試験提供という段階の受け止め方
オリジントライアルはChrome 148から始まり、153までの期間が示されています。手元で試すだけなら実験的なウェブプラットフォーム機能の設定を有効にすれば足りますが、実際の訪問者から値を集めたい場合は、サイトごとに発行されるトークンをページに埋め込む必要があります。
このトークンの置き方には、先行して試した事業者がつまずいた落とし穴が紹介されています。ふつうは、機能を使うJavaScriptより前にトークンが読まれていれば動きます。ところがContainer Timingでは、属性そのものも試験提供の対象です。つまりブラウザが最初の containertiming 属性に出くわす前にトークンが読まれている必要があり、計測用スクリプトを描画の妨げにならない形で読み込んでいると間に合いません。結局、サイト側で自分のトークンを登録してもらって初めて値が集まり始めた、という顛末が書かれています。
集めた数値の読み方にも工夫が要ります。ある部品の描画時刻をそのまま見ると、ページ全体の遅れを丸ごとかぶった値になります。たとえば表示の切り替えのために本文全体を数秒隠す仕掛けが入っていれば、その裏で待たされた部品の時刻もそろって遅くなる。それをその部品のせいだと読むのは無理があります。そのため、最初に何かが描画された時刻を引いて差分で見る、という扱い方が採られています。ページが出始めてから、その部品が出るまでに何秒余計にかかったのか。こちらのほうが、直す場所を決めるには役に立ちます。
仕様はまだ動く可能性があり、項目名や細かい挙動が変わることも十分あります。集めた値も、当面は長く追いかける指標ではなく、早い段階の観測データとして扱うのが無難でしょう。それでもこの手の話は、標準になってから慌てて追いかけるより、試験提供のうちに1つか2つ印をつけて眺めておくほうが、広く使えるようになったときの動きが速くなります。属性を書き足すだけで始められるのは、入り口としてはかなり低いほうだと思います。
