First Contentful Paint (FCP): 概要と測定・改善方法

First Contentful Paint の改善

First Contentful Paint (FCP) は、訪問者が見ることができる最初の意味のある要素をブラウザがページ上に描画する瞬間のことです。言い換えれば、ブラウザが画面上に最初に何かをレンダリングする瞬間です。そのため、FCP は体感的なページの読み込み速度を測定するための優れた方法です。

ブラウザが遅延なくレンダリングを開始できるようにすることで、FCP を改善できます。以下では、FCP とは何か、その測定方法、および高速化するための実証済みの15の手法について学びます。

First Contentful Paint (FCP) とは？

First Contentful Paint (FCP) は、ページの読み込み速度を測定する方法の1つです。ページ速度を単一の時点として要約することはできません。読み込みプロセスの間には、訪問者がサイトの読み込みが速い、あるいは遅いと感じる瞬間が実際にはいくつか存在します。FCP は、ページをリクエストしてから、最初の意味のあるコンテンツが初めて画面にレンダリングされるまでの時間の差を測定します。

では、それは具体的に何を教えてくれるのでしょうか？それは、FCP が訪問者の体感する読み込み速度について語るため、主に「ユーザー中心の指標」であることを示しています。それは user experience について何かを語っています。FCP の瞬間に、訪問者が実際に画面上で「何か」を見ていることを確信できます。

「First」、「Contentful」、そして「Paint」という言葉に分解してみましょう。

1. First (最初の): First とは、もちろん、ブラウザに実質的な何かが表示される最初の正確な瞬間を意味します。
2. Contentful (コンテンツのある): contentful とは、コンテンツを含む HTML 要素を意味します。つまり、空白の要素や背景色のようなレイアウト要素ではなく、テキスト、画像 (背景画像を含む)、SVG、または canvas のようなものです。
3. Paint (描画): Paint は（多かれ少なかれ）、ブラウザが画面に何かを配置する準備ができていることを意味します。これは単純に見えますが、実際にはブラウザの最も複雑なタスクです。画面に何かを配置するためには、ブラウザは要素のすべての特性を計算する準備ができていなければなりません。以下は、画面に何かが追加される前に必要とされるレンダリングプロセスの例です。

FCP と LCP: 違いは何ですか？

FCP と Largest Contentful Paint (LCP) はどちらも読み込みパフォーマンスを測定しますが、ページ読み込みのタイムラインにおいて異なる瞬間を捉えます。この違いを理解することで、最適化作業の優先順位を正しく付けることができます。

実際には、FCP は多くの場合 LCP よりもかなり前に発火します。例えば、ページが見出し (FCP) を400ミリ秒以内にレンダリングしても、ヒーロー画像が読み込まれる (LCP) までにさらに2秒待つことがあります。FCP はレンダリングパイプラインにおける一番最初のボトルネックを捉えるため、FCP が遅い場合、LCP もほぼ確実に遅くなります。詳しくは Largest Contentful Paint の完全ガイドをご覧ください。

良好な First Contentful Paint スコアとは？

良好な FCP スコアは 1.8秒未満のものです。FCP スコアが1.8秒から3秒の間にある場合は、改善が必要です。3秒を超える FCP スコアはすべて不良と見なされます。First Contentful Paint の推奨されるしきい値を満たすには、訪問者の少なくとも75%が「良好」な FCP スコアである必要があります。

他のパフォーマンス指標と同様に、First Contentful Paint スコアは遅いよりも速い方が優れています。

First Contentful Paint (FCP) はどのように測定しますか？

FCP は、Google が実際のユーザーからデータを収集することによって測定されます。そのデータは CrUX データセットに保存されます。このデータは、CrUX API または Google BigQuery を通じて公開されています。FCP は、いわゆるラボテストを通じて測定することもできます。最も一般的なラボテストは Lighthouse と呼ばれます。

CrUX データセットから First Contentful Paint を取得する

First Contentful Paint は、pagespeed.web.dev、CrUX API、または Google BigQuery を通じて CrUX データセットから読み取ることができます。

Real User Monitoring (RUM) を通じた First Contentful Paint の測定

RUM トラッキングは Real User Monitoring の略です。Real User Monitoring を使用すると、実際のユーザーとのインタラクションを通じて First Contentful Paint を追跡できます。RUM トラッキングの利点は、新しいデータを得るために28日間待つ必要がなく、データをはるかに詳細にクエリして分析できることです。

Lighthouse での FCP の測定

1. FCP を測定したいページを (Chrome で) 開きます。プラグインが干渉してページの FCP を遅くする可能性を防ぐため、必ずシークレットモードでこれを行ってください。
2. ページを右クリックし、「要素を検証」(Inspect) を選択します。これにより、Chrome のデベロッパーコンソールが開きます。
3. コンソールのトップに Lighthouse タブが表示されます。それをクリックします。次に Categories で Performance を選択し (他は空欄のまま)、Device で Mobile を選択します。
4. ここで Generate Report をクリックします。Lighthouse がページの速度レポートを作成します。レポートの左上隅に、そのページの FCP が表示されます。

これはこのページの Lighthouse レポートのスクリーンショットです。モバイルデバイスでのこのページの FCP は0.8秒です！悪くないですよね？

オンラインツールを使用した FCP の測定

多数のオンラインツールを使用して FCP を測定することもできます。最もよく知られているのは、GTMetrix、pingdom、および pagespeed.web.dev です。これらのツールは使いやすく、特定のラボ環境下での FCP に関するデータを提供してくれます。

実際の FCP データが示すこと

CoreDash のデータは、FCP が TTFB に密接に追随していることを示しています。p75 の FCP は全体で392ミリ秒であり、デスクトップは372ミリ秒、モバイルは692ミリ秒 (1.9倍遅い) です。FCP と TTFB の差はデスクトップでわずか248ミリ秒、モバイルで376ミリ秒であり、最適化されたサイトでは、レンダリングブロック時間が FCP に占める割合は比較的少ないことを示しています。

世界的には、2025 Web Almanac によると、デスクトップページの70%が良好な FCP を達成しているのに対し、モバイルページはわずか55%にとどまっています。どちらも2024年から改善しており、モバイルは4パーセントポイント上昇したことから、ウェブ開発者がレンダリングをブロックするリソースへの対応をますます進めていることがうかがえます。

FCP と TTFB の強い相関関係は、Time to First Byte の改善が、多くの場合、First Contentful Paint を改善する最も効果的な方法であることを意味しています。このサイトでは、FCP は TTFB より約250ミリ秒長いだけであり、これは FCP の時間の大部分が、レンダリングをブロックする処理ではなくサーバーの応答待ちに費やされていることを意味します。

First Contentful Paint の改善

FCP を高速化する時間です。高速な FCP の背後にある考え方は実は非常にシンプルで、ブラウザがすぐにレンダリングを開始できるようにすることです。レンダリングを遅延させる可能性のあるものはすべて、FCP スコアの低下につながります。

Largest Contentful Paint と同様に、First Contentful Paint は2つまたは4つのカテゴリに分類できます。

1. Time to First Byte (TTFB): ブラウザがページの読み込みを開始してから、HTML の最初のバイトを受信するまでの時間。
2. Resource load delay (リソース読み込みの遅延): TTFB から、ブラウザが FCP リソースの読み込みを開始するまでの時間。
3. Resource load time (リソース読み込み時間): FCP リソース自体の読み込みにかかる時間。
4. Element render delay (要素のレンダリング遅延): FCP リソースの読み込みが完了してから、FCP 要素が完全にレンダリングされるまでの時間。

Speed tip (速度向上のヒント): FCP 要素がネットワークリソースを必要としないようにすることで、ステップ2と3を簡単に排除できます。テキスト要素の場合は、font-display:swap の使用を検討してください。小さな画像要素の場合は、画像をインラインで配置することを検討してください。

これにより、最適化すべき項目は Time to First Byte と Element Render delay (要素のレンダリング遅延) だけになります。

以下は、私が FCP を改善するためによく使用する14の解決策です。ただし、間違った場所で解決策を使用すると、逆に遅延を引き起こす可能性があることに注意してください。そのため、ご自身で始める前に pagespeed の専門家に相談するのが最善です。

1. サーバーの高速な応答 (TTFB)

TTFB (リクエストからサーバーが最初のバイトを送信するまでの時間) は、常にレンダリングプロセスの最初のステップです。その時点からブラウザはマルチタスクを開始し、その後の最適化の影響は減少し始めます。HTML コードは、すべての速度指標に直接影響を与える唯一のリクエストです。

サーバーから HTML コードが送信される速度は、多くの場合 Time to First Byte (TTFB) として測定されます。これをできるだけ速くすることが重要です。多くの場合、これはサーバーサイドキャッシュを有効にすることで行います。

Time to First Byte に関しては、常に低い方が優れています。

Time to First Byte はご自身で簡単に測定できます。手順は以下の通りです：

1. ショートカットの Ctrl-Shift-I を使用して、Google Chrome のデベロッパーコンソールを開きます。
2. コンソールのトップに、Network (ネットワーク) タブが表示されます。それをクリックします。
3. Ctrl-R を押してページを再読み込みします。
4. Chrome がサーバーに送信したすべてのネットワークリクエストが表示されます。
5. 一番上のネットワークリクエストをクリックします。これがページ自体のリクエストです。
6. これにより、このネットワークリクエストに関する詳細情報が表示されます。この情報の上部にある timing (タイミング) タブをクリックすると、そのページの TTFB を確認できます。

2. HTTP/3

HTTP/3 は、HTTP プロトコルの3番目のバージョンです。HTTP/3 は、古い HTTP/1.1 や HTTP/2 プロトコルに見られる多くの問題を解決します。たとえば、HTTP/2 以降では、同じ接続を通じて複数のファイルを同時に送信できます。HTTP/3 は、より高速な初期接続を提供し、軽微なネットワークの中断によるトラブルを減らします。

詳細には踏み込みませんが、HTTP/3 を使用すると、特にモバイルネットワークのような低速なネットワークにおいて、大幅な速度向上が可能になります。ご利用のウェブサーバーがすでに高速な HTTP/3 プロトコルに対応しているかどうかは、ネットワーク管理者に確認できます。

ご自身のウェブサイトがすでに高速な HTTP/3 プロトコルを使用しているかどうかは、ご自身で確認できます。ショートカット Ctrl-Shift-I を使用して、Google Chrome のネットワークインスペクタを開きます。テーブルのヘッダーを右クリックして Protocol (プロトコル) を選択します。その後、ページを再読み込みして、サイトが使用しているプロトコルを確認します。

3. 103 Early Hints

103 Early Hints は、最終的なレスポンスの準備ができる前に、サーバーが予備のレスポンスヘッダーを送信できるようにする比較的新しい HTTP ステータスコードです。これは、サーバーが HTML を生成するのに時間を要する場合 (例えば、データベースへのクエリやサーバーサイドロジックの実行など) に特に有用です。ブラウザをアイドル状態で待機させる代わりに、サーバーは preload (事前読み込み) と preconnect (事前接続) のヒントを含む 103 レスポンスを送信し、ブラウザが重要なリソースの取得をすぐに開始できるようにします。

ブラウザは HTML が到着する前にフォント、スタイルシート、その他のレンダリングに不可欠なリソースのダウンロードを開始できるため、これは FCP を直接改善します。TTFB が高いページにおいて、その影響は最も大きくなります。

HTTP/1.1 103 Early Hints
Link: </static/font/outfit.woff2>; rel=preload; as=font; type=font/woff2; crossorigin
Link: </static/css/critical.css>; rel=preload; as=style

HTTP/1.1 200 OK
Content-Type: text/html
...

すべてのホスティングプロバイダーが 103 Early Hints をまだサポートしているわけではありません。Cloudflare は Early Hints を組み込みでサポートしており、Apache と Nginx はそれらを送信するように設定できます。詳しくは、103 Early Hints の完全ガイドをご覧ください。

4. ブラウザキャッシュ (Browser Caching)

ページ速度に関しては、ネットワーク接続が弱点となることがよくあります。ネットワークを完全にスキップできれば、どれほど簡単でしょうか？

訪問者が以前にあなたのサイトに訪れたことがある場合、ネットワークリソース (例えばスタイルシート) を訪問者のブラウザに保存するかどうか、およびその期間を指定できます。訪問者がこれらのファイルを再び必要とするたびに、ブラウザのキャッシュからすぐに呼び出されます。その結果、ブラウザははるかに速くレンダリングを開始でき、FCP を高速化できます。

5. 圧縮 (Compression)

ネットワーク速度は、ほとんどすべての場合において弱点となります。良好な First Contentful Paint のためには、ファイルがネットワーク経由で可能な限り速く送信されることが非常に重要です。圧縮は、サーバーから送信しなければならないバイト数を減らします。バイト数が少ないほど、ネットワークリソースを待つ時間が短くなります。私の意見では、圧縮はふさわしい注目を集めていない手法です。残念ながら、あまりにも多くのウェブマスターが「圧縮をオンにする」だけで、その後は二度と見直しません。しかし、それはほんの少しでも速くするための簡単な方法であるため、非常にもったいないことです。

一般的な圧縮技術には、Gzip と Brotli の2つがあります。Gzip は最も使用されている圧縮技術ですが、Brotli が急速に追いついています。Brotli は Google 自身によって作成されており、HTML、JavaScript、または CSS ファイルにおいて15〜20%優れた結果を出します。したがって、Brotli はウェブに最適です。

また、動的圧縮と静的圧縮には違いがあります。動的圧縮では、ウェブサーバー経由で送信する直前にファイルを圧縮します。静的圧縮では、圧縮されたファイルがサーバー上に保存されます。これは多くの場合、はるかにスマートな圧縮方法ですが、めったに使用されません。

6. リソースヒントによる Web フォントの早期取得

リソースヒントは、ブラウザが自身で実行する前にダウンロードまたはネットワーク接続を開始します。Web フォントや画像などの一部のネットワークリソースは、ブラウザがそれらを表示する必要があると確信した後にのみダウンロードされます。

サイトの可視部分をレンダリングするためにリソースが必要だと確信している場合は、「リソースヒント」を含めるのがほぼ常に良いアイデアです。これにより、ブラウザは直ちにリソースのダウンロードまたは接続を開始します。結果として、リソースがより早く利用可能になり、ブラウザはより早くレンダリングを開始できます。

ただし、リソースヒントには注意してください。誤って使用すると、逆にページが遅くなる可能性があります。

「preload (事前読み込み)」による早期ダウンロード

<link rel="preload" href="/static/font/opensans600.woff2" as="font" type="font/woff2" crossorigin>

preload リンクは、ページ速度を向上させる上で最も強力なツールの1つです。preload リンクを通じて、後で必要になるネットワークリソースをダウンロードします。これは、サイトの可視部分にあるフォント、重要なスクリプト、および画像において、非常に良いアイデアであることが多いです。

preconnect による事前接続

preconnect リンクは、事前にサーバーに接続します。これは、CDN や Google Analytics などのサードパーティサーバーでファイルをホストしている場合に便利です。

<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>

Google Fonts に事前接続するよりもさらに良いのは、Google Fonts をセルフホストすることです。これにより、サードパーティの接続が完全に排除され、キャッシュと配信を完全に制御できるようになります。

7. prefetch による次のページの事前取得

<link rel="prefetch" href="/page2.html">

prefetch を使用すると、優先度の低いリソースを取得できます。これは、例えば誰かが次のページのリンクをクリックすると予想される場合など、後で必要になると思われるリソースを取得するための便利な方法です。

8. リダイレクトを避ける

よくある間違いは、リダイレクトチェーンが長すぎることです。説明しましょう：あなたのサイトはおそらくセキュアな接続で実行されています。訪問者が https を付けずにサイトを入力すると、訪問者は非セキュアなバージョンのウェブサイトにリダイレクトされます。しかし、すべてが正しく設定されていれば、訪問者はセキュアなウェブサイトにリダイレクトされます。これは以下の緑色の例で確認できます。

しかし、赤色の例のように、リダイレクトが1つ以上の中間ステップを経由して行われることがあります。ウェブサイトの動作を遅くし、First Contentful Paint スコアを低下させる原因となるのは、これらの中間ステップです。各中間ステップには余分な時間がかかり、それはすぐに積み重なります。したがって、常に1回のリダイレクトで正しいページに到達するようにしてください。

9. CSS の最小化

外部 CSS ファイルは常にレンダリングをブロックします。これが意味するのは、ブラウザは通常、すべてのスタイルシートがダウンロードされて解析されるまで、コンテンツの表示を開始できないということです。したがって、スタイルシートは可能な限り小さく保つのが最善です。こうすることで、スタイルシートのダウンロードを長く待つ必要がなくなります。より完全なガイドについては、未使用の CSS を修正して削除する方法に関する記事をお読みください。

ショートコードを使用した CSS サイズの削減

CSS のサイズを削減する方法の1つは、ショートコードを使用することです。これらは、CSS セレクタの最も重要なプロパティを1行で記述できるワンライナーです。

body{
    font-style: normal;
    font-weight: 400;
    font-stretch: normal;
    font-size: 0.94rem;
    line-height: 1.6;
    font-family: "Segoe UI", "Segoe UI", system-ui, -apple-system, sans-serif;
}

次のように書くこともできます：

body{font: 400 .94rem/1.6 Segoe UI,Segoe UI,system-ui,-apple-system, sans-serif;}

CSS サイズのさらなる削減

セレクタをカンマで結合し、改行やスペースを削除し、短いカラーコードを記述することで、CSS のサイズをさらに小さくすることが可能です。

h1{
  color : #000000;
}
h2{
  color : #000000;
}
h3{
  color : #000000;
}
h4{
  color : #000000;
}
h5{
  color : #000000;
}

次のように短縮できます

h1,h2,h3,h4,h5{color:#000}

10. クリティカル CSS (Critical CSS)

クリティカル CSS を使用することで、CSS をさらに一歩進めることができます。クリティカル CSS は、高速なウェブサイトと高速な First Contentful Paint にとって必須です。

クリティカル CSS は、ページの可視部分を表示するために必要なすべてのセレクタ (body、p、h1 など) のコレクションです。このクリティカル CSS は別のスタイルシートに配置せず、ページの <head> に直接追加します。こうすることで、新しいファイルをダウンロードする必要がなくなり、ブラウザは超高速でレンダリングを開始できます。これにより、FCP が高速化されます。ページの可視部分に直接必要ない CSS は、最初のレンダリングサイクルが完了した後に読み込まれます。訪問者にとってページはすでに完成しており、バックグラウンドで新しいスタイルがまだ追加されていることに気付く人は誰もいません。

クリティカル CSS は、私たちが提供する クリティカル CSS ツールで簡単に生成できます。ツールの入力欄にウェブページの URL を貼り付けるだけで、残りの作業はすべて代行します！

インラインクリティカル CSS の例

<head>
  <style>
    /* Critical CSS: only what is needed for above-the-fold content */
    body{font:400 1rem/1.6 system-ui,sans-serif;margin:0}
    h1{font-size:2rem;margin:.5em 0}
    .hero{padding:2rem;background:#f5f5f5}
  </style>
  <!-- Non-critical CSS loaded asynchronously -->
  <link rel="preload" href="/css/full.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
  <noscript><link rel="stylesheet" href="/css/full.css"></noscript>
</head>

11. JavaScript の読み込みの遅延

First Contentful Paint が遅くなる最も一般的な理由の1つは JavaScript です。JavaScript の使用方法によっては、ページのレンダリングをブロックする可能性があります。通常、JavaScript はレンダーツリーが構築される前にダウンロードおよび実行されます。レンダーツリーがないと、ブラウザは画面に何も配置できず、これには FCP も含まれます。遅延技術の完全な概要については、JavaScript を遅延させる14の方法をお読みください。

JavaScript を後回しにすることでこれを回避できます。これには3つの方法があります。

Async JavaScript

<script async src="async.js"></script>

script タグに async 属性を追加することで、JavaScript がダウンロードされている間、ページの構築がブロックされなくなります。async 属性は、ダウンロードとレンダーツリーの構築が同時に行われることを示します。

スクリプトが実行されると、ページはブロックされます。多くの場合、async 属性のおかげで、ブラウザはページの重要な部分を構築するための十分な時間を持ち、First Contentful Paint はすでにページ上に表示されています。

Defer JavaScript

<script defer src="deferred.js"></script>

defer 属性は、多かれ少なかれ async 属性と同じように機能します。script タグに defer 属性を追加することで、スクリプトもページの構築と同時にダウンロードされるようになります。すべてのスクリプトがダウンロードされた後、それらは HTML コード内で見つかった順番に実行されます。これもページの表示をブロックする可能性がありますが、多くの場合、First Contentful Paint はすでに画面上にあります。

12. 外部リソースに依存しない

外部フォント、外部画像、外部スタイルシート、外部スクリプトなどの外部リソースは、First Contentful Paint において潜在的なボトルネックとなります。ファイルがホストされているサーバーを制御できないため、それらがどれだけ速く送信されるかを知ることはできません。さらに、ウェブサーバーへの既存の接続を使用することもできません。新しいサーバーへの新しい接続をセットアップする必要があり、それには時間がかかります。

ウェブ上で最も一般的な外部リソースの1つは Google Fonts です。Google Fonts をセルフホストすることで、サードパーティへの接続が完全に排除され、キャッシュ、圧縮、および font-display の動作を完全に制御できるようになります。

外部リソースのブロック (Blocking external resources)

外部リソースなし (No external resources)

13. 適切なフォント形式を使用する

First Contentful Paint に関しては、フォントに特別な注意を払う必要があります。私たちが確認するページの約99%において、FCP 要素はテキスト行です。外部の Web フォントを使用する場合、まずサーバーからこれらのフォントをダウンロードする必要があり、当然のことながら時間がかかります。

最近、Web フォントがますます注目を集めており、より新しく高速なフォント形式が登場しています。現在最も速いフォント形式は woff2 であり、woff がそれに続きます。woff2 はすべてのモダンブラウザでサポートされています。

CSS の font-face 宣言で、Web フォントの優先順位を指定できます。これは次のように行います：

 @font-face {
   font-family: 'myFont';
   font-weight: 400;
   font-style: normal;
   font-display: swap;
   unicode-range: U+000-5FF
   src: local('myFont'),
        url('/fonts/myFont.woff2') format('woff2'),
        url('/fonts/myFont.woff') format('woff');
}

14. font-display: swap

Web フォントを使用する場合、これらのフォントのデフォルトの動作は、フォントが読み込まれるまでページ上にテキストを表示しないことです。これは通常、First Contentful Paint を直接犠牲にします。Web フォント読み込み中にテキストが確実に見えるようにする方法に関する完全ガイドをお読みください。

これは font-display:swap 宣言を使用することで解決できます。これにより、Web フォントがバックグラウンドで読み込まれている間、ブラウザが認識しているフォントで、とにかくページ上にテキストを表示することを選択できます。

font-display:swap なし

font-display:swap あり

font-display: swap と optional の比較

FCP 最適化のための一般的な font-display 戦略は2つあります：

/* swap: fallback フォントをすぐに表示し、Web フォントが読み込まれたら切り替えます */
@font-face {
  font-family: 'MyFont';
  font-display: swap;
  src: url('/fonts/myfont.woff2') format('woff2');
}

/* optional: fallback フォントを表示し、すでにキャッシュされている場合にのみ Web フォントを使用します */
@font-face {
  font-family: 'MyFont';
  font-display: optional;
  src: url('/fonts/myfont.woff2') format('woff2');
}

font-display: swap を使用すると、テキストが fallback フォントですぐにレンダリングされるため、可能な限り最速の FCP が保証されます。font-display: optional を使用すると、最初の訪問時にスタイル付けされていないテキストのフラッシュ (FOUT) を完全に回避できますが、Web フォントはすでにブラウザのキャッシュにある場合にのみ表示されます。ほとんどのサイトにおいて、FCP のためには swap の方がより良い選択です。

15. DOM サイズの最小化

ウェブページは HTML で構成されています。ブラウザが最初に行うのは、HTML を DOM ノードに変換することです。これは、後でレンダーツリーを構築するために使用される HTML 要素のツリー構造です。ブラウザはレンダーツリーからレンダリングを開始し、最終的にウェブページが画面に表示されます。

DOM ノード (HTML 要素) の数と、これらの DOM ノードがツリー構造のどれだけ深くにあるかによって、ブラウザがページを構築する際の複雑さが決まります。DOM ノードが多すぎると、CSS と JavaScript の解析にもさらに時間がかかります。これもまた、FCP を直接犠牲にすることになります。

これを以下の方法で解決します：

• ウェブページの一部の遅延読み込み (Lazy load)
  初期表示を高速化するために、フッターなどのウェブサイトの一部を後で AJAX を経由して読み込むことを検討してください。
• content-visibility の活用
  CSS プロパティの content-visibility は、レンダリング中のスタイル、レイアウト、およびペイントをスキップするようブラウザに指示します。これは要素が表示される直前に行われます。
• 大きなページを複数のページに分割する
  大きなページを複数のページに分割することで、DOM ノードの数を減らすことができます。
• 無限スクロールの実装
  無限スクロールは基本的に遅延読み込みです。画像 (Pinterest のような) や大量のデータのテーブルなど、繰り返される要素をスクロールする際、無限スクロールはページを大幅に高速化できます。
• JavaScript による DOM の操作を避ける
  ページ上に多数の DOM ノードがある場合は、JavaScript に特に注意してください。querySelectorAll のようなコマンドは、多数の DOM ノードを読み込み、メモリ使用量を増加させる可能性があります。
• 複雑な CSS 宣言を避ける
  多数の DOM ノードを持つ複雑な CSS コマンドには特に注意してください。例えば、ページ上のすべての div 要素について last-child ステータスを確認することは、負荷が高くなる可能性があります。
• Web Workers を使用してブラウザのメインスレッドを節約する
  Web Workers は、ウェブページと並行して実行できる JavaScript です。これらの Web Workers に、バックグラウンドで実行されるコマンドを与えることができます。Web Worker がコマンドを実行し終えると、それを元のページに渡します。これの利点は、ページをフリーズさせることなく、複雑な JavaScript を引き続き実行できることです。

関連する最適化ガイド

FCP の改善には、複数の領域にわたる作業が必要です。関連性の高いガイドをいくつかご紹介します：

• Google Fonts をセルフホストする: サードパーティの接続を排除し、フォント配信を完全に制御します。
• Web フォント読み込み中にテキストが確実に見えるようにする: font-display を使用して高速なテキストレンダリングを保証します。
• JavaScript を遅延させる14の方法: JavaScript が FCP をブロックするのを防ぐためのあらゆる技術。
• 未使用の CSS を修正して削除する: レンダリングをブロックする CSS を最小限に抑えます。
• 103 Early Hints: HTML が到着する前に、ブラウザがリソースの取得を開始できるようにします。
• Largest Contentful Paint (LCP) ガイド: FCP と LCP は多くの最適化戦略を共有しています。FCP が遅い場合、LCP も遅くなります。
• Time to First Byte (TTFB) ガイド: TTFB は FCP に対する唯一の最大の要因です。サーバーの応答が遅い場合は、ここから始めてください。