閲覧の増加で負荷の警告が続くとき、プランを上げるか仕組みを変えるか

この判断が当てはまる状態と、先に確かめること

この判断が当てはまるのは、WordPressのサイトで、調査を頼んだ先から負荷の原因は閲覧の増加だけだと報告を受けた場合と、警告はまだ届いていないもののアクセスが増え続けていて先に備えたい場合です。後者では、増えているのが人の閲覧かを先に確かめます。ボットのアクセスが原因なら、プランを上げても負荷の元が残ったまま費用だけが増えます。同じ発信元や、同じソフトウェアを名乗るアクセスが偏っていないかを、サーバー会社か制作会社にアクセスの記録で確かめてもらえます。ただし、偏りが無くても、ボットではないとは言い切れません。

警告が届いていて、まだ調査で原因を確かめていない場合（時期の一致から閲覧の増加だと見当をつけている場合も含みます）や、侵入が疑われる場合は、先に高負荷の警告への対応で初動を確かめてください。侵入されて動かされている処理が原因なら、その処理を止めることが先になるためです。

会員、注文、予約をWordPressのプラグインでサイトの中で扱っているサイトでは、後で挙げる方法のうち静的移行は使えません。ほかの方法で負荷に対処し、仕組みそのものを変えるならサイトの作り替えが候補になります。

負荷の元と、共有サーバーの上限

WordPressは、ページが開かれるたびにPHP（Webサイトを動かすプログラムの処理系）でページを組み立て、データベース（記事や設定を保存する場所）から内容を読み出します。閲覧が増えると、この処理も閲覧の数だけ繰り返され、そのぶんサーバーの処理能力を使います。

共有サーバー（1台のサーバーを複数の契約者で使うレンタルサーバー）では、使える処理能力に上限があります。上限の値と、何を超えたら制限されるかは、サーバー会社とプランによって違います。

エックスサーバーの仕様一覧（2026年10月確認）には、転送量を無制限としたうえで「ネットワークやサーバーに対して過大な負荷が掛かる場合には、制限を行う場合があります」と書かれています。同じ仕様一覧には、プランごとに保証されるCPU（計算を受け持つ部品）とメモリの量（保証値）も、サーバーの番号の範囲ごとに載っています。最も古い世代のサーバーには保証がありません。

この上限への対処には、次の4つの方法があります。1は上限を上げる方法、2と3は1回の表示で使う量を減らす方法、4は公開側の処理そのものを無くす方法です。

1. プランやサーバーの増強が合う場合

上限を上げる方法です。サイトに手を入れずに済むので、すぐに効果を出せます。キャンペーンの期間中や報道の直後のように、閲覧の増加が一時的で、終わる時期が見えている場合に合います。

ただし、閲覧が増えるたびに上のプランへ上げることになり、そのぶんの月額がかかり続けます。前の節で見たとおり、保証値はサーバーの番号の範囲によって違うので、上げる前に、いま使っているサーバーの番号と、上げた先の保証値を確かめてください。

共有サーバーの中でプランを上げるほかに、VPS（仮想の専用サーバー）や専用サーバーへ移り、上限を大きく引き上げる方法もあります。この場合は、移った先でサーバーの更新や監視を誰が受け持つかを決める必要があります。

2. ページキャッシュが合う場合

1回の表示で使う量を減らす方法の1つです。WordPress公式のサポート文書（キャッシュによる最適化）では、キャッシュのプラグインについて「WordPress の投稿とページを静的ファイルとしてキャッシュします」と説明されています。一度組み立てたページを保存しておき、次からはページの組み立てとデータベースへの問い合わせを省いて保存したページを返すので、閲覧の増加に効果があります。サーバーの手前に置いた配信網（CDN）から保存したページを返す方法も、考え方は同じです。

記事やお知らせのように、誰が見ても同じ内容のページが閲覧の大半を占めるサイトに合います。同じ文書には「投稿やページに多くの動的コンテンツが含まれている場合、キャッシュの設定はより複雑になる可能性があります」ともあります。ログイン中の画面、問い合わせフォームの送信、サイト内の検索のように、閲覧者ごとに結果が変わる処理は、保存したページでは返せません。

なお、キャッシュを入れても、WordPress本体とプラグインは公開側で動き続けます。更新の作業も、更新で画面が止まる心配も残ります。

3. データベースを見直す場合

ログイン中の画面や検索のように、キャッシュで返せない処理では、データベースへの問い合わせも負荷の元になります。共有サーバーでは、データベースの設定値やサーバーの構成を契約者が変えられないことが多く、見直せるのはサイトの側の使い方です。見直す先は3つあります。

1つ目は、ページを表示するたびに読み込まれる設定のデータです。WordPressの開発チームは、2024年6月の開発者向けのお知らせで「Autoloading a large amount of data that is not used negatively impacts website performance」（使わない大量のデータを自動で読み込むと、サイトの性能が落ちる）と書いています。WordPress 6.6 からは、自動で読み込む設定のデータが合計で800KBを超えると、管理画面の「サイトヘルス」に警告が出ます。同じバージョンから、新しく追加または更新される150,000バイトを超える値は、既定で自動読み込みされなくなりました。ただし、すでに入っている設定はそのままなので、使わなくなったプラグインの設定が残っていると、合計は大きいままです。

2つ目は、重い問い合わせを出しているプラグインです。負荷の元が本体ではなく特定のプラグインにあるなら、外すか別のものに替えれば減ります。どのプラグインが重いかは、制作会社か開発の担当者に調べてもらう必要があります。

3つ目は、オブジェクトキャッシュ（データベースから読み出した結果を、速く取り出せる場所に置いておく仕組み）です。キャッシュの節で挙げたWordPress公式のサポート文書（外部サイト）には、オブジェクトキャッシュによく使われる仕組みとして Redis、Memcached、APC、ファイルシステムが挙げられています。共有サーバーで使えるかどうかは、契約先に確かめる必要があります。

見直しで減るのは1回の表示あたりの負荷で、閲覧のたびにデータベースへ問い合わせる仕組みは残ります。そのため、閲覧が増え続けるサイトでは、見直しだけでは追いつかなくなります。また、インデックス（データベースで探す手間を減らす目印）を足すなど表の構造に手を入れると、WordPress本体やプラグインを更新するたびに、互換性を確かめる手間がかかります。

4. 静的移行が合う場合

公開側の処理そのものを無くす方法です。ページをあらかじめHTMLのファイルとして書き出し、公開するサーバーにはそのファイルだけを置きます。閲覧のたびにPHPとデータベースが動くことがなくなるので、閲覧が増えても、ページを組み立てる処理は増えません。

配信先によっては、閲覧の数が費用に響きにくくなります。たとえば Cloudflare Pages の料金の資料には、無料と有料のどちらのプランでも「requests to static assets are free and unlimited」（静的なファイルへのリクエストは無料で、回数の上限もない）とあります。ただし対象は、処理を呼び出す機能（Functions）を使わないリクエストに限られます。

記事やお知らせが中心で、閲覧の増加が一時的ではなく続いているサイトに合います。会員、注文、予約をサイトの中で扱う機能は、サーバー側の処理が要るため残せません。問い合わせフォームは、外部のサービスか、別の場所で動かす小さなプログラムへ移して残します。送信数や契約の種類によっては、その利用料が別にかかります。サイト内の検索は、書き出すときに作った検索用のデータをブラウザで読む方式なら、外部のサービスなしで動かせる場合があります。どの機能を残せるかは、静的サイトで残せる機能の条件で確かめられます。

負荷とは別の負担もあります。記事を更新してから公開するまでの流れが変わり、編集のあとに書き出しと配置の手順が加わります。移すための作業にも費用と期間がかかるので、閲覧の増加が一時的なだけなら、割に合わないことがあります。

どれが合うかの選び方と、相談相手に確認すること

4つの方法は、どれか1つを選ぶものではありません。たとえば、一時的な増加はプランの増強でしのぎ、その間にキャッシュとデータベースを見直す、という組み合わせもできます。次の表で、当てはまる状況を確かめてください。

• サーバー会社に確認すること：警告で超えたのはどの指標か（CPU、同時に処理している数、データベースへの問い合わせ回数など）。いまのサーバーとプランの保証値と、上げた先の保証値。オブジェクトキャッシュを使えるか。
• 制作会社や開発の担当者に確認すること：ページキャッシュを入れる場合に、キャッシュから外す画面はどれか。重い問い合わせを出しているプラグインはどれか。自動で読み込む設定に、使っていないプラグインのものが残っていないか。静的移行する場合に、残す必要がある動的な機能はどれか。