ブロックテーマ時代に適したWordPress向けサーバーとは

WordPress用のマネージドサーバーは、WordPressを快適に動作させるために設計されています。負荷がかかった際の挙動やキャッシュの処理方法、PHPの実行方式に最適化された環境を提供するのが特徴です。

ブロックテーマを使うことで、サーバーの根本的な仕組みが変わることはありませんが、パフォーマンスのボトルネックが生じる箇所が変わります。ここでサーバーの役割がより明確になり、単にインフラを整えるだけでは、サイトを高速化することはできません。特に、動的ブロックやサイトエディター、プレビュー、ログインセッションなどが関わる最新のWordPressワークフローでは、適切に最適化されていないインフラの問題が顕在化しやすくなります。

この点を理解するには、ページリクエスト時に実際に何が起きているのか、そしてブロックベースのアーキテクチャを採用した場合に、サーバーの選択がユーザー体験にどのような影響を与えるのかに注目することが重要です。

WordPressページのリクエスト処理の流れ

まずは、200 OKレスポンスが返される単純なリクエストの流れを見てみます。

1. ブラウザがリクエストを送信

まずはユーザーがURLを入力するか、リンクをクリックします。サーバーのIPアドレスがキャッシュされていない場合、ブラウザはDNSルックアップを実行し、その後TCP接続を確立、さらに安全なTLSセッションを開始します。

WordPressが関与する前に、リクエストはウェブサーバーやファイアウォール、リバースプロキシなどの各レイヤーを通過します。

2. キャッシュの確認

サーバーがリクエストされたページの有効なキャッシュが存在するかを確認します。

フルページのHTMLキャッシュが有効な場合、WordPressは実行されず、キャッシュされたレスポンスが即座に返されます。

一方、キャッシュが存在しない場合や、ログインユーザー、プレビュー、特定エンドポイントなどでキャッシュがバイパスされる場合は、リクエストはWordPressへと渡されます。

3. WordPressの起動

WordPressがコアファイル、有効なプラグイン、テーマを読み込み、フックを初期化してリクエスト処理の準備を行います。

この段階ではまだ出力は行われず、どのコンテンツが要求されているかを判別します。

4. メインクエリの解決

リライトルールとクエリ変数をもとに、WordPressがメインのデータベースクエリを構築・実行します。

これにより、リクエストが投稿、固定ページ、アーカイブ、検索結果など、どのコンテンツに対応するものかが決定されます。この処理が完了して初めて、テンプレートの選択に進みます。

5. テンプレートの解決

ここで、ブロックテーマとクラシックテーマの構造的な違いが現れます。

クラシックテーマ

テンプレート階層に基づいて、single.php、page.php、archive.phpなどのPHPテンプレートが選択されます。これらはPHPロジックを通じて直接HTMLを出力します。

ブロックテーマ

まずデータベース内のカスタムテンプレートを確認し、存在すればそれを使用します。存在しない場合は、テーマ内のsingle.htmlやindex.htmlなどにフォールバックします。

選択されたテンプレートは、ブロックレンダリングシステムを通じて処理されます。

6. レイアウトの組み立て

クラシックテーマ

PHPテンプレートを通じて、マークアップ、ロジック、関数呼び出しを組み合わせてHTMLを生成します。

ブロックテーマ

ブロックテンプレート、テンプレートパーツ、投稿コンテンツをもとにレイアウトが構築されます。ブロックマークアップが解析され、各ブロックがHTMLとしてレンダリングされます。

7. コンテンツ構造

クラシックテーマ

投稿コンテンツは主にHTMLとして保存され、出力時にフィルターやショートコードなどが適用されます。

ブロックテーマ

コンテンツは以下のようなブロックメタデータを含むHTMLとして保存されます。

<!-- wp:image {"id":123} -->

<img src="logo.png">

<!-- /wp:image -->

WordPressはこのコンテンツを処理する際、ブロック構造を解析し、属性やネスト関係を理解した上で、余白、配置、タイポグラフィなどのブロック単位の属性やスタイルを適用し、最終的なHTMLを生成します。

8. 動的レンダリング

動的レンダリングは両テーマで利用されます。クラシックテーマでは、カスタムクエリやウィジェット、ショートコードによって実行時に出力が生成されます。

ブロックベースのアーキテクチャでは、動的な処理は動的ブロックとして体系化されています。たとえば、クエリループブロックは、データベースに静的なHTMLを保存するのではなく、リクエスト時にPHPを使ってマークアップを生成します。

フルページキャッシュが無効な場合、この処理はリクエストごとに実行されます。

9. スタイリング

クラシックテーマの場合、主にテーマが提供する静的なCSSファイルによってスタイルが適用されます。

ブロックテーマでは、theme.jsonやブロックのメタデータで定義されたグローバルスタイルにより、WordPressが一貫したCSSを自動生成できます。これにより、大規模な手作業のスタイルシートの必要性が減り、デザイン設定を一元化できます。

10. 最終出力

すべての処理が完了すると、WordPressは最終的なHTMLレスポンスを生成します。

サーバーはこのレスポンスをブラウザに送信し、設定に応じてキャッシュされる場合もあります。

ブロックテーマが負荷を分散させる箇所

先ほど説明したリクエストのライフサイクルは、クラシックテーマとブロックテーマの両方に共通しています。WordPressは引き続き、クエリの解決、テンプレートの選択、PHPの実行、HTMLの返却といった処理を行います。

ブロックテーマの使用で変化するのは、基盤そのものではなく、「どこで処理が行われるか」と「どの処理をスキップできないか」という点です。

まず、テンプレートはデータベースに保存できるようになりました。サイトエディタでテンプレートを編集すると、その内容がデータベースに保存され、テーマディレクトリ内のファイルよりも優先されます。これにより柔軟性は高まりますが、同時にデプロイやキャッシュ無効化の際には、データベース内のテンプレートも考慮する必要があります。

次に、動的ブロックによって実行時レンダリングがより明示的になりました。従来のテーマでも、カスタムクエリやウィジェット、ショートコードを通じて動的な出力は可能でしたが、ブロックテーマではクエリループブロックなどを通じてこの仕組みが体系化されています。フルページキャッシュがバイパスされる場合、これらのブロックはリクエストごとにPHPを実行します。

さらに、エディターのワークフローはREST APIに大きく依存しています。テンプレートの保存、グローバルスタイルの更新、プレビュー、パターンの操作などは、いずれもキャッシュされないリクエストを発生させます。これらの処理は、PHPの実行性能、データベースの応答速度、そしてオブジェクトキャッシュに直接影響を受けます。

また、theme.jsonによるグローバルスタイルの導入により、デザイン設定は一元化されました。その一方で、スタイルやテンプレート構造が変更された際に、訪問者や編集者が最新の状態を即座に確認できるようにするには、キャッシュ制御の重要性がこれまで以上に高まります。

これらの変化は、新たな種類のサーバーを必要とするものではありませんが、特にキャッシュが効かないリクエストやログイン状態での操作では、インフラの性能や最適化の違いが、これまで以上に明確に表れるようになります。

この点を踏まえると、次に考えるべきなのは、ブロックテーマを使用したWordPressサイトでは、適切に最適化されたサーバー環境がどのような処理を担うべきかという点です。

ブロックテーマを使用する場合のサーバーの考慮事項

ブロックテーマによって、新たなサーバー要件が生まれるわけではなく、既存の要件を正しく満たすことの重要性が高まります。

適切に構成された環境では、特に編集者やログインユーザーに対して、キャッシュされたパスとキャッシュされていないパスの両方を考慮する必要があります。

レイヤー間で連携するキャッシュ

フルページキャッシュは、匿名トラフィックに対して依然として最も効果的なパフォーマンス層です。公開ページは積極的にキャッシュすべきですが、プレビュー、ログイン中のセッション、特定のエンドポイントなどは、自動的にキャッシュをバイパスする必要があります。

オブジェクトキャッシュも重要な役割を果たします。繰り返し実行されるクエリの結果や計算済みのデータ構造をメモリに保持することで、データベースへの負荷を軽減し、フロントエンドとバックエンドの両方の応答性を向上させます。

キャッシュの無効化は、各レイヤー間で連携して行う必要があります。コンテンツ、テンプレート、またはグローバルスタイルが更新された場合、関連するページは速やかに更新されるべきです。連携が不十分な場合、古いレイアウトの表示やスタイルの不整合、混乱を招くプレビュー挙動が発生する可能性があります。

CDNは、画像、フォント、スクリプトなどの静的アセットをユーザーに近い場所で配信・キャッシュすることで、この構成を補完します。

キャッシュは単一のレイヤーで完結するものではありません。重要なのは、これらのレイヤーがどのように連携して機能するかです。

PHPの処理能力と実行時パフォーマンス

フルページキャッシュがバイパスされると、WordPressはクエリの解決、テンプレートのレンダリング、動的ブロックの処理のためにPHPを実行します。

そのため、PHPの処理能力（キャパシティプランニング）が重要になります。環境は、キューの滞留を発生させることなく、想定される同時接続数を処理できる十分なPHPスレッドを備えている必要があります。また、負荷時にスワップが発生しないよう、適切なメモリ制限を設定することも重要です。

さらに、PHPバイトコードの再コンパイルを防ぐために、OPcacheを有効化し、適切なサイズに調整する必要があります。デプロイ時には、更新されたコードが確実に反映されるよう、OPcacheのリフレッシュも欠かせません。

これらの対策はすべてのWordPressサイトに共通して重要ですが、レンダリングが動的になるほど、特にブロックベースのワークフローではパフォーマンスへの影響がより顕著になります。

データベースとオブジェクトキャッシュ

サイトエディターでカスタマイズされたブロックテンプレートは、データベースに保存されます。また、ブロックコンテンツには構造化されたメタデータが含まれており、WordPressは出力前にこれを解析します。この処理自体は効率的に設計されていますが、キャッシュがバイパスされる場合、パフォーマンスは依然としてデータベースの応答速度に大きく依存します。

永続的なオブジェクトキャッシュは、繰り返し実行されるクエリの結果を保持することで、データベースへのアクセスを削減します。これにより、フロントエンドの訪問者だけでなく、ダッシュボードで作業する編集者にとっても、パフォーマンスの安定性が向上します。

可観測性と監視

アクティビティがランタイムパスへと移行するにつれて、可視性の重要性はさらに高まります。サーバーおよびサイト所有者は、少なくとも以下の指標を継続的に監視する必要があります。

• キャッシュヒット率

• PHPスレッドの利用率とキューの長さ

• データベースクエリのパフォーマンス

• REST APIの応答時間

• キャッシュあり／なしそれぞれのTime to First Byte（TTFB）

ブロックテーマ自体が特別なインフラストラクチャを要求するわけではありません。しかし、インフラの設定や最適化が不十分な場合、その問題はこれまで以上に明確に表れるようになります。

現代のWordPressが求めるインフラとは

テンプレートがデータベースに保存され、動的ブロックが実行時にレンダリングされ、編集者がキャッシュされないRESTリクエストに依存する現在のワークフローでは、インフラストラクチャはもはや「見えない存在」ではありません。ワークフローをスムーズに支えるか、ボトルネックとなるかのどちらかです。

こうした背景において真価を発揮するのが、WordPress専用のマネージドサーバーです。

Kinstaでは、キャッシュ構成や永続的オブジェクトキャッシュ、PHPのパフォーマンス最適化、そしてクラウドインフラ上でのグローバルCDN配信まで、スタック全体を現代のWordPressの動作に合わせて最適化しています。その目的は、動的なレンダリングが発生する場合でも、訪問者と編集者の双方に一貫したパフォーマンスを提供することです。

WordPressが特別に重くなったわけではなく、可視性が高まっただけといえます。そして、基盤が適切に整備されていれば、その可視性は大きな強みになります。