サイトスピードとは｜意味・使い方・関連用語をわかりやすく解説

『サイトスピード』って、ぶっちゃけ何のことか、ちゃんと説明できますか?

株式会社Cameen 西村温裕ことおんゆーです。

近年、SEO対策・UX改善・コンバージョン最適化、こういう文脈で「サイトスピード」という言葉を見かけることが増えました。Googleが2021年にCore Web Vitalsをランキング要因として正式採用して以降、サイトスピードは「SEO対策の一部」として広く語られるようになっています。

でも、いざ「サイトスピードって具体的にどう測る?」「何秒なら速い?」「改善するならどこから手をつける?」と聞かれると、答えに詰まる方が多いんですよね。「ページが速く開けばいい」という認識で止まって、サイトスピードの本質的な役割まで理解している人は意外と少ない。これ、自分だけだと思ってませんか?

うちの事業ではWordPress複数サイトを運用しています。onyou0720.com・cameen.jp・stylo-education系・CBCマートなど合計6サイトを日々運用しながら、サイトスピード改善を継続的に取り組んできました。その中で見えてきたのは、サイトスピードは単なる「秒数」ではなく、「ユーザーの体感速度とGoogleの技術評価が一致する地点を狙う指標」だということ。速ければ良いのではなく、3つの指標バランスが本質です。

もう1つ繰り返し観察したのは、「速度改善に時間をかけたのに、コンバージョンが伸びない運営者」が多いという事実。これは秒数だけ追って、Core Web Vitalsの3指標(LCP・INP・CLS)を区別せずに改善しているケースが大半。表示が速くなっても、操作レスポンスが遅ければユーザーは離脱します。指標を分けて見る発想が決定的に重要です。

今回はその「今さら聞けないサイトスピード」を、表面的な解説ではなく、Core Web Vitals 3指標の構造と、うちで運用してきた改善優先順位の判断軸まで一気に深掘りしていきます。読み終わる頃には、自分のサイトのどこから手をつけるべきか、紙に書き出せるレベルになっているはずです。

結論:サイトスピードの核心は「秒数」ではなく「Core Web Vitals 3指標」

サイトスピードの本当の正体は、「ユーザーの体感速度を3つの観点(視覚的安定・操作可能性・反応性)で分解し、それぞれに数値目標を設定して管理する技術指標群」のことです。単一の秒数で測るものではなく、複数の指標を組み合わせて評価します。

業界の体感として、Googleが公式に採用しているのがCore Web Vitalsという3指標。LCP(Largest Contentful Paint:最大の要素が描画されるまでの時間)、INP(Interaction to Next Paint:操作への反応時間)、CLS(Cumulative Layout Shift:画面のガタつき量)、この3つです。各指標に「良好」「改善が必要」「不良」の閾値があり、Search ConsoleでURL単位で判定されます。

3指標の基準値はこうです。LCPは2.5秒以下が良好、INPは200ミリ秒以下が良好、CLSは0.1以下が良好。これを75パーセンタイル(実ユーザーの75%以上が達成)で判定するのがGoogleの仕様です。1秒で表示されても、INPが500ミリ秒だと「不良」判定になるんですよね。秒数だけでは足りないんです。

サイトスピードの真の価値は「ユーザー離脱率の低下」と「Google検索ランキングへの寄与」の同時達成にあります。Googleの公開資料では、ページ表示が1秒から3秒に遅延すると直帰率が32%上昇、5秒だと90%上昇というデータが共有されています。速度はUX指標であり、SEO指標であり、収益指標でもある、こういう3層構造が本質です。

なぜサイトスピードがビジネス指標として重要視されるのか

もう少し深く掘ります。なぜサイトスピードはここまでビジネス指標として重要視されるのか。背景を整理します。

サイトスピードの重要性が認知されたのは2010年代後半。Googleが2018年に「Speed Update」を発表し、モバイル検索のランキング要因として速度を組み込んだのが転換点です。それまで「速度はUX上望ましいもの」程度の認識だったのが、「SEO上必須の指標」になりました。

2020年に発表されたCore Web Vitalsは、業界に大きなインパクトを与えました。Googleが「ユーザー体験を数値化できる」という前提を全面に出し、3指標(LCP・FID→INPに置換・CLS)を公開したことで、Web運営者全員が同じ物差しで議論できるようになった。これは業界の標準化として画期的でした。

業界の体感として、サイトスピードを軽視するとビジネスへの直接的なダメージが大きい。Amazonの公開資料では「ページ表示が0.1秒遅くなると売上が1%減」と報告されています。Walmartは「1秒の改善で2%のCV向上」、Pinterestは「LCP改善でユーザー登録率15%向上」など、業界各社が改善効果を数値で公開してきました。

日本市場でも、モバイル端末経由のアクセスが7割を超える現在、サイトスピードはECサイト・メディアサイト・SaaS・LP、すべてのWebプロパティで最優先課題になっています。特に4G/5G環境下のユーザーは「2秒以内」を期待するため、3秒を超えると一気に離脱が増える構造です。

2024年3月にGoogleはFID(First Input Delay)指標を廃止し、INP(Interaction to Next Paint)に置換しました。これは「初回タップだけでなく、ページ操作全体の反応性」を測る新指標です。ユーザーがページ内で複数回クリック・スクロール・入力する現実に合わせた進化で、サイトスピード管理の難易度が一段上がりました。

業界の進化として、Web運営者の関心は「速度を上げる」から「速度を維持しながら機能を増やす」にシフトしています。JavaScript肥大化・サードパーティタグ増加・画像高解像度化、こうした「機能追加によるパフォーマンス劣化」と継続的に戦う領域に変わってきました。サイトスピードは一度改善して終わりではなく、運用継続が前提の指標です。

サイトスピード低下時にユーザーの頭の中で何が起きているか

サイトスピードが低下したとき、ユーザーの頭の中で何が起きているか。5段階で整理します。

段階1:タップ直後の「白い画面」の不安(0〜1秒)

ユーザーがリンクをタップした直後、画面が真っ白なまま固まる時間。ここで「ちゃんと読み込まれてる?」「壊れた?」という不安が芽生えます。1秒以内に何かしらの視覚的反応(背景色・ロゴ・スケルトンUI)がないと、ユーザーは「遅い」と判断します。

このフェーズで重要なのがFCP(First Contentful Paint)指標。最初のコンテンツが画面に表示されるまでの時間で、1.8秒以下が良好基準。FCPが遅いと、ユーザーは「何も起きていない」と感じて戻るボタンを押します。

段階2:メインコンテンツが見えるまでの「待ち時間」(1〜2.5秒)

ヘッダーや背景色は出たけれど、肝心の本文・商品画像・記事タイトルが出てこない時間帯。ここで測られるのがLCP(Largest Contentful Paint)、最大要素の描画時間です。2.5秒以下が良好基準で、これを超えると「このサイト重いな」という印象が定着します。

LCPの主犯はだいたいヒーロー画像・動画・大きなテキストブロック。WebP変換していない大型画像、preload設定なしのフォント、レンダリングブロックするCSSが原因として頻出します。改善余地が大きい指標で、ここで2〜3秒削れるサイトが多い。

段階3:タップ・スクロールへの反応が遅い「フリーズ感」

表示はされたけれど、ボタンをタップしても反応がない、スクロールがカクつく、入力フォームが固まる、こういう操作不能感。ここで測られるのがINP(Interaction to Next Paint)、操作からの反応時間です。200ミリ秒以下が良好基準。

INPの主犯は重いJavaScript・サードパーティタグ・無限スクロール。Google Tag Manager経由でタグを増やしすぎる、解析スクリプトを5社分入れる、こういう運営判断がINPを悪化させる典型です。表示は速くてもINPが遅いと「使えないサイト」と評価されます。

段階4:画面のガタつきによる「誤タップ」のストレス

読もうとした文字が突然下にズレる、押そうとしたボタンが画面外に移動する、こういう画面のガタつき。ここで測られるのがCLS(Cumulative Layout Shift)、累積レイアウトシフト量です。0.1以下が良好基準。

CLSの主犯は画像のサイズ指定なし・広告挿入・遅延読み込みフォント・動的バナー。img要素にwidth/height属性を書かないと、画像読み込み時に下のコンテンツが押し下げられてCLSが悪化します。意外と見落とされる指標ですが、誤タップによる離脱を直接生み出す要因です。

段階5:再訪意欲の喪失と「次は別サイト」の決断

上記4段階のどれか一つでも顕著に悪いと、ユーザーは「このサイトは使いにくい」と記憶します。次回同じ検索結果に並んでも、無意識のうちにクリックを避けます。SEOランキングへの影響以前に、リピート訪問率が下がる構造が出来上がります。

業界の体感として、サイトスピードの3指標すべてが「良好」を維持できているサイトは全体の40〜50%。残りの半分以上は何かしらの指標で改善余地がある状態です。逆に言えば、3指標を整えるだけで上位50%に入れる構造でもあります。手をつける価値が大きい領域です。

身近な話で全体像をつかむ

ちょっと身近な話で、全体像を掴み直しましょう。

サイトスピードは、ファミリーレストランの接客体験に置き換えるとわかりやすい。あなたがファミレスに入店した時のことを思い出してください。入口の自動ドアが開くのが遅い、案内係がなかなか出てこない、席に着いてから水が来るまで5分待つ、メニューを開いてもサンプル写真が読み込まれない、注文ボタンを押しても反応がない、料理が運ばれてきた瞬間に隣のテーブルが移動して通路がふさがれる、こういう一連の体験。

これ、まんまサイトスピードの3指標と同じ構造なんです。「水が出るまでの時間」=LCP、「注文ボタンの反応速度」=INP、「席のレイアウト変更による戸惑い」=CLS。料理の味(コンテンツの質)がどれだけ良くても、接客体験(サイトスピード)が悪いと「もうこの店は使わない」と思いますよね。

業界の体感として、ファミレス経営者がやることはサイトスピード改善と同じ。注文取りまでの導線設計、厨房オペレーションの効率化、配膳ロボット導入、メニュー写真の事前共有、テーブル配置の固定。一つ一つは小さな改善ですが、合計するとリピート率が大きく変わります。

もう一つの例として、コンビニのレジ精算。バーコードを読ませてから決済完了までの時間。読み取りが遅い、決済端末の反応が悪い、レシートが出てくるのに5秒、こういう一つ一つの遅延が積み重なると、客は「あの店は時間がかかる」と覚えます。サイトスピードも同じで、各指標の小さな遅延が積み重なって離脱を生む構造です。

逆に、Amazonのレジなし店舗「Amazon Go」のように「商品を手に取って店を出るだけ」の体験は、サイトスピードの理想形に近い。LCPゼロ・INPゼロ・CLSゼロを目指す方向性です。ただし、これを実装するには莫大な技術投資が必要で、現実的にはCore Web Vitalsの基準値を確実にクリアすることが運営者の到達点になります。

サイトスピード改善は、ファミレスのオペレーション改善と同じで、現場の小さな積み重ねが顧客の印象を決めます。一度の大改修ではなく、毎月のように測定して、ボトルネックを潰し続ける運用です。これが大事なんです。

サイトスピードを構成する5要素と改善優先順位

要素1:画像最適化(効果:大・コスト:小)

もっとも効果が大きく、実装コストが低い改善領域。WebP/AVIF形式への変換、適切なサイズ指定、loading=”lazy”属性、preload設定、レスポンシブ画像、こういう基本対応で2〜3秒のLCP短縮が見込めます。

WordPressサイトの場合、EWWW Image OptimizerやImagify、Smushなどのプラグインで一括変換できます。手動の場合、Squoosh等のツールで個別変換。画像にwidth/height属性を必ず設定することでCLSも同時改善できます。サイトスピード改善の入口として、まず手をつける領域。

要素2:JavaScript・CSSの最適化(効果:大・コスト:中)

JavaScriptの実行時間がINPに直結します。サードパーティスクリプト(解析タグ・広告タグ・ヒートマップ・チャットボット)が増えすぎるとINPが悪化します。1サイトあたりサードパーティタグは10個以下が業界の標準目安。

改善手法は、(1)不要なJavaScriptの削除、(2)defer/async属性で遅延読み込み、(3)Code Splitting(必要なコードだけ読み込む)、(4)Tree Shaking(未使用コードの削除)、(5)Critical CSSのインライン化。WordPressならAutoptimize、WP Rocket、Perfmattersなどのプラグインで対応できます。

要素3:サーバーレスポンス・CDN(効果:中・コスト:中)

サーバー側の応答速度。TTFB(Time to First Byte)で測定します。0.8秒以下が良好基準。共有レンタルサーバー(月500円程度)だとTTFBが2秒以上になることが頻発するため、サイト規模が大きくなったら専用サーバー・VPS・クラウドホスティングへの移行が必要です。

CDN(Content Delivery Network)導入で、静的ファイルを世界中のエッジサーバーから配信できます。Cloudflare(無料プランあり)、Akamai、Amazon CloudFront、こういうサービスが代表例。海外向けサイトや画像が多いサイトでは特に効果が大きい。WordPressサイトならCloudflare無料プランで十分対応できます。

要素4:フォント最適化(効果:中・コスト:小)

Webフォント(Google Fonts等)の読み込み待ちがLCPを悪化させます。font-display: swap指定、preload設定、サブセット化(必要な文字だけ含める)、ローカルホスティング、こういう対応で改善できます。

日本語フォントは英語フォントの数十倍のサイズになるため、特に注意が必要。ヒラギノ角ゴ・游ゴシック・BIZ UDPGothicなどシステムフォントを優先するアプローチで、フォント読み込みを完全に省略する設計も業界では一般化しています。本サイトもシステムフォント主体で構成しています。

要素5:キャッシュ戦略(効果:中・コスト:中)

ブラウザキャッシュ・サーバーキャッシュ・ページキャッシュ・オブジェクトキャッシュ、複数階層のキャッシュ設計でリピート訪問時の表示速度を大幅に改善できます。初回訪問時のLCPは改善できませんが、2回目以降の体感速度が劇的に変わります。

WordPressならWP Super Cache、W3 Total Cache、WP Rocket、LiteSpeed Cache、こういうキャッシュプラグインで対応します。ただしキャッシュ設定はサイト構成によって最適解が変わるため、設定ミスで表示崩れが起きるリスクもあります。設定変更後は必ず複数端末で動作確認が必要です。

5要素の優先順位は、サイト規模・現状の指標・運営体制で決まります。「画像最適化→JavaScript最適化→キャッシュ→CDN→フォント」の順で改善するのが、多くのサイトでコスパが高いアプローチ。一気に全部やろうとせず、効果の大きい順に1つずつ潰すのが王道です。

サイトスピード改善で失敗する典型3パターン

うちでサイト運用してきた中で見えてきた、サイトスピード改善の失敗パターンはこの3つに集約されます。

うちで運用してわかった本音

うちの事業ではWordPress 6サイトを日々運用してきました。その中で見えてきた本音をお伝えします。

本音1:画像最適化だけで7割の課題は解決する

うちで運用しているサイトでサイトスピード診断を初回かけた時、改善ポイントの7割が画像関連でした。サイズの大きい画像、WebP未変換、width/height属性なし、loading=”lazy”なし、こういう基本的な対応漏れがほとんどです。

画像最適化プラグインを導入して既存画像を一括変換するだけで、LCPが4秒→2秒に半減したサイトもあります。手間は導入と一括変換の数時間だけ。費用対効果が最も高い改善領域です。サイトスピードに悩んでいる方は、まず画像から手をつけることをお勧めします。

本音2:サードパーティタグを5個以下に絞ると劇的に変わる

うちで運用していて気づいたのは、Google AnalyticsとGoogle Tag Managerだけ入れていれば十分で、それ以上のサードパーティタグはINPを直接悪化させるという事実です。ヒートマップ、チャットボット、A/Bテストツール、リターゲティング、こういうタグを盛り込むほどINPが200ミリ秒、300ミリ秒と悪化していきます。

運用効率と速度のバランスで、サードパーティタグは5個以下に絞るのが現実的なバランスです。それぞれのタグの「本当に必要か?」を定期的に棚卸しする運用が、INP維持の鍵になります。タグを増やす判断は慎重に、減らす判断は積極的に、これが基本姿勢です。

本音3:Search Console を毎月チェックする習慣化が一番効く

これはうちで運用しながら確信したことなんですが、サイトスピード改善で一番効くのは「Google Search ConsoleのCore Web Vitalsレポートを毎月見る習慣」です。実ユーザー基準の指標(フィールドデータ)が、URL単位で「良好/改善が必要/不良」と判定されて表示されます。

具体的に、毎月どこを見るか。PCとモバイル別に、(1)良好URL数の推移、(2)改善が必要URL数の推移、(3)不良URL数の推移、(4)新規に不良判定されたURL、(5)指標別の判定理由。この5要素を月次でモニタリングするだけで、サイト全体のサイトスピード状態が把握できます。劣化検知時点で早めに手を打てる構造です。

うちの運用では、Search Consoleのレポートをスプレッドシートに毎月転記して、トレンドを可視化しています。1ヶ月単位だと変動が見えにくくても、3ヶ月・6ヶ月の推移で見ると改善効果・劣化要因がはっきりわかる。継続的な数値管理が、長期的なサイトスピード維持の核心です。

もう一つ重要なのが、PageSpeed Insightsの「ラボデータ」と「フィールドデータ」を混同しないこと。ラボデータはGoogleの仮想環境での測定値、フィールドデータは実ユーザーの体感値。SEOランキングに影響するのはフィールドデータです。ラボデータが90点でもフィールドデータが「不良」なら、検索順位への影響は不良判定が優先されます。両方を見る目線が必要です。

今日から使える計測→改善の5ステップ

ここまで読んでくださった方、お疲れさまです。今日からサイトスピード改善を始めるための5ステップを置いておきます。

シンプルですが機能するサイトスピード改善の骨格が完成します。完璧を狙う必要はありません。5ステップを順に進めて、月次運用に乗せれば、十分にCore Web Vitals良好レベルを維持できます。

よくある質問(FAQ)

まとめ

で、結局サイトスピードとは、こういうことです。

• サイトスピードの核心は「秒数」ではなく「Core Web Vitals 3指標(LCP・INP・CLS)の管理」
• 本質は単一の表示速度ではなく、視覚的安定・操作可能性・反応性の総合体験
• 5要素(画像/JS・CSS/サーバー・CDN/フォント/キャッシュ)を効果順に潰し、月次測定で継続運用する

速ければ良いという話ではなく、ユーザー体験とGoogle評価が同時に成立する地点を狙うこと。これがサイトスピード管理の本来の役割です。検討しているなら、PageSpeed InsightsとSearch Consoleの2画面チェックから始めてみてください。

ではでは。