[レベル: 上級]
ファーストビューに掲載されている画像を Lazy-load（遅延読み込み）すると コア ウェブ バイタル の 1 指標である LCP を低下させる恐れがあります。
そのため WordPress は、ファーストビューの画像にネイティブ Lazy-load を適用しないように改善する予定です。
ネイティブ Lazy-load は、画像の <img> タグに loading="lazy" 属性を付けることで、ブラウザの機能として遅延読み込みを実現する技術です。
現在は、Chrome や Edge、Firefox など多くのブラウザがサポートしています。
ファーストビュー画像を遅延読み込みさせた WP は LCP が悪化
Lazy-load の利点は、スクリーン領域に入っていない画像を読み込ませないことでデータの転送量を抑えられることです。
スクリーン領域に近づいたところで初めて画像の読み込みを始めます。
結果として、ページの表示速度が速くなります。
ところが、ファーストビューにある画像はページを表示するのと同時に読み込ませても普通は問題ありません。
むしろ、すぐに読み込ませないと画像の表示が通常よりも遅くなるかもしれません。
※すずき補足: 「ファーストビュー」は画面をスクロールせずに、最初から見えている領域のこと。ファーストビューは和製英語で、英語では “Above the fold”（アバブ・ザ・フォールド）と言う。対して、Above the fold よりも下の領域を “Below the fold”（ビロウ・ザ・フォールド ）と言う。
WordPress はバージョン 5.5 からデフォルトでネイティブ Lazy-load を実装しました。
何もしなくても、WordPress の標準機能として、<img> タグに loading="lazy" を自動で追加します（width/height 属性が設定されていることが条件）。
ネイティブ Lazy-load の自動設定はすばらしい機能なのですが、落とし穴がありました。
すべての画像を WordPress は遅延読み込みの対象にしてしまいます。
ファーストビューの画像も例外ではありません。
最初から読み込むべき画像まで遅延読み込みの対象にしてしまうことで、結果的に LCP が悪化するケースが出てきたのです。
たとえば、記事の最初に大きなアイキャッチ画像を掲載している WordPress サイトがたくさんあります。
その画像が、ページで最も大きなコンテンツとして判定された場合は LCP はその画像に対して計測されます。
つまり、すぐに読み込ませるべき画像が遅延読み込みの対象になってしまい LCP が遅くなってしまうのです。
WP 5.9 では 2 番目の画像からネイティブ Lazy-load を適用
そこで WordPress 5.9 では、2 番目の画像からネイティブ Lazy-load を適用するように改良を予定しています。
ネイティブ Lazy-load 適用に関してどのように改良すべきかを WordPress の開発元が検証しました。
- ネイティブ Lazy-load の実装をやめる
- 1 つ目の画像をネイティブ Lazy-load の適用対象から外す
- 2 つ目の画像までをネイティブ Lazy-load の適用対象から外す
これらのパターンの検証結果から、ネイティブ Lazy-load のメリットを享受しつつ LCP にも悪影響を与えないのが、1 つ目の画像を除外する構成だったのです。
現時点の WordPress の最新バージョンは 5.8 です。
自動でのネイティブ Lazy-load のままだと、LCP が悪くなっている可能性があります。
5.9 では改善されることでしょう。
WordPress 5.9 は 2021 年 12 月にリリース予定です。
※すずき補足: ここで説明した WordPress のネイティブ Lazy-load の改良は <iframe> タグにも適用されます。
サイトの状況に合わせて loading 属性の値を指定する
説明したように、WordPress 5.9 では、1 つ目の画像を一律にネイティブ Lazy-load の対象から除外します。
しかしながら、1 つ目の画像が必ずしもファーストビュー (Above the fold) にあるとは限りません。
ひょっとしたら、Below the fold にあるかもしれません。
逆に、2 つ目の画像もファーストビューにあるかもしれません。
画像がどの場所に位置するかは、コンテンツの構成と何よりも利用しているテーマに依存します。
同じコンテンツでも、テーマを変更したら、ファーストビューから Belew the fold に画像が移動するかもしれません。
あるいは反対に、Belew the fold からファーストビューに移動するかもしれません。
また、WordPress は サーバー側で loading 属性を追加します。
デバイスのビューポート（スクリーンのサイズ）がどうなっているのか判明する前の段階です。
そのデバイスで画像がビューポートに入っているのか入っていないのかを知ることなしに画像を配信します（あるいは Lazy-load で配信しない）。
理想的なのは、テーマに応じてネイティブ Lazy-load を適用するかしないかを判断することです。
さらに、デバイスの状況に合わせることも必要です。
ですが、多種多様なテーマがあるなか WordPress 側ですべてのテーマに合わせることはできません。
それに仕様上、ビューポートに合わせることも不可能です。
実際には、WordPress のネイティブ Lazy-load を最適化するにはサイト側での調整が必要です。
状況に応じてネイティブ Lazy-load を使い分けたいのであれば loading 属性の値を明示することを提案します。
次のどちらかの loading 属性を自分で設定します。
loading="lazy": 遅延読み込みの対象にするloading="eager": 遅延読み込みさせずにすぐに読み込ませる
たとえば、1 つめの画像であってもページのずっと下の方にあるなら、loading="lazy" を自分で追加しておけばネイティブ Lazy-load が適用されます。
2 つ目の画像であってもファーストビュー（の近く）にあるなら、loading="eager" を追加しておけば遅延読み込みされずにすぐに読み込みが始まります。
loading を自分で追加しておいた場合、WordPress の自動ネイティブ Lazy-load 機能はそれを上書きしません（明示した指定が優先される）。
現状の WordPress 5.8（以前）であっても、ファーストビューの画像に loading="eager" を追加すれば、すぐに読み込まれるので LCP が改善するかもしれません。
5.9 のリリースまで待てないというのなら、今の時点でファーストビュー画像に loading="eager" を付けてもいいでしょう。
なお WordPress を利用していないサイトでも、ファーストビューの画像に loading="lazy" を設定すると同じように LCP が悪化することがありえます。
注意してください。
WordPress のネイティブ Lazy-load の改良および Lazy-load が LCP に悪影響を与える状況についての詳しい情報は次の記事で読めます。