ウェブに関する指標用の 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> のできるだけ早い段階で配置する必要があります。

アニメーション

アニメーションが Web Vitals に影響を与える主な要因は、レイアウト シフトを引き起こすことです。使用を避けるべきアニメーションは 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 を遅らせることを検討してください。

まとめ

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