コンテンツに移動
Silktideヘルプ

ページ速度とウェブに関する主な指標

現代の検索においてページ速度とは、ページを高速に感じさせることです。つまり、メイン コンテンツがすばやく表示され、レイアウトが安定し、操作に遅延なく応答することを意味します。この体感を捉える 3 つのフィールド指標について Google が公表している名称が、です。Largest Contentful Paint（）、Interaction to Next Paint（）、Cumulative Layout Shift（）で構成されます。

このページでは、Fernwood が料金ページ、比較ページ、主要なガイドについて、モバイルで「良好」のしきい値を満たす必要があるとします。新規訪問者の大半と、AIアシスタント経由のクリックの多くはモバイルから訪れます。

この手法は、意図的に包括的なエンジニアリング マニュアルにはしていません。詳細な実装手順はすでに web.dev が提供しています。ここでは、意思決定の枠組みを説明します。指標の意味、重要度、Silktide を使った優先順位付け、そして修正のためにエンジニアをどこへ案内すべきかです。

なぜ有効なのか（どの程度重要か）

気にする対象は 2 つあります。

  • 訪問者。 LCP が遅く CLS が不安定だと、回答や CTA が表示される前に離脱されます。ランキングに問題がなくても、これはコンバージョン上の問題です。
  • 検索。 Google は、ページ エクスペリエンスの一環としてランキング システムでウェブに関する主な指標を使用し、検索で成功するには良好な指標を推奨すると述べています（ウェブに関する主な指標と Google 検索結果、ページ エクスペリエンスについて）。また Google は、ページ エクスペリエンスが不十分でも、検索では引き続き最も関連性の高いコンテンツを表示しようとすると述べています。したがって、これらの指標は実際のシグナルではありますが、魔法のようなランキング向上策ではありません。回答優先のコンテンツや権威性の代替ではなく、必須条件であり、他の条件が似たページ間でのタイブレーカーとして扱ってください。

特に AEO については、ページが高速だからといって AIアシスタントがあなたを引用するわけではありません。しかし、遅くてレイアウトがずれるページでは、そうした引用が送り込む人間の訪問者を失います。また、速度を損なう重いクライアントサイド レンダリングは、多くの場合、JavaScript なしで読めるコンテンツも損ないます。

重要な 3 つの指標

以下のしきい値は、実際のユーザーのおよそ 75 パーセンタイルで評価される Google の「良好」目標値です（フィールドデータ）。ラボツールは診断に使い、検索が評価するのはフィールドデータです。

指標測定内容良好
LCPメイン コンテンツが表示されるタイミング≤ 2.5 秒
INPページがクリックやタップに応答する速さ≤ 200 ミリ秒
CLS読み込み中にレイアウトがどの程度ずれるか≤ 0.1

詳細とデバッグの手順については、web.dev Vitals、LCP の最適化、INP の最適化、CLS の最適化を参照してください。

問題への取り組み方（Fernwood の作業順序）

1. 重要なページを選ぶ

すべてを一度に解決しようとしないでください。まず対象にするのは次のページです。

  • トラフィックの多いランディング ページとホームページ
  • 収益に直結するページ（料金、登録、主要な比較）
  • 引用されたい柱となるガイドと調査ページ

平凡なブログ アーカイブは後回しにできます。遅い料金ページは後回しにできません。

2. ラボ診断とフィールドの実態を分ける

  • ラボ（Silktide の速度テスト、Lighthouse、WebPageTest）：再現可能で、特定の URL とデバイス プロファイルにおける原因の特定に適しています。
  • フィールド（Chrome UX Report / Search Console のウェブに関する主な指標レポート、利用可能な場合は Silktide のアナリティクスなどの RUM）：実際の訪問者が体験した内容です。

両者の結果が異なっても、どちらかが間違っているとは限りません。デバイス、国、キャッシュ状態が異なるためです。フィールドでの不合格に明確に対応するラボ上の問題を修正してください。すでにフィールドのしきい値を通過している URL について、ラボでの完璧さを追い求めないでください。

Silktide の速度画面では、アナリティクスが接続されている場合、ラボ診断と実際の訪問者による測定値を組み合わせて確認できます。Web Vitalsチェックはラボのパフォーマンスを要約します。読み込みが遅いページとレイアウト シフトは、LCP と CLS をそれぞれ特定します。

3. スコアではなく原因を修正する

Silktide（または Lighthouse）が原因を示したら、その原因を修正します。

よくある原因代表的な指標Silktide / 次のステップ
巨大なヒーロー画像、遅いサーバー、レンダリングをブロックする CSS/JSLCP読み込みが遅いページ、LCP 画像をプリロード、画像最適化チェック
領域が確保されていない画像、広告、埋め込み要素、遅れて読み込まれるフォントCLSレイアウト シフト、画像サイズを明示的に指定
クリック時に実行される長時間の JavaScript タスクINP / TBTJavaScript の実行時間を削減、レンダリングをブロックするリソースを排除
全体的なバイト数の過多すべてバイト量を確認、最新の画像形式、キャッシュ

実装の詳細については、エンジニアは上記の web.dev ガイドを使用してください。フレームワーク固有のパターンは、このページで扱うべき頻度よりも速く変化します。

4. 同じ URL を再テストする

修正後は、同じデバイス プロファイルでラボテストを再実行し、その後フィールドデータが反映されるまで待ちます（CrUX の集計期間は複数週です）。スライド資料に載せたホームページだけの Lighthouse スクリーンショットではなく、重要な URL のフィールド ステータスで成功を判断してください。

正直な限界

  • 依然としてコンテンツが勝ちます。 高速でも中身のないページは、遅くても完全な回答に負けます。弱いページの速度改善は、見た目を整えているにすぎません。
  • サードパーティ。 タグマネージャー、チャット ウィジェット、A/B テストツールは、しばしば INP と LCP の大部分を占めます。これらを削除または遅延させるための社内調整に力を割いてください。自社の CSS を圧縮しても、同期的に読み込まれるサードパーティの重い処理は解決しません。
  • SPA / クライアントのみのレンダリング。 Fernwood のマーケティングサイトが空のシェルを配信している場合、ウェブに関する主な指標と AI クローラーの可読性の両方に苦戦している可能性があります。公開コンテンツには SSR/SSG を優先してください（JavaScript なしで読めるコンテンツ）。
  • 過剰最適化という見せかけ。 すでにフィールドで良好な URL のラボ LCP を 20 ミリ秒削ることは、比較ページにエビデンス ブロックがまだない状況では、エンジニアの時間を最も有効に使う方法であることはめったにありません。

Silktide が役立つ方法

関連項目

最終更新

このページは役に立ちましたか？