標準化された読み込み属性を導入した際の学び
この投稿の目的は、ブラウザレベルの画像遅延読み込み機能のサポートを実装する時期が来ていることを、CMS プラットフォームのデベロッパーとコントリビューター（CMS のコアを開発する人々）に説得することです。また、遅延読み込みを実装しながら、高品質のユーザー エクスペリエンスを確保する方法と、他のデベロッパーによるカスタマイズを可能にする方法についても説明します。これらのガイドラインは、WordPress へのサポート追加の経験と、Joomla、Drupal、TYPO3 でのこの機能の実装を支援した経験に基づいています。
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 にサイズ属性を指定することをおすすめします。すべての要素でこれができない場合は、これらの属性の両方を指定していない画像の遅延読み込みをスキップすることをおすすめします。
折り返しの上の要素を遅延読み込みしない
現時点では、2021 年 7 月に判明したように、Largest Contentful Paint 指標の遅延を回避するため、CMS では、折り返しの下にある画像と iframe にのみ loading="lazy" 属性を追加することをおすすめします。この遅延は、場合によっては大幅になる可能性があります。ただし、レンダリング プロセスの前にビューポートを基準とした要素の位置を評価するのは複雑です。これは、CMS が loading 属性の追加に自動アプローチを使用している場合に特に当てはまりますが、手動による介入に基づいていても、さまざまなビューポート サイズやアスペクト比などの要素を考慮する必要があります。それでも、ヘッダー画像や、スクロールせずに表示される画像や iframe は、遅延読み込みから除外することを強くおすすめします。
JavaScript のフォールバックは避ける
JavaScript を使用して、loading 属性を（まだ）サポートしていないブラウザに遅延読み込みを提供することはできますが、このようなメカニズムでは、常に画像または iframe の src 属性を最初に削除する必要があります。これにより、属性をサポートしているブラウザで遅延が発生します。また、大規模な CMS のフロントエンドにこのような JavaScript ベースのソリューションを導入すると、潜在的な問題の発生範囲が広がります。これは、ブラウザ機能の標準化前に主要な CMS がコアに遅延読み込みを採用しなかった理由の一部です。
技術的な推奨事項
遅延読み込みをデフォルトで有効にする
ブラウザレベルの遅延読み込みを実装する CMS では、デフォルトで有効にすることをおすすめします。つまり、loading="lazy" は画像と iframe に追加する必要があります。サイズ属性を含む要素にのみ追加することをおすすめします。この機能をデフォルトで有効にすると、イメージごとに手動で有効にする場合よりもネットワーク リソースを大幅に節約できます。
loading="lazy" は、可能な限りスクロールしないと表示されない要素にのみ追加してください。クライアントサイドの認識が不足しているため、さまざまなビューポート サイズに対応した CMS でこの要件を実装するのは複雑ですが、少なくとも近似ヒューリスティクスを使用して、折り返しの上に表示される可能性があるヘッダー画像などの要素を遅延読み込みから除外することをおすすめします。
要素ごとの変更を許可する
loading="lazy" はデフォルトで画像と iframe に追加する必要がありますが、LCP を最適化するために特定の画像で属性を省略できるようにすることが重要です。CMS のユーザーが平均して技術に精通している場合は、画像や iframe ごとに公開される UI コントロールで、その要素の遅延読み込みをオプトアウトできます。または、API をサードパーティのデベロッパーに公開して、コードで同様の変更を加えることもできます。
たとえば WordPress では、HTML タグまたはコンテキスト全体またはコンテンツ内の特定の HTML 要素に対して loading 属性をスキップできます。
既存のコンテンツを改造する
大まかに言うと、CMS の HTML 要素に loading 属性を追加する方法は 2 つあります。
- バックエンドのコンテンツ エディタ内から属性を追加し、データベースに永続的に保存します。
- フロントエンドでデータベースからコンテンツをレンダリングするときに、属性をその場で追加します。
既存のコンテンツにも遅延読み込みのメリットをもたらすため、CMS ではレンダリング時に属性をその場で追加することをおすすめします。属性をエディタでのみ追加できる場合、そのメリットを受けるのは新しいコンテンツまたは最近変更されたコンテンツのみとなり、ネットワーク リソースの節約に対する CMS の影響が大幅に軽減されます。さらに、属性をその場で追加することで、ブラウザレベルの遅延読み込み機能がさらに拡張された場合に、将来の変更を簡単に行うことができます。
属性をその場で追加する場合は、要素に存在する可能性のある loading 属性を考慮し、そのような属性が優先されるようにする必要があります。これにより、CMS またはその拡張機能は、重複する属性との競合を引き起こすことなく、エディタ主導のアプローチを実装することもできます。
サーバーサイドのパフォーマンスを最適化する
サーバーサイド ミドルウェアなどを使用してコンテンツに loading 属性を動的に追加する場合は、速度を考慮する必要があります。CMS によっては、DOM トラバースまたは正規表現で属性を追加できます。パフォーマンスを重視する場合は、後者をおすすめします。
正規表現の使用は最小限に抑える必要があります。たとえば、コンテンツ内のすべての img タグと iframe タグ（属性を含む）を収集し、必要に応じて各タグ文字列に loading 属性を追加する単一の正規表現などです。たとえば WordPress では、特定の要素に対してさまざまなオンザフライ オペレーションを実行する単一の一般的な正規表現が使用されています。loading="lazy" の追加は、単一の正規表現を使用して複数の機能を容易にするための 1 つの例にすぎません。また、この形式の最適化は、拡張機能ではなく CMS のコアに遅延読み込みを採用することをおすすめするもう 1 つの理由です。これにより、サーバーサイドのパフォーマンスの最適化が容易になります。
次のステップ
CMS で機能のサポートを追加するための既存の機能リクエスト チケットがあるかどうかを確認します。まだない場合は、新しいチケットを作成します。必要に応じて、この投稿を参照して提案を裏付けてください。
ご質問やコメントがある場合、またはブラウザレベルの遅延読み込みのサポートが追加された CMS をこのページに掲載したい場合は、私（felixarntz@）にツイートしてください。他にも問題が発生した場合は、解決策を見つけられるよう、詳細をお知らせください。
CMS プラットフォームのデベロッパーは、他の CMS で遅延読み込みを実装している方法を確認してください。
調査で得た知見と、この投稿の技術的な推奨事項を使用して、パッチやプルリクエストなどの形で CMS にコードをコントリビュートできます。
ヒーロー写真は、Unsplash の Colin Watts によるものです。