初心者のためのサイト速度：実際に読み込み時間を改善するには

「ウェブサイトの速度」が本当に意味すること

「サイトが遅い」と言うとき、人々が通常指しているのは次のどちらかです：

• ページが何も表示し始めるまで時間がかかる、または
• 見た目は読み込み済みでも反応が鈍い（ボタンの反応が遅い、画像が後から出てくる、ページがジャンプする）。

「読み込み時間」は単一のストップウォッチの数字ではありません。ページは段階的に読み込まれます：ブラウザがファイル（HTML、画像、フォント、スクリプト）を要求し、ダウンロードし、それを使えるページに変換します。店を開けることに例えると、鍵を開け、照明を付け、棚を並べ、ようやく接客準備が整う、といった流れです。

速度が重要な理由（単に「見栄えがいい」以上の話）

速度は次に影響します：

• ユーザー： モバイルや不安定な接続では遅いページはストレスになります。ユーザーはすぐ離脱し、サイトへの信頼も下がります。
• SEO： Googleはページ体験の一部として速度関連のシグナル（Core Web Vitalsを含む）を使用します。速いサイトが自動的に1位になるわけではありませんが、遅いサイトは足を引っ張ります。
• コンバージョン： 余分な遅延は摩擦を増やします—登録が減る、購入が減る、フォーム送信が減る。

期待値を設定：多くの成果は少数の改善から来る

50個のマイクロ最適化は必要ありません。多くの初心者サイトで最大の改善は短いリストから得られます：画像、過剰なJavaScript/CSS、サードパーティウィジェット、そしてサーバー／ホスティングの応答時間です。

このガイドで扱うこと（と扱わないこと）

このガイドは実用的でリスクが低く、実際のページ読み込み時間を改善する手順に集中しています。アプリアーキテクチャの全面的な書き直し、カスタムキャッシュレイヤーの構築、大規模なエンジニアチーム向けのパフォーマンス予算などの高度なトピックには踏み込みません。目標は、サイトを壊さずに実行・検証できる変更を手に入れることです。

知っておくべき主要な速度指標（専門用語抜きで）

「サイトが遅い」と言うとき、人々が通常意味するのは主に3つです：主要コンテンツの表示が遅い、操作に対して反応が鈍い、あるいはレイアウトが読み込み中にジャンプする。GoogleのCore Web Vitalsはこれらの不満に対応しています。

3つのCore Web Vitals

LCP（Largest Contentful Paint）: 最大の「主要」要素（多くはヒーロー画像や見出しブロック）が表示されるまでの時間。LCPが遅いと、ユーザーはほとんど空白のページを見続けることになります。

INP（Interaction to Next Paint）: ユーザーが操作（タップ、クリック、入力）した後にページがどれだけ速く応答するか。INPが高いと、サイトはもたつく感じになります—ボタンの反応が遅れたり、メニューの開閉に遅延が出たりします。

CLS（Cumulative Layout Shift）: 読み込み中にページがどれだけジャンプするか。テキストがずれてボタンを誤タップしたら、それがCLSです。

TTFB：最初の応答時間

**TTFB（Time to First Byte）**は、サーバー（とその間のすべての処理）が何かを送り始めるまでの時間です。TTFBが遅いと他のすべてが遅れます：画像のダウンロード開始が遅れ、フォントが遅れ、結果としてLCPが悪化することが多いです。TTFBの問題はしばしばホスティング、重いバックエンド処理、あるいはキャッシュの欠如を示します。

ラボテストと実ユーザーデータの違い

ラボテスト（Lighthouseなど）は特定の条件でのページ読み込みをシミュレートします。デバッグやビフォーアフターの比較に便利です。

実ユーザーデータ（フィールドデータ、たとえば PageSpeed Insights の CrUX）は訪問者が実際に体験するものを反映します。実際のユーザーにとって「本当に速く感じるか」はこちらが最も重要です。

初心者向けの「十分良い」目標

• LCP: 目標 ≤ 2.5s（4.0s までは改善が必要）
• INP: 目標 ≤ 200ms（500ms までは改善が必要）
• CLS: 目標 ≤ 0.10（0.25 を超えると問題）
• TTFB: 目標 ≤ 0.8s（1.8s を超えると体感で遅いことが多い）

何かを変更する前にサイトをどう測るか

ベースラインを取らずに「最適化」を始めると、時間を無駄にしたり、誤ってサイトを遅くしてしまうことがあります。まず20分かけて測定し、どの変更が効果的かを把握しましょう。

PageSpeed Insights を使う（素早い現実チェック）

PageSpeed Insights を使うと迅速なスナップショットが得られます。フィールドデータ（実ユーザー体験、利用可能な場合）とラボデータ（シミュレーション）を報告します。注意すべき点：

• モバイルとデスクトップの結果（問題は通常モバイル）
• 「Opportunities」リスト（アイデアには良いが厳密なTo‑Doではない）
• テストにそのURLの実ユーザーデータがあるかどうか

詳細なラボテストは Chrome の Lighthouse を使ってください：

1. DevTools を開き → Lighthouse
2. Mobile と Performance を選択
3. 2〜3回実行して中央の結果を取る（テストはばらつきます）

ウォーターフォールを見るなら WebPageTest

何がページを遅くしているかを知りたいときは、WebPageTest の ウォーターフォールビュー が非常に分かりやすいです。HTML、画像、フォント、スクリプト、サードパーティタグなど、ブラウザが待っている箇所を一つずつ表示します。

重要なページ（トップページや主要ランディングページ）で次をテストしてください：

• First View（コールドキャッシュ）と Repeat View（キャッシュあり）
• 可能ならモバイルデバイスプロファイルで

テスト条件を記録する（結果に意味を持たせるため）

各テストで書き留めること：

• デバイス（ノートPC、ミドルレンジのスマホなど）
• ネットワーク（Wi‑Fi、4G、スロットリング設定）
• 場所（WebPageTest のテスト地域）
• 正確なURL（パラメータ含む）

シンプルなビフォー／アフターチェックリストを作る

小さなログ（スプレッドシートで十分）を作り、日付、使用ツール、URL、結果、行った変更を記録します。1〜2点だけ同時に変更し、同じ条件で再テストしてください。

アプリを反復している場合（静的サイトだけでなく）、スナップショットを取って変更をテストし、問題があればロールバックできる仕組みを用意しておくと便利です。たとえば Koder.ai のようなプラットフォームは、チャットワークフローからReact/Goアプリを生成・ホストでき、スナップショットとロールバック機能で性能実験を安全に行えます。

ページが遅い最も一般的な理由

遅いページはたいてい1つの謎めいた問題のせいではありません。いくつかの一般的な「重さと遅延」の問題が積み重なっていることが多いです（特にモバイルで顕著）。

1) 必要以上に大きい画像

画像はページで最も重い部分であることが多いです。ヒーロー画像が間違ったサイズで出力されているだけで数メガバイトになり、数秒を追加します。

よくある例：

• 表示幅が1200pxなのに4000pxの写真をアップロードしている
• 写真にPNGを使っている（古いフォーマット）—WebP/AVIFが有利
• 同じ大きな画像をデスクトップとモバイル両方に配信している

2) 過剰なJavaScript（と追加のアドオン）

JavaScriptはページが使えるようになるまでを遅らせることがあります。ページが「表示」されても、スクリプトの読み込み・解析・実行中は体感で遅く感じることがあります。

サードパーティスクリプト（チャット、ポップアップ、ヒートマップ、A/Bテスト、広告タグ、ソーシャル埋め込み）はしばしば問題を引き起こします。各スクリプトが追加のネットワークリクエストを生み、ブラウザの重要な作業を遅らせます。

3) 遅いホスティングや重いサーバ処理

ブラウザがページを読み込み始める前にサーバーを待っていることがあります。これはTTFBとして感じられます。原因は、力不足のホスティング、混雑したデータベース、最適化されていないテーマやプラグイン、あるいは毎回動的にページを作っていることなどです。

4) キャッシュがないこと＋リクエストが多すぎる

サイトが毎回ゼロから読み込むようになっていると、再訪問者は不利になります。キャッシュがなければサーバーは何度もページを再構築し、ブラウザは頻繁に変わらないファイルを再ダウンロードします。

また、フォントやスクリプト、スタイル、トラッカーなど小さなファイルが多数あると「リクエストのオーバーヘッド」が発生します。個々は小さくても合計の待ち時間は積み重なります。

朗報：これらの原因は修正可能で、多くの場合はこの順で対処すると最大の成果が得られます。

画像：最も速く確実な速度改善

一つだけ改善するなら、画像です。多くの初心者サイトでは、画像がページのダウンロード「重さ」の大部分を占めます。良いニュースは、画像の修正は通常安全で、短時間で済み、デザインを変える必要がほとんどないことです。

1) 表示サイズに合わせてリサイズする

よくあるミスは、大きな写真（例：4000px幅）をアップロードしてサイトでは800pxで表示することです。ブラウザは依然として大きなファイルをダウンロードします。

最大表示サイズに近いサイズで画像をエクスポートするようにしましょう。たとえばブログのコンテンツ幅が800pxなら、3000〜4000pxを不必要にアップロードしないでください。

2) 可能ならモダンフォーマット（WebP/AVIF）を使う

JPEGやPNGも動作しますが、モダンフォーマットは同等の見た目でファイルサイズをかなり小さくできます。

• WebP は広くサポートされ、デフォルトとして良い選択です。
• AVIF はさらに小さくなることがありますが、エンコードが遅くサポート状況がやや限定的です。

CMSや画像プラグインが自動でWebP/AVIFを配信し、フォールバックを用意してくれるのが理想です。

3) 画像を圧縮し、不要なメタデータを削除する

圧縮で即効性のある改善が得られます。「見た目はほとんど変わらない」画像が30〜70%も小さくなることがあります。カメラ情報や位置データなどのメタデータは見た目に影響しないので削除してください。

実用ルール：品質に明確な劣化が見えるまで圧縮し、そこから一段戻すイメージで調整します。

4) レスポンシブ画像（srcset）でモバイルとデスクトップに応じたサイズを提供する

モバイルユーザーにデスクトップ用サイズをダウンロードさせるべきではありません。レスポンシブ画像を使うと、ブラウザが画面幅に基づいて適切なサイズを選びます。

テーマやCMSが複数の画像サイズを自動生成するなら、ページのHTMLで srcset のような仕組みが使われているか確認してください。単一の巨大ファイルだけが出力されているのは避けたいです。

クイックチェックリスト

本格的なチューニング（コードの最小化など）に進む前に上位の画像だけを監査してください：

• 表示される場所に合わせたサイズになっているか？
• 可能ならWebP/AVIFで配信されているか？
• 圧縮は適切か？
• モバイルには小さいバージョンが提供されているか？

これら4点を徹底すれば、多くの場合すぐにサイト速度とページ読み込み時間が改善し、Core Web Vitalsに良い影響を与えます。

レイジーロードとファーストスクリーンの優先順位

レイジーロードは、ページが全て同時にダウンロードするのを避け、表示直前まで画像（および場合によってはiframe）を遅らせる手法です。長いページや画面外に大量の画像がある場合に特に有効です。

いつレイジーロードが有効か

次の場合に効果的です：

• 商品グリッド、ブログ記事、ランディングページのようにファーストスクリーンの下にコンテンツが多い場合
• 埋め込み動画や地図がすぐには必要ない場合
• モバイルユーザーで接続が遅い場合

適切に使えば初期の作業量が減り、ページが速く感じられます。

ヒーローは遅延読み込みしない（LCPを守る）

ファーストスクリーンの最大の画像は多くの場合ヒーローです。これを遅延読み込みすると、ブラウザがリクエストを遅らせてしまい、LCPが悪化することがあります。

経験則：主要なヒーロー画像やファーストスクリーンの重要要素は遅延読み込みしてはいけません。

レイアウトシフトを防ぐために幅／高さを予約する

レイジーロードは画像出現時に「ジャンプ」を引き起こすことがあります。CLSを防ぐにはスペースを予約してください：

• 画像に width と height を設定する、または
• 固定アスペクト比を使ったCSSを適用する

こうすることで画像が読み込まれてもレイアウトが安定します。

本当に重要なものをプリロードする

ファーストインプレッションに不可欠な画像やフォントは プリロード を検討し、ブラウザが早めに取得するようにします。ただしプリロードをやりすぎると帯域を奪い逆効果になるので節度を持って使ってください。

このチェックを /blog/how-to-measure-site-speed-before-you-change-anything の測定ステップと組み合わせると効果的です。

キャッシュの基本：再訪問を格段に速くする

キャッシュはブラウザが「これは前にダウンロードしたから再利用できる？」と判断する仕組みです。同じロゴやCSSファイル、JavaScriptバンドルを毎回ダウンロードさせないことで再訪問が速くなりデータ利用も減ります—特にモバイルで効果的です。

ブラウザキャッシュを平易に説明すると

ファイル（styles.css や app.js など）を送るときに、そのファイルをどれくらいの期間再利用してよいかを指示できます。ブラウザが30日間キャッシュしてよいと指示されていれば、次回訪問時にそのファイルは端末から素早く読み込まれます。

これは初回訪問を魔法のように速くするわけではありませんが、次のような場面で劇的に速さをもたらします：

• ユーザーが別のページをクリックしたとき
• 数日〜数週間の間に行う再訪問
• 接続が不安定なユーザー

「静的」ファイルには長めのキャッシュヘッダーを設定する

静的ファイルは毎分変わるものではありません：画像、CSS、JavaScript、フォント。こうしたファイルは長めにキャッシュするのが良い候補です。

概念的には欲しい設定：

• CSS/JS/画像： 週〜月単位で長くキャッシュ
• HTMLページ： 注意して短めに（コンテンツ変更のため）

ホストやCMS、フレームワークに「静的アセットキャッシュ」のトグルがあることが多いです。開発者がいるなら、アセットに適切な Cache-Control ヘッダーを設定してもらってください。

更新時にユーザーが古いファイルを受け取らないようにする（バージョン付きファイル名）

長めにキャッシュしておくと「1か月後に更新してもユーザーに反映されないのでは？」という不安が出ます。解決策は バージョン付きファイル名 です。

例：

• app.3f2a1c.js
• styles.a81b09.css

内容が変わるとファイル名が変わるのでブラウザは新しいファイルとして取得します。これにより長いキャッシュと迅速な更新が両立します。

サービスワーカーについて（上級）

サービスワーカーを使うとキャッシュ制御をさらに細かく行え、オフライン動作を可能にすることもあります。ただし実装が不適切だと「古いコンテンツが出続ける」などのトラブルを招くので、初心者は上級オプションとして扱い、明確な目的と経験者による保守がある場合に検討してください。

CDNの説明：効果があるときとないとき

CDN（コンテンツ配信ネットワーク）は、複数地域に分散したサーバー群が訪問者に近い場所からファイルを配信する仕組みです。すべてのリクエストが単一のホスティングサーバーまで届く代わりに、多くのリクエストを近くのサーバーで捌けるようになります。

CDNが実際にしてくれること

CDNは主に静的アセット（画像、CSS、JavaScript、フォント、動画など）を速く配信するのに向いています。これらのファイルはコピーしてエッジサーバーに置き、多くの訪問者で共有できます。

特に効果的なのは、訪問者が複数都市／国に散らばっているサイト、メディアを多く配信するサイト、国外からのトラフィックがある広告キャンペーンを走らせるビジネスなどです。

グローバルな訪問者へのレイテンシ低下

距離は遅延を増やします。サーバーがある国と訪問者のいる大陸が違うと、すべてのファイルリクエストに余分な遅延がかかります。CDNはキャッシュされたファイルを訪問者の近くのエッジサーバーから配信することでその遅延を減らし、ページ読み込み時間とCore Web Vitalsに寄与することが多いです。

静的資産と動的ページの違い

• 静的資産： CDNに最適。積極的にキャッシュする。
• 動的ページ（カート、アカウント領域）： 安全にキャッシュできない場合が多い。部分的にしかキャッシュできないこともあります。いくつかのCDNは「ダイナミックアクセラレーション」をサポートしますが、これは上級で必ずしも確実な勝ち筋ではありません。

よくある落とし穴

キャッシュヘッダーの誤設定でキャッシュされなかったり、逆に古いキャッシュが残ったりします。これを避けるにはバージョン付きファイル名を使い、CDNの「パージ」機能を覚えておいてください。

CDNは重い画像や肥大化したスクリプト、遅いホスティングの代替にはなりませんが、基礎が整っていれば強力な乗数効果をもたらします。

CSSとJavaScriptを削っても壊さない方法

CSSとJavaScriptは「目に見えない重さ」としてページを遅くします。画像のように見てすぐ分かるわけではありませんが、ブラウザはこれらのファイルをダウンロードして解析・実行する必要があります。

CSS/JavaScriptの最小化（何が変わり、何が変わらないか）

最小化（minify）は空白やコメント、改行を取り除きます。ファイルサイズは小さくなり、ダウンロードは速くなります。

変わるもの：ファイルサイズ。変わらないもの：ブラウザがコードを解析・実行する負荷。ロード時にやることが多ければ、最小化だけでは根本解決になりません。最小化は短期の勝利です。

未使用のCSSを取り除き、そのページに必要な分だけ送る

多くのサイトは「オールインワン」スタイルシートを読み込み、現在のページで使われないルールまで含みます。余分なCSSもダウンロードされ、描画を遅らせます。

実用的アプローチ：

• ページビルダーや大きなテーマを使っている場合は「ページ単位でアセットを読み込む」オプションを探す。
• 開発者がいるなら、ファーストスクリーンに必要な最小限の critical CSS を出して、残りを遅延ロードするように頼む。

目標は簡単：ホームページがサイト全体の重さを背負わないようにすること。

非クリティカルなJavaScriptを defer または async にする

一部のスクリプトはページが利用可能になるのをブロックします。

• 自分のスクリプトでHTML解析後に実行してよいものは defer を使うのが一般的に良い。
• 他のコードに依存せず独立して動くスクリプトは async が適する。

まずはファーストスクリーンに必要でないもの（メニュー、アニメーション、スライダー、追加のトラッキング）を defer にするところから始めてください。

重いライブラリや大きなフレームワークを見直す

大きなライブラリは数百KB、あるいはそれ以上を追加します。新しいプラグインやフレームワークを入れる前に：

• 単純なコードで代替できないか？
• そのライブラリは一ページだけで使っているのではないか？

スクリプトが少ないほど予期しない問題も少なくなり、特にモバイルではCPU時間がダウンロードサイズと同程度に重要です。

サードパーティスクリプト：小さなウィジェット、大きな遅延

サードパーティスクリプトは別会社のサーバーから読み込むすべてのスクリプトです。機能をすばやく追加できる利点がありますが、ページ読み込み時間に対して最も予測不能で大きな影響を与えることが多いです。

よくある犯人（そしてなぜ遅くするのか）

主なカテゴリーは：

• 分析とトラッキング（Google Analytics、ピクセル、タグマネージャー）
• チャットウィジェット（ライブチャット、チャットボット）
• 広告とリターゲティング（広告ネットワーク、ヘッダービディング）
• 埋め込み（YouTube、ソーシャル投稿、地図、レビューウィジェット）

これらのスクリプトは追加ファイルをダウンロードし、多くのJavaScriptを実行し、時にはページの完了をブロックします。

長時間タスクやブロッキングスクリプトの見つけ方

Chrome DevTools → Performance を開き、ページ読み込みを記録して次を探します：

• 長時間タスク（メインスレッドを長時間占有しているブロック）。多くはJavaScriptが原因です。
• 早期に実行されるスクリプト（スクロールやクリックができる前に走っている）。

Lighthouse（DevTools → Lighthouse）でも「Reduce JavaScript execution time」や「Eliminate render-blocking resources」に関する推奨を確認できます。

サードパーティを害が少なく動かす方法

初心者向けの勝ち筋いくつか：

• 操作後に読み込む：チャットやレビュー、動画埋め込みはユーザーがクリックやスクロールしたときに初期化する。
• 非必須タグを遅延する：初回表示に不要なスクリプトは初期ロードで実行しない。

重い埋め込みを軽いプレビューに置き換える

フルのYouTubeやFacebook埋め込みを読み込む代わりに、サムネイル＋再生ボタンの軽いプレビューを表示し、ユーザーがクリックしたときに本体を読み込む方法が有効です。

これにより機能を残しつつ、特にモバイルでページを速く保てます。

ホスティングとサーバーパフォーマンス：TTFBを平易に

TTFBはブラウザがページを要求してからサーバーが応答を開始するまでの時間です。料理で言えば「厨房が料理を作り始めるまでの時間」であり、料理がテーブルに届くまでではありません。

TTFBが高いと、いくら見た目が最適化されていてもページは遅く感じます—特にモバイル回線では遅延が目立ちます。

TTFBを遅くする典型的な要因

TTFBは主にサーバー側の処理時間によります：

• サーバー処理時間： サイトのコードが動き、ページを組み立てる時間。
• データベース遅延： 多数のクエリや遅いクエリは時間を増やす。
• キャッシュミス： 何もキャッシュされていないとサーバーはフルビルドをする。

画像やスクリプトを最適化しても、サーバーの応答が遅ければブラウザは空白のまま待たされます。

初心者でも効く一番簡単な改善：サーバーサイドキャッシュ

CMSや動的にページを生成するサイトなら、サーバーサイドのキャッシュ がTTFB改善に最も効きます。同じページを毎回再構築する代わりに、準備済みのレスポンスを返せます。

実用例：

• ほとんど変わらないブログ記事やマーケティングページはキャッシュする。
• プラットフォームがサポートしていればフルページキャッシュを使う。
• ストアや会員サイトではキャッシュ可能な箇所（カテゴリページ、ログアウト閲覧ページ）を選んでキャッシュする。

圧縮を忘れずに（Brotli/Gzip）

テキスト系のファイル（HTML、CSS、JavaScript）は Brotli（推奨）か Gzip を有効にして圧縮してください。ネットワーク上を流れるデータ量が減り、特にモバイルでの体感速度が改善します。

いつホスティングをアップグレードするか

より良いホスティングは確かにTTFBを改善しますが、最初はフロントエンドの明らかな問題（巨大な画像、過剰なサードパーティスクリプト、重いJavaScript）を先に直す方が賢明です。大量のファイルをダウンロードさせている段階でホスティングだけ速くしても、体感は大きく変わりません。

基礎が整ったらホスティング（CPU/RAMの増強、チューニングされたDB、ランタイムの最適化）をアップグレードするのが最終手段として有効です。

新製品を作る場合は、初めからホスティングの変数を少なくしたいなら、管理されたプラットフォームを検討してください。たとえば Koder.ai はアプリをグローバルにAWS上でホストし、デプロイ、カスタムドメイン、環境のロールバックをサポートし、地域間のパフォーマンステストやデータ所在地要件への対応に便利です。

初心者向けの実用的な1週間スピードプラン

大掛かりなプロジェクトは必要ありません。終わらせられる単純な順序と、悪化していないことを確認する方法、そして確実に効果のある修正を優先する姿勢があれば十分です。

1週間の順序：測定 → 画像 → キャッシュ → JavaScriptの整理

Day 1: 測定（何も触らない）

重要なページを2〜3つ（ホーム、主要ランディング、人気のブログ/商品ページ）選び、次を実行：

• PageSpeed Insights（Core Web Vitalsに注目）
• Chrome DevTools の Lighthouse

モバイルでのベースラインとデスクトップも記録しましょう。可能なら実際の携帯でセルラー回線にてテストすると、ラボが見逃す問題が出ることがあります。

Days 2–3: 画像を直す（最速で確実な勝利）

優先すること：

• 大きな画像を圧縮し、可能ならWebP/AVIFで配信する
• 実際に表示される最大サイズにリサイズする
• メインのヒーロー画像が素早く読み込まれるようにする

数枚だけ変えて再テストし、効果を確認してください。

Days 4–5: キャッシュを整える（再訪問を格段に速く）

ブラウザキャッシュとサーバー／ページキャッシュを有効にし、同じ資産を何度も再生成・再ダウンロードさせないようにします。有効化後は再訪問で体感が速くなるか確認してください。

Days 6–7: JavaScriptを削る（長期的に大きな成果）

チェックするポイント：

• 使っていないプラグイン／機能は削除する（最適化より削除が有効）
• コンバージョンに寄与しない重いスライダーやアニメーションを外す
• 不要なトラッキングタグを減らす

ここでの小さな変更が、特にモバイルでのインタラクティビティとCore Web Vitalsを大きく改善することがあります。

各変更後のシンプルなリグレッションチェック

大きな編集をするたびに次の3点を確認してください：

1. 同じページで同じテストを再度実行し、Day 1 のベースラインと比較する。
2. 実際にサイトを訪問者のように操作（フォーム、チェックアウト、メニューなど）して、機能が壊れていないか確認する。
3. モバイル最優先で確認：デスクトップだけ速くても意味がありません。

助けを求めるタイミング

画像とキャッシュを最適化しても TTFBが高いまま なら、ホスティングやサーバー設定、遅いデータベース、あるいは重いバックエンド処理が原因であることが多いです。会員サイトやマーケットプレイスのような複雑なアプリでは「キャッシュすればよい」という単純な話にならないこともあり、その場合は外部の助けを検討してください。

詳しいサーバー応答時間に関する解説が必要なら /blog/ttfb-explained を参照してください。