表示が遅いとき、CPUやメモリの数字だけを見ても原因は分かりません。ブラウザへ届くまでにはDNS・通信・サーバー処理・キャッシュがあり、届いた後には画像やJavaScriptの処理があります。まずページ表示速度を測り、サーバーの機能を確認したうえで、改善作業を進めるのが安全です。

同じページと条件で基準を作る

測定にはPageSpeed Insightsを使います。モバイルとデスクトップを分け、トップページだけでなく画像の多いページやフォームも測ります。実際の利用者データとラボ環境の結果は役割が異なり、ラボ値は測定条件によって揺れます。一回の点数ではなく、同じURLを複数回確認して基準を作ります。

変更前の時刻・URL・端末区分・主要指標を残します。管理画面の遅さはPageSpeed Insightsでは測れないため、操作の開始から完了までを別に記録します。遅いという感覚を、全ページ・特定ページ・特定時間帯・編集時だけのどれかに分けます。この範囲が分からないままプランを上げると、改善したかも判断できません。

応答開始と描画完了を分けて読む

TTFBはリクエストから応答の最初のバイトを受け取るまでを示し、その後の表示指標より前に発生します。ただしTTFBにはサーバー処理だけでなく、DNSや接続、CDNの影響も含まれます。TTFBが長いから直ちにサーバー性能不足とは言えません。キャッシュ済みと未キャッシュの応答を比べ、経路を確認します。

TTFBが短くても大きな画像や描画を止めるスクリプトがあれば、利用者が内容を見るまで時間がかかります。反対に主要表示が速くても、フォーム送信や管理画面だけ遅いことがあります。PageSpeed Insightsの提案をサーバー側とページ側へ分け、どの工程の時間を減らす提案かを読みます。

サーバー処理は動的ページとログから確かめる

WordPressの動的ページは、PHPが処理しデータベースから内容を取得して応答を作ります。静的ファイルは速いのに未キャッシュのHTMLだけ遅い場合は、この処理経路を調べます。サーバーのアクセスログ・エラーログ・利用可能な負荷情報を同じ時刻で照合します。遅いリクエストのURLと発生条件を残します。

プラグインをすべて多すぎると判断せず、処理時間や外部通信を確認します。データベース容量が大きいことだけでも遅さは決まりません。管理画面のサイトヘルスや事業者の計測機能を使い、PHP版・メモリ制限・実行時間など現在の条件を把握します。計測機能がなければ保守担当へ再現時刻を渡して調査します。

スペックの数字は共有範囲と制限を含めて見る

CPUコア数やメモリ容量が公開されていても、共有サーバーでは利用者が自由に占有できる量とは限りません。一定時間の実行数やCPU利用に制限がある場合は、上限時の挙動を確認します。SSDなどの記憶媒体も一要素ですが、キャッシュで応答するページと毎回データベースを読むページでは影響が違います。

上位プランで何が増えるかを事業者の仕様から確認します。容量だけ増えて処理制限が同じなら、速度問題の解決には直結しません。反対に同時実行や専用資源が増えるなら、アクセス集中時の改善を見込めます。平均時の遅さと集中時の遅さを分け、必要な資源とプラン差を対応させます。

設定は原因に近い一層ずつ変更する

未キャッシュのPHP処理が遅いなら、対応版へのPHP更新・不要処理の見直し・オブジェクトキャッシュなどを検討します。静的ファイルの転送が課題なら、ブラウザキャッシュやCDNが候補です。画像が主要表示を遅らせているなら、サーバープランより画像最適化を先に行います。利用中のサーバーが標準で提供する機能も確認します。

複数のキャッシュや最適化を同時に有効にすると、効果と不具合の原因が分かりません。一つ変更したら同じ条件で測り、表示・フォーム・管理画面を確認します。効果がなければ設定を戻し、次の原因へ進みます。変更記録を残すことで、速度向上と機能停止を引き換えにしない運用ができます。

移転や上位プランは測定差から判断する

サーバー機能を使い、サイト側の明らかな負荷を直しても未キャッシュ応答が遅い場合は、上位プランや移転を比較します。候補環境で同じサイトを測れるなら、同じページと時間帯で確認します。広告上のスペックだけでなく、負荷制限・サポート・移転後の管理負担も判断材料です。

速度改善の完了条件は点数を最大にすることではありません。利用者が主要内容へ到達し、問い合わせなどの処理を無理なく完了できることです。変更前よりどの指標と業務操作が改善したかを記録します。改善幅が費用と移転リスクに見合う場合にだけ、プラン変更を実行します。