遅いヒーロー画像の修正と Core Web Vitals の改善

遅いヒーロー画像の修正方法 - 要約

ヒーロー画像はウェブページの上部にある大きな画像です。ヒーロー画像が最適化されていない場合、Largest Contentful Paint が長くなります。 最適化を依頼されるサイトの10件中9件は、ヒーロー画像に問題を抱えています。 この記事では、ヒーロー画像を高速化するためのさまざまなテクニックを紹介します。

ヒーロー画像とは？

ヒーロー画像は「ヒーローヘッダー」とも呼ばれ、テキストを伴う大きな画像で、ウェブページの上部に配置されることが多いです。ヒーロー画像は通常全幅に広がるウェブページの上部に目立つように配置されるため、企業やサービスに対するユーザーの第一印象となります。

おさらい：ヒーロー画像、Core Web Vitals、Largest Contentful Paint

ヒーロー画像のサイズ（通常、ページの全幅とビューポートの高さの大部分を占める）により、ほぼすべてのケースでこの要素が Largest Contentful Paint 要素となります。

Largest Contentful Paint は重要な Core Web Vitals の指標です。Largest Contentful Paint 要素は、ブラウザの可視ビューポートに描画される最大の要素です。

最適化されていない画像は多くの帯域幅を消費し、読み込みに長い時間がかかるため、ヒーロー画像は Largest Contentful Paint の指標を悪化させることが多いです。

ヒーロー画像と Largest Contentful Paint の最適化

ヒーロー画像と Largest Contentful Paint を最適化するためのテクニックは数多くあります。ここではそれらを解説します。ほとんどのテクニックは組み合わせることで、さらに良い結果を得ることができます！

1 ヒーロー画像をプリロードするか、103ヘッダーを送信する

ブラウザでできるだけ早く要素を利用可能にしたい場合、その要素をプリロードすることができます。プリロードにはリソースヒントの使用が含まれます。リソースヒントは要素の優先度についてブラウザに通知し、そのリソースの非常に早いダウンロードをトリガーします。

<link 
  rel="preload" 
  as="image" 
  href="wolf.jpg" 
  imagesrcset="hero_400px.jpg 400w, hero.jpg 800w, hero_1600px.jpg 1600w" 
  imagesizes="50vw">

近い将来、103 Early Hints が Chrome ブラウザでサポートされる予定です。これにより、最終的な HTML レスポンスが送信される前にリソースヒントを送信することが可能になります。103 Early Hints は Largest Contentful Paint の改善において画期的な技術となることが期待されています。Early Resource Hints に興味がある方は、こちらの記事をご覧ください。

2 ヒーロー画像を圧縮し、次世代フォーマットを使用する

画像を圧縮するとファイルサイズが小さくなります。ファイルサイズが小さくなると帯域幅の消費が減り、ブラウザでできるだけ早く利用可能になります。画像の圧縮は、フォトエディタ、CMS（ヒント：開発者が WordPress の圧縮レベルを設定できます）、またはオンライン画像圧縮ツールで行えます。

遅いヒーロー画像のほとんどは、PNG や JPEG のような「間違った」画像フォーマットで配信されているために必要以上に遅くなっています。JPEG や PNG よりもはるかに高速な WebP や AVIF などの代替フォーマットがあります。 

多くの CMS システムには、画像を次世代フォーマットに変換するプラグインがあります。画像変換をウェブサイトに統合するのが難しい場合、画像変換をサポートする CDN がお求めのソリューションかもしれません。

3. 背景画像を使用せず、通常のレスポンシブ画像を使用する

ヒーロー画像は通常の画像であるべきで、背景画像であってはなりません。ヒーロー画像の一般的な実装方法は、ヒーローコンテナに背景画像を追加し、そのコンテナの background-size を cover に設定することです。これにより、ヒーロー画像がすべてのケースで画面にフィットすることが保証されます。

背景画像は Core Web Vitals に悪影響を与えます。これを覚えておいてください！背景画像を使用する正当な理由はありません。

• 背景画像は低い優先度で読み込まれます
• 背景画像はレスポンシブではありません（本当に複雑にしたい場合を除いて）
• 背景画像はほとんどの遅延読み込みライブラリで Core Web Vitals の問題を引き起こす可能性があります。
  

私のやり方は、absolute ポジションで通常の画像を追加し、その画像の object-fit プロパティを cover に設定することです。 背景画像を通常の画像に変更したら、レスポンシブ画像を使い始めることができます。

レスポンシブ画像とは、異なるデバイス（モバイル、デスクトップ、タブレット）に対して、同じヒーロー画像の異なるバージョンを送信できることを意味します。デスクトップデバイスには 1920x1280 の大きなヒーロー画像を送信する一方、モバイルデバイスには 400×266 ピクセルの小さなヒーロー画像だけを送信すれば済みます。データ量は25分の1です！

• ヒーロー画像がより高い優先度で読み込まれるようになりました
• ヒーロー画像にレスポンシブ画像を使用できるようになりました

style.css

<style>
#herocontainer{
    position:relative;
    padding:4rem 0
}
#heroimg{
    object-fit: cover;
    width: 100%;
    height: 100%;
    position: absolute;
    top: 0;
}
</style>

index.html

<div id="herocontainer">
<h1>Welcome to my site</h1>
<picture>
    <source 
        type="image/webp" 
        media="(max-width:540px)" 
        srcset="herosm.webp">
    </source>
    <img loading="eager" decoding="async" src="hero.webp" id="heroimg">
</picture>
</div>

4. メインドメインからヒーロー画像を配信し、Content Delivery Network（CDN）の利用を検討する

Largest Contentful Paint 画像が「static.mydomain.com」のような別のドメインから配信されているのをよく目にします。これらのサブドメインは通常 CDN を指しています。CDN の使用は推奨しますが（下記参照）、このような設定はお勧めできません。サブドメイン上の画像は新しいサーバーへの新しい接続を必要とします。新しい接続はコストが高く、貴重な時間を消費します。画像がメインドメイン（例えば www.mydomain.com）から配信される場合、すでに確立されたサーバー接続を通じてはるかに高速に画像を取得できます。

メインドメインに設定した場合、CDN は大幅な速度向上を提供する可能性があります。特にサイトが世界中からアクセスされる場合に有効です。CDN は世界中に戦略的に配置されたサーバーを持ち、静的リソース（画像など）がキャッシュされ、高速なローカルレスポンスタイムを実現します。これにより、データが世界中を移動する必要がなく、ローカルのエッジサーバーから配信できます。

5. Largest Contentful Paint 画像の遅延読み込みを避け、ヒーロー画像を明示的に eager-load する

ヒーロー画像に遅延読み込みが適用されていないことを確認してください。ヒーロー画像は常に eager で読み込む必要があります。

多くのサイト、特に WordPress サイトは、WP Rocket や WP Core Web Vitals のような WordPress の速度最適化プラグインを使用しています。これらのプラグインは通常、遅いサイトの高速化において素晴らしい仕事をしますが、愚かなミスは修正できません :-)

これらのプラグインは遅延読み込みの良い候補と思われる画像を遅延読み込みします。ヒーロー画像が eager 画像でない場合、これらのプラグインはヒーロー画像も遅延読み込みしてしまう可能性があります。

これは最良の場合でも LCP 指標にわずかな遅延を引き起こします。最悪の場合、特に JavaScript ベースの遅延読み込みが有効になっている場合、より大きな遅延を引き起こします。

画像を eager で読み込ませるのは非常に簡単です。画像に loading="eager" を追加するだけで完了です。

<img src="hero.webp"  width="800" height="400">

6. ヒーロー画像によるレイアウトシフトを避ける

ヒーローバナーやヒーロー画像でよく見かけるもう一つの問題は、大きなレイアウトシフトを引き起こすことです。これらのレイアウトシフトはさまざまな理由で発生する可能性があります。

• ヒーロー要素が JavaScript で作成されている。一部のヒーロープラグインや Elementor のようなページビルダーは、ヒーローコンテンツのレンダリングに JavaScript に依存することが知られています。JavaScript 自体に問題はありませんが、ヒーロー要素が JavaScript なしでも同じようにレンダリングされることを確認してください。
• ヒーロー要素のフォントがレイアウトシフトを引き起こす。ヒーロー要素には通常、コールトゥアクションやタグラインを含む大きなテキストがあります。これらの大きなフォントがレイアウトシフトを引き起こさないようにしてください。
• 画像のサイズ指定がない。ヒーロー画像がカバー画像でない場合（背景画像または absolute ポジションの画像のいずれでもない場合）、画像のサイズ指定（width と height）がないと確実に大きなレイアウトシフトを引き起こします。

レイアウトシフトの修正は Largest Contentful Paint を改善しませんが、ページの Core Web Vitals を改善します。レイアウトシフトの修正方法の詳細については、こちらの Cumulative Layout Shift の修正に関する詳細ガイドをお読みください！

7. 2段階読み込みでヒーローの Core Web Vitals を改善する

2段階読み込みは、すべての画像に適用している高速なテクニックです。まず、高画質画像よりもはるかに早くダウンロードされることが期待される非常に低画質の画像を配信します。 低画質画像が画面に描画されると、ブラウザはバックグラウンドで高画質画像を取得するようトリガーされます。高画質画像がダウンロードされると、低画質画像は高画質画像に置き換えられます。

2段階読み込みには3つの方法があります。最初の2つは検討すべき方法です。最後の1つはやるべきではない方法です。

1. 完全な2段階読み込み

完全な2段階読み込みでは、最初の低画質画像は元の高画質画像とまったく同じサイズ（width と height）を持ちます。

この2段階読み込みの結果、Largest Contentful Paint 要素ははるかに高速な低画質画像になります（その後遅延的にスワップされます）。画像のスワップは非常に速く行われるため、一般的な訪問者はおそらく気づかないでしょう。このテクニックの結果、LCP がはるかに早く描画され、ページが早く「準備完了」に見え、はるかに優れた user experience と Core Web Vitals の改善に貢献します。

2. より小さなインラインプレースホルダー

小さなプレースホルダーは非常に優れたテクニックですが、1つの欠点があります：Core Web Vitals を改善しないことです。それでも user experience を改善するため、優れたテクニックです。

基本的な考え方は2段階読み込みテクニックと同じですが、同じサイズの低画質画像の代わりに、はるかに小さいサイズの画像が data URI を通じてインラインに配置されます。最終的なヒーロー画像（Largest Contentful Paint 画像となる）はバックグラウンドでダウンロードされます。このトリックは Largest Contentful Paint を改善しませんが、2段階読み込みテクニックよりもさらに速くページが準備完了に見えるようにします。

3. 透明なプレースホルダー

一般的な2段階読み込みテクニックであり、ブラウザに早い Largest Contentful Paint メトリクスを送信させるトリックは、透明な SVG 要素を使用することです。これらの要素は小さく、小さなインラインプレースホルダーと同様にインラインに配置できます。

インライン SVG 要素を使用してスワップすることは、実際には遅延読み込みテクニックです。このテクニックの利点は、クロスブラウザで動作することです。 

遅延読み込みは、もちろんビューポート外の要素にのみ適用すべきです。この場合、透明な SVG 要素は実際のヒーロー画像を遅延させるだけで、訪問者にとって付加価値はありません。ペイント指標は良好かもしれませんが、ページの UX は実際には悪化します。

だからこそ、ヒーロー画像は常に UX を悪化させるトリックなしで eager に読み込むべきです。