FCPとは？8つの改善方法と仕組みをわかりやすく解説！

FCPとは？8つの改善方法と仕組みをわかりやすく解説！

このページではFCPについてわかりやすく解説していきます。

FCPの8つの具体的な改善方法を詳しく紹介していきます。

FCPとは？

FCPとはFirst Contentful Paintの略で、ユーザーがページに初めて移動してから、ページのコンテンツのいずれかの部分が画面上にレンダリングされる（何かしら表示される）までの時間を測定します。

この指標の「コンテンツ」とは、テキスト、画像（背景画像を含む）、<svg> 要素、白色以外の <canvas> 要素を指します。

上記の画像はページが表示されていく過程をイメージした画像となりますが、読み込みが始まって1秒で初めのコンテンツが表示された場合（3枚目の部分）はFCPは1秒となります。

ロゴだけでもテキストだけでも初めに視認できるものが表示されるところまでの秒数となります。

FCPの評価は秒数で評価されます

FCPは秒数で表現されます。

上記の画像のように1.8秒以下は良好で1.8秒〜3.0秒は改善が必要で3.0秒以上は不良といった評価となります。

評価

表示時間

表示色

説明

良好

1.8秒以下

緑色

ユーザーにとって快適な読み込み速度。理想的なパフォーマンス。

改善が必要

1.8秒〜3.0秒

オレンジ色

許容範囲だが改善の余地あり。ユーザー体験向上のため最適化推奨。

不良

3.0秒以上

赤色

ユーザーの離脱率が高まる可能性。早急な改善が必要。

PageSpeed Insightsでも1.8秒以内を推奨しています。

マーケティング担当の方は是非1.8秒以内を目指して改善してみてください。

優れたユーザー エクスペリエンスを提供するには、サイトで 1.8 秒以内にファースト コンテンツフル ペイントを実現するようにします。ほとんどのユーザーが閲覧する際に目標値が達成されるよう、モバイル デバイスとデスクトップ デバイスでページ読み込みの75 パーセンタイルを測定することをおすすめします。

引用：PageSpeed Insights

FCPの計測の仕組みをわかりやすく解説

FCPの仕組みをしっかり理解するための仕組みをわかりやすく解説します。

FCPの計測対象となる要素

FCPが計測対象とする「コンテンツ」は、以下の要素が含まれます。

FCP計測対象の要素

  • テキスト
  • 画像（imgタグ）
  • SVG要素
  • 背景画像以外の要素
  • キャンバス要素（canvasタグ）

上記の項目のように、FCPが計測される要素はテキスト、画像（imgタグ）、SVG要素、背景画像以外の要素、キャンパス（canvasタグ）要素が該当します。

改善を行う際などは上記の要素が該当するということはしっかり理解しておくといいでしょう。

FCPの測定タイミングと終了までのフロー

FCPで計測が始まるタイミングから終わるタイミングまでの流れを解説します。

計測開始のアクション

  • ユーザーがURLまたはリンクをクリックした瞬間
  • ブラウザのアドレスバーにURLを入力してEnterキーを押した瞬間
  • ページをリロードした瞬間
  • フォーム送信やJavaScriptによるページ遷移の開始時点

ページを表示させるためにアクションしたタイミング（URLのクリックやリロードなど上記参照）で計測がスタートする形になります。

計測がスタートすると、初めのコンテンツを表示させるまで下記のような順序で読み込まれていきます。

計測開始から終了までのフロー

  1. ユーザーがページのURLをクリックまたは入力（計測開始）
  2. ブラウザがURLの解析を開始
  3. DNSを使ってURLと対応するIPアドレスを取得
  4. ブラウザがサーバーにIPアドレスを使ってHTTPリクエストを送信
  5. サーバーからブラウザにHTMLを受信
  6. ブラウザがページをレンダリングし最初のコンテンツが画面に描画される（計測終了）

URLをクリック（計測開始）から初めのコンテンツが表示されるまでにこのようなフローを組みます。

この過程でも改善できるポイントがあるため、フローを理解しておくことで、どこの動作が遅いかなど改善できるポイントも見えやすくなります。

FCPの評価を上げる8つの改善ポイント

FCPを改善するための項目と改善方法を紹介していきます。

レンダリングを妨げるリソースの除外

最も効果的なFCP改善方法の一つが、レンダリングをブロックするリソースの除外です。

主な改善ポイントとして下記の3つがあげられます。

レンダリングを防げるリソースの除外の改善ポイント3つ

  • CSSとJavaScriptのインライン化の実施
  • ファーストビュー以外のリソースを非同期化（遅延読み込み）
  • 不要なリソースを削除

ファーストビューの表示に必要なCSSとJavaScriptのインライン化の実施

<head>タグ内で読み込まれるCSSやJavaScriptは、ブラウザがそれらを処理するまでページのレンダリングをブロックします。

このレンダリングブロックが表示までの速度を落とす要因となります。

その対策としてファーストビューの表示に必要なCSSやJavaScriptだけをインライン化させます。（クリティカルCSS、クリティカルJavaScriptの実施）

こうすることでファーストビュー表示に必要なCSSやJavaScriptが先に読み込まれレンダリングブロックを防げるので表示までの速度が早くなるという仕組みです。

下記はCSSのインライン化させる前とインライン化させた後の表示例となります。

レンダリングブロックについては「レンダリングブロックとは？」の記事をご覧ください。

Before（インライン化させる前のCSS例）

<head>
  <link rel="stylesheet" href="styles.css">
</head>

After（インライン化させた後のCSS例）

<head>
  <style>
    /* ファーストビューに必要な最小限のCSS */
    .header { background: #333; height: 60px; }
    .hero { height: 100vh; background: url('hero.jpg'); }
    .content { max-width: 1200px; margin: 0 auto; }
  </style>
</head>

下記はJavaScriptのインライン化させる前とインライン化させた後の表示例となります。

Before（インライン化させる前のJavaScript例）

<head>
  <script src="critical.js"></script>
</head>

After（インライン化させた後のCSS例）

<head>
  <script>
    // ファーストビューに必要な最小限のJS
    document.documentElement.className = 'js-enabled';
    // その他重要な初期化処理
  </script>
</head>

ファーストビュー以外のリソースを非同期読み込み（遅延読み込み）にする

ファーストビュー以外のリソースの非同期読み込み（遅延読み込み）をすることでレンダリングブロックを防ぐことができます。

ここでいうリソースとは、CSS、JavaScript、画像（imgタグ）のことを指します。

ファーストビューで使用されるCSSやJavaScriptはインライン化させ、それ以外は下記のソース例のように非同期読み込み（遅延読み込み）の指定をします。

CSSの非同期読み込み（遅延読み込み）rel=”preload”属性を利用したソース例

<head>
  <!-- Critical CSS はインライン -->
  <style>/* Critical CSS */</style>
  
  <!-- 非クリティカルCSS は非同期 -->
  <link rel="preload" href="non-critical.css" as="style" 
        onload="this.onload=null;this.rel='stylesheet'">
  <noscript><link rel="stylesheet" href="non-critical.css"></noscript>
</head>

media=”print”属性を使った条件付き読み込みの例

<!-- 印刷用CSS -->
<link rel="stylesheet" href="print.css" media="print">

<!-- 大画面用CSS -->
<link rel="stylesheet" href="desktop.css" media="(min-width: 1024px)">

<!-- 後で全メディア用に変更 -->
<link rel="stylesheet" href="styles.css" media="print" 
      onload="this.media='all'; this.onload=null;">

下記はJavaScriptのソース例です。

JavaScriptのasync属性を使用した非同期読み込み（遅延読み込み）ソース例

<!-- 実行順序が重要でないスクリプト -->
<script src="analytics.js" async></script>
<script src="social-widgets.js" async></script>

JavaScriptのdefer属性を使用した非同期読み込み（遅延読み込み）ソース例

<!-- DOM構築後に実行したいスクリプト -->
<script src="main.js" defer></script>
<script src="ui-components.js" defer></script>
<!-- defer は記述順で実行される -->

JavaScriptの動的読み込みソース例

<script>
// 条件付きで必要な場合のみ読み込み
function loadScript(src, callback) {
  const script = document.createElement('script');
  script.src = src;
  script.onload = callback;
  document.head.appendChild(script);
}

// 特定のイベント後に読み込み
document.addEventListener('DOMContentLoaded', function() {
  if (needsAdvancedFeatures) {
    loadScript('advanced-features.js');
  }
});
</script>

非同期読み込み（遅延読み込み）を実施することでファーストビューの必要最低限の読み込みだけで済むため、FCPの秒数も短縮できます。

JavaScriptの最適化について詳しくは「JavaScriptの速度改善方法」もご覧ください。

不要なリソースの削除

上記で説明したインライン化や非同期読み込み（遅延読み込み）の設定ができていたとしても、使用していないCSSやJavaScriptがある場合は削除しておくようにしましょう。

せっかく設定していても、無駄な読み込みやレンダリングブロックが発生してしまい表示速度の遅延に繋がります。

PageSpeed InsightsやChrome DevToolsのCoverageを活用して稼働していない不要なソースを発見することができます。

Coverageの方であれば下記のように具体的な部分まで探すことができます。

注意点としては、実際に使用していないと表示されるソースでもGTM（google tag manager）など設置しておく必要のあるものもあるため削除する際は必要か必要でないかチェックしながら進めましょう。

上記のように削除が必要な部分を探し、不必要なファイルもしくは不必要なソース部分を手動でそのまま削除することで改善に繋がります。

また、WordPressではfunctions.phpでの削除実装や、JavaScriptでの動的リソース管理が有効的です。

HTML・CSS・JavaScriptなどのサイズ圧縮

HTML・CSS・JavaScriptなどをそれぞれ圧縮することもFCPの表示速度改善に繋がります。

サイズが圧縮されることで読み込まれるまでの速度も早くなります。

圧縮例

圧縮前のソース例

<html>
  <head>
    <title>サンプルページ</title>
    <style>
      body {
        margin: 0;
        padding: 20px;
        font-family: Arial, sans-serif;
      }
    </style>
  </head>
</html>

圧縮後のソース例

<html><head><title>サンプルページ</title><style>body{margin:0;padding:20px;font-family:Arial,sans-serif}</style></head></html>

このようにHTMLの改行をなくし記述するだけでもファイルサイズの圧縮にも繋がります。

これは、CSSやJavaScriptも同様に改行を減らしてあげることで圧縮が可能です。

次世代フォーマットの活用と画像サイズの最適化

FCPにフォーカスした対策で言うと、特にファーストビューに出てくる画像が重要となります。

具体的にはJPGやPNGといった拡張子の画像を、AVIFやwebPといった次世代フォーマットの活用の実施です。

次世代フォーマットについては「次世代フォーマット画像とは？」をご覧ください。

品質設定

AVIF

WebP

JPEG

高圧縮

45KB

78KB

150KB

標準

75KB

125KB

180KB

高品質

120KB

200KB

250KB

目安ではありますが、変更することで30％〜50％どのファイル容量の軽減が期待できます。

また、レスポンシブ画像で最適なサイズ設定を行うことでファイルの読み込み速度も上げることができます。

レスポンシブ画像のサイズ設定では閲覧するデバイスに応じて画像の大きさが変わるため、デバイスに合わせて最善の容量で読み込むことができます。

デバイス別の画像サイズ最適化のソース例

<picture>
  <!-- スマートフォン用（小サイズ・高圧縮） -->
  <source media="(max-width: 480px)" 
          srcset="hero-mobile.avif 480w" 
          type="image/avif">
  <source media="(max-width: 480px)" 
          srcset="hero-mobile.webp 480w" 
          type="image/webp">
  
  <!-- タブレット用（中サイズ） -->
  <source media="(max-width: 768px)" 
          srcset="hero-tablet.avif 768w" 
          type="image/avif">
  <source media="(max-width: 768px)" 
          srcset="hero-tablet.webp 768w" 
          type="image/webp">
  
  <!-- デスクトップ用（大サイズ・高品質） -->
  <source media="(min-width: 769px)" 
          srcset="hero-desktop.avif 1200w, hero-desktop-2x.avif 2400w" 
          type="image/avif">
  <source media="(min-width: 769px)" 
          srcset="hero-desktop.webp 1200w, hero-desktop-2x.webp 2400w" 
          type="image/webp">
  
  <!-- フォールバック -->
  <img src="hero-desktop.jpg" 
       alt="Hero Image"
       width="1200" 
       height="600"
       fetchpriority="high">
</picture>

こうすることで、各デバイスで無駄な量の読み込みが発生しないため、FCPの初めのコンテンツ表示の表示速度の改善にもなります。

サーバーのキャッシュを使用する

サーバーのキャッシュとは、サーバーにWEBサイトのデータを一時的に保存しておくことを言います。

それにより、再度同じページを読み込む際にその保存したデータを読み込むため、サーバーへの処理が短縮されページの表示速度を短縮できFCPの数値も改善します。

また、サーバーで保存期間の設定もできるので、更新頻度の少ないページであれば、こちらの期間を長めに設定してあげるなどの設定で改善もされます。

CDN（コンテンツデリバリーネットワーク）の導入とキャッシュ利用

CDN（コンテンツデリバリーネットワーク）は、ユーザーから最も近いキャッシュサーバーのアクセス要求に応答することで、表示速度を高速化できます。

通常、ユーザーからサーバーまでの物理的距離が遠い場合は、読み込みに時間がかかるためコンテンツの配信の時間がかかります。

前述しているサーバーキャッシュとCDNを併用して導入でサーバーリクエストの短縮が見込めますのでFCPの改善にも役立ちます。

DNSサービスの選定

DNSのルックアップは初期コンテンツの表示速度にも影響します。

要はDNSを読み込むまでの速さも重要となります。

DNSサービスもサービスによってやや速度の違いがあります。おすすめはCloudflareを推奨します。

DNSプロバイダー

平均応答時間

FCP改善効果

Cloudflare

14ms

+高

Google DNS

20ms

+高

Quad9

25ms

+中

OpenDNS

35ms

+中

ISPデフォルト

80-200ms

基準

Cloudflareでは、DNSの接続を行う際に物理的に近くのサーバーにアクセスが行われるためレスポンスが早くなります。

また、DNSのプリフェッチ（Prefetch）やPreconnectの実装も速度改善に繋がります。

プリフェッチ（Prefetch）の実装例

<!DOCTYPE html>
<html>
<head>
    <!-- 重要なドメインを事前解決 -->
    <link rel="dns-prefetch" href="//fonts.googleapis.com">
    <link rel="dns-prefetch" href="//fonts.gstatic.com">
    <link rel="dns-prefetch" href="//cdn.example.com">
    <link rel="dns-prefetch" href="//analytics.google.com">
    
    <!-- Critical リソースは preconnect -->
    <link rel="preconnect" href="https://fonts.googleapis.com" crossorigin>
    <link rel="preconnect" href="https://cdn.example.com">
</head>
<body>
    <!-- DNS解決済みのため即座にリクエスト可能 -->
    <link rel="stylesheet" href="https://fonts.googleapis.com/css2?family=Roboto">
    <img src="https://cdn.example.com/hero-image.jpg">
    <script src="https://analytics.google.com/gtag.js"></script>
</body>
</html>

Preconnect による完全な事前接続例

<head>
    <!-- レベル1: DNS解決のみ（軽量） -->
    <link rel="dns-prefetch" href="//third-party-analytics.com">
    <link rel="dns-prefetch" href="//social-widgets.com">
    
    <!-- レベル2: DNS + TCP接続（中程度） -->
    <link rel="preconnect" href="https://fonts.googleapis.com">
    <link rel="preconnect" href="https://api.example.com">
    
    <!-- レベル3: 完全事前接続（重要リソース） -->
    <link rel="preconnect" href="https://cdn.example.com" crossorigin>
    <link rel="preconnect" href="https://critical-api.example.com" crossorigin>
</head>

フォントの読み込みに最適化をかける

フォントの読み込みもFCPの数値に影響があります。

font-displayオプションの最適化

基本はautoの値が一般的ですが、「swap」「fallback」「optional」を使い分けてあげるといいでしょう。

font-displayの値の最適化もすることで初期の読み込みも早くなりFCP数値の改善に繋がります。

値

動作

FCP影響

注意点

auto

ブラウザ判断

中程度

標準

swap

すぐフォールバック表示

良い

レイアウトシフト

fallback

100ms後フォールバック

良い

バランス型

optional

ネットワーク状況判断

最良

一貫性重視

font-displayオプションのソース例

@font-face {
  font-family: 'CustomFont';
  src: url('font.woff2') format('woff2');
  font-display: swap; /* 推奨設定 */
}

例でいうswapの箇所の値を変更して活用してみてください。

preloadを活用する

preloadを活用してファーストビューなど必要な部分のフォントだけ先に読み込むことで、表示速度にも影響を与えます。

下記は表示例となります。

<!-- 最重要フォントの事前読み込み -->
<link rel="preload" href="/fonts/main-font.woff2" 
      as="font" type="font/woff2" crossorigin>

<!-- DNS事前解決（Google Fonts使用時） -->
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>

フォントファイルを最適化する

フォントファイルの最適化も改善ポイントの一つとなります。

基本的には「woff2」を活用しますが「woff」や「ttf」もケースに応じて指定してあげるといいでしょう。

それぞれの特徴を表にまとめました。

フォーマット

サイズ削減効果

用途

WOFF2

TTFより30-50%削減 🏆
・最高の圧縮率
・Brotli圧縮技術

モダンWebサイト最適
・第一選択
・高速化重視
・モバイル対応

WOFF

TTFより20-40%削減
・中程度の圧縮率
・gzip圧縮技術

フォールバック用
・IE11対応
・古いブラウザサポート
・互換性重視

TTF

削減なし（基準）
・非圧縮
・最大ファイルサイズ

レガシー・非Web用途
・デスクトップアプリ
・印刷・DTP
・開発テスト

フォントファイル最適化のソース例

@font-face {
  font-family: 'OptimizedFont';
  src: url('font.woff2') format('woff2'),    /* 最優先 */
       url('font.woff') format('woff'),      /* フォールバック */
       url('font.ttf') format('truetype');   /* 古いブラウザ用 */
}

まとめ

FCPは、ユーザーがページにアクセスしてから最初のコンテンツが表示されるまでの時間を測定する重要な指標です。

FCPの改善は、ユーザーエクスペリエンスの向上だけでなく、SEOの観点からも非常に重要な要素です。

設定が難しいケースや知識がなく難しいと言う方は、是非一度LandingHubにご相談ください。

タグの設置一つで表示速度改善に役立てるツールとなります。

また、表示速度において詳しい知識を持ち合わせるスタッフもおりますのでご相談を承ります。

記事を書いた人

井上寛生

井上寛生

LandingHub 執行役員 / 事業責任者 / 技術責任者

大学院では情報工学を専攻し、修了後に株式会社TeNへ新卒入社。当時は社内唯一のエンジニアながら、開発部門をゼロから立ち上げ、採用・育成を一手に担い、全員が未経験からスタートした精鋭エンジニアチームを組成。2021 年にはWEBサイト高速化プラットフォーム「LandingHub」を立ち上げ、プロダクトオーナー兼事業責任者として企画・開発・グロースを牽引。現在は執行役員として、会社の技術戦略と事業成長の双方をリードしている。
コラム一覧に戻る