IntersectionObserverは遅延読み込みを足す前に読者が最初に見る内容を分ける

IntersectionObserverで遅延読み込みを始めるなら、先に読者がpageを開いた直後に必要な内容を決めます。画面の下にある画像や補足を後から読み込むことはできますが、pageの結論、申込みの条件、現在の営業時間のように最初から読める必要がある情報まで待たせません。速くするためのscriptと、読者へ必ず渡す内容を別にします。

W3Cは9月14日、Intersection Observerの最初の公開Working Draftを出しました。このAPIは、DOM elementがviewportまたは指定したrootとどの程度重なるかを、非同期で受け取る仕組みです。画面へ近づいた画像や追加contentを読み込む用途に使えます。ただし、Working DraftのAPIを入れることと、全ての利用者へ同じように内容を渡せることは別です。

先に見せる内容と待たせてもよい内容を分ける

遅延読み込みの対象は、重いfileなら何でもよいわけではありません。最初の画面に出るmain image、pageの見出し、価格や受付条件、問い合わせbuttonを後回しにすると、読者は何のpageか分からないまま待つことになります。画像が大きいからという理由だけで、topの案内まで遅らせません。

たとえば、施工例を並べるpageを考えます。最初に読者へ伝えるのは、何の施工を扱うか、依頼できる地域、問い合わせや見積りの入口です。施工写真が数十枚あり、下の方まで一度に読み込む必要がないなら、後ろの写真を遅らせる候補になります。しかし、写真だけで施工内容を説明しているなら、画像が出るまで本文の意味が分かりません。画像を待たせる前に、captionや本文で何を示しているかを読めるようにします。

記事一覧でも同じです。最初の数件にtitle、日付、要約、linkがあり、さらに下に多くの記事が続く場合、下の画像や補足を後から扱う方法を検討できます。一方で、記事のtitleそのものをscriptが動いた後に作る設計なら、scriptが使えないと一覧の内容が伝わりません。遅延読み込みは、読者へ必要な情報を減らす方法ではありません。

対象を決めるときは、pageを開いた直後、少しscrollした位置、最後まで読んだ位置を分けます。最初の画面で必要なimage、本文、linkは通常どおり出します。読者がscrollして初めて必要になる写真、動画のpreview、追加の推薦記事は、後から出す候補になります。pageの種類ごとに同じ基準を当てはめず、読者が最初に何を判断するかで決めます。

viewportとrootは読む場所の違いで決める

IntersectionObserverは、見ている対象がどこへ入ったかを判定します。page全体をscrollする普通の画面なら、viewportを基準に考えます。長い一覧の中に、独立してscrollするboxがあるなら、そのboxをrootにする場面があります。どちらを使うかは、codeの書きやすさでなく、読者が実際にどの領域を動かして内容を見るかで決めます。

説明用の仮例として、商品比較表の横にscrollできる写真一覧がある場合を考えます。page全体のviewportだけを基準にすると、一覧のboxが画面内にあるだけで、まだ読者が見ていない写真まで読み込むことがあります。写真一覧のscrollするboxをrootとして考えれば、boxの中で写真が近づいたときに扱えます。反対に、rootを細かく分けすぎると、後からどの要素が何を基準にしているか分かりにくくなります。

rootMarginは、rootの周囲へ余白を加えて判定するための設定です。読者が写真へ到達する少し前に読み込みを始めたい場合に使えます。余白を大きくすれば早く読み始められますが、pageを開いた直後に多くのfileを読めば、遅延読み込みの意味が薄くなります。余白を小さくしすぎれば、読者がscrollした後に画像の空白を見ることがあります。最初から大きな数値を決めず、実際の画面幅と画像の大きさを見ます。

thresholdは、対象とrootがどの程度重なったときに通知を受けるかを考えるための値です。画像を読み始めるだけなら、細かい段階を多く用意する必要がない場合があります。一方で、表示の割合に応じて別の案内を替えるなら、どの割合が読者にとって意味を持つかを決めます。要素が少し見えたことと、内容を十分に読んだことは同じではありません。表示の割合を数えることだけを目的に、複雑な設定を足しません。

scriptが動かない状態でも案内を残す

IntersectionObserverはbrowser上のJavaScriptで動きます。対象のbrowserがAPIを使えるか、scriptの読み込みに失敗したときに何が見えるかは、別に確認します。遅延読み込みの仕組みが動かなければ、文章、画像の代替文、link先、問い合わせの入口まで消える設計にしません。

画像を後から読み込む場合でも、画像が何を示すかをaltやcaptionで伝えます。写真が出ないと説明が成立しないなら、最初から画像を読ませるか、本文へ説明を置くかを決めます。JavaScriptが動かない画面を「古い環境だから仕方がない」として終わらせず、その環境でも事業の案内と連絡先が読めるかを確認します。

WordPressで使う場合は、theme、plugin、投稿本文のどこがscriptと画像の属性を出すかを調べます。themeが記事一覧の画像を出し、pluginが遅延読み込みを加え、投稿者が本文へ画像を置く構成なら、変更場所は一つではありません。pluginを入れることと、どの画像が後から読まれるかを理解することは別です。更新後に画像が出ない場合、誰がtheme、plugin、本文、serverのどこを確認するかを決めます。

読者の画面で表示時刻と内容を確認する

遅延読み込みの確認は、開発者用の画面だけで終わりません。広い画面とsmall screenでpageを開き、最初の案内がすぐ読めるか、scrollすると画像や補足が必要な順に現れるかを見ます。通信が遅い状態でも、読者が何をすればよいか分かるかを確認します。画像が遅れて出ても、表示の位置が急に動き、読んでいた本文を見失うなら、読者にとって便利とは言えません。

公開前には、対象pageを一つずつ選びます。top page、記事一覧、記事本文、商品やserviceの説明、問い合わせpageでは、最初に見せる情報が違います。全pageへ同じscriptを入れてから問題を探すより、写真が多いpageから小さく試します。変更前後で、何を読み込む時刻を変えたか、どの画面で確認したか、戻す方法を記録します。

制作会社へ依頼するなら、「画像をlazy loadにしてください」とだけ頼みません。遅らせる画像、最初から出す画像、対象page、対応するbrowser、確認する画面、問題が出たときの戻し方を渡します。制作側は、scriptを置いた場所、変更したtemplateやplugin、確認した画面を返します。実装を任せても、掲載する写真と読者へ最初に伝える内容を決める責任は事業側に残ります。

最初の一手は、一つのpageを開き、読者がscrollしなくても読むべき内容に印を付けることです。次に、その下で初めて必要になる画像や補足を選びます。IntersectionObserverは、要素の位置を知るためのAPIです。pageを軽くする目的は、読者へ必要な内容を遅らせることではなく、必要な順に読める状態を作ることです。