First Contentful Paint

First Contentful Paint（FCP）とは？

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

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

言葉を分解してみましょう：「First」「Contentful」「Paint」。

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

良いFirst Contentful Paintスコアとは？

良いFCPスコアは0〜1.8秒未満です。FCPスコアが1.8〜3秒の場合は改善が必要です。3秒を超えるFCPスコアは不良とみなされます。Largest Contentful PaintのCore Web Vitalsに合格するには、訪問者の少なくとも75%が「良い」FCPスコアである必要があります。

Core Web Vitalsの他の指標と同様に、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. ページ上で右クリックし、「要素を検証」を選択します。これでChrome開発者コンソールが開きます。
3. コンソールの上部にLighthouseタブが表示されます。それをクリックします。次に、カテゴリでPerformanceを選択し（他は空白のまま）、デバイスでMobileを選択します。
4. 「レポートを生成」をクリックします。Lighthouseがページの速度レポートを作成します。レポートの左上にページのFCPが表示されます。

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

オンラインツールでFCPを測定する

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

First Contentful Paintの改善

First Contentful Paintとは何かを理解したところで、それを速くする作業に取り掛かりましょう。速いFCPの基本的な考え方は実にシンプルです：ブラウザがすぐにレンダリングを開始できるようにすることです。レンダリングの遅延を引き起こすものはすべて、FCPスコアの低下につながります。

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

1. Time to First Byte（TTFB） - ページの読み込み開始からブラウザがHTMLの最初のバイトを受信するまでの時間。 
2. リソース読み込み遅延 - TTFBからブラウザがFCPリソースの読み込みを開始するまでの時間
   
3. リソース読み込み時間 - FCPリソース自体の読み込みにかかる時間。
   
4. 要素レンダリング遅延 - FCPリソースの読み込み完了からLCP要素が完全にレンダリングされるまでの時間
   

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

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

以下は、FCPを改善するためによく使用する14の解決策です。ただし注意が必要で、間違った場所で解決策を使用すると、かえって遅延を引き起こす可能性があります。そのため、自分で始める前にページ速度の専門家に相談することをお勧めします。

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. ブラウザキャッシング

ページ速度に関して、ネットワーク接続はしばしばボトルネックになります。ネットワークを完全にスキップできたら、はるかに簡単ではないでしょうか？

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

4. 圧縮

ネットワーク速度はほぼすべての場合においてボトルネックです。良いFirst Contentful Paintのためには、ファイルをネットワーク経由でできるだけ速く送信することが非常に重要です。圧縮により、サーバーから送信しなければならないバイト数が削減されます。バイト数が少なければ、ネットワークリソースの待ち時間も短くなります。圧縮は、私の意見では、十分な注目を受けていない技術です。残念ながら、多くのウェブマスターは「圧縮をオンにする」だけで、その後は見直さなくなります。それは非常にもったいないことです。なぜなら、少しの工夫で物事を速くする簡単な方法だからです。

一般的な圧縮技術は2つあります：GzipとBrotliです。Gzipは最も使用されている圧縮技術ですが、Brotliが急速に追い上げています。BrotliはGoogle自身によって開発され、HTML、JavaScript、CSSファイルに関しては15〜20%優れた結果を示します。そのため、BrotliはWeb向けに理想的です。

動的圧縮と静的圧縮の違いもあります。動的圧縮では、ウェブサーバーから送信する直前にファイルを圧縮します。静的圧縮では、圧縮済みのファイルがサーバーに保存されます。これは多くの場合、はるかに賢い圧縮方法ですが、あまり使用されていません。

5. リソースヒントによるWebフォントの早期読み込み

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

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

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

「preloading」による早期ダウンロード

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

preloadリンクは、ページ速度対策の中で最も強力なツールの一つです。preloadリンクを使用すると、後で必要になるネットワークリソースをダウンロードします。これはフォント、重要なスクリプト、サイトの可視部分にある画像に対して非常に有効です。

preconnectによる事前接続

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

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

6. prefetchで次のページをプリフェッチする

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

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

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

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

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

8. CSSの最小化

外部CSSファイルは常にレンダリングブロッキングです。つまり、ブラウザは通常、すべてのスタイルシートがダウンロードされ分析されるまでコンテンツの表示を開始できません。そのため、スタイルシートはできるだけ小さく保つことが最善です。こうすることで、スタイルシートのダウンロードを長く待つ必要がなくなります。

ショートコードによるCSSサイズの削減

CSSサイズを削減する方法の一つは、ショートコードを使用することです。これは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}

9. Critical CSS

CSSをさらに一歩進めて、Critical CSSを使用できます。Critical CSSは、高速なウェブサイトと高速なFirst Contentful Paintに必須です。

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

Critical CSSは、私たちの Critical CSSツールで簡単に生成できます。ツールにウェブページのURLを貼り付けるだけで、残りは私たちが行います！

10. JavaScriptの遅延読み込み

First Contentful Paintが遅くなる最も一般的な原因の一つはJavaScriptです。JavaScriptの使用方法によっては、ページのレンダリングをブロックする可能性があります。通常、JavaScriptはレンダーツリーが構築される前にダウンロードされ実行されます。レンダーツリーなしでは、ブラウザは画面に何も表示できません。これにはFCPも含まれます。

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

Async JavaScript

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

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

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

Defer JavaScript

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

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

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

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

ブロッキング外部リソース

外部リソースなし

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

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');
}

13. Font display:swap

Webフォントを使用する場合、デフォルトの動作では、フォントが読み込まれるまでページ上のテキストは表示されません。これは通常、First Contentful Paintに直接悪影響を及ぼします。 

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

font-display:swapなし

font-display:swapあり

完全な記事を読む Ensure text remains visible during webfont load

14. DOMサイズの最小化

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

DOMノード（HTML要素）の数とツリー構造内でのDOMノードの深さが、ブラウザがページを構築する際の複雑さを決定します。CSSやJavaScriptも、DOMノードが多すぎると分析に時間がかかります。これもすべてFCPに直接悪影響を及ぼします。

以下の方法で解決できます：

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