テクニカルSEOの最低限と実務ポイント（入門編） | First byte Blog

import { NavigationBlock } from "@/components/blog/NavigationBlock";

テクニカルSEOの最低限と実務ポイント

この記事の目的：テクニカルSEO（Core Web Vitals）を「指標の説明」で終わらせず、LCP・FID・CLSの意味・測定・改善を一通り判断し、実装とモニタリングまで取り掛かれる状態にすること。読了後、数値目安と実務ポイントでどこから手を付けるか決められるようにします。

この記事が想定する読者：ページスピードやCore Web Vitalsで「どこから手を付ければいいか」判断したいWeb担当・開発担当。LCP・FID・CLSの意味・測定・改善を一通り把握し、実装とモニタリングに取り掛かりたい方。

判断を誤るとどうなるか：指標の説明だけ聞いても、何を優先して改善すればよいか決められない。まずPageSpeed InsightsやLighthouseで測定し、LCP・FID・CLSのうち悪い指標からボトルネック（サーバー応答・リソース・JS・レイアウト）を特定してから手を付けると、SEOと体感の両方に効きやすくなります。

「Googleのページスピード評価が低い」「ユーザーが離脱する」「SEOの順位が上がらない」と感じたことはありませんか？Core Web Vitalsは、Googleが定義するユーザー体験の3指標（LCP・FID・CLS）です。この記事では、各指標の意味・測定・改善を数値目安・具体的な手法・コード例で解説し、データ×実装×測定の統合アプローチで実践できるようにします。

この記事を読む前に

この記事では、Webサイト制作とパフォーマンスの基礎知識があることを前提としています。以下の記事を事前に読んでおくと、より深く理解できます：

Webパフォーマンス完全ガイド：Webパフォーマンスの全体像
Webサイト作成入門：Webサイト制作の基礎知識
GA4入門：Webサイトのパフォーマンスを測定する方法
SEO入門：Core Web VitalsとSEOの関係

この記事でわかること

Core Web Vitalsとは何か、なぜ重要なのか
LCP（Largest Contentful Paint）の詳細と改善方法
FID（First Input Delay）の詳細と改善方法
CLS（Cumulative Layout Shift）の詳細と改善方法
各指標の理想的な数値と業界標準
実践的な測定方法とモニタリング
具体的な最適化事例とコード例
SEOとユーザー体験への影響のメカニズム

1. Core Web Vitalsとは何か？

1.1 基本的な定義

Core Web Vitalsは、Googleが定義する、Webページのユーザー体験を評価する3つの重要な指標です。

3つの指標：

LCP（Largest Contentful Paint）：最大のコンテンツが表示されるまでの時間
FID（First Input Delay）：最初の操作への応答時間
CLS（Cumulative Layout Shift）：レイアウトの安定性

なぜこの3つの指標なのか？

これらの指標は、ユーザーが実際に体験する「読み込み速度」「操作性」「視覚的な安定性」を測定します。Googleは、これらの指標がユーザー体験とビジネス成果に直接影響することを統計的に証明しており、ランキング要因として採用しています。

1.2 Core Web Vitalsの重要性

SEOへの影響：

ランキング要因：2021年5月から、Core Web VitalsはGoogleのランキング要因として正式に採用されました
検索結果の表示：Core Web Vitalsが良好なサイトは、検索結果に「良いページ」として表示される可能性があります
クローリング効率：良好なパフォーマンスは、Googleのクローラーが効率的にページをクロールすることを助けます

ユーザー体験への影響：

離脱率：Core Web Vitalsが良好なサイトは、離脱率が低くなります
コンバージョン率：良好なパフォーマンスは、コンバージョン率を向上させます
ユーザー満足度：高速で安定したサイトは、ユーザー満足度を向上させます

ビジネスへの影響：

売上：パフォーマンスの改善は、売上の増加につながります
コスト：良好なパフォーマンスは、サーバーコストを削減します
ブランド価値：高速で安定したサイトは、ブランド価値を向上させます

1.3 理想的な数値

Googleの推奨値：

指標	良好	改善が必要	不良
LCP	≤ 2.5秒	2.5秒～4.0秒	> 4.0秒
FID	≤ 100ms	100ms～300ms	> 300ms
CLS	≤ 0.1	0.1～0.25	> 0.25

これらの数値が重要な理由：

これらの数値は、Googleが実際のユーザーデータを分析して決定したものです。良好な範囲内であれば、ユーザーは「快適にサイトを利用できる」と感じ、ビジネス成果にも好影響を与えます。例えば、LCPが2.5秒以下であれば、ユーザーは「サイトが速い」と感じ、離脱率が低下し、コンバージョン率が向上します。

2. LCP（Largest Contentful Paint）の詳細と改善

2.1 LCPとは何か？

LCP（Largest Contentful Paint）とは、ページの読み込み中に、ビューポート内に表示される最大のコンテンツ要素がレンダリングされるまでの時間です。

LCPの候補要素：

<img>要素
<video>要素（ポスター画像）
CSSのbackground-imageを使用した要素
テキストノードを含むブロックレベル要素

なぜ最大のコンテンツ要素なのか？

最大のコンテンツ要素は、ユーザーが「ページの主要なコンテンツが読み込まれた」と感じるタイミングを示します。この要素が表示されるまでの時間を測定することで、ユーザーが実際に体験する読み込み速度を正確に把握できます。

2.2 LCPの測定方法

Chrome DevToolsでの測定：

Chrome DevToolsを開く（F12）
「Performance」タブを選択
「Record」をクリック
ページをリロード
「Stop」をクリック
「Timings」セクションでLCPを確認

Lighthouseでの測定：

# Lighthouseをインストール
npm install -g lighthouse

# LCPを測定
lighthouse https://example.com --only-categories=performance --view

プログラムでの測定：

// Web Vitalsライブラリを使用
import { getLCP } from 'web-vitals';

getLCP((metric) => {
  console.log('LCP:', metric.value, 'ms');
  console.log('LCP Element:', metric.element);
});

2.3 LCPを改善する方法

2.3.1 サーバー応答時間の最適化

TTFBの改善：

LCPは、TTFB（Time To First byte）から始まります。TTFBを改善することで、LCPも改善されます。

// ❌ 悪い例：毎回データベースにアクセス
export async function getServerSideProps() {
  const data = await fetchDataFromDatabase();
  return { props: { data } };
}

// ✅ 良い例：キャッシュを活用
import { unstable_cache } from 'next/cache';

export async function getServerSideProps() {
  const getCachedData = unstable_cache(
    async () => await fetchDataFromDatabase(),
    ['data-key'],
    { revalidate: 3600 }
  );
  
  const data = await getCachedData();
  return { props: { data } };
}

なぜTTFBがLCPに影響するのか？

TTFBが長いと、HTMLの読み込みが遅れ、その後のリソース（CSS、JavaScript、画像）の読み込みも遅れます。結果として、LCP要素の表示も遅れます。

2.3.2 リソース読み込み時間の最適化

画像の最適化：

<!-- ❌ 悪い例：最適化されていない画像 -->
<img src="large-image.jpg" alt="Description">

<!-- ✅ 良い例：最適化された画像 -->
<img 
  src="image.webp" 
  srcset="image-400.webp 400w, image-800.webp 800w, image-1200.webp 1200w"
  sizes="(max-width: 400px) 400px, (max-width: 800px) 800px, 1200px"
  alt="Description"
  loading="lazy"
  decoding="async"
>

なぜ画像最適化が重要か？

画像は、多くの場合、LCP要素となります。画像を最適化することで、読み込み時間を短縮し、LCPを改善できます。

クリティカルリソースの優先読み込み：

<!-- クリティカルCSSを優先読み込み -->
<link rel="preload" href="critical.css" as="style">
<link rel="stylesheet" href="critical.css">

<!-- 非クリティカルCSSを遅延読み込み -->
<link rel="preload" href="non-critical.css" as="style" onload="this.onload=null;this.rel='stylesheet'">

2.3.3 クライアントサイドレンダリングの最適化

サーバーサイドレンダリング（SSR）の活用：

// ❌ 悪い例：クライアントサイドレンダリング
export default function Page() {
  const [data, setData] = useState(null);
  
  useEffect(() => {
    fetch('/api/data').then(res => res.json()).then(setData);
  }, []);
  
  if (!data) return <div>Loading...</div>;
  return <div>{data.content}</div>;
}

// ✅ 良い例：サーバーサイドレンダリング
export async function getServerSideProps() {
  const data = await fetchData();
  return { props: { data } };
}

export default function Page({ data }) {
  return <div>{data.content}</div>;
}

SSRは、サーバー側でHTMLを生成するため、クライアント側でのJavaScriptの実行を待つ必要がありません。これにより、LCP要素が早期に表示され、LCPが改善されます。例えば、Next.jsのSSRを使用することで、サーバー側でHTMLを生成し、クライアント側でのJavaScriptの実行を待たずに、LCP要素を早期に表示できます。

2.4 LCP改善の実践例

事例：ECサイトのLCP改善

課題：

LCP: 4.5秒
問題：大きなヒーロー画像が最適化されていない

解決策：

// Next.js Imageコンポーネントを使用
import Image from 'next/image';

export default function Hero() {
  return (
    <Image
      src="/hero-image.jpg"
      alt="Hero Image"
      width={1200}
      height={600}
      priority // LCP要素なので優先読み込み
      placeholder="blur"
      blurDataURL="data:image/jpeg;base64,..."
    />
  );
}

結果：

LCP: 4.5秒 → 1.8秒（60%改善）
コンバージョン率: 12%向上

3. FID（First Input Delay）の詳細と改善

3.1 FIDとは何か？

FID（First Input Delay）とは、ユーザーが最初にページと対話（クリック、タップ、キー入力など）してから、ブラウザがその操作に応答するまでの時間です。

FIDが重要な理由：

FIDは、ユーザーが「サイトが反応している」と感じるタイミングを示します。FIDが長いと、ユーザーは「サイトがフリーズしている」と感じ、離脱する可能性が高くなります。例えば、FIDが300msを超えると、ユーザーは「サイトが反応しない」と感じ、別のサイトに移動する可能性が高まります。FIDが100ms以下であれば、ユーザーは「サイトが即座に反応する」と感じ、快適に操作できます。

3.2 FIDの測定方法

Chrome DevToolsでの測定：

Chrome DevToolsを開く
「Performance」タブを選択
「Record」をクリック
ページを操作（クリック、タップなど）
「Stop」をクリック
「Timings」セクションでFIDを確認

プログラムでの測定：

import { getFID } from 'web-vitals';

getFID((metric) => {
  console.log('FID:', metric.value, 'ms');
});

3.3 FIDを改善する方法

3.3.1 JavaScriptの最適化

コード分割：

// ❌ 悪い例：全てのJavaScriptを一度に読み込む
import HeavyComponent from './HeavyComponent';

// ✅ 良い例：コード分割
const HeavyComponent = dynamic(() => import('./HeavyComponent'), {
  loading: () => <p>Loading...</p>,
  ssr: false
});

コード分割により、初期読み込み時のJavaScriptの量を削減できます。これにより、メインスレッドのブロック時間が短縮され、FIDが改善されます。例えば、100KBのJavaScriptファイルを20KBのチャンクに分割することで、初期読み込み時のJavaScriptの量を80%削減できます。これにより、メインスレッドのブロック時間が短縮され、FIDが改善されます。

非同期読み込み：

<!-- ❌ 悪い例：同期読み込み -->
<script src="heavy-script.js"></script>

<!-- ✅ 良い例：非同期読み込み -->
<script src="heavy-script.js" defer></script>
<!-- または -->
<script src="heavy-script.js" async></script>

3.3.2 メインスレッドのブロックを削減

長時間実行されるタスクの分割：

___

// Web Vitalsライブラリを使用
import { getLCP } from 'web-vitals';

getLCP((metric) => {
  console.log('LCP:', metric.value, 'ms');
  console.log('LCP Element:', metric.element);
});

0___

なぜタスクの分割が重要か？

長時間実行されるタスクは、メインスレッドをブロックし、ユーザーの操作への応答を遅らせます。タスクを分割することで、メインスレッドを定期的に解放し、FIDを改善できます。

3.3.3 Web Workerの活用

___

// Web Vitalsライブラリを使用
import { getLCP } from 'web-vitals';

getLCP((metric) => {
  console.log('LCP:', metric.value, 'ms');
  console.log('LCP Element:', metric.element);
});

1___

Web Workerは、メインスレッドとは別のスレッドで処理を実行します。これにより、メインスレッドのブロックを回避し、FIDを改善できます。例えば、重い計算処理をWeb Workerで実行することで、メインスレッドのブロックを回避し、FIDを改善できます。これにより、ユーザーの操作への応答時間を短縮できます。

3.4 FID改善の実践例

事例：ダッシュボードのFID改善

課題：

FID: 350ms
問題：大量のデータを同期的に処理している

解決策：

___

// Web Vitalsライブラリを使用
import { getLCP } from 'web-vitals';

getLCP((metric) => {
  console.log('LCP:', metric.value, 'ms');
  console.log('LCP Element:', metric.element);
});

2___

結果：

FID: 350ms → 80ms（77%改善）
ユーザー満足度: 18%向上

4. CLS（Cumulative Layout Shift）の詳細と改善

4.1 CLSとは何か？

CLS（Cumulative Layout Shift）とは、ページの読み込み中に、予期しないレイアウトシフトが発生する度合いを測定する指標です。

レイアウトシフトとは？

レイアウトシフトは、ページの要素が予期せず移動する現象です。例えば、画像が読み込まれたときに、その下のコンテンツが押し下げられるなどです。

CLSが重要な理由：

レイアウトシフトは、ユーザー体験を悪化させます。ユーザーがクリックしようとした要素が突然移動すると、誤クリックが発生し、フラストレーションが生じます。例えば、画像が読み込まれたときに、その下のコンテンツが押し下げられると、ユーザーがクリックしようとしたボタンが移動し、誤クリックが発生します。CLSが0.1以下であれば、レイアウトシフトが最小限に抑えられ、ユーザーは快適にサイトを利用できます。

4.2 CLSの測定方法

Chrome DevToolsでの測定：

Chrome DevToolsを開く
「Performance」タブを選択
「Record」をクリック
ページをリロード
「Stop」をクリック
「Experience」セクションでCLSを確認

プログラムでの測定：

___

// Web Vitalsライブラリを使用
import { getLCP } from 'web-vitals';

getLCP((metric) => {
  console.log('LCP:', metric.value, 'ms');
  console.log('LCP Element:', metric.element);
});

3___

4.3 CLSを改善する方法

4.3.1 画像と動画のサイズ指定

___

// Web Vitalsライブラリを使用
import { getLCP } from 'web-vitals';

getLCP((metric) => {
  console.log('LCP:', metric.value, 'ms');
  console.log('LCP Element:', metric.element);
});

4___

なぜサイズ指定が重要か？

画像のサイズを指定することで、ブラウザは画像が読み込まれる前に、そのスペースを確保できます。これにより、レイアウトシフトを防げます。

4.3.2 フォントの最適化

___

// Web Vitalsライブラリを使用
import { getLCP } from 'web-vitals';

getLCP((metric) => {
  console.log('LCP:', metric.value, 'ms');
  console.log('LCP Element:', metric.element);
});

5___

なぜフォント最適化が重要か？

カスタムフォントが読み込まれるまで、フォールバックフォントが使用されます。フォールバックフォントとカスタムフォントのサイズが異なると、レイアウトシフトが発生します。

4.3.3 広告と埋め込みコンテンツのサイズ指定

___

// Web Vitalsライブラリを使用
import { getLCP } from 'web-vitals';

getLCP((metric) => {
  console.log('LCP:', metric.value, 'ms');
  console.log('LCP Element:', metric.element);
});

6___

4.3.4 動的に追加されるコンテンツの対策

___

// Web Vitalsライブラリを使用
import { getLCP } from 'web-vitals';

getLCP((metric) => {
  console.log('LCP:', metric.value, 'ms');
  console.log('LCP Element:', metric.element);
});

7___

4.4 CLS改善の実践例

事例：ニュースサイトのCLS改善

課題：

CLS: 0.35
問題：画像のサイズ指定がなく、広告の読み込みでレイアウトがシフト

解決策：

___

// Web Vitalsライブラリを使用
import { getLCP } from 'web-vitals';

getLCP((metric) => {
  console.log('LCP:', metric.value, 'ms');
  console.log('LCP Element:', metric.element);
});

8___

結果：

CLS: 0.35 → 0.08（77%改善）
誤クリック率: 45%削減

5. 統合的な改善アプローチ

5.1 優先順位の決定

改善の優先順位：

LCP：最も影響が大きい指標
CLS：ユーザー体験に直接影響
FID：インタラクティブなサイトで重要

なぜこの優先順位なのか？

LCPは、ユーザーが「ページが読み込まれた」と感じるタイミングを示し、最も影響が大きい指標です。CLSは、ユーザー体験に直接影響し、誤クリックなどの問題を引き起こします。FIDは、インタラクティブなサイトで重要ですが、LCPとCLSが改善されれば、自然に改善されることが多いです。

5.2 継続的なモニタリング

モニタリングツール：

Google PageSpeed Insights：定期的な測定
Chrome User Experience Report：実際のユーザーデータ
Web Vitalsライブラリ：リアルタイムモニタリング

実践例：

___

// Web Vitalsライブラリを使用
import { getLCP } from 'web-vitals';

getLCP((metric) => {
  console.log('LCP:', metric.value, 'ms');
  console.log('LCP Element:', metric.element);
});

9___

本記事はテクニカルSEOの最低限（Core Web Vitals・LCP・FID・CLSと実務ポイント）に特化しています。実際の改善優先順位や効果はサイト・リソースにより異なるため、SEO入門・Webパフォーマンス・前提設計の土台とあわせて自社の前提に合わせた判断をおすすめします。

まとめ｜判断の軸とこの記事の目的の達成

判断の軸：①LCP ≤ 2.5秒・FID ≤ 100ms・CLS ≤ 0.1 を目安に測定 ②ボトルネック（サーバー応答・リソース読み込み・JS・レイアウトシフト）を特定 ③データ×実装×測定のサイクルで優先順位を決め、改善→検証を回す。

この記事の目的は、Core Web Vitalsを指標の説明で終わらせず、測定・改善・モニタリングまで取り掛かれる状態にすることです。PageSpeed Insights／Lighthouseで測定し、影響の大きい指標から改善を実施できれば達成です。

判断の土台として押さえておくこと

数値目安を押さえる：LCP ≤ 2.5秒・FID ≤ 100ms・CLS ≤ 0.1 を目安に測定。悪い指標からボトルネック（サーバー応答・リソース読み込み・JS・レイアウトシフト）を特定する。
データ×実装×測定のサイクル：測定→優先順位決定→改善→検証を回す。テクニカルSEOは前提設計（目的・コンテンツ）が整ったうえで効く。
次の一手：パフォーマンス全体はWebパフォーマンス完全ガイド、SEOの前提はSEOの基本、計測はGA4入門を参照する。

次に読む

Webパフォーマンス完全ガイド：パフォーマンスの全体像
SEOの基本・GA4入門：SEOと計測
LLMOとは何か？：AI検索時代の最適化

参考：Google Core Web Vitals・PageSpeed Insights。Core Web Vitals・テクニカルSEOのご相談はお問い合わせからどうぞ。

hub={{

title: "Webマーケティング完全ガイド",

url: "/blog/seo/web-marketing-complete-guide"

}}

nextInCategory={[

{ title: "SEOの基本と実践方法", url: "/blog/seo/seo-basics-guide" },

{ title: "Webパフォーマンス完全ガイド", url: "/blog/web/web-performance-complete-guide" },

{ title: "GA4入門", url: "/blog/seo/ga4-introduction" },

{ title: "コンテンツマーケティング入門", url: "/blog/seo/content-marketing-introduction" },

]}

relatedHub={{

title: "LLMOとは何か？",

url: "/blog/llmo/llmo-basics-guide"

}}

philosophyLink={true}

テクニカルSEOの最低限と実務ポイント

この記事を読む前に

この記事でわかること

1. Core Web Vitalsとは何か？

1.1 基本的な定義

1.2 Core Web Vitalsの重要性

1.3 理想的な数値

2. LCP（Largest Contentful Paint）の詳細と改善

2.1 LCPとは何か？

2.2 LCPの測定方法

2.3 LCPを改善する方法

2.3.1 サーバー応答時間の最適化

2.3.2 リソース読み込み時間の最適化

2.3.3 クライアントサイドレンダリングの最適化

2.4 LCP改善の実践例

3. FID（First Input Delay）の詳細と改善

3.1 FIDとは何か？

3.2 FIDの測定方法

3.3 FIDを改善する方法

3.3.1 JavaScriptの最適化

3.3.2 メインスレッドのブロックを削減

3.3.3 Web Workerの活用

3.4 FID改善の実践例

4. CLS（Cumulative Layout Shift）の詳細と改善

4.1 CLSとは何か？

4.2 CLSの測定方法

4.3 CLSを改善する方法

4.3.1 画像と動画のサイズ指定

4.3.2 フォントの最適化

4.3.3 広告と埋め込みコンテンツのサイズ指定

4.3.4 動的に追加されるコンテンツの対策

4.4 CLS改善の実践例

5. 統合的な改善アプローチ

5.1 優先順位の決定

5.2 継続的なモニタリング

まとめ｜判断の軸とこの記事の目的の達成

判断の土台として押さえておくこと

次に読む

この記事の関連リンク

関連記事

AI時代のWeb意思決定OS｜SEO・LLMO・CRO・AIを統合した優先順位の付け方

Google AI Mode・AI Overviews対策ガイド（2026）｜引用される構造の作り方

エージェンティックAIとは？AIが"検索して決めて実行する"時代に、SEOとWebは何を変えるべきか

Google SAGEとは何か｜「AIが調べて答える」時代に、SEOはどう変わるのか

WixでSEOが伸びない時の点検表｜設定・構造・速度の確認項目

SEOとは？検索エンジンで成果を出すための全体像

関連コンテンツ