このページは Cloud Translation API によって翻訳されました。

CMS 向けのブラウザレベルの遅延読み込み

標準化された読み込み属性を導入するための教訓

Felix Arntz

この投稿の目標は、CMS プラットフォームのデベロッパーとコントリビューター（CMS コアの開発担当者）に、今こそブラウザレベルの画像遅延読み込み機能のサポートを実装するときを説得することです。また、遅延読み込みを実装する際に高品質のユーザーエクスペリエンスを確保し、他のデベロッパーがカスタマイズできるようにするためのおすすめの方法も紹介します。これらのガイドラインは、WordPress にサポートを追加し、Joomla、Drupal、TYPO3 で機能を実装できるように Google の経験に基づいています。

CMS プラットフォームのデベロッパーか CMS ユーザー（CMS を使用してウェブサイトを構築する担当者）かを問わず、この投稿を参照して、CMS におけるブラウザレベルの遅延読み込みのメリットについて詳しく説明しています。CMS プラットフォームに遅延読み込みを実装するおすすめの方法については、次のステップセクションをご覧ください。

背景

過去 1 年間で、loading 属性を使用した画像や iframe の遅延読み込みは、WHATWG HTML 標準の一部となり、さまざまなブラウザで採用が進んでいます。しかしながら、今回のマイルストーンは、より高速で、よりリソースを節約するウェブの土台となるものです。現在は、分散型ウェブエコシステムで loading 属性を利用しています。

コンテンツマネジメントシステムはウェブサイトの約 60% を支えており、これらのプラットフォームは最新のブラウザ機能をウェブに導入するうえで重要な役割を果たしています。WordPress、Joomla、TYPO3 などの一般的なオープンソース CMS にはすでに画像の loading 属性のサポートが実装されていますが、これらのアプローチと、他の CMS プラットフォームにこの機能を導入する際に役立つ要点を見ていきましょう。メディアの遅延読み込みは、サイトが大規模に活用できる重要なウェブパフォーマンス機能です。そのため、CMS コアレベルに導入することをおすすめします。

遅延読み込みを実装するケース

標準化

CMS に標準化されていないブラウザ機能を導入すると、広範なテストが可能になり、改善の余地がある領域を特定できます。ただし、ブラウザ機能が標準化されていない限り、各プラットフォームの拡張機能またはプラグインの形で実装することが望ましい、という CMS 間の一般的なコンセンサスがあります。標準化された場合にのみ、機能をプラットフォームコアへの導入を検討できます。

ブラウザサポート

ブラウザによるこの機能のサポートについても同様に懸念があります。CMS ユーザーの大部分がこの機能の恩恵を受けることができます。この機能がまだサポートされていないブラウザが相当数に上る場合、少なくともその機能に悪影響を及ぼさないように、機能を確認する必要があります。

ビューポートからの距離のしきい値

遅延読み込みの実装に関する一般的な懸念は、読み込みサイクルが後の段階で開始されるため、ユーザーのビューポートに表示されると、原則として画像が読み込まれない可能性が高くなることです。以前の JavaScript ベースのソリューションとは対照的に、ブラウザは控えめなアプローチを取っており、実際のユーザーエクスペリエンスデータに基づいて微調整することで影響を最小限に抑えられるため、CMS プラットフォームではブラウザレベルの遅延読み込みを安全に導入できる必要があります。

ユーザーエクスペリエンスに関する推奨事項

要素の寸法属性を要求する

レイアウトシフトを回避するため、画像や iframe などの埋め込みコンテンツには常にサイズ属性 width および height を含めることが、以前から推奨されてきました。これにより、ブラウザが実際に要素を読み込む前に、これらの要素のアスペクト比を推測できます。この推奨事項は、要素が遅延読み込みされるかどうかに関係なく該当します。ただし、一度ビューポートに画像が完全に読み込まれない可能性は 0.1% 高いため、遅延読み込みを設定すると、その可能性は若干高くなります。

CMS では、すべての画像と iframe にサイズ属性を指定することをおすすめします。そのようなすべての要素で遅延読み込みを行えない場合は、両方の属性を提供していない画像の遅延読み込みをスキップすることをおすすめします。

注意: CMS が画像や iframe に対して width 属性と height 属性を大規模に提供できない場合、ネットワークリソースを追加で節約することと、レイアウトシフトが発生する可能性を少し高めることとのトレードオフを比較して、遅延読み込みの価値を判断する必要があります。

スクロールせずに見える範囲の要素の遅延読み込みを避ける

現時点では、Largest Contentful Paint 指標（2021 年 7 月に発見されている重要な指標）の遅延を避けるために、CMS ではスクロールしなければ見えない位置にある画像と iframe にのみ loading="lazy" 属性を追加することをおすすめします。ただし、レンダリングプロセスの前に、ビューポートに対する要素の位置を評価するのは複雑な作業であることを認識しておく必要があります。これは、CMS が loading 属性を自動的に追加する自動アプローチを使用している場合に特に当てはまります。ただし、手動による操作であっても、ビューポートのサイズやアスペクト比の違いなど、いくつかの要因を考慮する必要があります。それでも、ヒーロー画像のほか、スクロールせずに見える範囲に表示される可能性が高いその他の画像や iframe は遅延読み込みを行わないことを強くおすすめします。

注: CMS の機能と対象ユーザーに応じて、画像または iframe が最初のビューポートに配置される可能性があるかどうかについて妥当な推定を定義するようにしてください。たとえば、ヘッダーテンプレートやメインコンテンツのヒーロー画像で要素の遅延読み込みを行わないようにします。さらに、要素の loading 属性の存在を変更できる UI または API を提供します。

JavaScript のフォールバックを避ける

JavaScript を使用して、loading 属性をまだサポートしていないブラウザに遅延読み込みを提供することもできますが、このような仕組みでは必ず最初に画像または iframe の src 属性を削除することに依存します。そのため、この属性をサポートしているブラウザでは遅延が発生します。さらに、このような JavaScript ベースのソリューションを大規模な CMS のフロントエンドに展開すると、潜在的な問題が生じる領域が増加します。これは、標準化されたブラウザ機能以前は主要な CMS がコアに遅延読み込みを採用していなかった理由の一つです。

注意: CMS で JavaScript ベースの代替手段を用意することは避けてください。loading 属性の導入が進み、まだサポートされていないブラウザバージョンへの悪影響がないため、そうしたブラウザにはこの機能を提供せず、新しいバージョンのブラウザへの更新を推奨する方が安全です。

技術的な推奨事項

遅延読み込みをデフォルトで有効にする

ブラウザレベルの遅延読み込みを実装する CMS については、全体的に、デフォルトで有効にすることを推奨します。つまり、loading="lazy" は画像と iframe に追加する必要があり、可能であればディメンション属性を含む要素にのみ追加します。この機能をデフォルトで有効にすると、イメージごとに手動で有効にする場合よりも、ネットワークリソースを大幅に節約できます。

loading="lazy" は、可能な限り、スクロールしなければ見えない範囲に表示される可能性が高い要素にのみ追加します。クライアントサイドでの認識の欠如とさまざまなビューポートサイズにより、CMS へのこの要件の実装は複雑になる可能性がありますが、少なくとも近似ヒューリスティックを使用して、スクロールせずに見える範囲に表示される可能性が高いヒーロー画像などの要素を遅延読み込みから除外することをおすすめします。

要素ごとの変更を許可する

loading="lazy" はデフォルトで画像や iframe に追加する必要がありますが、LCP 向けに最適化するなど、特定の画像の属性を省略できるようにすることが重要です。CMS のユーザーが平均してテクノロジーに精通していると判断すれば、すべての画像と iframe で UI コントロールを公開することで、その要素の遅延読み込みを無効にできます。または、API をサードパーティデベロッパーに公開し、コードを使用して同様の変更を行うこともできます。

たとえば、WordPress では、HTML タグまたはコンテキスト全体、またはコンテンツ内の特定の HTML 要素で、loading 属性をスキップできます。

注意: 要素を遅延読み込みすべきでない場合は、loading 属性を完全にスキップするよう要求するか、推奨します。サポートされている代替方法として loading="eager" を使用できますが、これは常に画像をすぐに読み込むようにブラウザに明示的に指示するため、遅延読み込みする要素を自動的に決定するメカニズムとヒューリスティックをブラウザがさらに実装している場合、メリットが生じる可能性があります。

既存のコンテンツをレトロフィットする

loading 属性を CMS の HTML 要素に追加するアプローチは、大きく分けて次の 2 つです。

バックエンドのコンテンツエディタ内から属性を追加し、データベースに永続的に保存する。
フロントエンドでデータベースからコンテンツをレンダリングするときに、その場で属性を追加します。

遅延読み込みのメリットを既存のコンテンツにもたらすため、CMS では、レンダリング時にその場で属性を追加するよう選択することをおすすめします。この属性をエディタからのみ追加できれば、新しいコンテンツや最近変更されたコンテンツのみにメリットがもたらされるため、ネットワークリソースの節約に対する CMS の影響が大幅に軽減されます。さらに、この属性をその場で追加することで、ブラウザレベルの遅延読み込み機能がさらに拡張された場合に、将来の変更を容易に行うことができます。

ただし、その場で属性を追加すると、要素に存在している可能性がある loading 属性に対応し、そのような属性が優先されます。これにより、CMS またはその拡張機能でも、重複する属性との競合を発生させることなく、エディタ主導のアプローチを実装できます。

サーバーサイドのパフォーマンスを最適化する

サーバー側ミドルウェアなどを使用して、loading 属性をその場でコンテンツに追加する場合は、速度が重要になります。CMS によっては、DOM トラバーサルまたは正規表現のいずれかを使用して属性を追加できます。パフォーマンスを向上させるには、後者を使用することをおすすめします。

正規表現の使用は最小限にとどめる必要があります。たとえば、コンテンツ内のすべての img タグと iframe タグ（その属性を含む）を収集し、必要に応じて各タグ文字列に loading 属性を追加する 1 つの正規表現などです。たとえば WordPress では、特定の要素に対してさまざまなオンザフライオペレーションを実行する 1 つの汎用正規表現がありますが、loading="lazy" の追加は 1 つにすぎず、1 つの正規表現を使用して複数の機能を容易にします。この最適化形式は、拡張機能よりも CMS のコアで遅延読み込みを採用する方が推奨されるもう 1 つの理由です。遅延読み込みを採用することで、サーバーサイドのパフォーマンスの最適化が向上します。

次のステップ

CMS でその機能のサポートを追加するための既存の機能リクエストチケットがあるかどうかを確認します。まだない場合は新しいチケットをオープンします。提案の裏付けとして、必要に応じてこの投稿への参照を使用してください。

ご質問やご意見は、こちら（felixarntz@）までお寄せください。また、ブラウザレベルの遅延読み込みのサポートが追加された場合には、ご使用の CMS をこのページに掲載していただきます。また、他の課題に直面した場合は、解決策を見つけるために、その課題について詳しく知りたいと思っています。

CMS プラットフォームのデベロッパーは、他の CMS での遅延読み込みの実装方法を確認してください。

調査から得た教訓と、この投稿の技術的な推奨事項を活用して、パッチや pull リクエストなどの形で、CMS へのコードの投稿を開始できます。

ヒーロー写真（投稿: Colin Watts、Unsplash）