ページ速度はSEOにどれほど重要か | Googleコアウェブバイタル（LCP、FID、CLS）合格基準

Googleは公式に、Core Web Vitals（LCP 2.5秒以下、FID 100ms以下、CLS 0.1以下）が主要なランキング要因であると確認しました。そのため、モバイルページの75%がTop 3のランキングの機会を失っています。

Googlebotは1秒でタイムアウトするとクロールを停止するため、新しいコンテンツのインデックス作成が最大で47%遅延する可能性があります。ページの読み込みが1秒から5秒に増えると、直帰率は90%急増します（Adobeデータ）。モバイルユーザーの53%は、3秒以内に読み込まれない場合、すぐに離脱します。

HTTP Archiveによると、世界の平均LCPは2.9秒と高く（未達率62%）、サーバー応答時間を100ms短縮するごとにコンバージョン率が8.4%向上します。

LCP（Largest Contentful Paint）

想像してみてください：ウェブページを開いたら、白い画面かロード中のアイコンしか見えないとします。主要コンテンツが3秒以内に表示されなければ、すぐに閉じてしまいませんか？Googleの調査によると、ページの読み込みが2.5秒を超えると、ユーザーが離脱する確率は32%も上昇します。3秒を超えると、モバイルユーザーの53%が即座に離脱します。

これがLCPです。Largest Contentful Paint（最大コンテンツ描画時間）の略で、ページ上で「最も重要で大きな」コンテンツ（例：メイン画像、バナー、カバービデオなど）が表示されるまでの時間を測定します。ページ全体が読み込まれる時間ではなく、ユーザーが最初に注目する重要コンテンツが表示されるまでの時間を見ます。

LCPが1秒遅くなるごとに、コンバージョン率は7%下がる可能性があります！

LCPの「合格ライン」は？

GoogleはLCPのパフォーマンスを3つのレベルに分け、色で区別しています：

優秀（緑）: ≤ 2.5秒

—— これは目標基準です。Googleは訪問者の少なくとも75%がこの範囲内でLCPを経験する必要があり、これを「良好な体験」と見なします。

改善が必要（黄）: 2.5秒 ~ 4秒

—— 4分の1以上のユーザーがページを遅く感じ、直帰率は5%-10%上昇し、検索順位にも影響します。

低評価（赤）: > 4秒

—— 体験は非常に悪く、半数近くのユーザーが即座に離脱し、コンバージョン率は平均より20%-30%低下し、検索順位も大きく下がります。

ウェブサイトのLCPスコアを確認する方法

• PageSpeed Insights（PSI）: URLを入力するだけで、LCPの値、色分けのランク、実際のユーザーLCPデータを確認できます。

• Lighthouse: Chromeの開発者ツールに組み込まれており、読み込み速度をシミュレーションし、LCPスコアを取得できます（目標: 90以上）。

• Web Vitals拡張機能: Chromeプラグインで、LCP、FID、CLSをリアルタイムで表示します。

• Search Consoleレポート: 過去28〜90日間のあなたのサイトのすべてのページのLCPパフォーマンスをまとめ、どのページを最適化する必要があるかを教えてくれます。

目標は明確です: LCPを2.5秒以下に保ち、少なくとも75%の訪問がこの速度を達成することを目指します。

よくあるLCPの問題

LCPが遅くなる原因はさまざまですが、以下が最も一般的な問題です：

サーバーの応答が遅い（TTFBが長い）

—— サーバーの反応が遅いと、ページのコンテンツがすぐに表示されません。TTFB（Time To First Byte）は理想的には200ms以内、最大でも500msを超えてはいけません。

影響要因:

• サーバー性能の低さ
• データベースクエリが遅い
• CDN未使用、CMSが重い

ファーストビューのリソースが大きすぎる、または遅い

• 画像・動画が大きすぎる: 2MB、5MB以上、特にホームページの大きなビジュアル。WebPやAVIF形式を使うと、ファイルサイズを30%〜50%削減できます。

JavaScript/CSSによるレンダリングブロック: JSが大きすぎる、またはdefer/asyncが設定されていない、CSSの読み込み順序が不適切だとファーストビューの読み込みが遅くなります。

リソースの読み込み順序が混乱

—— ブラウザがどの要素がLCPの主要要素か判断できず、重要でないコンテンツを先に読み込んでしまう場合があります。preloadやfetchpriority="high"を使って、ブラウザに優先度を伝えると解決できます。

クライアントサイドレンダリング（CSR）の問題

—— React/Vueで作られたページでサーバーサイドレンダリングをしていない場合、ユーザーはJSが実行されるまで空白の画面しか見えません。JSが大きい（1MB以上）と実行が遅く、LCPは簡単に4秒を超えます。

CDN未使用またはCDN設定が不適切

—— ユーザーがサーバーから遠い場合（例：中国のユーザーが米国サーバーにアクセス）、読み込み速度が遅くなります。CDNはリソースをユーザーに近いノードに分配し、速度を大幅に向上させます。

サードパーティのスクリプトが多すぎる、または重い

—— 広告、分析ツール、トラッカーなどはメインスレッドを占有し、レンダリングを遅らせます。広告スクリプト1つだけでもページを500ms以上遅くすることがあります。

LCPの最適化方法

サーバー応答速度の向上（TTFB）

CDNを利用: CloudflareなどのCDNで画像、CSS、JSを配信すると、サーバーの負荷が減り、応答速度が速くなります。世界中のユーザーのアクセス速度は30%-70%向上することがあります。

サーバー性能の最適化: メモリを増設したり、データベースを最適化したり、キャッシュ（Redis、Memcached）を使ったり、実行環境をアップグレードしましょう。

良いホスティングを選ぶ: 共有ホスティングが遅い場合は、VPSや最適化されたクラウドサーバーに変更しましょう。月に少し費用を増やすだけで、LCPが1秒速くなり、コンバージョン率が大きく向上します。

画像と動画の最適化

最大コンテンツ要素（LCP）を特定: 通常はファーストビューのヒーロー画像や動画です。ツールでどれかを確認しましょう。

画像最適化のポイント:

• 適切なサイズ: 小さい画面に大きな画像を使わないでください。モバイルには小さめの画像、PCには大きめの画像を使いましょう。
• 最新フォーマット: JPGやPNGの代わりにWebPやAVIFを使うと、容量を大幅に削減できます。
• 圧縮: Squooshなどのツールで数百KB以下に圧縮しましょう。
• 遅延読み込み: ファーストビュー以下の画像はloading="lazy"を使います。ただし、LCP画像は遅延読み込みしないでください！

リソース読み込み優先度の調整

• 重要なリソースをプリロード: <link rel="preload">を使って、LCP要素（画像、CSS、フォントなど）を先に読み込みましょう。
• 優先度を上げる: fetchpriority="high"でブラウザに重要なリソースを伝えます。
• 重要でないJSを非同期で読み込む: 広告や解析スクリプトなどはasyncやdeferを使い、メインスレッドをブロックしないようにしましょう。

レンダリングブロックを軽減

• 重要なCSSをインライン化: ファーストビューに必要なスタイルはHTML内に直接書きましょう。15KB以下がベストです。
• SSR（サーバーサイドレンダリング）やSSG（静的生成）を活用: ReactやVueプロジェクトではNext.jsやNuxt.jsを使うと、サーバー側でHTMLを事前生成できます。これによりLCPを4～6秒から1～2秒に短縮できます。

サードパーティスクリプトの管理

• 整理と監査: 読み込み>500msまたは実行>300msの遅いスクリプトをツールで特定し、不要なら削除、削除できない場合は軽量なものに置き換えましょう。
• 遅延実行: 重要でないスクリプトはページロード後に実行（例：window.onload後）しましょう。
• サンドボックスで隔離: iframeを使ってリスクの高いスクリプトを隔離し、メインページのパフォーマンスに影響を与えないようにしましょう。

FID（初回入力遅延）

ユーザーがウェブページ上のボタン（例：「今すぐ購入」や「メニューを開く」）を初めてクリックしたとき、ページの反応が 300ms を超えると、76% のユーザーがページが遅いと感じます。

この待機時間を FID（初回入力遅延） と呼びます。これは、ユーザーが初めて操作した時点から ブラウザが反応を開始するまでの時間を測定するものです。

FIDはスクリプト全体の実行時間を見るのではなく、「ブラウザのメインスレッド」が他のタスクで占有されていてユーザー操作にすぐに応答できないかどうかを確認します。

なぜ遅くなるのか？

ブラウザは一度に一つの作業しかできません（メインスレッドは一つだけです）。クリック時にメインスレッドが大きな広告スクリプトを実行している場合、クリックの反応はその作業が終わるまで待つ必要があります。

Googleの2023年モバイルデータによると：

• FIDが300msを超えると、コンバージョン率が 22% 減少

• 100msの遅延ごとに、ユーザーの離脱率が 8% 増加

• ECサイトの決済ページでFIDが250msを超えると、カート放棄率が 18% 増加

📌 FIDは、実際のユーザーが最初にクリック、タップ、またはキーボード操作を行ってからブラウザが反応するまでの時間を測定します。シミュレーションテストだけでは完全に再現できず、実際のユーザーデータ（RUM）に基づく分析が必要です。

何ミリ秒なら「スムーズ」と言えるか？

GoogleのCore Web Vitalsは、過去28日間の実際のユーザーデータに基づき、FIDの評価基準を定めています：

合格ライン：
訪問の75%以上が 100ms以内であること、特にモバイル端末で。

推奨ツール：

• Chrome ユーザーエクスペリエンスレポート（CrUX）：ドメイン全体の FID 分布を確認

• PageSpeed Insights：シミュレーションと実データを組み合わせて確認

• Search Console：基準を満たすページの割合を確認

なぜクリックしても反応しないのか？

🔸 メインスレッドを占有する長いタスク

50ms以上実行されるJSスクリプトは「長いタスク」と見なされます。
例えば、最適化されていない広告スクリプトの読み込みはメインスレッドを 400ms以上ブロックする可能性があり、その間ユーザーのクリックは完全に無視されます。

🔸 JSファイルが大きすぎる

500KBを超えるJSファイルの読み込みは、特に低スペック端末では、解析だけで 800msかかることがあります。
ReactやVueなどのフレームワークを使う場合、ページ初期読み込み（hydrationフェーズ）で特に重く感じます。

🔸 サードパーティスクリプトが多すぎる

平均的に、1ページで 22以上のサードパーティリソースが読み込まれます。
例えば、ソーシャルメディアプラグインは低スペック端末で大きく差が出て、実行時間は 200msから800msまで変動します。

🔸 CPU負荷が高すぎる

中位スマホ（例：Snapdragon 6シリーズ）では、メインスレッドの占有率が 80%以上の場合、ユーザーのタップがキューに入り、待ち時間は 150msから1200msになる可能性があります。

💡 推奨ツール：

Chrome DevToolsの Performanceパネル を使って、長いタスクやメインスレッドのウォーターフォールを確認できます。

操作がカクつかないようにする方法

✅ 方法1：長いタスクを小分けにする

元々1つのタスクの実行に 120ms かかっていたため、ブラウザがユーザー操作を挟めませんでした。

// 分割後は各処理を30ms以内に抑える
function chunkedProcess() {
let index = 0;
function doChunk() {
const start = Date.now();
while (index < data.length && Date.now() – start < 30) {
processItem(data[index++]);
}
if (index < data.length) {
setTimeout(doChunk, 0); // メインスレッドを解放
}
}
doChunk();
}

効果：元々250msかかっていたタスクが最大32msに圧縮され、FIDが 85% 減少

✅ 方法2：JSの読み込み優先度を最適化

重要なJSコードはHTML内に直接書く（15KB以下）

重要でないJSスクリプトは遅延読み込み

<!– ファーストビューに不要なスクリプトは遅延読み込み –>
<script defer src=”non-critical.js”></script>

<!– 広告や分析スクリプトはページ読み込み後に挿入 –>
<script>
window.addEventListener(‘load’, () => {
const script = document.createElement(‘script’);
script.src = “ads.js”;
document.body.appendChild(script);
});
</script>

効果：メインスレッドの負荷が 40%～70% 減少

✅ 方法3：サードパーティコードを「隔離して実行」

iframeサンドボックスを使用:<iframe sandbox=”allow-scripts” src=”third-party-ad.html”></iframe>

これにより、サードパーティコードがメインスレッドに影響を与えません。

• 重いタスクはWeb Workerで処理

// メインスレッド
const worker = new Worker(‘crypto-worker.js’);
worker.postMessage(data);

// Worker内で重い処理を実行
self.onmessage = (e) => {
const result = heavyCryptoWork(e.data);
self.postMessage(result);
};

効果：例えば暗号化タスクがメインスレッドで 300ms → 20ms に短縮

CLS（累積レイアウトシフト）

ウェブページを開いたときに突然画面がジャンプして間違えてクリックしてしまったことはありませんか？これがCLSの問題です。

CLSは Cumulative Layout Shift（累積レイアウトシフト） の略で、ページ読み込み中の視覚的安定性を測定します。スコアは0から1までで、低いほどページが安定、高いほどジャンプが多くなります。Googleの推奨：CLSスコアは0.1以下が理想、0.05以下は優秀、0.25以上はすぐに最適化が必要です。

なぜCLSに注目すべきなのでしょうか？それはユーザー体験に直接影響し、場合によっては収益の損失につながるからです。例えば：

• CLSが0.2を超えると、平均で直帰率が25％上昇し、コンバージョン率は18％低下します;

• ページの読み込みがわずか100ミリ秒遅れるだけで、CLSのリスクが15％上がります;

• サイズが未定義の画像は、CLSイベントの65％を占めています;

• CLSを0.05以下に抑えられれば、ユーザーの定着率は20％向上し、平均セッション時間が30秒延びます。

CLSの基準ライン

GoogleはCLSの明確な基準を設定しています：0.1未満は合格、0.05未満は優秀、0.25以上は警告ライン。世界の90％のウェブサイトが0.1以下を目標にしているのには理由があります。

データによると：CLS < 0.1のページは平均離脱率が5％にすぎませんが、CLS > 0.25のページは離脱率が30％に達することもあります。特にECサイトやニュースサイトでは、CLSの中央値を0.08以下に保つ必要があり、標準偏差は0.02を超えないようにする必要があります。さもなければランキングやトラフィックに影響します。

遅延読み込みの問題も無視できません。ページ要素の読み込みが0.3秒遅れると、CLSスコアは約0.05上昇します。さらに広告に固定サイズ（例：400px × 200px）が設定されていない場合、CLSは0.15まで上がる可能性があります。

経済的な観点から見ると、CLSを適正に保つことで、コンバージョン率は安定して10％向上し、ROIも8％増加します。統計的には、65％のサイトで平均CLSは0.12ですが、合格ラインの中央値は0.07で、ピークが0.4を超えるページは平均で修正に3日かかり、コストは約500ドルかかります。

さらに、CLSの精度はデバイスの違いやページの複雑さも考慮する必要があります。ページ要素が100個を超える場合、CLSの許容範囲は±0.02以内に抑え、精度を95％に達する必要があります。さもなければ、離脱率が25％上昇し、利益が10％減少する可能性があります。

CLS のよくある問題

最初のタイプは 動的コンテンツの読み込み です。例えば、広告やポップアップが固定サイズを設定していない場合、読み込み時に他の要素を押し出してしまいます。この場合、シフトスコアは通常 0.1〜0.15 で、全体の 60% を占めます。そのたびにユーザーの操作の 5% が失われる可能性があります。

次に サードパーティスクリプトの遅延 です。多くのサイトがオンラインチャットやデータ分析のために外部スクリプトを読み込むと、200ms の遅延が発生し CLS が 0.05 増加します。このため、75% のサイトでユーザー体験が悪化します。例えば、あるECサイトのスクリプトが 10Mbps の帯域を占有し、ページ読み込みが 4 秒に遅延、CLS が 0.25 に急上昇し、離脱率が 20% 上昇しました。

三つ目は サイズ未定義の画像/動画 です。幅 800px、高さ 600px のコンテンツにサイズが設定されていないと、読み込み時に周囲の要素を押し出しやすくなります。これがシフトイベントの 45% を占め、CLS は ±20% 変動します。50 ページのサンプルでは 70% 以上が偏差し、修正コストは 1 回あたり約 200 ドルです。

次は 要素の重なり です。高さ 100px の div が密集して並ぶと、ページの負荷が 50% 増加し、CLS のリスクが 30% 上昇します。

時間的要因もあります: リソースの読み込みが 500ms を超え、これが 10 回繰り返されると CLS が 0.03 増加します。広告が 30 秒ごとに自動更新される場合、CLS のピークは 0.35 に達することがあります。

これらの問題を適時修正しないと、毎月 5〜10% の収益が失われる可能性があり、CLS は毎週 2% ずつ悪化する可能性があります。

CLS を効果的に改善する方法

第一歩は基本の「サイズを設定」です。すべての画像、広告、動画コンポーネントに事前に幅と高さ（例: 400px × 250px）を設定することで、40% のレイアウトシフト問題を削減できます。さらに CSS の max-width: 100% を追加すると、レスポンシブにも対応し、読み込み時間が約 0.2 秒短縮され、CLS リスクが 35% 減少します。

第二に、リソース読み込みを最適化します。画像を 500KB 以下に圧縮すればトリガー頻度が 70% 減少し、CLS が 0.1 低下します。また、フォントや動画などのリソースを 10MB 以下に抑え、読み込み時間を 100ms 以下にすることで、シフト発生率が 30% 減少します。

第三に、サードパーティスクリプトを処理します。非同期または遅延読み込みを推奨します。例えば外部ツールを 500ms 遅らせて読み込むことで、トリガー頻度を減らし、CLS の中央値を 0.05 に下げ、コンバージョン率は 10% 向上します。

動的コンテンツも「滑らか」に挿入する必要があります。50ms のアニメーション遷移を追加したり、20% のバッファスペースを確保することで、CLS の誤差を ±0.01 に抑え、読み込みがスムーズに見えるようにします。

最後に、適切なテストツールを使用することも重要です。Lighthouse と Chrome DevTools を推奨しており、精度は 95% に達します。1 週間追跡して回帰分析を行い、重点的に最適化すべき対象を特定します。

コスト面も経済的です。CLS を修正する平均費用は約 50 ドルで、最適化期間はわずか 1 日です。しかし効果は大きく、ユーザー維持率は 15% 上昇し、ウェブサイトの寿命は 2 年延び、CLS の中央値は 0.15 から 0.06 に下がり、変動幅は半分になり、最終的に収益は 5% 増加します。

今すぐ PageSpeed Insights であなたのサイトをチェックしてください — わずか 30 分で最も重要な最適化ポイントが見つかります！