パフォーマンス

Webサイトが遅いのはなぜ?原因の見つけ方と直し方

「遅い」と言っても、サーバーが遅い、メイン画像の表示が遅い、タップへの反応が鈍い、ページがガタつく、とさまざまです。どれに当たるのかを見分ける方法と、最初に直すべきものを紹介します。

執筆：Rudra Techno Team2026年9月25日読了時間 8分

このページの内容

「サイトが遅い」という言葉は、いくつかの異なる問題を指している可能性があります。サーバーが最初の1バイトを返すまでに時間がかかっているのかもしれません。ページ自体はすぐ届くのに、メイン画像の表示にひどく時間がかかっているのかもしれません。準備できたように見えて、1秒ほどタップに反応しないのかもしれません。あるいは、読み込まれたあとで広告や画像が本文を押し下げ、ページがガタつくのかもしれません。原因はそれぞれ違うので、最初にやるべきことは、自分のサイトがどれに当たるのかを突き止めることです。

何かを変える前に、まず測定する

速度のデータには2種類あり、それぞれ答えてくれる問いが違います。

フィールドデータは、実際の訪問者がそれぞれの端末と回線で体験した結果から得られます。十分なトラフィックがあるサイトについてはGoogleのChrome UX Reportが収集しており、PageSpeed Insightsや、Google Search Consoleの「ウェブに関する主な指標」レポートで確認できます。人々が実際に何を体験しているかを教えてくれるデータです。
ラボデータは、Lighthouseのように、管理された条件下でページを1回読み込んで得られます。実態を代表する度合いは下がりますが、再現性があり、ページがなぜ遅いのかを説明してくれます。

GoogleのCore Web Vitalsは、実際の訪問の75パーセンタイルで測定して、Largest Contentful Paint (LCP) が2.5秒以下、Interaction to Next Paint (INP) が200ミリ秒以下、Cumulative Layout Shift (CLS) が0.1以下であることを良好な体験としています。

原因の診断には、ラボテストを実行します。Rudraの無料サイト表示速度チェッカーは、Lighthouseでページを読み込み、First Contentful Paint、LCP、Total Blocking Time、CLS、Speed Index、Time to Interactiveに加えて、合格しなかったLighthouseの監査項目を深刻なものから順に報告します。ただし、限界も頭に入れておいてください。これは当社のサーバーから、Lighthouseのシミュレーション条件下で1回読み込んだ結果なので、数値がフィールドデータと完全に一致することはありません。また、実際の操作が必要なINPは測定できません。ラボで得られる指標のうち、応答性に最も近いのはTotal Blocking Timeです。

代表的なページの種類をいくつか(トップページ、商品またはサービスのページ、記事)選び、それぞれ複数回テストして、デスクトップだけでなくモバイルの結果も確認してください。

よくある原因と、その直し方

1. サーバーの応答が遅い

サーバーがHTMLを返すまで、ほかのことは何も始まりません。Time to First Byteが長い場合、原因はたいてい、安価なホスティングや過負荷のホスティング、リクエストのたびにページを一から生成していること、遅いデータベースクエリ、あるいは訪問者がサーバーから遠いことです。対処法は、ページキャッシュを有効にする(ほとんどのCMSにキャッシュ用のプラグインか設定があります)、サイトの前段にCDNを置く、不要なプラグインを削除する、そしてサーバーが単純に力不足ならホスティングをアップグレードする、です。GoogleのガイダンスではTTFBが0.8秒以下なら良好とされています。Rudraはサイト全体のクロールで、サーバーの応答に1.5秒を超えてかかったページを指摘し、3秒を超えた場合は重大として扱います。

2. 大きすぎる画像

カメラやスマートフォンからそのまま書き出した写真は、数メガバイト、幅数千ピクセルになることがあります。それが800ピクセルで表示されているわけです。リサイズと圧縮を行い、新しい画像形式を使いましょう。画像サイズを小さくする方法のガイドで、手順を順を追って説明しています。

3. JavaScriptが多すぎる

大きなバンドルやサードパーティのタグ(アクセス解析、チャットウィジェット、A/Bテスト、広告スクリプト)は、ブラウザのメインスレッドを奪い合います。長いスクリプトが実行されている間、ページはタップに反応できません。これはラボではTotal Blocking Timeの長さとして、フィールドではINPの悪化として表れます。サードパーティのタグをすべて棚卸しして、誰も使っていないものは削除しましょう。必須でないウィジェットは、ページが操作可能になったあと、または訪問者が求めたときに読み込みます。大きなバンドルは分割して、各ページが必要なものだけを読み込むようにします。

4. レンダリングを妨げるCSSとスクリプト

<head> 内にある async も defer も付いていないスクリプトと、すべてのスタイルシートは、ブラウザが何かを描画する前に読み込まれなければなりません。すぐに実行する必要のないスクリプトには defer を付けます(例: <script src="/app.js" defer></script>)。不要なスタイルシートは統合するか削除し、ページ上部の表示に必要なわずかなCSSはインライン化することも検討してください。

5. 圧縮されていない

テキストファイル(HTML、CSS、JavaScript、JSON、SVG)は、gzipやBrotliで劇的に小さくなります。ブラウザのNetworkタブでページのレスポンスヘッダーを開き、content-encoding: br または gzip があるかを確認してください。なければ、サーバー側(nginxなら gzip on; と gzip_types のリスト)またはCDNで有効にします。

6. キャッシュされていない静的ファイル

再訪問した人に、ロゴやスタイルシートをもう一度ダウンロードさせるべきではありません。内容が変わるとファイル名も変わるファイル(ほとんどのビルドツールは app.3f9a2c.js のようにハッシュを付けます)には、Cache-Control: public, max-age=31536000, immutable を送信します。HTMLは短めのキャッシュか再検証にしておき、更新がすぐ反映されるようにします。

7. 重いWebフォント

複数のフォントファミリーをそれぞれ多くのウェイトで読み込むと、あっという間に容量がかさみます。しかもフォントのダウンロード中は、テキストが見えないままになることがあります。ウェイトの数を減らし、WOFF2で配信し、必要な文字だけにサブセット化しましょう。font-display: swap を指定すれば、代替フォントでテキストがすぐに表示されます。プリロードするのは、ファーストビューで使う1つのフォントだけにします。システムフォントスタックを使えば、ダウンロード自体が不要になります。

8. レイアウトシフト

ページがガタつく原因は、たいてい、表示領域が確保されていない画像や埋め込み、コンテンツに差し込まれる広告、読み込み後に本文の上に現れるバナーです。すべての画像に width 属性と height 属性(またはCSSの aspect-ratio)を指定し、広告や埋め込みには min-height で領域を確保します。Cookieバナーやキャンペーンのバナーは、コンテンツを押し下げるのではなく、重ねて表示するようにします。

9. 肥大化したページと多すぎるリクエスト

非常に大きなHTMLドキュメント(インラインで埋め込んだデータや、延々と続く商品グリッドが原因であることが多い)、何十ものスクリプト、同じスクリプトの二重読み込みは、いずれもページを遅くします。長いリストはページ分割し、大きなインラインデータはキャッシュされる別ファイルに移し、重複したタグは削除しましょう。Rudraのクロールは、1 MBを超えるHTMLドキュメント、100を超えるリソースを参照しているページ、複数回読み込まれているスクリプトを指摘します。

10. ページの読み込みが始まる前のリダイレクト

example.com と入力した訪問者が https://example.com へ、次に https://www.example.com へ、さらに /home へとリダイレクトされると、転送のたびに待たされます。最終的なURLへ1回で直接リダイレクトし、リンクはどこでも最終的なURLに張ってください。

最初に直すべきもの

サーバーの応答が遅いなら、そこから始めます。 ほかの指標はすべて、サーバーの応答を待つことになるからです。
LCPが悪いなら、LCP要素を特定します。 Lighthouseがどの要素かを示してくれます。たいていはヒーロー画像(圧縮し、遅延読み込みはせず、fetchpriority="high" の指定も検討します)か、フォントやレンダリングを妨げるCSSに足止めされている見出しです。
Total Blocking TimeやINPが悪いなら、JavaScriptを調べます。 特にサードパーティのタグです。
CLSが悪いなら、表示領域を確保します。 対象は画像、埋め込み、広告、バナーです。
変更のたびに再テストします。 実際に何が効いたのかがわかるようにするためです。

速度テストではわからないこと

ラボテストは、公開されている1つのURLを、ログアウトした状態で、1つの場所から読み込みます。ログインの先にある遅い購入手続きのステップ、別の大陸の訪問者にだけ遅いページ、1分ほどスクロールして初めて不具合を起こすウィジェットは見えません。ラボテストは問題を見つけて説明するために使い、改善の効果はその後の数週間、フィールドデータで確認してください。

よくある間違い

訪問者が体感する指標ではなく、Lighthouseの満点を追いかける。
オフィスの高速なWi-Fiにつないだデスクトップでしかテストしない。
ヒーロー画像を遅延読み込みして、LCPを遅らせてしまう。
「高速化」やキャッシュのプラグインを複数入れて、互いに競合させてしまう。
1回のテスト結果だけで変更の効果を判断する。結果は実行のたびにばらつきます。

サイトを遅くしている原因を見つける

無料の監査を実行しましょう。Rudraがページをクロールし、遅いサーバー応答、レンダリングを妨げるリソース、圧縮の未設定、サイズ指定のない画像を指摘します。

よくある質問

ページの読み込み時間はどれくらいなら良いのですか?

1つの数字で答えることはできません。「読み込み時間」にはいくつもの意味があるからです。最も役に立つ目標はGoogleのCore Web Vitalsで、実際の訪問の75パーセンタイルで測定して、LCPが2.5秒以下、INPが200ミリ秒以下、CLSが0.1以下です。

テストするたびに速度スコアが変わるのはなぜですか?

ラボテストの結果は、サーバーの負荷、ネットワークの状況、実行のたびに挙動が変わるサードパーティのスクリプトによってばらつきます。テストを数回実行して典型的な結果を比べ、実際の状況はフィールドデータで判断してください。

サイトの表示速度はSEOに影響しますか?

Core Web VitalsはGoogleがページ体験を評価する要素の一部ですが、関連性とコンテンツの質のほうがはるかに重要です。表示速度はまずユーザー体験の問題としてとらえ、検索での成果にもいくらかプラスになり得るもの、と考えるのがよいでしょう。

自分には速いのに、ほかの人には遅いのはなぜですか?

あなたのブラウザにサイトがキャッシュされている、サーバーの近くに住んでいる、高性能な端末を使っている、あるいはログイン中やキャッシュ済みのバージョンを見ている、といった可能性があります。サーバーから遠く、ミドルレンジのスマートフォンとモバイル回線で訪れる人の体験は別物です。だからこそフィールドデータが重要なのです。