ウェブに関する指標用の CSS

ウェブに関する指標を最適化するための CSS 関連の手法

Katie Hempenius 氏
Katie Hempenius
X
ウナ・クラベツ

スタイルの記述方法とレイアウトの作成方法は、Core Web Vitals に大きな影響を与える可能性があります。これは、Cumulative Layout Shift（CLS）と Largest Contentful Paint（LCP）に特に当てはまります。

この記事では、ウェブに関する指標を最適化するための CSS 関連の手法について説明します。こうした最適化は、ページのさまざまな要素（レイアウト、画像、フォント、アニメーション、読み込み）ごとに分けて行われます。その過程で、サンプルページを改良します。

サンプルサイトのスクリーンショット

レイアウト

DOM へのコンテンツの挿入

周囲のコンテンツがすでに読み込まれてからページにコンテンツを挿入すると、ページ上の他のものがすべて押し下げられます。これによりレイアウト シフトが発生します。

この問題の一般的な例として、Cookie に関する通知、特にページ上部に配置されている Cookie に関する通知が挙げられます。読み込み時にこの種のレイアウト シフトを引き起こすことが多いページ要素には、広告と埋め込みがあります。

特定

Lighthouse の「大規模なレイアウト シフトを避ける」の監査では、シフトしたページ要素を特定します。このデモでは、結果は次のようになります。

Lighthouse の「大規模なレイアウト シフトを避ける」の監査

Cookie 通知自体は読み込み時にシフトしていないため、これらの検出結果には Cookie 通知は含まれていません。ページ上のその下にあるアイテム（div.hero と article）が移動します。レイアウト シフトの特定と修正について詳しくは、レイアウト シフトのデバッグをご覧ください。

解決方法

Cookie に関する通知は、絶対位置または固定位置を使用してページの下部に配置します。

ページの下部に表示される Cookie に関する通知

プログラム開始前:

.banner {
  position: sticky;
  top: 0;
}

申し込みの後:

.banner {
  position: fixed;
  bottom: 0;
}

このレイアウト シフトを修正するもう 1 つの方法は、画面上部の Cookie 通知用のスペースを確保することです。このアプローチも同様に効果的です。詳しくは、Cookie に関する通知に関するベスト プラクティスをご覧ください。

画像

Images と Largest Contentful Paint（LCP）

画像は一般に、ページ上の Largest Contentful Paint（LCP）要素です。その他の LCP 要素にできるページ要素には、テキスト ブロックや動画のポスター画像などがあります。LCP 要素が読み込まれる時刻によって LCP が決まります。

ページの LCP 要素は、ページが最初に表示されたときにユーザーに表示されるコンテンツによって、ページの読み込みごとに異なる場合があることに注意してください。たとえば、このデモでは、Cookie に関する通知の背景、ヒーロー画像、記事テキストが LCP 要素になりうるものです。

さまざまなシナリオでページの LCP 要素をハイライト表示した図。

このサンプルサイトでは、Cookie に関する通知の背景画像は実際には大きな画像です。LCP を改善するには、画像を読み込んで効果を作成するのではなく、CSS でグラデーションを描画します。

解決方法

画像ではなく CSS グラデーションを使用するように .banner CSS を変更します。

プログラム開始前:

background: url("https://cdn.pixabay.com/photo/2015/07/15/06/14/gradient-845701\_960\_720.jpg")

申し込みの後:

background: linear-gradient(135deg, #fbc6ff 20%, #bdfff9 90%);

画像とレイアウト シフト

ブラウザでは、画像が読み込まれた後にのみ、画像のサイズを判断できます。ページがレンダリングされた後に画像の読み込みが行われたものの、画像用のスペースが予約されていない場合は、画像が表示される際にレイアウト シフトが発生します。このデモでは、ヒーロー画像の読み込み時にレイアウトが移動しています。

特定

width と height が明示的に指定されていない画像を特定するには、Lighthouse の「画像要素の幅と高さが明示的に指定されている」の監査を使用します。

Lighthouse の「画像要素で幅と高さが明示的に指定されている」の監査

この例では、ヒーロー画像と記事画像の両方に width 属性と height 属性がありません。

解決方法

レイアウト シフトを避けるため、これらの画像に width 属性と height 属性を設定します。

プログラム開始前:

<img src="https://source.unsplash.com/random/2000x600" alt="image to load in">
<img src="https://source.unsplash.com/random/800x600" alt="image to load in">

申し込みの後:

<img src="https://source.unsplash.com/random/2000x600" width="2000" height="600" alt="image to load in">
<img src="https://source.unsplash.com/random/800x600" width="800" height="600" alt="image to load in">
画像がレイアウト シフトなしで読み込まれます。

フォント

フォントによってテキストのレンダリングが遅れたり、レイアウトがずれたりすることがあります。そのため、フォントを迅速に提供することが重要です。

遅延テキスト レンダリング

デフォルトでは、関連付けられたウェブフォントがまだ読み込まれていない場合、ブラウザはテキスト要素をすぐにレンダリングしません。これは、「スタイル設定されていないテキストのフラッシュ」（FOUT）を防ぐためです。多くの場合、これにより First Contentful Paint（FCP）が遅延します。状況によっては、Largest Contentful Paint（LCP）が遅延することがあります。

レイアウト シフト

フォントの切り替えは、ユーザーにコンテンツをすばやく表示するのに優れていますが、レイアウト シフトを引き起こす可能性があります。このようなレイアウト シフトは、ウェブフォントとその代替フォントがページ上の占有するスペースが異なる場合に生じます。同様の比率のフォントを使用すると、これらのレイアウト シフトのサイズを最小限に抑えることができます。

フォントの入れ替えによるレイアウト シフトを示す図
この例では、フォントの入れ替えによりページ要素が 5 ピクセル上に移動しています。

特定

特定のページに読み込まれているフォントを確認するには、DevTools で [ネットワーク] タブを開き、[フォント] でフィルタします。フォントは大きなファイルになる可能性があるため、通常は、使用するフォントの数を減らすとパフォーマンスが向上します。

DevTools に表示されたフォントのスクリーンショット

フォントがリクエストされるまでの時間を確認するには、[Timing] タブをクリックします。フォントがリクエストされるタイミングが早いほど、そのフォントの読み込みと使用も早くなります。

DevTools の [タイミング] タブのスクリーンショット

フォントのリクエスト チェーンを表示するには、[Initiator] タブをクリックします。一般的に、リクエスト チェーンが短いほど、フォントを早くリクエストできます。

DevTools の [Initiator] タブのスクリーンショット

解決方法

このデモでは、Google Fonts API を使用します。Google Fonts には、<link> タグまたは @import ステートメントを使用してフォントを読み込むオプションが用意されています。<link> コード スニペットには preconnect リソースヒントが含まれています。これにより、@import バージョンを使用する場合よりもスタイルシートの提供が速くなります。

大まかに言うと、リソースヒントは、特定の接続を設定するか、特定のリソースをダウンロードする必要があることをブラウザに伝える手段と考えることができます。その結果、ブラウザはこれらのアクションを優先します。 リソースヒントを使用するときは、特定のアクションに優先順位を付けると、ブラウザのリソースが他のアクションから奪われることに留意してください。したがって、リソースヒントは慎重に使用する必要があり、すべてに使用する必要はありません。詳細については、ネットワーク接続を確立して認識されるページ速度を改善するをご覧ください。

スタイルシートから次の @import ステートメントを削除します。

@import url('https://fonts.googleapis.com/css2?family=Montserrat:wght@400&family=Roboto:wght@300&display=swap');

ドキュメントの <head> に次の <link> タグを追加します。

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link href="https://fonts.googleapis.com/css2?family=Roboto:wght@100&display=swap" rel="stylesheet">

このリンクタグは、Google Fonts で使用されるオリジンへの早期接続を確立し、Montserrat と Roboto のフォント宣言を含むスタイルシートを読み込むようブラウザに指示します。これらの <link> タグは、<head> のできる限り早い段階で配置する必要があります。

アニメーション

アニメーションがウェブに関する指標に影響を与える主な方法は、レイアウト シフトが発生した場合です。使用を避けるべきアニメーションは 2 種類あります。1 つはレイアウトをトリガーするアニメーション、もう 1 つはページ要素を移動する「アニメーションに似た」効果です。通常、これらのアニメーションは、transform、opacity、filter などの CSS プロパティを使用することで、よりパフォーマンスの高い同等のものに置き換えることができます。詳しくは、高パフォーマンスの CSS アニメーションを作成する方法をご覧ください。

特定

パフォーマンスの悪いアニメーションを特定するには、Lighthouse の「合成されていないアニメーションを回避する」の監査が役立ちます。

Lighthouse の「合成されていないアニメーションの回避」の監査

解決方法

margin-left プロパティを移行するのではなく、transform: translateX() を使用するように slideIn アニメーション シーケンスを変更します。

プログラム開始前:

.header {
  animation: slideIn 1s 1 ease;
}

@keyframes slideIn {
  from {
    margin-left: -100%;
  }
  to {
    margin-left: 0;
  }
}

申し込みの後:

.header {
  animation: slideIn 1s 1 ease;
}

@keyframes slideIn {
  from {
    transform: translateX(-100%);
  }

  to {
    transform: translateX(0);
  }
}

重要な CSS

スタイルシートはレンダリングをブロックします。つまり、ブラウザはスタイルシートを取得し、そのスタイルシートをダウンロードして解析するまで、他のリソースのダウンロードを停止します。これにより LCP が遅れる可能性があります。パフォーマンスを向上させるには、未使用の CSS の削除、重要な CSS のインライン化、重要でない CSS の延期を検討してください。

まとめ

画像圧縮を使用して画像を高速に配信するなど、さらなる改善の余地はありますが、これらの変更により、このサイトのウェブに関する指標が大幅に改善されました。これが実際のサイトである場合は、次のステップとして、実際のユーザーからパフォーマンス データを収集して、ほとんどのユーザーの Web Vitals のしきい値を満たしているかどうかを評価します。ウェブに関する指標の詳細については、ウェブに関する指標について学ぶをご覧ください。