WordPress ホスティング ＆ プラグイン
WordPressを高速かつセキュアにする：パフォーマンスとプラグインのチェックリスト
WordPressの速度と安全性は、そこで稼働するもの次第です。ここでは、弊社がホストするすべてのWordPressサイトに適用している実践的なチェックリストをご紹介します。何をキャッシュし、何を保護し、どのプラグインがその存在価値を持ち、どれが不要になるのかをまとめています。
WordPressの性能は、それを動かす環境次第です
WordPressがWebの大部分を支えているのはその柔軟性ゆえですが、まさにその柔軟性こそが、サイトの動作を重くし、セキュリティを低下させる原因にもなります。デフォルトのインストールでは、1ページあたり何十回もデータベースにクエリを投げ、誰でも見られるようにバージョンやスタックの情報をブロードキャストし、パフォーマンスと攻撃対象領域がどちらも静かに膨れ上がるまでプラグインを追加するように仕向けます。これらの問題のどれ一つとしてWordPress自体の欠陥というよりは、何の助けにもならないインフラ上でそれを運用していることの結果なのです。
良いニュースとして、これらの問題の大半は、コンテンツではなくスタックに関する少数の決定を下すだけで解決できます。適切なレイヤーでの積極的なキャッシュ、ホットパスからのデータベースの排除、真に価値のある少数のプラグインの実行、すべてのパッチの適用、そして問題が局所化されるようなサイトの分離です。この記事は、プラットフォーム上のすべての WordPress サイトに適用している順序で、そのチェックリストをまとめたものです。
プラグイン内だけでなく、サーバーでキャッシュする
WordPressの速度向上における最大の要因は、ほとんどのアクセスにおいてWordPress自体を稼働させないことです。標準的なリクエストでは、WordPressを起動し、プラグインを実行し、データベースにクエリを送信してから初めてデータが送信されますが、フルページキャッシュであれば、次のアクセス時には完成したページをウェブサーバーから直接配信するため、その起動プロセス全体をスキップできます。そのキャッシュの保存場所が重要となります。キャッシュプラグインはPHPの内部で動作するため、キャッシュが応答する前段階としてPHPが依然として起動する必要がありますが、サーバーレベルのキャッシュはリクエストのより早い段階で応答し、サーバーが即座にフラッシュできる形式でページを保持します。
私たちがホストするすべての WordPress サイトは、サーバーレベルの LSCache を備えた LiteSpeed Enterprise上で稼働しており、専用のキャッシュプラグインが初期状態で WordPress と正しく連携します。プレインストールされ自動更新されるため、設定や最新状態の維持の手間が1つ減ります。LiteSpeed 以外のオリジンサーバーでは、このプラグインは単にフルページヘッダーを出力せず、オブジェクトキャッシュが機能し続ける一方で干渉しないため、移行したサイトの設定が中途半端になることはありません。ご自身のチェックリストにおける実用的なルールは次のとおりです：サーバー側でのフルページキャッシュは1つにし、2つ目のキャッシュプラグインをその上に重ねないでください。競合してしまいます。
オブジェクトキャッシュとデータベース
すべてのリクエストを静的ページにすることはできません。ログインセッション、管理画面、検索、カート、およびパーソナライズされたフラグメントはすべてPHPを実行する必要があり、それらの場合、目標はアプリケーションのバイパスからデータベースのバイパスへとシフトします。サイトごとのオブジェクトキャッシュ（私たちの場合は Redis）は、繰り返し行われるデータベース読み取りの結果をメモリ内に保持するため、同じオプション、トランジェント、およびルックアップが、ヒットごとにデータベースに対してクエリされることはありません。この効果は、フルページキャッシュが機能しないまさにその場所、つまり、より高速な管理画面、より高速なカート、そしてトラフィック下における大幅なデータベース負荷の軽減として現れます。
重要なのは「サイトごとの分離」という点です。共有型のオブジェクトキャッシュでは、アクセスの多いサイトや不具合のあるサイトのせいで他のすべてのキャッシュデータが破棄され、隣接するサイトのデータベースがリソース不足に陥る可能性があります。一方、サイトごとに専用のキャッシュを用意し、サイト別のデータベース制限を組み合わせることで、影響範囲をそのサイト内に封じ込めることができます。チェックリストにおいては、ログインユーザーがいるサイトやECサイトでは、永続的オブジェクトキャッシュを必須項目として扱い、複数テナント間でキャッシュが共有されるようなホスティング環境には警戒してください。
導入する価値のあるプラグイン、そしてプラットフォームが代替するもの
追加するプラグインはすべて、リクエスト時に実行されるコードであり、いつか誰かが通り抜けるかもしれないドアです。そのため、正直な目標は、最も多くのことを行う最小限のプラグインにすることです。優れたホストは、プラグイン全体を不要にします。サーバーレベルのキャッシュ、マネージドオブジェクトキャッシュ、およびプラットフォームバックアップがあれば、キャッシュプラグイン、個別のオブジェクトキャッシュプラグイン、バックアッププラグインは必要ありません。それらの作業はWordPressの下層でより適切に行われ、その上で実行すると競合とオーバーヘッドが追加されるだけだからです。
実際に稼働させる価値が残るのは、真の機能を追加する少数のものだけです。つまり、サイトの機能に実際に必要なプラグインと、弊社のプラットフォームにおいては、すべてのサイトに構築・同梱されている2つのリポジトリグレードのプラグインです。当社のキャッシュプラグインはWordPressをサーバーキャッシュに接続し、スマートパージを処理するため、編集を行っても影響を受けるべきページのみがクリアされます。当社のフットプリントプラグインは、WordPressのデフォルトのインストールが発信する情報（バージョンとジェネレータータグ、ディスカバリーエンドポイント、XML-RPC、ピンバック、powered-byヘッダーなど）をすべてのデプロイ時に削除するため、プラグインやテーマのアップデートによってそれらが知らぬ間に復活させられることはありません。どちらもWordPress.orgのプラグインディレクトリの標準に準拠して構築されており、無料で、自動的にアップデートされます。
WordPressのセキュリティと最新状態の維持
WordPressの侵入のほとんどは巧妙なものではなく、古くからある手法によるものです。期限切れのコア、テーマ、またはプラグインに既知の公開された脆弱性が存在することが、サイトが攻撃を受ける圧倒的な原因です。そのため、常に最新の状態を維持することが最も価値のあるセキュリティ対策となりますが、同時に最も面倒な作業でもあるため、見過ごされがちです。マネージドホスティングは、この負担を解消するべきものです。WordPressの背後にあるスタックにパッチを適用し、テスト用のステージング環境とロールバック用のバックアップを提供することで、コアおよびプラグインのアップデートを安全に適用できるようにします。
通貨とは別に、境界線が自動的に保護されることも期待できます。マルウェアスキャンがデフォルトで有効になっているため、訪問者に発見される前に感染を検知できます。また、1つのサイトが侵害されても他のサイトに影響が及ばないよう隔離され、エッジでのDDoS保護、そしてTLSが標準装備され証明書は自動更新されます。もちろん、強力な認証情報、最小特権のアクセス、不要なプラグインの削除といった基本的な対策に代わるものではありませんが、インフラストラクチャが弱点にならないことを意味します。チェックリストにおいて、どのホスティング事業者に対しても問いはシンプルです。セキュリティはデフォルトで備わっているものですか、それとも購入するオプションですか？
WooCommerceと絶対にキャッシュしてはいけないページ
ECサイトにおいて、アグレッシブなキャッシュは、その設定が単純であればあるほど、最大の効果を生む一方で、最悪の被害をもたらします。カタログ、商品、カテゴリーの各ページは、トラフィックが最も多くキャッシュ効率の高いページであり、これらをフルページキャッシュから配信することが、ストアの高速化にとって最善の対策となります。しかし、カート、チェックアウト、アカウントの各ページは個人情報に関連するため、共有キャッシュから決して配信してはなりません。それを誤ると、買い物客が他人の買い物かごを見てしまうことになり、ストアの機能不全とプライバシー侵害の両方を引き起こすことになります。
両方を実現する方法は、ページをキャッシュしつつ、動的な部分に対してホールパンチング（穴あけ）を行うことです。ページの残りの部分がキャッシュから配信される一方で、Edge Side Includesがリクエストごとにカートの断片、ミニカートの合計、アカウントの状態をレンダリングし、cart、checkout、my-account、およびすべてのnonceページやセッションページはデフォルトで除外されます。最新性の管理は、商品、価格、または注文が変更されたときに実行されるスマート自動パージによって行われるため、古い価格が残ることはありません。WooCommerceを運用している場合、チェックリストの中で正確に理解すべきポイントは次のとおりです。キャッシュによる高速なショップフロント、ユーザーごとのリアルタイムなカート、個人のデータの完全な非キャッシュ化。
よくある質問
WP Rocketのようなキャッシュプラグインはまだ必要ですか？
フルページキャッシュはWebサーバー上のLiteSpeedによるLSCacheで処理され、独自のキャッシュプラグインがWordPressをそれに接続してスマートパージを処理し、その背後でサイトごとのRedisオブジェクトキャッシュが機能します。その上に追加のフルページキャッシュプラグインを導入しても、サーバーレベルのキャッシュの助けになるどころか競合することが多いため、必要なく、推奨もされません。
このプラットフォームにより、どのプラグインが不要になりますか？
ここでは、キャッシングプラグイン、独立したオブジェクトキャッシュプラグイン、バックアッププラグインはすべて不要です。それらの作業は WordPress の下層（サーバーレベルのキャッシュ、管理されたサイトごとのオブジェクトキャッシュ、プラットフォームのバックアップ）で処理されるためです。それらを削除することで、競合や攻撃対象領域が減少します。残しておくだけの価値があるのは、サイトの機能に本当に必要なプラグインと、プリインストールされている当社の2つの無料キャッシュおよびフットプリントプラグインです。
キャッシュによってWooCommerceのカートやログイン中のページが壊れることはありますか？
カート、チェックアウト、マイアカウント、およびすべてのナンス（nonce）またはセッションページはデフォルトでキャッシュから除外され、Edge Side Includesによって、それ以外はキャッシュされているページ上でもカートの断片や合計金額がリアルタイムに保持されます。購入者は、ストアフロントがキャッシュから読み込まれている間も常に自身の買い物かごや機能するチェックアウトを確認でき、スマート自動パージ機能によって、商品、価格、または注文が変更されたときに関連ページがクリアされます。
私が管理しなくても、どのようにWordPressの安全性を維持できますか？
WordPress の下のスタックにパッチを適用し、ステージングとワンクリック復元によってコアとプラグインのアップデートを安全に適用できるようにし、デフォルトでマルウェアスキャンと DDoS 保護を実行し、1つのサイトの侵害が他に広がらないように各サイトを分離し、TLS 証明書の発行と更新を自動で行います。これによりインフラストラクチャが弱点となることはなくなりますが、強力なパスワードの使用や使用していないプラグインの削除といった基本的な対策は引き続きお客様の責任となります。