表示速度の改善は測ってから｜Webサイトが遅い原因の見つけ方と直す順番

営業先や社内から「スマホで開くと遅い」と言われ、PageSpeed Insights で調べると、点数がオレンジや赤で表示されることがあります。結果の画面には画像・CSS・JavaScript・サーバーなどの指摘が数多く並び、どこから手を付ければよいかが見えにくい状態です。

表示が遅い原因はページごとに違い、サーバーの応答が遅いページで画像だけを軽くしても速くはなりません。この記事では、サイトの表示速度の測り方と遅い原因の見つけ方、直す順番の決め方を解説します。株式会社メリルが Astro で作った自社サイトの4ページを、同じ条件で3回ずつ測った記録も、例として示しました。

記事を読めば、点数の上下に振り回されずに直す場所を決められます。表示速度の改善は、時間がかかっている段階(サーバーの応答・表示を止めるファイル・画像・外部のタグ)を同じ条件で測って確かめ、全ページに効く部分から直すのが近道です。

表示速度の改善はまず同じ条件で測ることから始める

表示速度を直す前に、今の速さを数字で残しておく必要があります。直したあとに同じ条件で測り直さなければ、速くなったかどうかを比べられないからです。

表示速度を測るときに押さえておくことは、以下の4つです。

• 実際の利用者のデータとラボのデータを分けて見る
• Core Web Vitalsの「良好」の目安を確かめる
• Lighthouseの点数は5つの指標から計算される
• 1回の計測の値でサイトの速さを決めない

実際の利用者のデータとラボのデータを分けて見る

表示速度の数字には、実際の利用者から集めたフィールドのデータと、決まった端末と回線の条件で測ったラボのデータの2種類があります。PageSpeed Insights の結果の画面には、両方のデータが表示されます。

出典：Google Search Console の「ウェブに関する主な指標」(オウンドメディア相談室が使っている blog-soudan.com のプロパティ。2026年10月31日の画面)。ソースは Chrome UX レポートです。Google Search Console は Google LLC の商標です。オウンドメディア相談室は、Google が推奨・提携しているものではありません。

出典：Google の「PageSpeed Insights」(https://pagespeed.web.dev/)の画面。この記事の URL を調べたデスクトップの結果です(2026年10月31日)。Google は Google LLC の商標です。オウンドメディア相談室は、Google が推奨・提携しているものではありません。

2種類のデータの違いは、以下の表のとおりです。

項目	フィールドのデータ	ラボのデータ
集め方	実際の利用者から集める(Chrome ユーザー エクスペリエンス レポート)	1台の端末で、決まった回線の条件で読み込む
期間	過去28日間	測ったその1回
向いている使い方	利用者が実際に感じている速さを知る	遅い原因を調べる、直す前後を比べる
見られる場所	PageSpeed Insights、Search Console の Core Web Vitals レポート	PageSpeed Insights、Lighthouse

アクセスの少ないページでは、ページ単位のフィールドのデータが足りなくなります。PageSpeed Insights は、ページのデータが足りないとサイト全体(オリジン)のデータにまとめ、オリジンでも足りないときは実際の利用者のデータを表示しない作りです。

両方のデータがそろっている場合は、フィールドのデータで直す優先順位を付けます。ラボのデータは、原因を調べるときと、直す前後を比べるときに使い分けましょう。

Core Web Vitalsの「良好」の目安を確かめる

Core Web Vitals は、ページの読み込み・操作への反応・表示の安定を測る3つの指標です。3つの指標と「良好」の目安は、以下の表のとおりです。

指標	表すもの	良好の目安
LCP(Largest Contentful Paint)	読み込みの速さ	2.5秒以内
INP(Interaction to Next Paint)	操作への反応の速さ	200ミリ秒以下
CLS(Cumulative Layout Shift)	表示のずれの少なさ	0.1以下

目安と比べるときは、モバイルとパソコンを分けたうえで、ページの読み込みの75パーセンタイルの値を使います。75パーセンタイルの値が目安を満たしていれば、4回の読み込みのうち3回は目安以内で表示された状態です。

Google のランキング システムは Core Web Vitals を使っています。ただし、Google 検索はページの体験が平均を下回っていても、最も関連性の高いコンテンツを表示するように作られています。表示速度を直しただけで、検索順位が上がるとは限りません。

» 検索順位が上がらない原因の確かめ方と直し方｜サーチコンソールで見る4つの順番

Lighthouseの点数は5つの指標から計算される

PageSpeed Insights のラボのデータの点数は、Lighthouse が5つの指標に重みを付けて計算した値です。点数は90〜100が良好、50〜89が改善が必要、49以下が低いの3つに分かれます。

出典：Google の「PageSpeed Insights」(https://pagespeed.web.dev/)の画面。この記事の URL を調べたデスクトップの結果です(2026年10月31日)。Google は Google LLC の商標です。オウンドメディア相談室は、Google が推奨・提携しているものではありません。

点数を決める5つの指標と重みは、以下の表のとおりです。

指標	表すもの	重み
FCP(First Contentful Paint)	最初の表示	10%
SI(Speed Index)	画面が表示されていく速さ	10%
LCP	読み込みの速さ	25%
TBT(Total Blocking Time)	処理のために操作を受け付けない時間	30%
CLS	表示のずれ	25%

Lighthouse は INP を測れないため、INP の代わりに TBT を使います。各指標の値は、HTTP Archive に集められた実際のウェブサイトのデータと比べて点数に直されます。

点数は5つの指標をまとめた結果にすぎず、どこが遅いかは点数からは読み取れません。原因は、指標の値と、Lighthouse の指摘の一覧で確かめます。

1回の計測の値でサイトの速さを決めない

Lighthouse の点数は、同じページを同じ機械で測っても、測るたびに変わります。広告の入れ替わりや回線の経路の変化に加え、測る端末の性能やブラウザの拡張機能・ウイルス対策ソフトも値を動かします。

1回の値で結論を出さず、同じ条件で何回か測ることが大切です。Lighthouse の点数は、5回測った中央値のほうが、1回だけの値より2倍安定します。

測るときにそろえる条件は、以下のとおりです。

• 測る道具と版(PageSpeed Insights か、手元の Lighthouse か)
• モバイルかパソコンか
• 測る機械と回線
• 測る回数と、値の取り方(中央値など)

手元の Lighthouse は、CPU の遅さを手元の機械の性能を基準にして再現します。機械が変わると値も変わるため、直す前後は同じ機械で測りましょう。同じ機械で2つの計測を同時に動かすことも、値が乱れる原因になります。

メリルがAstroで作った自社サイトを手元のLighthouseで測った結果

株式会社メリルは2026年10月30日に、Astro で作った2つの自社サイトのトップと記事の4ページの表示速度を、同じ条件で測りました。測ったのは、会社のサイトの meril.co.jp と、メリルが運営する Web集客ブック(hands-plus.com/media/)です。

測った記録からわかったことは、以下の3つです。

• 4ページを同じ条件で3回ずつ測った
• 静的なページはサーバーの応答が0.04秒未満だった
• 90点以上のページでも3回の点数は最大3点動いた

4ページを同じ条件で3回ずつ測った

メリルが測った条件は、以下のとおりです。

• 日時: 2026年10月30日14時0分〜14時9分
• 機械: Mac mini(Apple M2 Pro)、Lighthouse 13.6.0
• 条件: Lighthouse のモバイルの既定(画面の幅412px、回線は「遅い4G」相当、CPU は4倍遅くする)
• 回数: 1ページを約3分おきに3回

LCP などの値は、回線や CPU を実際に遅くして測ったものではありません。遅くしない状態で読み込んだ記録から、遅い回線と CPU での値をシミュレーションで計算しています。3回の中央値は、以下の表のとおりでした。

ページ	置き場所	点数(3回の幅)	サーバーの応答
meril.co.jp のトップ	Cloudflare	99(97〜100)	0.03秒
meril.co.jp の記事	Cloudflare	93(90〜93)	0.02秒
Web集客ブックのトップ	Xserver	100(100〜100)	0.01秒未満
Web集客ブックの記事	Xserver	100(100〜100)	0.01秒未満

表の数字は、手元の機械で測ったラボの値です。実際の利用者が感じている速さとは別の数字です。ある日の10分ほどの間に3回ずつ測っただけの値なので、サイトの実力として言い切れるものではありません。

静的なページはサーバーの応答が0.04秒未満だった

サーバーが最初の応答を返すまでの時間は、4ページの12回の計測のすべてで0.04秒未満でした。最も長い回でも0.038秒です。サーバーの応答の時間は、シミュレーションではなく、手元の Mac mini から実際に読み込んだときの値を使っています。

Astro で作った4ページは、あらかじめ書き出しておいた HTML のファイルを、そのまま返す静的なページです。アクセスを受けてからサーバーでページを組み立てる作りと違い、応答を返す前の処理がほとんどありません。

Lighthouse の「ドキュメント リクエストのレイテンシ」の項目は、転送が無いか・サーバーの応答が速いか・文字のデータを圧縮して送っているかの3つを確かめます。4ページは、12回すべてで3つとも満たしていました。サーバーの応答が短いページでは、時間がかかっている段階を、表示を止めるファイル・画像・外部のタグの中から探すことになります。

90点以上のページでも3回の点数は最大3点動いた

同じ機械と同じ条件で約3分おきに測っても、点数は回によって変わりました。meril.co.jp のトップは97〜100点、記事は90〜93点で、どちらも3点の幅があります。Web集客ブックの2ページは、3回とも100点でした。

Lighthouse の結果のファイルには、測る前に手元の機械で簡単な処理を走らせて測った、機械の性能の目安も残ります。レポートの画面では「スロットリングされていない CPU / メモリ容量」として表示される値です。

同じ Mac mini でも、性能の目安は12回の計測で2,901.5〜3,091の間で動きました。最も低い回と最も高い回の差は6.5%です。

点数の差が数点のときは、1回ずつの値では、直した効果なのか測るたびの揺れなのかを見分けられません。直す前後を比べるときは、何回か測った中央値どうしで比べるのが確実です。

表示が遅い原因は時間がかかっている段階で見つける

Lighthouse の指摘はいくつも並びますが、ページが表示されるまでの流れに沿って段階に分けると、どこで時間がかかっているかが見えてきます。遅い原因を見つけるために確かめる段階は、以下の4つです。

• サーバーが最初の応答を返すまでの時間を見る
• 表示を止めるCSS・JavaScript・フォントを数える
• 表示サイズより大きい画像を見つける
• 外部のサービスのタグと埋め込みを数える

サーバーが最初の応答を返すまでの時間を見る

最初に確かめるのは、ページを開いてからサーバーの応答の最初の1バイトが届くまでの時間(TTFB)です。TTFB には、転送(リダイレクト)・サーバーの名前の問い合わせ・接続・リクエストの時間が含まれます。

TTFB は、ほとんどのサイトで0.8秒未満に抑えるのが大まかな目安です。Core Web Vitals の指標ではありませんが、TTFB は FCP や LCP より先に来るため、TTFB が遅れると文字や画像の表示も遅れます。

TTFB の問題は、Lighthouse の結果では「ドキュメント リクエストのレイテンシ」の項目に表示されます。TTFB が遅いときに疑う場所は、以下のとおりです。

• サーバーの性能(共有のレンタルサーバーは遅くなりやすい)
• データベースの問い合わせなど、サーバーの中の処理
• キャッシュや CDN を使っていない
• 転送が何段も重なっている

サーバーの中のどの処理に時間がかかっているかは、外からの計測ではわかりません。Server-Timing のヘッダーで処理ごとの時間を返すか、サーバーの記録を調べる必要があります。

» htaccessのリダイレクトの書き方｜301の設定例と確かめ方・注意点

表示を止めるCSS・JavaScript・フォントを数える

次に確かめるのは、ページの表示を止めているファイルの数です。HTML の head にある CSS と、async や defer の付いていない JavaScript は、読み込みが終わるまでページの表示を止めます。

Lighthouse 13 で表示を止めるファイルが出るのは、「レンダリングをブロックするリクエスト」の項目です。一覧にはファイルの URL・転送した量・かかった時間が並ぶため、件数とファイルごとの時間を書き出しておくと、直したあとの件数と比べられます。

文字の形(フォント)を外から読み込むと、フォントのファイルの分だけ読み込む量が増えます。フォントを指定する CSS を head に書いていれば、その CSS も表示を止めるファイルの1つです。

Web集客ブックは、フォントを外から読み込まず、端末に入っているフォントで表示する作りです。メリルが測った Web集客ブックの2ページでは、3回ともフォントのファイルの読み込みが0件で、表示を止めるファイルは CSS の1件だけでした。Lighthouse が見込む短縮も0秒です。

表示を止めるファイルは、ページに欠かせない部分だけを HTML の中に書き、残りの JavaScript には async や defer を付けて後から読み込むと減らせます。使っていない CSS や JavaScript は、読み込みそのものをやめるのが確実です。

表示サイズより大きい画像を見つける

表示される大きさより大きい画像を送ると、データが無駄になり読み込みの時間も長くなります。Lighthouse 13 で画像の無駄が出るのは、「画像配信を改善する」の項目です。

一覧には画像ごとに、ページの中の場所・画像の URL・ファイルの大きさ・減らせる見込みの量が並びます。減らせる見込みの大きい画像から、表示している場所の幅と実際の画像の幅を見比べていけば、直す画像を絞り込めます。

画像の無駄を減らす方法は、表示の大きさに合わせた画像を用意し、画面の幅に応じて出し分けることです。HTML の img に srcset と sizes を書くと、画面の幅に合う大きさの画像をブラウザが選んで読み込みます。

外部のサービスのタグと埋め込みを数える

アクセス解析のタグ・広告・動画の埋め込みなど、外部のサービスから読み込むファイルも、表示を遅くする原因です。外部のファイルは自社の管理の外にあり、サーバーへの問い合わせが増えるうえ、JavaScript の処理がブラウザを占有します。

メリルが測った4ページには、どれもアクセス解析の Google タグが入っていて、1ページあたり約182KBでした。Web集客ブックの2ページが読み込む JavaScript のファイルは Google タグの1つだけで、トップでは読み込む量全体(0.30MB)の6割が Google タグです。

軽いページほど、アクセス解析のタグ1つが読み込む量に占める割合は大きくなります。タグを足すときは、足す前と後で読み込む量を測っておくと、タグの分の重さがわかります。

動画の埋め込みで確かめるのは、ページを開いたときに再生画面まで読み込む作りか、押されたときに読み込む作りかです。Web集客ブックの記事は、最初は動画の画像だけを出し、押されたときに再生画面を読み込む作りにしています。

メリルが測った Web集客ブックの記事では、ページを開いたときに YouTube から読み込んだのは動画の画像1件(0.24MB)だけでした。YouTube の JavaScript の読み込みは0件で、ページ全体の JavaScript は Google タグの0.18MBだけです。

外部のタグは、サイトに明確な価値をもたらさないものから外します。残すタグには async や defer を付け、埋め込みは必要になったときに読み込む形にすると、ページを開いたときの読み込みを減らせます。

表示速度を直す順番は影響の範囲と遅れの大きさで決める

遅い原因の候補が見えたら、直す順番を決めます。Lighthouse の指摘を上から順に直すより、効果の大きいものから直したほうが、少ない手間で速くなります。

直す順番を決めるときの考え方は、以下の3つです。

• 全ページに効く共通の部品から直す
• 遅れている段階に合った直し方を選ぶ
• 直したら同じ条件で測り直して比べる

全ページに効く共通の部品から直す

ヘッダーの画像・フォント・アクセス解析のタグ・共通の CSS は、サイトのほぼすべてのページで読み込まれます。共通の部品を1か所直せば全ページが速くなるため、1ページだけにある画像より先に直します。

メリルが測った4ページでも、Google タグは4ページのすべてに入っていました。全ページに入るタグは、1ページの読み込む量を測れば、ほかのページでも同じ量を読み込んでいると見当がつきます。

直す順番を決めるときに比べる項目は、以下のとおりです。

• 全ページに効くか、1ページだけか
• Lighthouse が見込む短縮の時間や、減らせる量の大きさ
• 自社で直せるか、制作会社やサーバー会社に頼む必要があるか
• アクセスの多いページか

Search Console の検索パフォーマンスで検索からのクリックが多いページを確かめておくと、同じ手間でも効果の大きい場所から直せます。

遅れている段階に合った直し方を選ぶ

直し方は、時間がかかっている段階によって変わります。段階ごとの、Lighthouse で見る項目と主な直し方は、以下の表のとおりです。

遅れている段階	Lighthouse で見る項目	主な直し方
サーバーの応答	ドキュメント リクエストのレイテンシ	キャッシュや CDN を使う、サーバーの処理を見直す、転送を重ねない
表示を止めるファイル	レンダリングをブロックするリクエスト	欠かせない部分を HTML に書く、async や defer を付ける、使わないコードを消す
画像	画像配信を改善する	表示の大きさに合わせた画像を用意する、形式と圧縮を見直す
外部のタグ・埋め込み	サードパーティの一覧	価値の無いタグを外す、async や defer を付ける、必要になってから読み込む

サーバーの応答が遅いページは、ページの中を軽くしても、応答の遅れがそのまま残ります。TTFB が目安の0.8秒を大きく超えているときは、ほかの指摘より先にサーバーの側を確かめましょう。

直したら同じ条件で測り直して比べる

直したあとは、直す前と同じ道具・同じ版・同じ条件・同じ回数で測り直し、中央値どうしで比べます。測った日時と条件を記録しておかないと、次に測ったときに比べられません。

メリルも、測った日時・機械・Lighthouse の版・条件と、Lighthouse が出した結果のファイルをそのまま残しています。後から同じ条件で測り直したときに、点数だけでなく、サーバーの応答・表示を止めるファイルの数・読み込む量も比べられるようにするためです。

実際の利用者の数字は、ラボの数字より遅れて変わります。フィールドのデータは過去28日間の集計なので、直した直後の数字には直す前に見た利用者の分も含まれ、効果はすぐには表れません。

Search Console の Core Web Vitals レポートでは、問題を直したあとに検証を始めると、28日間どの URL でも問題が出なければ解決と判断されます。直した効果は、まずラボの数字で確かめ、利用者の数字は28日たってから確かめます。

表示速度の改善は測って時間がかかる段階を確かめてから直す

表示速度の改善は、点数を上げることではなく、利用者が待つ時間を減らすことが目的です。点数は測るたびに動き、どこが遅いかも点数からは読み取れないため、点数だけでは直す場所を決められません。

記事の要点は、以下のとおりです。

• フィールドのデータで優先順位を付け、ラボのデータで原因を調べる
• 同じ条件で何回か測り、中央値で比べる
• サーバーの応答・表示を止めるファイル・画像・外部のタグの順に、時間がかかっている段階を探す
• サーバーの応答が遅いときは、サーバーの中の処理ごとの時間を確かめる
• 全ページに効く共通の部品から直し、直したら同じ条件で測り直す

時間がかかっている段階がわかれば、自社で直す部分と、制作会社やサーバー会社に頼む部分も分けられます。まずは自社のトップと記事を1本ずつ、同じ条件で3回測り、サーバーの応答と読み込む量を書き出しましょう。