2026.09.02

自社ECサイトの表示が重い――原因はサーバー？プログラム？無料ツールでできる簡易診断と「直すべき場所」の判断基準

執筆者情報

中村圭介

株式会社カジヤ/代表取締役　男性向けファッション通販サイト運営の会社を経験し、現職に至る。デザインや開発から、ECやメディアのコンサルティングまでを一貫して行う。お付き合いのあるお客様の事業を成功に導けるように、再現性のある成長支援ができる会社を目指す。

【AIによる要約】
– 表示速度の遅さの原因は「サーバー」「画像」「プログラム」の3系統に大別でき、無料ツールで概ね切り分けられます。
– PageSpeed Insightsでモバイルを計測し、LCPが2.5秒以内か、どの項目が赤字かを確認するのが診断の核心です。
– 画像の最適化は自分たちでも対応できますが、サーバー応答やJavaScript周りはプロに相談するのが安全です。

「最近、自社のECサイトの表示が遅い気がする……」――それを感じたとき、多くの担当者は「サーバーのせい？」「制作会社に作ってもらったプログラムのせい？」と原因が分からず、そのまま放置してしまいます。

しかし、私たちカジヤが業界歴10年以上・300社以上の支援を通じて見てきた限り、表示速度の低下は「遅い」と感じている以上に売上へ影響しています。 ECサイトは表示が1秒遅くなるだけで、商品をカートに入れる前に訪問者が離脱していく世界です。

結論から言うと、表示速度の原因の多くは、無料ツールを使うだけで概ね切り分けられます。本記事では、プログラミングの知識がない担当者でもできる診断手順と、そこで出た数字の読み方、そして「自力で対応できる範囲」と「プロに任せるべき境界線」を、現場目線で解説します。

1. なぜ「表示が重い」が売上の問題になるのか

訪問者は待たない。数字で明確な事実

表示速度と売上の関係は、Googleが公開するデータでも明確に示されています。

ページの読み込み時間が1秒→3秒に伸びると、モバイルでの離脱確率が32%上昇するという計測結果が、Google公式のリサーチで公表されています。
出典：Find out how you stack up to new industry benchmarks for mobile speed（Think with Google）

また、Googleは検索順位の判断材料として「Core Web Vitals（コアウェブバイタル）」という表示速度・操作性の指標を導入しています。つまり表示速度は「離脱＝機会損失」と「SEO評価」の両方を同時に悪化させる、ダブルパンチの問題です。

私たち自身、自社でも複数のEC事業（日本酒ラボ、SAKE CABINETなど）を運営しているため、この「表示が遅い日には売上が静かに落ちる」という感覚を当事者として知っています。サーバー障害のように派手に止まるわけではない分、気づきにくく、被害が長期化しやすいのが速度問題の厄介なところです。

2. まず押さえるべき「遅さの原因は3系統」の全体像

原因不明のまま漠然と不安になるのが一番よくありません。表示速度の遅さは、次の3系統に大別できます。

系統	典型的な原因	技術に詳しくなくても分かるサイン
① サーバー系	サーバーのスペック不足、古いPHP、同時アクセス増加で処理が追いつかない	最初の1バイトが返ってくるまでが遅い。時間帯（昼のアクセス集中時）だけ重くなる
② 画像・コンテンツ系	スマホで撮影した縦数千pxの写真をそのままアップロード、動画・フォントが重い	画像が表示されるまでやたら時間がかかる。サイト全体ではなく商品ページだけ重い
③ プログラム系	CMS・プラグインの肥大化、古い独自システム、お問い合わせや検索機能の処理が重い	画像は出ているのに操作（検索・カート投入）への反応が遅い

表示速度の診断フロー

診断とは、この3系統のどれに原因があるかを無料ツールで絞り込む作業です。順番に見ていきましょう。

3. 【実践】技術に詳しくなくてもできる簡易診断の進め方

ステップ1：PageSpeed Insightsで一度計測する

Googleが無料で提供している PageSpeed Insights に自社サイトのURLを入力するだけで、数十秒後に診断結果が出ます。インストールも専門知識も不要です。

ここで見るべきポイントは、数字そのものより「赤い項目」です。

「パフォーマンスの診断」スコア：モバイルが30〜40台であれば明確に問題あり。50以上なら致命的ではないが改善余地あり、と現場では判断しています。
Core Web Vitalsの指標：中でも重視すべきは LCP（最大コンテンツの描画）。Googleは2.5秒以内を「良好」と定めています。
出典：Core Web Vitals（web.dev）
「改善できる項目」セクション：ここに「画像の配信に最適化されていないフォーマットを使用しています」「使用していないJavaScriptの削除」などが並んでいたら、そのカテゴリが原因の候補です。

読み方の判断基準をまとめます。

診断結果のサイン	推定される原因系統	対応の方向性
「画像を最適化して配信してください」が上位に表示	② 画像・コンテンツ系	自分たちでも対応可能な領域
「サーバー応答時間を短縮してください（TTFB）」が表示	① サーバー系	インフラ・開発会社への相談案件
「使用していないJavaScript」「レンダリングを妨げるリソース」が大量表示	③ プログラム系	プロへの相談案件（部分改善は可能だが手を出すと壊れる）

ステップ2：時間帯による差を確認する（サーバー系の切り分け）

朝・昼・夜の数時間おきに、スマホで自社サイトを数回開いて体感を比較します。

昼の受注ピーク時間帯だけ明らかに重い → 同時アクセスに対してサーバー処理が追いついていない「① サーバー系」の疑いが濃厚です。
時間帯に関係なく常に重い → 画像やプログラムなど「ページそのものの重さ」の疑いが高い。

これは完璧な計測ではありませんが、「タイミングで重さが変わるかどうか」はプロでも最初に必ず確認するポイントです。

ステップ3：ページを1つ固定して比較する

トップページ・商品一覧・商品詳細・カート画面のそれぞれでPageSpeed Insightsを回すと、「どのページだけ悪いか」が分かります。

商品詳細ページだけ悪い → その商品ページだけ画像が極端に大きい（②系）
全ページ一様に悪い → サーバー or サイト全体のプログラム問題（①③系）

このように「範囲を狭めていく」こと自体が診断です。原因が絞れていれば、プロに依頼する場合も「〇〇が原因の可能性が高い」と伝えられるため、調査費用の削減に直結します。

4. 【重要】自力で触ってはいけない境界線

ここまで診断方法を解説してきましたが、私たちが300社以上の支援で繰り返し見てきた一番大きな事故は「診断で見つけた改善項目を、知識のないまま自分で直そうとしてサイトを壊す」ことです。

自分たちで対応してよい範囲（②系の一部）

商品画像が縦数千pxのままアップロードされている → 画像リサイズツールで縮小して登録し直す。これは管理画面操作だけで完結し、効果も出やすい
動画を直接アップロードしている場合は、YouTube等の埋め込みへの切り替えを検討

プロへ相談すべき範囲（①③系）

サーバーのプラン変更・PHPバージョンの更新・キャッシュ設定
プラグインの無効化・削除、テーマの改修
「使用していないJavaScriptを削除」といったコードレベルの対応

特にプラグインの停止やPHPの変更は、ECサイトでは決済機能が止まる事故を起こし得る領域です。うまくいかない場合、復旧コストの方が大きくなります。「スコアが悪い=自分で直す」ではなく、「スコアの悪さを数値として記録し、プロに渡せる状態にする」ことまでが社内の担当範囲と考えていただくのが安全です。

5. プロは診断後に何をしているのか（裏側の可視化）

「無料ツールで数値が出るなら、なぜ業者に依頼すると費用がかかるのか」という疑問はもっともです。当社が保守管理や速度改善のご依頼をいただいた際に実際に行っている工程を公開します。

計測環境の整備：PageSpeed Insightsの数値は変動するため、実ユーザーデータ（Chrome UX Report）を含めた複数回計測で母数を確保
サーバー側の調査：サーバーのスペック・同時接続数・PHPバージョン・DB（データベース）の負荷状況を確認
フロント側の調査：読み込まれている画像・JS・CSS・外部スクリプト（アクセス解析やタグ等）の総量と読み込み順序の分析
本番に触らない範囲での仮説検証：ステージング環境での改善シミュレーション
改善の実施・実機テスト：速度だけでなく、カート投入や決済導線が壊れていないかの実機テストまでがセット

つまり無料ツールが出すのは「問診票」までであり、「どこをどう直して、直した結果売上にどう効くか」までを判断するには技術調査と検証工程が必要です。この工程の有無が、「速度改善」と謳うサービスの品質の分かれ目だと私たちは考えています。