画像の遅延読み込みでおなじみの loading=”lazy” が、video要素と audio要素でも使えるようになった。要素にこの属性を書き足すだけで、ページを開いた瞬間ではなく、その要素が画面に近づいたタイミングまで読み込みを後回しにできる。Chrome 148 で標準の挙動として全プラットフォームに行き渡り、特別な準備なしにそのまま動くようになっている。

面白いのは、後回しになる対象が動画本体のデータだけではない点だ。ポスター画像やメタデータの取得、それに autoplay の再生開始まで、要素が表示領域に入る手前まで待つ。これまでも preload=”none” やメタデータのみの指定で動画データの通信量はある程度抑えられたが、ポスター画像の取得まで含めて遅らせられるのは新しい。書き方は img要素や iframe要素の loading=”lazy” とまったく同じで、WHATWG の仕様に沿った標準の動きとして扱われる。特別なライブラリを読み込む必要はなく、既存のマークアップに一語足すだけで完結する手軽さがある。

実務でうれしいのは、専用の JavaScript を用意しなくてよくなることだ。従来はページ下部に並ぶ動画を遅らせるために、IntersectionObserver で表示位置を監視する自前のコードを書くのが定番だった。その方法だと、スクリプトが動くタイミングとブラウザ内部の読み込みスケジュールが微妙にずれて、境目でのちらつきや二重の読み込みに気を配る必要がある。属性ひとつに任せれば、こうした細かな調整から解放される。preload 属性の指定自体はこれまでどおり効くが、その判断が要素の表示まで遅れる、と理解しておけばよい。

ひとつ気を配りたいのは、レイアウトのずれだ。メタデータの取得が後回しになると、動画の縦横比が分かるのも遅れるため、読み込みの瞬間に高さが変わって周囲がガタつくことがある。video要素に width と height を指定しておくか、CSS の aspect-ratio で先に場所を確保しておけば、この飛び跳ねは避けられる。遅延読み込みと表示の安定は、セットで考えると気持ちよく収まる。

使いどころも選びたい。ページを開いてすぐ目に入る主役の動画に付けると、かえって表示が一拍遅れて見えることがある。向いているのは、スクロールした先に置いた紹介動画や、複数の音声サンプルを並べたページなど、最初の画面には映らない要素だ。折り返しより下にあるものを選んで付ける、という素直な使い分けでよい。

対応はまず Chrome 系が先行し、ほかのブラウザは順次追随していく段階にある。とはいえ非対応のブラウザでは属性が無視されて従来どおり読み込まれるだけなので、progressive enhancement として今から書き足しておいて困ることはない。動画を多く載せる商品紹介ページやサービスサイトで、最初の表示を軽くするための一行として頭の隅に置いておきたい。細かな挙動はweb.devの解説にまとまっている。