ホスティングとパフォーマンス
WordPressを高速化する仕組み：LiteSpeed Enterprise、LSCache、サイトごとのRedis
WordPressにおいて最も高速なリクエストとは、実行されないリクエストのことです。ここでは、PHPやMySQLが呼び出される前に、弊社のスタックがどのようにキャッシュから大部分のアクセスに応答しているのか、そしてそれがCore Web Vitalsにとって何を意味するのかについて解説します。
実行されないリクエストが最も速いリクエストです
WordPressの標準的なリクエストには大きなコストがかかります。ウェブサーバーが処理をPHPに引き渡し、PHPがWordPressを起動し、プラグインを実行し、MySQLに対して何度もクエリを投げ、HTMLを組み立てて、ようやくバイトデータを返送します。アクセスが集中するサイトでは、この一連の処理が訪問者ごとに発生し、ほぼすべてのTime to First Byte（TTFB）の原因となります。
私たちが導き出した答えは、ほとんどの訪問において、そうした処理を一切行わないようにすることです。弊社がホストしている10万以上のPBNサイトと主流のマネージド WordPress サイト全体において、フロントエンドのページビューの大半は、PHPの呼び出しやデータベースへのアクセスなしに、キャッシュから直接事前レンダリングされたフルページとして配信されます。この投稿の残りの部分では、それを可能にしている各レイヤーがどのように連携し、それぞれがどのようにその役割を果たしているのかについて説明します。
重要なポイントは、これらが二者択一の競合するキャッシュではないということです。フルページキャッシュ、オブジェクトキャッシュ、CDNエッジはそれぞれ異なるクラスのリクエストを処理し、その真価はそれらがどのように連携（ハンドオフ）するかを発揮する点にあります。
LiteSpeed Enterprise + LSCache: フルページレイヤー
すべてのサイトは、サーバーレベルの LSCache を備えた LiteSpeed Enterprise で稼働しています。フロントエンドの応答がキャッシュ可能な場合、Web サーバーはそれに LiteSpeed の cache-control および tag ヘッダーを付与し、次のヒット時には LiteSpeed が完全なページを直接配信します。PHP プロセスは起動されず、MySQL クエリも発行されません。これは、ホットパスからアプリケーションの起動プロセス全体を排除するため、WordPress の TTFB において最も大きな効果をもたらす要素です。
LSCacheはPHPプラグインではなくウェブサーバー内部で動作するため、リクエストライフサイクルのより早い段階で処理を開始し、サーバーが即座に出力できる形式でページを保持します。キャッシュクローラーが人気ページを常にウォームアップ状態に保つため、パージ後に最初に訪れたユーザーがページの再生成コストを負担することはありません。その結果、キャッシュが依然としてPHPの後方に位置する一般的なスタックに追加されたプラグインだけのキャッシュと比較して、著しく低く、より一貫したTTFBを実現します。
当社のリポジトリグレードのキャッシュプラグインはすべてのサイトにプレインストールされ、自動更新されるため、WordPressがLSCacheにすぐに正しく接続されます。LiteSpeed以外のオリジンではフルページヘッダーを出力せずに干渉しない一方で、オブジェクトキャッシュと除外ルールは機能し続けるため、移行したサイトが設定途中の壊れた状態になることはありません。
サイトの速度を落とさず古いコンテンツを配信しない：ESIとスマート自動パージ
積極的なフルページキャッシュには、ログイン中のユーザーに他人のページを表示してしまうことと、本来変更されるべきページを誰にでも表示してしまうことという、2つの典型的な障害モードがあります。どちらも、キャッシュを減らすのではなく、キャッシュレイヤーで解決されます。
ESI (Edge Side Includes) を使用すると、リアルタイム性を維持する必要がある部分に穴を開けながら、ページをキャッシュすることができます。WooCommerce ストアでは、カタログ、商品、カテゴリの各ページがフルページキャッシュとして配信され、可能な限り最速の TTFB を実現する一方、ESI はリクエストごとにカートの断片、ミニカートの合計、アカウントの状態をレンダリングします。カート、チェックアウト、マイアカウント、および nonce やセッション関連のページはデフォルトで除外されます。購入者は常に自分の買い物かごや機能するチェックアウトを確認できる一方で、すべてのユーザーがストアフロントをキャッシュから取得できます。
フレッシュネスはスマート自動パージによって管理されます。コンテンツ、商品、価格、または注文が変更されるとパージフックが自動的に実行されるため、タイマーではなく関連するキャッシュページが即座に更新されます。また、ダッシュボードやWordPress内からオンデマンドでパージすることも可能です。タグベースのパージにより、1つの投稿を編集するとサイト全体ではなくその投稿と関連アーカイブのみがクリアされるため、1回の編集でサイト全体がコールドスタートすることはありません。
サイトごとのRedisオブジェクトキャッシュ：フルページにできないコンテンツ向け
すべてのリクエストが静的なフルページになるわけではありません。ログイン中のセッション、WordPress の管理画面、WooCommerce のカート、検索、そして ESI が残す動的なフラグメントはすべて PHP を実行する必要があります。そのため、目標は「アプリケーションのスキップ」から「データベースのスキップ」へと移行します。
各サイトに専用のRedisオブジェクトキャッシュが割り当てられます。WordPressは、オプション、トランジェント、投稿やタームの検索、WooCommerceの商品やセッションデータなど、繰り返し行われるデータベース読み取りの結果をメモリ内にキャッシュするため、アクセスごとに同じクエリがMySQLに対して実行されません。この効果は、フルページキャッシュが機能しない場面で最も顕著に現れます。管理画面の高速化、カートの高速化、そしてトラフィック急増時のデータベース負荷の大幅な軽減を実現します。
オブジェクトキャッシュは共有されずサイト単位となるため、パフォーマンスと分離性の両方の面で重要です。サイトごとのデータベーススロットリングと組み合わせることで、1つのサイトにおける負荷の高いクエリや不適切に記述されたクエリが、近隣のサイトに対してデータベースを枯渇させることはありません。多層構成全体の仕組みについてはキャッシュ機能ページで、テナント間の境界については分離の解説で詳しくご覧いただけます。
エッジとその下のトランスポート
オリジン上にあるキャッシュも、依然としてネットワークを経由する必要があります。サーバーの手前にはCDNエッジが配置されているため、静的アセットやキャッシュ可能なページは訪問者の近くにあるPoP（POP）から配信され、負荷がかかっている時でもオリジンサーバーは静かに保たれます。当社のフットプリントフリーホスティングラインでは、同じエッジが複数のプロバイダーに分散されたマルチCDNプールになっており、パフォーマンスだけでなくSEOの目的も果たします。メインストリームのWordPressにおいては、それは単にオリジンをアイドル状態に保つ、高速で優れたレイヤーです。
その下で、基本性能も妥協していません。サイトはHTTP/3対応のNVMeストレージ上で稼働するため、キャッシュから送信されるデータは、キャッシュミス時にも高速なストレージを背景に、モダンで多重化されたトランスポート経由で到着します。これらのレイヤーはいずれも追加オプションではなく、LiteSpeed、LSCache、サイトごとのRedis、NVMe、HTTP/3はすべてのプランで標準装備されており、アップセル用の階層ではありません。
Core Web Vitalsを実際に動かす要因は何ですか
正確性を期す価値があります。なぜなら、ホスティングはCore Web Vitalsに関してしばしば過剰に宣伝されるからです。TTFBはサーバーが担う部分であり、その上位にあるキャッシュスタックがそれを最小限に抑える要因となります。HTTP/3を使用してエッジから配信されるキャッシュ済みのフルページは、TTFBとしてほぼ最小限の数値になります。TTFBはLargest Contentful Paintの最前線であるため、高速なオリジンは、他の方法では得られない有利なスタートをすべてのダウンストリーム指標にもたらします。
しかし、LCP、CLS、INPの大部分は、最適化されていないヒーロー画像、レンダリングをブロックするCSSやJavaScript、フォントや広告の読み込みに伴うレイアウトのズレ、そしてプラグインによるメインスレッドの重い処理など、ブラウザ側、つまりページ自身によって決まります。どれほどサーバーキャッシュを活用しても、2 MBのヒーロー画像や、何メガバイトものJavaScriptを読み込むテーマを修正することはできません。誠実なホスティングはサーバー側の負荷を実質的にゼロにして安定させ、その上で、サイト側がフロントエンドを軽量に保つことが求められます。
労働の分業という考え方は、役に立つメンタルモデルです。私たちはリクエストがブラウザに高速で届くこと、そしてトラフィックが増えてもその速さを維持することを保証します。お客様はペイロードを小さく安定させてください。キャッシュのウォームアップ、エッジ配信、そして動的ページが滞らないようにデータベースの応答性を維持することなど、その両者が交わる場所こそが、私たちのスタックがチューニングされている領域であり、このプラットフォームでのマネージド WordPress が一般的なホスト上の同じサイトよりも高速である理由です。
よくある質問
WP Rocketのようなキャッシュプラグインはまだ必要ですか？
いいえ。フルページキャッシュはWebサーバー上の LiteSpeed の LSCache と、プリインストールおよび自動アップデートされる独自のキャッシュプラグインによって適切に WordPress に接続され、その背後にはサイトごとの Redis オブジェクトキャッシュが備わっています。2つ目のフルページキャッシュプラグインを重ねて使用すると、サーバーレベルのキャッシュの助けになるどころか競合することが多いため、不要であり、推奨もされません。
キャッシュによってWooCommerceのカートやログイン中のページが壊れることはありますか？
カート、チェックアウト、マイアカウント、およびnonceやセッション関連のページはデフォルトでキャッシュから除外され、ESI（Edge Side Includes）により、キャッシュされたページ内でもカートの断片や合計金額が常に最新の状態に保たれます。これにより、ストアフロントの読み込みをキャッシュから行いながら、購入者は常に自分の買い物かごや機能するチェックアウト画面を確認できます。
公開や編集を行った際、キャッシュはどのように最新の状態に保たれますか？
スマート自動パージは関連するWordPressフックで動作するため、コンテンツの公開・編集、または商品、価格、注文の変更を行うと、キャッシュ全体ではなく、影響を受けるページとそのアーカイブのみがクリアされ、クローラーによって再度ウォームアップされます。また、ダッシュボードやWordPress内からオンデマンドでパージすることも可能です。
ホスティングだけで完璧な Core Web Vitals を実現できますか？
サーバーの応答速度であるTTFBを最大限に高め、Largest Contentful Paintの素早い立ち上がりを実現します。しかし、LCP、CLS、INPの大部分は、画像サイズ、レンダリングブロックアセット、レイアウトの安定性、メインスレッドのJavaScriptなど、ページ自体によって決まります。当社のスタックによりサーバー側の処理は高速かつ一貫したものになりますが、残りの課題をクリアするにはフロントエンドのペイロードを軽量に保つことが鍵となります。