無料相談

表示速度対策Room

表示速度対策Room

その3秒で、
お客様は帰ってしまいます。

ページの表示が遅いサイトは、内容を読まれる前に離脱されます。表示速度はユーザー体験の問題であると同時に、Googleが評価指標として明示している「Core Web Vitals」の問題でもあります。何を、どの順番で直せばよいのかを整理しました。

Google公式の実測データにもとづく診断×36項目の実行チェック

36項目表示速度チェック基準
2.5秒LCP「良好」の基準値
86点自社サイトの現在地(改修前68点)

最終更新:2026年8月25日|監修:株式会社ビズデザイン(EC・IT・AI戦略コンサルティング)

01 ── BASIC

表示速度は「Core Web Vitals」で測る

Googleは、ページ体験の良し悪しを判断する指標として Core Web Vitals(コアウェブバイタル)を公開しています。指標は3つだけで、しかも数値で良否が決まります。まずはこの3つを押さえてください。

LCP Largest Contentful Paint

いちばん大きいものが出るまでの時間

画面の主役となる画像や見出しが表示されるまでの時間です。3指標のなかで最も改善しやすく、最も効果が大きい指標です。

良好:2.5秒以下
INP Interaction to Next Paint

タップしてから反応するまでの時間

ボタンやメニューを操作したときの「もたつき」を測ります。2024年3月にFIDに代わって正式指標になりました。

良好:200ミリ秒以下
CLS Cumulative Layout Shift

読み込み中に画面がガタつく量

広告や画像が後から入って、押そうとしたボタンがずれる現象です。EC サイトの誤タップ・カゴ落ちに直結します。

良好:0.1以下

チェッカーで判定に使っている基準値(全8指標)

指標良好の基準何を表すか
LCP2.5秒以下主要コンテンツの表示完了(Core Web Vitals)
INP200ms以下操作への応答速度(Core Web Vitals)
CLS0.1以下レイアウトのずれ量(Core Web Vitals)
FCP1.8秒以下最初の何かが表示されるまで
TBT200ms以下JavaScriptで操作が塞がれた合計時間
TTFB0.8秒以下サーバーの応答(最初の1バイトまで)
総転送量2MB以下1ページの読み込みデータ量
DOM要素数1,500個以下ページの構造の複雑さ

→ 表は横にスクロールできます

TBTとINPの関係。TBTは検査環境で測る「操作が塞がれた時間」、INPは実際の訪問者の操作に対する応答時間です。実測ツールではINPが取得できない場面があるため、その代わりにTBTを見ます。TBTが大きいページは、ほぼ確実にINPも悪化します。
02 ── POINT

「点数が低い=サイトが壊れている」ではありません

表示速度の診断でいちばん誤解されるのがここです。PageSpeed Insights には性質のまったく違う2種類の数値が並んでおり、両方を見ないと判断を誤ります。当社のチェッカーが他の速度ツールと最も違うのも、この点を必ず両方表示するところです。

ラボ値(検査環境の実測)

条件をそろえた「健康診断」

Googleの検査環境で、あえて厳しい条件をつくって測った数値です。総合スコア(0〜100点)はこちらから算出されます。

  • 低速4G相当の回線に制限
  • CPUを約4倍遅く設定
  • 毎回同じ条件なので改善の前後比較に向く
フィールド値(CrUX・実訪問者)

実際のお客様が体験した速度

Chromeユーザーの実データ(CrUX)を過去28日分集計したものです。Googleが評価に用いるのは、原則としてこちらです。

  • 実際の回線・端末・地域が反映される
  • 訪問数が少ないサイトはデータなしになる
  • 改善しても反映まで数週間かかる

この2つは、正反対の結果になることがあります。当社が実測したあるBtoB向けサイトでは、ラボスコアが40〜50点・LCPは20秒超と表示されたにもかかわらず、実訪問者のデータ(CrUX)は3ページとも「良好(FAST)」判定でした。訪問者の回線が速い商圏では、こうした乖離が普通に起こります。ラボ値だけを見て「サイトが壊れている」と判断すると、必要のない改修に費用を投じることになります。

パターン A

ラボ良好 × 実測良好

問題ありません。この状態を維持しながら、コンテンツやSEOに投資を回すのが正解です。

パターン B

ラボ不良 × 実測良好

お客様は困っていません。緊急の改修は不要です。ただし商圏を広げると悪化する可能性があるため、優先度「中」で計画的に直します。

パターン C

ラボ不良 × 実測不良

最優先で対応すべき状態です。離脱・カゴ落ち・検索評価のすべてに影響しています。

パターン D

実測データなし

訪問数が少なく、Googleに十分なデータが蓄積していない状態です。当面はラボ値を目安に整えます。

当社のチェッカーは、この4パターンを自動で判定し、そのサイトに合った解釈文を表示します。

03 ── CHECKLIST

表示速度対策 実行36項目

「サイト全体で一度やればよいこと」と「ページごとに毎回気をつけること」は別物です。混ぜて管理すると必ず抜けが出るため、当社は3つのグループに分けています。ここでは各グループの代表的な項目をご紹介します。

合計 36項目 必須 17項目 推奨 19項目 自動判定 32項目 / 手動確認 4項目

A. サイト全体の土台

12項目

必須サーバー応答(TTFB)を0.8秒以下に

  • 共用サーバーのプラン・PHPバージョンを確認
  • データベースの肥大化と重いプラグインを点検

必須テキスト圧縮(gzip / Brotli)を有効化

  • HTML・CSS・JSの転送量が数分の1になる
  • サーバー設定か .htaccess で一度きりの作業

必須ブラウザキャッシュの保存期間を設定

  • 2回目以降の表示が劇的に速くなる
  • 画像・CSS・JSは長め、HTMLは短めが基本

推奨キャッシュ/CDNの導入

  • ページキャッシュで生成処理そのものを省略
  • 画像配信をCDNに逃がす(手動確認項目)

B. ページごとの作り込み

18項目

必須画像をWebP/AVIFで配信する

  • JPEG比で3〜7割の削減が見込める
  • 削減効果が最も大きい定番の一手

必須すべての画像に width / height を指定

  • CLS(ガタつき)の最大の原因を潰せる
  • 指定するだけで済み、費用はかからない

必須ファーストビュー外の画像を遅延読み込み

  • loading=”lazy” を付ける
  • ただしLCP画像には付けないこと(逆効果)

必須レンダリングを妨げるCSS/JSをなくす

  • JSは defer / async、CSSは必要分だけ先に
  • LCPの短縮に直結する

推奨使われていないCSS/JSを削る

  • 全ページに全部を読み込ませない
  • 不要プラグインの整理が最短ルート

推奨Webフォントの読み込みを最適化

  • font-display: swap で文字を先に見せる
  • 使うウェイトだけに絞る

C. ECサイト特有の論点

6項目

必須商品一覧ページの画像枚数と1枚あたりの重さ

  • 一覧は数十枚が同時に載る最重量ページ
  • サムネイルは表示サイズちょうどで書き出す

必須外部タグ(計測・レビュー・接客ツール)の棚卸し

  • タグマネージャー経由の読み込みが重なりやすい
  • 使っていないタグを止めるだけで効果が出る

必須カート・決済導線の速度を単独で測る

  • 売上に直結する最重要ページ(手動確認項目)
  • トップだけ速くても意味がない

推奨ASPカートで改修できる範囲を把握する

  • テンプレート側で触れる範囲には限界がある
  • できることから確実に潰す(手動確認項目)

※ 36項目の全文と、各項目の「なぜ必要か・どうやるか」の解説は、下記のチェッカーでご覧いただけます。

04 ── OUR SITE

自社サイトの現在地を公開します ── 改修1回目の結果

当サイトはSEO・AIOの40項目チェックで92点まで改善してきました。しかし表示速度は別物です。2026年8月に改善前の数字(70点)を先に公開し、9月3日に1回目の改修を実施しました。測って・直して・また測る。その記録を、この場所に残していきます。

86総合スコア(モバイル)
改修前 68点 → +18点
3.54LCP
改修前 8.51秒 → −4.97秒
226KB総転送量
改修前 1.3MB → 約83%削減
9リクエスト数
改修前 18件 → 半減

改修前後の比較(2026年9月3日・同日計測)

指標改修前改修後基準判定
総合スコア68点86点50以上○ 達成
LCP8.51秒3.54秒2.5秒以下△ あと約1秒
FCP2.93秒2.71秒1.8秒以下△ 継続課題
CLS0.00100.1以下○ 良好
TBT45ms50ms200ms以下○ 良好
総転送量1.3MB226KB2MB以下○ 83%削減
リクエスト数18件9件100件以下○ 半減
画像の次世代形式0/12枚主要画像すべてWebP半数以上○ 達成
テキスト圧縮(gzip)未設定HTML/CSS/JS すべて圧縮有効○ 達成

原因は「通信量」ではなく「演出」でした ── 実施した改修(2026/09/03)

改修前のLCP 8.51秒は、転送量1.3MB・リクエスト18件という規模には不釣り合いな数字でした。ソースを調べると、トップのヒーロー画像と見出しに「スクロールでふわっと現れる演出」が付いており、JavaScriptが動くまで画像が透明(opacity:0)のままでした。Googleの計測は「主要な要素が実際に見えた瞬間」をLCPとするため、低速回線の想定ではJSの到着と0.8秒のフェードを待たされ、8秒超と判定されていたのです。

  1. ファーストビューのフェード演出を解除 ── LCP 8.51秒→3.54秒。今回もっとも効いた1手。演出はページ下部にのみ残した
  2. 画像のWebP化 ── ロゴ・ヒーロー・プロフィール・ブログサムネイルを変換。ロゴは表示幅の8倍もあった元画像を適正サイズに(69KB→9KB)。ブログ画像は最大98%減
  3. テキスト圧縮(gzip)とキャッシュ ── HTML/CSS/JSを圧縮配信に。サーバー側の設定だけで、デザインには一切影響なし
  4. スクリプトの整理 ── フォームのないトップでフォーム用CSS/JSを停止し、残りは defer で後回しに。スクリプト9本→3本
  5. 画像の幅・高さ指定と遅延読み込み ── 12枚すべてに width/height を指定、画面外は lazy に。CLSは0に

残る課題:LCPは基準の2.5秒まであと約1秒。主因はGoogleタグマネージャーがヒーロー画像と回線を取り合うことと、テーマCSS1本の読み込み待ちです。ブログ本文内の画像もまだ従来形式です。次の改修結果は、このページに追記します。

2026/08/25 70 STEP 1 現在地(改善前)
  • LCP 7.12秒(要改善)
  • 9/3 の再計測では 68点・LCP 8.51秒
  • 総転送量 1,039KB〜1.3MB
2026/09/03 86 STEP 2 画像と初期表示(実施済み)
  • フェード解除で LCP 3.54秒
  • WebP化・gzip・defer
  • 総転送量 226KB(−83%)
目標 90 STEP 3 到達目標
  • LCP 2.5秒以下
  • 3指標すべて「良好」
  • 次回の実測値をここに追記

「SEOは92点、速度は86点」。1回の改修で18点上がりましたが、LCPはまだ基準に届いていません。速度改善は一度やれば終わりではなく、コンテンツを足すたびに重くなっていくものです。だからこそ、測って・直して・また測るという記録の形でお見せするのが最も誠実だと考えています。

計測条件:Google PageSpeed Insights(モバイル・低速4G相当/CPU4倍遅延)/対象URL:当サイトトップページ/計測日:2026年8月25日(改善前)、2026年9月3日(改修前・改修後を同日に計測)。計測は実行のたびに数値が変動します。

05 ── TOOL

表示速度チェッカーで、自社サイトを実測する

上でご覧いただいた診断は、すべてこのツールで行っています。URLを入れるとGoogleの実測データを取得し、36項目の自己チェックと「答え合わせ」ができます。LINE会員限定で無料公開しています。

LINE会員限定・無料公開中

表示速度チェッカー
一般サイト・ECサイト両対応

単なるチェックリストではありません。URLを入力すると Google PageSpeed Insights で実測し、自己チェックとの食い違いを洗い出すのが最大の特長です。「できているつもりで、できていなかった項目」が赤で表示されます。

  1. サイトのURLを入力して実測(モバイル/PC切替、ECは3ページ同時計測)
  2. 36項目を自分の認識でチェック(各項目に「なぜ必要か・どうやるか」の解説付き)
  3. 答え合わせ。実測と突き合わせて5区分で表示
  4. 削減効果の大きい順に、直すべき順番が並ぶ
チェッカーを起動する
70総合スコア

診断結果イメージ:総合スコアと8指標の実測値、実訪問者データとの突き合わせ、改善の優先順位を表示します。

LINE会員募集中!

友だち追加していただくと、表示速度チェッカー・SEO対策チェッカーをはじめとする会員限定ツールをすべて無料でご利用いただけます。

表示速度チェッカー SEO対策チェッカー(40項目) 企業診断チェックシート4種
友だち追加する(無料)
LINE友だち追加QRコード スマホのカメラでQRコードを読み取り

配信は月2回程度・登録は無料です。不要になればいつでもブロックできます。

LINE会員特典のくわしい内容を見る

Q&A

よくあるご質問

表示速度が遅いと、検索順位は本当に下がりますか?

速度は評価要素のひとつですが、それだけで順位が決まるわけではありません。Googleは、内容の質が同等であればページ体験の良いほうを優遇する、という位置づけを示しています。実務上は「順位のため」より「離脱を減らすため」の投資と考えたほうが成果につながります。表示が遅いページは読まれる前に離脱され、その行動自体が評価にも影響していきます。

点数は何点を目指せばよいですか?

総合スコアは目安に過ぎません。目指すべきはCore Web Vitalsの3指標(LCP 2.5秒以下/INP 200ms以下/CLS 0.1以下)を、実訪問者のデータで「良好」にすることです。総合スコアを1点上げる作業に時間を使うより、LCPを1秒縮める作業に集中してください。

診断すると点数が毎回変わります。壊れているのでしょうか?

正常です。計測は実際にページを読み込んで測るため、そのときのサーバー状況やネットワークで数値が上下します。1回の点数に一喜一憂せず、改善前後で数回ずつ測って傾向を見てください。当社のチェッカーも同じ理由で、単発のスコアではなく指標ごとの実測値と改善余地を並べて表示しています。

ECサイトはASPカートを使っていて、自由に改修できません。

触れる範囲が限られていても、効果の出る打ち手は残っています。商品画像の書き出しサイズと枚数、使っていない外部タグの停止、テンプレートで指定できる幅・高さ、この3つだけでも体感は変わります。まず「どこまで触れるか」を切り分けるところからご一緒します。

チェッカーは無料で使えますか?

はい。LINE公式アカウントの友だち(LINE会員)であればどなたでも無料でご利用いただけます。入力したURLの計測にはGoogleの公式サービスを利用しており、チェックの回答内容は端末内で処理され、サーバーに保存されることはありません。

自社で対応しきれない項目は相談できますか?

はい。サーバー設定、キャッシュ・CDNの導入、テーマやテンプレートの改修など、専門的な項目は当社が実装まで代行します。診断結果をお手元にご用意のうえ、LINEまたはお問い合わせフォームからご相談ください。初回のご相談は無料です。

OUR APPROACH

速さは、売上の話です。

株式会社ビズデザイン 代表・宮地章は、1998年に楽天市場で売上TOPを獲得し、2000年からは直営店舗の開発・運営を実践してきました。回線もサーバーも今より遥かに遅かった時代から、「表示が遅い店は売れない」という現実に向き合い続けています。速度改善は技術の話に見えて、その実、注文が入るか入らないかの話です。だからこそ数字で測り、効果の大きい順に直す。当社は自社サイトでそれを実践し、その過程をこのページに公開していきます。

1998 楽天市場 売上TOP ダイヤルアップ時代のEC。1枚の画像の重さが売上を左右した
2000 直営店舗の開発・運営 自社ECを開発・運営し、表示速度と転換率の関係を現場で検証
現在 Core Web Vitals × AI活用 Google公式の実測データにもとづき、36項目で計画的に改善する

まずは自社サイトの現在地を、数字で確かめるところから。

LINE友だち追加でチェッカーを使う