アーム代表の伊藤です。
サイトの表示速度の合格ラインは、主要コンテンツが出るまで2.5秒以内です（Googleの指標LCP）。
アームの自社サイトはスマートフォンでLCP8.2秒でした。原因を切り分けたら、直したのは「先に読む」指定を足しただけです。
表示速度の目安はLCP2.5秒以内
- LCPは2.5秒以内、INPは200ミリ秒以下
- CLSは0.1以下が合格ライン
- 90点を100点にするより4秒を2.5秒に
LCP（Largest Contentful Paint）は、ページの主要なコンテンツが表示されるまでの時間です。Googleが定めるサイトの表示速度の指標群「Core Web Vitals」の中心です。3つの指標にそれぞれ合格ラインがあります（出典: Google web.dev「Web Vitals」）。
指標 | 合格ライン |
|---|---|
LCP（主要コンテンツの表示） | 2.5秒以内 |
INP（操作への反応） | 200ミリ秒以下 |
CLS（表示のガタつき） | 0.1以下 |
迷ったらLCP2.5秒だけ見る
「表示速度は何秒が目安ですか」と聞かれたら答えはこの2.5秒です。90点を100点にする労力より、LCP4秒のページを2.5秒に縮める労力のほうが事業の数字に表れます。3つの指標の意味と、指標別にどこを改善するかは、こちらにまとめています。
サイトの表示速度とは
サイトの表示速度とは、ページを開こうとしてから内容が表示されて操作できるようになるまでの速さです。回線速度（Wi-Fiや光回線の速さ）とは別物で、サイト側のつくりで決まる部分を指します。
ただ、合格しているかどうかは手元の感覚では分かりません。アームの自社サイトは、PageSpeed Insightsでパソコン99点、スマートフォン60点でした。
表示速度の計測はPageSpeed Insightsで無料でできる
- 表示速度の計測はURLを入れて分析を押すだけ
- 見るのは実ユーザーの評価と改善できる項目
- トップページ以外も表示速度を計測する
感覚で「サイトが重い気がする」と手を動かすと、関係のない場所を直して時間だけが溶けていきます。サイトの表示速度の計測は、Googleが無料で提供するPageSpeed Insightsひとつで足ります。URLを入力して「分析」を押すと、モバイルとデスクトップのスコア（100点満点）と、改善できる項目の一覧が出ます。
PageSpeed Insightsの結果画面で見るのは2つです。
見る欄 | 確かめること |
|---|---|
実際のユーザーの環境で評価する | LCPが2.5秒以内か |
改善できる項目 | 重い原因はどれか |
点数そのものより「どこが悪いか」を見ます。トップページだけでなく、料金や問い合わせフォームなど、よく見られるページも計測してください。ページによって表示速度が遅い原因は違います。サイト全体を見張るなら、Google Search Consoleの「ウェブに関する主な指標」で合格状況をまとめて確認できます。
ただし、PageSpeed Insightsの数字をそのまま信じると判断を誤ります。アームは「最初の表示に23.4秒かかる」と算定されました。実測は89点でした。
計測結果の読み方
- 更新直後のスコアは実力より低く出る
- 推定削減時間は短縮秒数ではない
- 100点を目指す必要はない
更新した直後に計測しない
PageSpeed Insightsは、更新直後は画像の変換結果などが保存されていない状態で計測し、スコアが実力より低く出ます。改善の前後を比べるなら、更新から半日以上あけてください。「改善したのに悪化した」と焦る必要はありません。
推定削減時間は実際の短縮秒数ではない
「◯◯秒短縮できます」は遅い回線を想定した計算値です。アームの自社サイトでは2026年7月末、日本語のWebフォントが重いとして「最初の表示に23.4秒かかる」と算定されました。実際に遅い回線を再現して計測すると89点、パソコンでは100点。PageSpeed Insightsが「フォントの到着を待ってから表示する」と判断したための数字でした。
それでもフォントの配信方法を変えると、計測値は55点から87点へ上がりました。指摘の方向は正しく、削減できる秒数だけが誇張されている。表示速度の計測結果は、数字の大きさではなく何を指摘されているかで改善の優先順位を決めてください。
スコア100点を目指す必要はない
スコアは表示速度の診断の手がかりで、目指すのは実際のユーザーがストレスなく使えて事業の数字が動く状態です。Googleが基準にしているのは、実際のユーザーの記録によるページの読み込みの75パーセンタイル値です。集計はモバイルとデスクトップ別に行われます（出典: Google web.dev「Web Vitals」）。
表示速度が遅い原因は4つに切り分けられる
- 表示速度を落とす最多の原因は画像・動画の容量
- 使っているか分からないタグが温床
- 設計に入り込んだ重さは圧縮で戻らない
PageSpeed Insightsの「改善できる項目」に並ぶ指摘は、多くの場合この4つの原因のどれか（または複合）に切り分けられます。
診断の指摘 | 原因 |
|---|---|
画像の最適化 | 1 画像・動画の容量 |
未使用のJavaScript | 2 タグ・スクリプト |
サーバーの応答時間 | 3 サーバーの性能 |
指摘が1箇所に収まらない | 4 設計段階の重さ |
原因を自分で直せるか任せるか
原因が画像・タグ・サーバーのどれかなら、次の節の改善方法で自分で直せます。判断が要るのは指摘が1箇所に収まらないとき。重さがつくり方そのものに入り込んでいて（原因4）、コードの書き直しやサーバー構成の変更まで要るなら、任せるほうが早く確実です。
表示速度はデザインと情報設計の段階でほぼ決まります。この演出は必要か、この画像をこのサイズで載せる意味はあるか。そこが決まっていないサイトは、公開後にいくら圧縮しても頭打ちになります。
画像・動画のデータ容量が大きい
表示速度を落とす原因として最も多いのがこれです。撮影したままの画像や、圧縮されていない画像が並ぶページは、どうしても遅くなります。メインビジュアルの大きな画像は、LCPにそのまま響きます。
JavaScript・CSS・外部タグの積み重ね
アクセス解析、広告、チャットツール、SNS埋め込み。ひとつずつは小さくても、運用の中で足され続けると読み込み時間を押し上げ、表示速度を落とします。「入れた記憶はあるが、今も使っているか分からないタグ」が重さの温床です。
サーバーの性能が足りていない
安価なレンタルサーバーの共有プランは、アクセスが集中する時間帯に応答が遅くなります。PageSpeed Insightsで「サーバーの応答時間」が指摘されているなら、表示速度の原因はコンテンツ側でなくインフラ側です。
設計段階から重さが仕込まれている
過剰なアニメーション、多数のWebフォント、複雑すぎるページ構造。アームが引き継いだ案件でも、カンプでは美しかった演出が、実装されると積み重なって表示速度を落としていました。
画像圧縮などの対症療法では限界があり、「その演出は体験に本当に必要か」という設計の問い直しが要ります。
4つの原因のうち3つは、専門知識がなくても今日から改善に手を付けられます。
自分でできる表示速度の改善方法
- 画像圧縮は難易度が低く効果が高い
- 月数百円の差でサーバー応答速度が変わる
- キャッシュは2回目以降の表示を速くする
原因が見えたら表示速度の改善です。難易度の低い改善方法から並べます。
改善方法 | 難易度 |
|---|---|
画像の圧縮・形式の見直し | 低 |
不要なプラグイン・タグの整理 | 低〜中 |
キャッシュの活用 | 中 |
サーバープランの見直し | 中 |
画像を圧縮して形式を見直す（原因1）
表示速度の改善として、もっとも費用対効果が高い打ち手です。無料の圧縮ツールでサイズを落とし、WebPやAVIF（JPEG/PNGより軽い形式）に変換します。着手はPageSpeed Insightsに指摘された画像から。
画面の外の画像を後から読む遅延読み込み（Lazy Load）も、体感の表示速度を上げます。
不要なプラグイン・計測タグを整理する（原因2）
WordPressなら停止したまま残るプラグイン、タグマネージャーの中で誰も見ていない計測タグ。消してよいか分からないものは、導入の経緯を知る人に確認してから外します。整理するだけで表示速度の体感が変わることも珍しくありません。
キャッシュを活用する（原因1・2）
一度読み込んだデータを一時保存して次回を速くする仕組みで、2回目以降の訪問で表示速度が大きく改善します。WordPressならキャッシュ系プラグイン、レンタルサーバーなら管理画面のキャッシュ設定から有効化できます。
サーバープランを見直す（原因3）
サーバー応答の遅さが指摘されているなら、契約プランのアップグレードか、高速なサーバーへの移転です。アームの経験では、月数百円の差で応答速度が変わることもあります。画像や動画が多いサイトなら、ユーザーに近いサーバーから配信するCDNも選択肢です。
ただ、4つの改善方法を全部やっても戻らない重さがあります。アームの自社サイトの8.2秒は、圧縮でもサーバーでもありませんでした。
自社サイトを直した実例
- 表示速度はスマホ60点・PC99点で16倍の差
- 原因はアイキャッチ画像1枚の遅延読み込み
- 対応は「先に読む」指定を足しただけ
スマホ60点とPC99点
2026年8月、aaam.jpをPageSpeed Insightsで計測すると、スマートフォンで60点、LCPは8.2秒。同じページがパソコンでは99点、LCPは0.5秒でした。
計測条件 | スコア | LCP |
|---|---|---|
スマートフォン | 60点 | 8.2秒 |
パソコン | 99点 | 0.5秒 |
ここで切り分けられることがあります。中身そのものが重いならパソコンでも遅くなるはずです。そうなっていない以上、原因は回線が細い環境でだけ表に出る何かに限られます。CLSもTBTも良好圏。レイアウトでも実行量でもなく、残るのは最初の表示を待たせている何かでした。
最優先画像が最後だった
原因は記事のアイキャッチ画像1枚。開いた瞬間に画面へ入る位置にあるのに、後回しで読み込む設定になっていました。やった対応は「これを先に読む」という指定を足しただけで、圧縮のやり直しもサーバー変更もデザインの削減もしていません。
切り分けをせずに、スマートフォンが遅いという事実だけで動いていたら、サイト中の画像を圧縮し直すような見当違いの工事に何十時間も使っていました。表示速度の改善で高くつくのは直す作業ではなく、どこを直すか分からないまま動く時間のほうです。
依頼時に伝えること
- 伝えるのは「どの体験を速く」
- 「100点に」は無関係な工事を生む
- 見積もりは原因の切り分けで確かめる
スコアではなくどの体験を速くするか
「スマホでトップページのメイン画像が出るまでが遅い」「フォームの表示が重くて離脱されている気がする」。ここまで具体的なら、制作側は表示速度の原因の見当をつけやすく、見積もりの精度も上がります。「とにかく100点に」という依頼は、事業に関係のない箇所の最適化に費用を使う典型です。
見積もりは原因の内訳で確かめる
見積もりの前に、原因1〜4（画像・スクリプト・サーバー・設計）のどれが影響しているかを切り分けてもらってください。その際は、PageSpeed Insightsの結果とあわせて説明を求めてください。「設計まで踏み込むので実装の作り直しが要る」のように理由が具体的なら、内訳は課題の分解になっています。理由が曖昧なまま「一式で◯万円」と出てくる見積もりは、範囲を聞き直してから判断してください。
速度が数字に出た事例
- 読み込み1秒延びると10%が離脱
- 楽天24はCVRが33.13%上昇
- VodafoneはLCP31%改善で売上8%増
1秒の遅れで約10%が離れるという数字は、BBCが自社サイトで気づいた例として紹介されています（出典: Google web.dev「速度が重要な理由」）。
事例 | 結果 |
|---|---|
楽天24（CLS92.72%改善） | CVRが33.13%上昇 |
Vodafone（LCP31%改善） | 売上が8%増 |
どのサイトでも同じ効果が出るわけではありません。それでも表示速度の改善は「なんとなく快適になる」施策ではなく、離脱率とコンバージョンに直結する施策です。
速度は順位を下げない
- 適用は2018年7月、対象はモバイル検索のみ
- AI検索に表示速度の追加要件はない
- 内部SEOの3領域のうちページ体験に入る
Google明言の順位要素
サイトの表示速度はSEOにも影響します。Googleは2018年1月、ページの読み込み速度をモバイル検索のランキング要素に使うと発表しました。適用は同年7月からです（出典: Google検索セントラル「ページの読み込み速度をモバイル検索のランキング要素に使用します」）。ただし同じ発表に4つの条件が添えられています。
条件 | 内容 |
|---|---|
対象 | モバイル検索のみ |
影響するページ | もっとも遅い体験のページ |
影響するクエリ | ごく一部 |
検索意図 | 依然として非常に強いシグナル |
遅いページでも内容が優れていれば上位に出ます。表示速度は減点方式に近く、合格ラインを超えていれば十分です。
LLMOも特別対策なし
Googleの生成AI向け最適化ガイドは、AI検索に出る条件を「インデックスされていて、通常の検索でスニペット付きの表示対象になっていること」としています。表示速度の追加要件はありません（出典: Google検索セントラル「生成AI検索向けの最適化ガイド」、2026年7月更新）。
Core Web Vitalsがランキングで使われること自体は認めています。ただし「単一のシグナルはない」とも述べています。「良い数値でも上位表示は保証されない」とも述べています（出典: Google検索セントラル「ページエクスペリエンス」、2025年12月更新）。
表示速度はAI検索対策として別枠で取り組むものではなく、通常のSEOの一部です。AI検索のためにと別料金で速度の施策をすすめられたら、公式のガイドに載っている話かを一度確かめてください。
速度はページ体験に入る
内部SEO対策（テクニカルSEO）は3つの領域で構成され、表示速度とCore Web Vitals（LCP・INP・CLS）は3つ目に入ります。
内部SEOの領域 | 表示速度との関係 |
|---|---|
クロール最適化 | 直接は関係しない |
インデックス最適化 | 直接は関係しない |
ページエクスペリエンス | ここに入る |
前の2つが「検索結果に正しく載るための整備」ならページエクスペリエンスは「訪れたユーザーを逃さないための整備」です。「表示速度を上げれば順位が伸びる」という期待で着手すると期待外れに終わります。表示速度の改善は順位のためではなく、SEOで集めたアクセスを取りこぼさず商談につなげるための施策です。
よくある質問
WordPressのサイトの表示速度が遅い場合、まず何をすべきですか？
画像の圧縮、使っていないプラグインの削除、キャッシュ系プラグインの導入の順です。それでも遅ければテーマかサーバーが原因のことが多く、専門家に相談するタイミングです。
PageSpeed Insightsで「データがありません」と表示されるのはなぜですか？
実際のユーザーの訪問データ（CrUX）が足りないためで、公開直後のサイトやアクセスの少ないページで起こります。異常ではなく、下段の「パフォーマンスの問題を診断する」（ラボデータ）を手がかりに表示速度の改善を進めれば足ります。
モバイルとパソコン、どちらの表示速度を優先して改善すべきですか？
モバイルが先です。Googleはモバイル版のページを基準にサイトを評価し、実際の閲覧もスマートフォンが中心のサイトがほとんどです。PageSpeed Insightsでもまずモバイルの改善できる項目から見てください。
表示速度の改善は、内部SEO対策の中でどの順番でやるべきですか？
クロールとインデックスの整備が先です。検索結果に登録されていないページは、表示速度をどれだけ磨いても検索結果に出ません。すでに載っていて離脱の多さが課題なら、表示速度の改善から着手して問題ありません。
表示速度の改善は直す前にほぼ決着がつく
- 目安はLCP2.5秒以内でスコア100点は目指さない
- PageSpeed Insightsで画像・タグ・サーバー・設計に切り分ける
- 直すのは画像の圧縮から・設計に入った重さはプロに任せる
