ホスティングとパフォーマンス
WordPress を高速化する方法: LiteSpeed Enterprise、LSCache、およびサイトごとの Redis
最も高速な WordPress リクエストとは、実行すらされないリクエストです。PHP や MySQL が呼び出される前に、当社のスタックがキャッシュから大部分のアクセスにどのように応答するか、そしてそれが Core Web Vitals に何を意味するのかをご紹介します。
最も高速なリクエストは、一度も実行されないリクエストです
標準的な WordPress のリクエストは負荷がかかります。Web サーバーが PHP に処理を渡し、PHP が WordPress を起動してプラグインを実行し、MySQL に数十回クエリを投げ、HTML を組み立てて、ようやくバイトデータを返送します。アクセスの多いサイトではこの一連の動作が訪問者ごとに発生するため、Time to First Byte (TTFB) のほぼすべてがここで費やされることになります。
弊社の答えは、ほとんどのアクセスにおいて、それが一切発生しないようにすることです。弊社がホスティングしているサイト (10万以上の PBN サイトに加え、主流のマネージド WordPress) 全体で、フロントエンドのページビューの大部分は、PHP を呼び出したりデータベースにアクセスしたりすることなく、事前にレンダリングされた完全なページとしてキャッシュから直接配信されます。本記事の続きでは、これを実現する各レイヤーがどのように連携し、それぞれがどこで価値を発揮しているのかについて説明します。
重要な視点は、これらが二者択一で選ぶ競合関係のキャッシュではないということです。フルページキャッシュ、オブジェクトキャッシュ、そして CDN エッジは、それぞれ異なる種類のクエリを処理し、その真価はそれらがいかに連携して引き継ぎ合うかにあります。
LiteSpeed Enterprise + LSCache: フルページ層
すべてのサイトは、サーバーレベルの LSCache を備えた LiteSpeed Enterprise 上で動作します。フロントエンドのレスポンスがキャッシュ可能な場合、ウェブサーバーは LiteSpeed のキャッシュ制御およびタグヘッダーを付与し、次回のアクセス時には LiteSpeed が完全なページを直接配信します。PHP プロセスの生成も MySQL クエリの発行も行われません。これによりアプリケーション全体の起動処理がホットパスから排除されるため、WordPress の TTFB を短縮する最大の決定要因となります。
LSCache は PHP プラグインではなく Web サーバーの内部で動作するため、リクエストのライフサイクルのより早い段階で機能し始め、サーバーが即座にフラッシュできる形式でページを保持します。キャッシュクローラーが人気のあるページを常にウォーム状態に保つため、パージ後の最初の訪問者がページの再生成による遅延の影響を受けることはありません。その結果、キャッシュが 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 に対して実行されることはありません。その効果は、フルページキャッシュでは対応できない領域で最も顕著に現れます。ダッシュボードの高速化、カートの処理速度向上、そしてトラフィック急増時におけるデータベース負荷の大幅な軽減を実現します。
オブジェクトキャッシュは共有型ではなくサイトごとに独立しており、パフォーマンスと分離性の両方の面で重要となります。サイトごとのデータベース帯域制御と組み合わせることで、特定のサイトによる高負荷なクエリや粗雑なクエリが隣接サイトのデータベースリソースを枯渇させることを防ぎます。多層構造の全体的な連携の仕組みについてはキャッシング機能のページを、テナント間の境界の詳細については分離性に関する項目をご覧ください。
エッジとその下のトランスポート
オリジン上に存在するキャッシュは、依然としてネットワークを経由する必要があります。サーバーの前段には CDN エッジが配置されているため、静的アセットやキャッシュ可能なページは訪問者の近くにある拠点で配信され、高負荷時でもオリジンは平穏を維持できます。当社のフットプリントフリー・ホスティング製品群では、同一のエッジが複数のプロバイダーにまたがるマルチ CDN プールとなっており、パフォーマンスだけでなくフットプリント対策の目的も果たします。一般的な 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、フォントや広告の読み込み時にずれるレイアウト、プラグインによるメインスレッドへの過度な負荷などがその要因です。どれほどサーバーキャッシュを利用しても、2MB のヒーロー画像やメガバイト単位の JavaScript を配信するテーマを解決することはできません。誠実なホスティングはサーバー側の影響を事実上ゼロにして一貫性を保ちますが、フロントエンドを軽量に保つことはサイト側の責任です。
その役割分担こそが有用な思考モデルです。リクエストがブラウザに迅速に到達し、トラフィック下でも高速であり続けることを私どもが保証し、お客様にはペイロードを小さく安定した状態に保っていただきます。両者が交わる領域、すなわちキャッシュのウォームアップ、エッジ配信、そして動的ページを停滞させないためのデータベースの応答性維持こそが、私どものスタックが緻密に調整されている部分であり、汎用ホスト上の同じサイトよりもこのプラットフォーム上のマネージド WordPress を高速にする理由です。
よくある質問
WP Rocket のようなキャッシュプラグインはまだ必要ですか ?
いいえ。ページ全体のキャッシュはウェブサーバー上で LiteSpeed の LSCache によって処理され、あらかじめインストールされ自動更新される当社独自のキャッシュプラグインが WordPress を適切に連携させ、その背後でサイトごとの Redis オブジェクトキャッシュが機能します。その上にもう1つページ全体キャッシュプラグインを重ねても、効果をもたらすどころかサーバーレベルのキャッシュと競合するのが通常であるため、不要であり推奨されません。
キャッシュによって、WooCommerce のカートやログイン済みページが破損することはありますか ?
いいえ。カート、チェックアウト、my-account、および nonce やセッションのページはデフォルトでキャッシュから除外されており、ESI によって、他の点ではキャッシュされているページ上でもカートのフラグメントと合計がリアルタイムに維持されます。ストアフロントがキャッシュから読み込まれている間も、買い物客には常に自身の買い物かごと機能するチェックアウトが表示されます。
公開や編集を行った場合、キャッシュはどのように最新の状態に保たれますか ?
スマート自動パージは関連する WordPress フックで起動するため、コンテンツの公開や編集、または商品、価格、注文の変更を行っても、キャッシュ全体ではなく、影響を受けるページとそのアーカイブのみがクリアされ、クローラーがそれらを再び準備します。ダッシュボードまたは WordPress 内からオンデマンドでパージを実行することもできます。
ホスティングだけで完璧な Core Web Vitals を達成できますか ?
これにより可能な限り最高の TTFB が提供され、これはサーバーの役割を果たすとともに Largest Contentful Paint の有利なスタートとなります。しかし、LCP、CLS、INP は、画像のサイズ、レンダリングをブロックするアセット、レイアウトの安定性、メインスレッドの JavaScript など、ページ自体によって大部分が決まります。私たちのスタックはサーバーの処理を迅速かつ安定したものにします。残りの差を埋めるには、フロントエンドのペイロードを軽量に保つことが不可欠です。