SEO向きLazyload画像に関するTIPS×2

[レベル: 上級]

検索エンジン向けの Lazyload の推奨を Google は先日公開しました。
この推奨に関して、2つの補足をこの記事では紹介します。

1. polyfill は重要

ドキュメントでは、IntersectionObserver API と polyfill の2つの技術を実装するように Google は指示しています。
「SEO」という観点では、polyfill が非常に重要です。

現在の WRS(Web Rendring Service、Google 検索のレンダリングシステム)は、Chrome 41 相当です。
IntersectionObserver API は Chrome 51 からサポートされました。
したがって、IntersectionObserver API で遅延読み込みさせる画像を Google は認識できません。

そこで、polyfill が重要になってきます。

新しい技術をサポートしないブラウザのでも、その機能を利用できるようにするための仕組みが polyfill です。
polyfill によって、IntersectionObserver API をサポートしない Googlebot/WRS にも画像を認識させることができます。

ユーザーが使っているブラウザには IntersectionObserver API で Lazyload を適用して画像を遅延読込みさせてパフォーマンスを向上します。
一方、Googlebot には polyfill で最初からすべての画像を認識させます。

polyfill なしでは検索エンジンフレンドリーにはならないので注意してください。

Google が提供するスクリプトを利用して、ドキュメントの仕様に従った Lazyload が期待どおりに機能するかどうかを検証してくれた方がいました。
うまく機能したそうなので、参考にしてみてください。

構造化データと noscript も併用

ドキュメントが公開される以前は、Lazyload の画像を Google にインデックスさせるために次の2つの構成を Google は勧めていました

  • <noscript> タグ
  • 構造化データ

IntersectionObserver API と polyfill を実装して Lazyload で画像配信していれば、これらはもはや不要なのでしょうか?

そんなことはないようです。
noscript/構造化データも併用したほうがより確実です。

(IntersectionObserver API と polyfillを使う)仕様の策定に関わった Martin Splitt(マーティン・スプリット)氏に Chrome Dev Summit 2018 の際に確認してきました。
ドキュメントを今後更新するときにはこういったことにも触れたいとのことでした。

現在 Google は、WRS のアップデートに取り組んでいます。
最新の Chrome と同等の性能を WRS が常に保てるようになれば、面倒な手間がだいぶ省けるのではないでしょうか。
それまでは、推奨構成に忠実に従う必要があります。