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

ウェブ バイタルの最適化に役立つ CSS 関連の手法

Katie Hempenius
Katie Hempenius
X
Una Kravets

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

この記事では、ウェブ バイタルを最適化するための CSS 関連の手法について説明します。これらの最適化は、ページのさまざまな側面（レイアウト、画像、フォント、アニメーション、読み込み）に分類されます。説明の過程で、サンプルページの改善について説明します。

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

レイアウト

DOM へのコンテンツの挿入

周囲のコンテンツが読み込まれた後にページにコンテンツを挿入すると、ページ上の他のすべてのコンテンツが下に移動します。これにより、レイアウトがずれる。

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

特定

Lighthouse の「レイアウトが大きく変わらないようにする」監査では、移動したページ要素が特定されます。このデモでは、結果は次のようになります。

Lighthouse の「レイアウトが大きく変わらないようにする」監査

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

修正

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

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

プログラム開始前:

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

申し込みの後:

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

このレイアウトのずれを修正する別の方法として、画面上部に Cookie に関する通知用のスペースを予約することもできます。この方法も同様に効果的です。詳しくは、Cookie に関する通知に関するベスト プラクティスをご覧ください。

画像

画像と 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 に表示されたフォントのスクリーンショット

フォントがリクエストされるまでの時間を表示するには、[タイミング] タブをクリックします。フォントがリクエストされればされるほど、フォントは早く読み込まれ、使用できるようになります。

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

フォントのリクエスト チェーンを確認するには、[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 種類あります。レイアウトをトリガーするアニメーションと、ページ要素を移動する「アニメーションのような」効果です。通常、これらのアニメーションは、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 を遅らせることを検討してください。

まとめ

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