共有ホスティングで TTFB を削減する方法 (2026 ガイド)

キャッシュが有効になっています, 圧縮された画像, スクリプトが延期されました. 最適化プラグインが推奨することはすべて完了しました. それでも、PageSpeed Insights はまだフラグを立てています “サーバーの初期応答時間を短縮する” 赤で. 犯人はTTFB: 最初のバイトまでの時間. このメトリクスは、サーバーがリクエストを受信して​​からデータの送信を開始するまでにかかる時間を測定します。. 共有ホスティングについて, TTFB は通常 800ms を超えます. Googleは200ミリ秒未満を推奨しています.

簡単な回答: 共有ホスティングにおける TTFB の最速の改善は、LSCache を備えた LiteSpeed 搭載ホストへの切り替えによってもたらされます。, 他に何も変更せずに、応答時間を 800 ミリ秒から 200 ミリ秒未満に短縮できます。. ホストを切り替えることができない場合, 無料のCloudflare CDNを有効にする, PHP にアップグレードする 8.2+, OPcache を適切に構成すると、次のように TTFB を削減できます。 50-70% ほとんどのセットアップでは. 下, それぞれの方法を段階的な手順で説明します.

最終レビュー済み: 2月 2026. 現在のホスティング環境で検証された方法.

ほとんどの TTFB ガイドは、共有ホスティング特有の制約には触れずに、同じ一般的なアドバイスを繰り返しています。. カスタムサーバーソフトウェアをインストールできない. CPU とメモリを他の数十のアカウントと共有しています. このガイドは、これらの制限内で実際に機能する最適化に焦点を当てています。, 各方法に対する現実的な期待を伴う.

TTFB とは何か、またそれが重要な理由 2026?

TTFB (最初のバイトまでの時間) ブラウザがページをリクエストしてから応答データの最初のバイトを受信するまでの時間を測定します。. これには 3 つのコンポーネントが含まれます: DNSルックアップ時間, 接続の確立, およびサーバーの処理時間. の上 共有ホスティング, 通常、サーバー処理がボトルネックになります.

誰かがあなたのサイトにアクセスすると何が起こるか:

1. ブラウザはドメインの IP アドレスを検索します (DNS)
2. ブラウザがサーバーとの接続を確立します (TCP/TLSハンドシェイク)
3. サーバーはリクエストを受信して​​処理します (データベースクエリ, PHPの実行)
4. サーバーは HTML 応答の最初のバイトを送り返します

ステップの合計時間 1-4 あなたのTTFBは何ですか. 手順 1-2 ネットワークの状態と CDN 構成によって異なります. ステップ 3 サーバーの速度とサイトの最適化によって異なります. 共有ホスティングについて, ステップ 3 そこが一番時間をロスするところだ.

TTFB ベンチマーク 2026

Google のガイダンスでは、TTFB のパフォーマンスを次のように分類しています。:

• 良い: 800ミリ秒以下
• 改善が必要: 800msから 1.8 秒
• 貧しい: その上 1.8 秒

でも, これらは最小しきい値です. プレミアムマネージド WordPress ホストは TTFB を 200 ミリ秒未満で一貫して配信します. SEOとユーザーエクスペリエンスのため, を目指す 200ミリ秒未満 あなたの目標として. 600 ミリ秒を超えると、より高速な競合他社に対して不利になります。.

TTFB とコア ウェブ バイタル

TTFB は 3 つのコア Web Vitals の 1 つではありません (LCP, インド, CLS) Googleのランキングに直接影響するもの. しかし、LCP に合格できるかどうかを決定するのは基礎です (最大の満足のいくペイント). TTFB が 800ms を超える場合, 画像の最適化や JavaScript の遅延をどれだけ行っても、LCP スコアは節約できません. サーバーの起動が遅すぎるだけです.

TTFB をページ速度の基礎として考える. 基礎が遅いということは、その上に構築されるすべてのものが遅れることを意味します: 最初の満足のいくペイント, 最大の満足のいくペイント, インタラクティブまでの時間はすべて後で変更されます. Googleの 2025-2026 更新によりページ エクスペリエンス シグナルの重みが増加, TTFB の最適化がこれまで以上に重要になっています.

現在の TTFB を確認する方法

最適化する前に, ベースラインを確立する. TTFBを測定するにはいくつかの方法があります:

方法 1: Chrome DevTools (あなたの位置情報を最も正確に)

1. Chrome を開いて Web サイトに移動します
2. プレス F12 または右クリックして選択します 検査する
3. クリック 通信網 タブ
4. ページを更新する (Windows では Ctrl+Shift+R, Mac で Cmd+Shift+R を実行するとクリーン リロードが可能)
5. 最初の HTML ドキュメント リクエストをクリックします (あなたのページ名)
6. 見てください タイミング タブを押して検索します サーバーの応答を待っています

これ “サーバーの応答を待っています” 値は、現在の場所からの TTFB です。. 複数回テストして結果を平均する, TTFB はリクエストごとに異なるため.

方法 2: オンラインテストツール

地理的に異なる場所からのテスト用, これらのツールを使用してください:

• PageSpeed Insights (ページスピード.web.dev) サイトに十分なトラフィックがある場合、Chrome ユーザーからの実際のユーザー TTFB データを表示します
• GTmetrix (gtmetrix.com) 複数のサーバーの場所からテストできます
• KeyCDN ツール (tools.keycdn.com/パフォーマンス) からのテスト 10+ 世界中の拠点を同時に

対象ユーザーに最も近い場所からテストする. 訪問者が主にドイツにいて、米国からテストしている場合, 結果は実際のユーザーエクスペリエンスを反映していません.

数字が意味するもの

変更を加える前に、ベースライン TTFB を記録します。. 共有ホスティングでは通常、次のような結果が表示されます:

• 適切に最適化された共有ホスティング: 200-400MS
• 平均的な共有ホスティング: 400-800MS
• 過負荷または不適切な構成: 800msから 3+ 秒

すでに 400 ミリ秒未満の場合, 以下の最適化は役立ちますが、劇的な利益は得られません. 800ミリ秒を超える場合, 大幅な改善が可能です.

最適化 1: LSCache で LiteSpeed を使用する

予想される影響: 50-75% TTFBの削減

共有ホスティングにおける TTFB の最大の改善点は、LiteSpeed サーバー テクノロジーによるものです. LiteSpeed は、Apache に代わる高性能 Web サーバーです。. LSCache (LiteSpeedキャッシュ) PHP 経由ではなくサーバー レベルで動作する組み込みのキャッシュ システムです。.

独立したベンチマークによると、Apache を搭載したサーバーは通常 450 ～ 500 ミリ秒の TTFB を実現します. LiteSpeed は初期状態では平均 300 ミリ秒未満です, LSCache を有効にすると 100ms 未満に低下. 文書化された 1 つのケースでは、LiteSpeed ホストに移行した後、文字通り一晩で TTFB が 800 ミリ秒から 200 ミリ秒に低下したことが示されました。.

LiteSpeed が Apache に勝る理由

では、なぜ LiteSpeed はこれほど大きな違いをもたらすのでしょうか? 従来のキャッシュプラグイン (WPスーパーキャッシュ, W3トータルキャッシュ) PHP内で作業する. リクエストが届いたら, サーバーはまだ PHP をロードしています, プラグインコードを実行します, キャッシュが存在するかどうかを確認します, その後、キャッシュされたファイルを提供します. LiteSpeed のキャッシュは、PHP がロードされる前に動作します。. サーバーはキャッシュされたバージョンをチェックし、それを直接提供します, キャッシュされたページに対して PHP を完全にバイパスする.

このアーキテクチャの違いは、LiteSpeed に切り替えると Apache 上のどのプラグイン最適化よりも優れた結果が得られることが多いのかを説明しています。. 小さな利益ではない. キャッシュの仕組みが根本的に変わります.

ホストが LiteSpeed を提供しているかどうかを確認する方法

• ホスティングコントロールパネルにログインします (cPanel, DirectAdmin, または類似)
• 探す “LiteSpeed” ブランド化とか “LiteSpeed Web キャッシュ マネージャー”
• または、ホストのサポートに連絡して、LiteSpeed を使用しているかどうかを尋ねます。

LiteSpeed を使用する主要な共有ホスティング プロバイダーには HostArmada が含まれます, Hostinger (いくつかの計画について), A2ホスティング (ターボ計画), ChemiCloud, と他の多く. 現在のホストが Apache を使用している場合, LiteSpeed ホストへの移行は、より優れた TTFB への最速のパスである可能性があります.

WordPress 用の LiteSpeed キャッシュの構成

ホストが LiteSpeed を実行している場合, WordPress 用の無料の LiteSpeed Cache プラグインをインストールします:

1. をインストールしてアクティベートします LiteSpeedキャッシュ WordPress リポジトリからのプラグイン
2. 案内する LiteSpeed Cache > Cache ダッシュボードで
3. 有効 キャッシュを有効にする キャッシュ制御下
4. セット ゲストモード オンにする (初回訪問のパフォーマンスを向上させる)
5. 下 オブジェクトキャッシュ, ホストが Redis または Memcached を提供する場合に有効にします

デフォルト設定はほとんどのサイトで適切に機能します. 共有ホスティングではクローラー機能を有効にしないでください, リソースを消費し、ホストの規約に違反する可能性があるため.

最適化 2: CDN を有効にする (コンテンツ配信ネットワーク)

予想される影響: 20-40% 静的キャッシュ用, 70-90% フルページエッジキャッシュあり

CDN は、コンテンツのキャッシュされたコピーを世界中のサーバーに配置します。. 訪問者がサイトをリクエストしたとき, CDN は最も近い場所からサービスを提供します. これにより、データの物理的な移動距離が短縮されます。, ネットワーク遅延の削減.

特にTTFBの場合, CDN は 2 つの方法で役立ちます:

• ネットワーク遅延の削減: ロンドンの訪問者はロンドンのエッジサーバーからサービスを受けます, ダラスのオリジンサーバーではありません
• エッジキャッシング: CDN エッジでのフルページ キャッシュは、オリジン サーバーがキャッシュされたコンテンツに対するリクエストをまったく処理しないことを意味します

Cloudflareの無料利用枠のセットアップ

Cloudflareは、共有ホスティングとうまく連携する無料のCDNを提供します. 一部の競合他社とは異なり, 無料利用枠は人為的に制限されていません. 無制限の帯域幅が得られます, 基本的な DDoS 保護, グローバルエッジキャッシング, HTTP/2 および HTTP/3 の自動サポート. HTTP/3 だけでも、次の方法で接続遅延を短縮できます。 30-50% モバイルネットワーク上で.

1. Cloudflare.comで無料アカウントを作成します
2. ドメインを追加して、Cloudflare に既存の DNS レコードをスキャンさせます
3. ドメインのネームサーバーをCloudflareが提供するものに変更します (レジストラで)
4. DNS の伝播を待ちます (通常は下にあります 24 時間)
5. アクティブになると, 有効にする 完全SSL SSL/TLS設定の下で

セットアップ後, Cloudflareは静的アセットを自動的にキャッシュします (画像, CSS, JavaScript). フルページキャッシュの場合, ページルールまたはAPO機能が必要です (WordPress 用の有料アドオン (月額 5 米ドル)).

WordPress 用 Cloudflare APO

クラウドフレアAPO (自動プラットフォーム最適化) HTML ページ全体をエッジにキャッシュします. これは、移行せずに Apache ベースのホストに追加できる LiteSpeed レベルのキャッシュに最も近いものです。. APO の料金は月額 5 米ドルですが、TTFB を次のように削減できます。 70-90% ログアウトした訪問者向け.

ノート: Cloudflare APO は LiteSpeed Cache のゲストモードでは機能しません. LiteSpeed ホストを使用している場合, APO をスキップし、代わりにネイティブ LSCache を使用します.

最適化 3: PHP にアップグレードする 8.2 以上

予想される影響: 15-30% より高速な実行

PHP のバージョンはサーバーの応答時間に直接影響します. ベンチマークは PHP を示します 8.3 雑に扱う 14-20% PHP と比較して 1 秒あたりのリクエスト数が多い 7.4. WordPressの場合 6.4+, PHP 8.2 また 8.3 がおすすめ.

文書化された 1 つのテストでは、PHP からアップグレードするだけで TTFB が 500 ミリ秒から 175 ミリ秒に改善されることが示されました。 5.4 PHPへ 7.1. 最新の PHP 8.x バージョンもこのパフォーマンスの軌跡を継続します.

PHP を確認してアップグレードする方法

1. ホスティングコントロールパネルにログインします (cPanel または同等のもの)
2. 探す PHPバージョンの選択, PHPマネージャー, または類似
3. 現在のバージョンをメモしてください
4. PHPを選択します 8.2 またはPHP 8.3 (現在 2026, PHP 8.1 セキュリティサポートは終了しました)
5. 変更を保存する

アップグレードする前に, WordPress のテーマとプラグインに互換性があることを確認してください. 現在 2026, だいたい 90% のテーマとプラグインが PHP 8.x をサポートしています. 互換性を確認するには:

• をインストールします PHP互換性チェッカー プラグイン
• PHP に対してスキャンを実行する 8.2
• 切り替える前に互換性のないプラグインを更新または置き換えてください

最適化 4: OPcacheを適切に構成する

予想される影響: 20-40% PHPの実行時間の短縮

OPcache は、コンパイルされた PHP スクリプトをメモリにキャッシュする PHP 拡張機能です。. OPcache なし, PHP はリクエストごとにすべてのスクリプトを再コンパイルします. OPcacheを使用する場合, コンパイルされたコードはメモリに残り、すぐに実行されます. これにより、コンパイルのオーバーヘッドが排除され、TTFB が削減されます。.

ほとんどの共有ホストでは、OPcache がデフォルトで有効になっています. 問題は、デフォルト設定が WordPress にとって保守的すぎることが多いことです. OPcache を適切に調整すると、PHP の実行時間を次のように短縮できます。 50-80%.

推奨される OPcache 設定

ホストがカスタム php.ini または OPcache 構成を許可している場合, これらの値を使用します:

• opcache.enable=1
• opcache.memory_consumption=384 (デフォルト 128 WordPress には低すぎます)
• opcache.interned_strings_buffer=64
• opcache.max_accelerated_files=10000 (キャッシュするファイルが少ないとフラッシュが頻繁に発生します)
• opcache.revalidate_freq=0 (validate_timestamps をオフにした場合, また 60 それ以外の場合は秒)

デフォルトの 128MB メモリでは、複数のプラグインを使用する WordPress には十分ではないことがよくあります。. これにより、OPcache が定期的にリセットされます, キャッシュが再構築されるたびに TTFB スパイクが発生する. これを防ぐには、memory_consumption を 256 ～ 384MB に設定します。.

OPcache ステータスの確認

OPcache が動作していることを確認するには:

1. をインストールします OPcache ダッシュボード プラグインを使用するか、phpinfo ファイルを作成します
2. OPcacheが有効になっていることを確認してください
3. ヒット率を監視する (上にあるはずです 98%)
4. 立ち退きに注意 (ゼロに近いはずです)

ヒット率が低い、またはエビクションが多い場合, 割り当てられたメモリが小さすぎます. OPcache メモリ制限の引き上げについてホストに問い合わせる. 公正な警告: すべての共有ホストでカスタム OPcache 設定が許可されるわけではありません.

最適化 5: オブジェクトキャッシュを有効にする (Redis または Memcached)

予想される影響: 30-70% データベース操作の高速化 (動的ページで最も顕著です)

オブジェクト キャッシュは、WordPress データベース クエリの結果をメモリに保存します。. ページの読み込み時, WordPress はオプションを求めてデータベースに何十ものクエリを実行します, 投稿, ユーザーデータ, もっと. オブジェクトキャッシュあり, 繰り返されたクエリはデータベースにアクセスするのではなく、メモリから即座に返されます。.

この最適化は、完全にキャッシュできない動的ページで最も役立ちます。: ログインユーザーのダッシュボード, WooCommerce カート, メンバーエリア, および管理ページ. このような場合には, オブジェクト キャッシュは TTFB を最大で削減できます 70% データベースの最適化と組み合わせると.

ホストはオブジェクト キャッシュを提供していますか?

Redis と Memcached は基本的な共有ホスティングの標準ではありません. 空き状況を確認する:

• 探す レディス また Memcached ホスティングパネルのオプション
• ホスティング プランの機能リストを確認する
• サポートに連絡し、オブジェクト キャッシュが利用可能かどうか尋ねてください。

中間層およびプレミアム共有ホスティング プランには Redis が含まれることがよくあります. プランでそれが提供されていない場合, これが層またはホストをアップグレードする理由になる可能性があります. パフォーマンス上のメリットにより、データベースを多用するサイトのコストが正当化されます。.

WordPress で Redis をセットアップする

ホストが Redis を提供している場合:

1. ホスティング パネルで Redis を有効にする (通常はワンクリック)
2. をインストールします Redis オブジェクト キャッシュ プラグイン (ティル・クルス村)
3. に移動 Settings > Redis をクリックします オブジェクトキャッシュを有効にする
4. LiteSpeed キャッシュを使用する場合, 代わりに、LSCache プラグイン設定でオブジェクト キャッシュを有効にしてください

重要: Redis はサーバーに対してローカルである必要があります. リモート Redis 接続は、ネットワークのラウンドトリップにより遅延が増加するため、実際には TTFB を悪化させます。. ホストが Redis を提供している場合, 同じサーバー上にある必要があります.

最適化 6: データベースを最適化する

予想される影響: 10-30% より高速なクエリ (むくみのレベルによって異なります)

オブジェクト キャッシュは、データベースがクリーンな場合にのみ役立ちます. インデックスが不十分なテーブルを含む肥大化したデータベースでは依然としてパフォーマンスが低下します, 反復クエリを少し高速化するだけで. まず基礎となるデータ品質に対処します.

一般的なデータベース肥大化の原因

• 改訂後: WordPress はすべての編集をリビジョンとして保存します. 頻繁に編集される投稿には、 50+ 改訂
• wp_options テーブル: 自動ロードされたオプションは時間の経過とともに増加します. プラグインは削除後にデータを残すことがよくあります
• トランジェント: 期限切れのトランジェントは消去されないと蓄積される
• スパムとゴミ箱のコメント: これらはスペースを占有し、クエリが遅くなります
• ログテーブル: セキュリティおよび分析プラグインは大きなログを保存します

データベース最適化の手順

1. まずはバックアップ ホスティング パネルまたは UpdraftPlus などのプラグインを使用する
2. インストール WP-最適化 また 高度なデータベースクリーナー
3. クリーンな投稿リビジョン, 自動ドラフト, ゴミ箱に捨てられた投稿
4. スパムとゴミ箱コメントをクリーンアップ
5. 期限切れのトランジェントをクリーンアップ
6. データベーステーブルの最適化 (これによりデータが再編成され、より高速にアクセスできるようになります)

特に wp_options の場合, 自動ロード列を確認してください. autoload=’yes のオプション’ すべてのページにロードされる. 次のようなプラグインを使用します クエリモニター 「いいえ」に設定する必要がある大量の自動負荷データを識別するため.

最適化 7: プラグインの肥大化を軽減する

予想される影響: 5-25% 削除するプラグインに応じて

すべてのプラグインにより PHP の実行時間が増加します. 平 “軽量” プラグインはデータベースクエリを作成し、ファイルをロードします. と 30+ アクティブなプラグイン, 累積的なオーバーヘッドが大きくなる.

TTFB は特に次のようなプラグインの影響を受けます。:

• ページが読み込まれるたびに実行されます (分析, セキュリティスキャナー)
• 外部 API 呼び出しを行う (ソーシャルフィード, 株式ティッカー)
• データベースに大量のクエリを実行する (いくつかのページビルダー, 関連記事プラグイン)
• 大規模なライブラリをロードする (フォントアイコンパック, アニメーションフレームワーク)

遅いプラグインの特定

1. インストール クエリモニター プラグイン
2. サイト上の任意のページをロードします
3. [クエリ モニター] パネルを確認してください。 コンポーネント別のクエリ と PHP 時間
4. どのプラグインが最も多くのクエリを生成するか、または最も長い時間がかかるかに注目してください。

ホームページといくつかの主要なページでこのチェックを実行します. 結果から、データベース負荷の大部分を担っている 1 つまたは 2 つのプラグインが判明することがよくあります。.

アクションステップ

• 積極的に使用していないプラグインを無効化する
• 重いプラグインを軽量の代替プラグインに置き換える (例えば, 個別の単一目的プラグインを備えた Jetpack)
• 画像の最適化などのタスクについてサーバー側の代替手段を検討する (アップロード中に処理される vs. あらゆるリクエスト)
• クエリ モニターを使用して、過剰なデータベース クエリを行うプラグインを特定する

共有ホスティングでは不十分な場合

これが正直な真実です: 最適化だけでは不十分な場合もあります. 共有ホスティングには固有の制限があります:

• 騒々しい隣人: サーバー上の他のアカウントがリソースを消費します, パフォーマンスに影響を与える
• リソースの上限: CPU, メモリー, I/O制限により、サイトで実行できることが制限されます
• サーバーレベルの制御なし: Webサーバーの構成を調整することはできません, カスタム ソフトウェアをインストールする, またはMySQLを調整する

上記の最適化をすべて実装しても、TTFB が一貫して 500 ミリ秒を超える場合, これらのアップグレードを検討してください:

オプション 1: プレミアム共有ホスティング

一部の共有ホスティング層には専用リソースが含まれています, LiteSpeed, レディス, およびNVMeストレージ. これらは “仕事” また “ターボ” プランは、基本的な共有と VPS の間の中間点を占めます。. そちらのほうが費用がかかります (10～25ドル/月) ただし、多くの場合、300ms 未満の TTFB を配信します.

オプション 2: マネージドWordPressホスティング

Kinstaのようなプロバイダー, WPエンジン, Cloudways は WordPress に特化して最適化します. キャッシュを処理します, CDN統合, サーバーのチューニングも自動的に行われます. ほとんどの地域で TTFB が 200 ミリ秒未満になることが予想されます, ただし月額 25 ～ 50 米ドル以上.

オプション 3: VPS (仮想プライベートサーバー)

A VPS 専用のリソースと完全なサーバー制御を提供します. LiteSpeedをインストールできます, OPcacheを完全に構成する, そしてMySQLを調整する. でも, あなたはサーバー管理の責任者です. メンテナンスの負担をかけずに制御したい場合には、マネージド VPS オプションが用意されています.

クラウドベースの代替手段の詳細については、, ご覧ください クラウドホスティングの比較.

よくある質問

TTFB は共有ホスティングで何を目指すべきですか?

最適化による共有ホスティングの目標は 400 ミリ秒未満. LiteSpeed と適切なキャッシュにより 300 ミリ秒未満を達成可能. 最適化後に 600 ミリ秒を超える場合, ホストがリソースを過剰に販売しているか、古いインフラストラクチャを実行している可能性があります. プレミアム共有ホストとマネージド WordPress ホスティングは通常 200 ミリ秒未満で配信されます.

TTFB は Google のランキングに直接影響しますか?

TTFB は Google の Core Web Vitals における直接のランキング要素ではありません (これにはLCPが含まれます, インド, とCLS). でも, TTFB は LCP に直接影響します, これがランキング要素です. サーバーの応答が遅い場合, コンテンツがどれほど最適化されているかに関係なく、LCP スコアは低下します. Google のドキュメントでは、LCP パフォーマンスを最適化するために TTFB を 200 ミリ秒未満に保つことを推奨しています.

キャッシュ プラグインは Apache 上の TTFB を修正できますか?

キャッシュプラグインは役立ちますが、LiteSpeed レベルのパフォーマンスには匹敵しません. 最高のキャッシュプラグインであっても (WPスーパーキャッシュ, W3トータルキャッシュ, WPロケット) 引き続き PHP を介して処理します. アパッチ上, 良好なキャッシュを使用すると 300 ～ 500 ミリ秒の TTFB が予想されます. ネイティブ LSCache を使用した LiteSpeed 上, 100～200ミリ秒かかると予想されます. アーキテクチャの違いが重要.

TTFBを改善するにはプラグインを無効にする必要がありますか?

必須のプラグインを無効にしないでください. その代わり, Query Monitor を使用して重いものを特定し、より軽い代替手段を探す. すべてのリクエストで実行されるセキュリティ プラグインは、1 ページでのみ実行される問い合わせフォーム プラグインよりも多くの TTFB オーバーヘッドを追加します。. サイト全体で実行し、データベース クエリを実行するプラグインに焦点を当てる.

特定の時間帯に TTFB が悪化するのはなぜですか?

共有ホスティングのパフォーマンスはサーバーの負荷によって異なります. 隣接するアカウントがトラフィックの急増を受信した場合, リソースが制限される. 営業時間中または特定の時間帯に一貫して速度が低下していることに気付いた場合, サーバーが売れすぎている可能性があります. これはホストレベルの問題であり、最適化では完全には解決できません.

すべてを実行しましたが、TTFB はまだ遅いです. 今、何?

キャッシュを実装している場合, アップグレードされたPHP, データベースをクリーンアップしました, TTFB は依然として 600ms を超えています, 問題はほぼ間違いなくホストのインフラストラクチャです. 移行する前に, 1つのテストを試してみる: デフォルトのテーマを使用し、プラグインを含まない空の WordPress インストールを作成します。. TTFBを測定する. 新規インストールでも遅い場合, サーバーがボトルネックであることを確認しました. ホストを切り替えるか、VPS にアップグレードする時期が来ました.

最終的な推奨事項

共有ホスティングで TTFB を改善するには、多層的なアプローチが必要です. 単一の最適化ですべてを解決することはできません. 最小限の労力で最大の効果をもたらす変更から始めます:

1. ホストが LiteSpeed を使用しているかどうかを確認する. そうでない場合, 移行を検討する. 多くの場合、この 1 つの変更により、他のすべての最適化を組み合わせた場合よりも優れた結果が得られます。.
2. Cloudflareの無料CDNを有効にする. フルページキャッシュがなくても, ネットワーク遅延の短縮により、サーバーから遠く離れた訪問者を支援します.
3. PHP にアップグレードする 8.2+. クイックチェンジ, 無料でパフォーマンスを向上.
4. OPcache が有効であり、適切に構成されていることを確認します. メモリ割り当てが少なすぎる場合はホストに問い合わせてください.
5. 利用可能な場合は Redis オブジェクト キャッシュを有効にする. 動的ページで最も役立ちます.
6. データベースをクリーンアップしてプラグインを監査する. 時間の経過とともに悪化する継続的なメンテナンス.

これらの変更を実装した後, 前述の方法を使用して TTFB を再テストします。. 適切に構成されたサイトでもまだ 500 ミリ秒を超えている場合, 制限はホスティング インフラストラクチャです. その時点で, にアップグレードする VPSホスティング また クラウドホスティング 応答時間を短縮する唯一の道かもしれない.

具体的なホスティングに関する推奨事項を探しています? 私たちの 共有ホスティングの比較 LiteSpeed と最適化されたインフラストラクチャを備えたプロバイダーをカバーします. WordPress 固有のオプションの場合, ご覧ください マネージド WordPress ホスティング ガイド.