フロントをいくら改善してもパフォーマンスが速くならない理由｜共用サーバーの“見えない制限・限界”

PageSpeed Insights の改善に取り組む中で、多くの方が次のような違和感に直面します。

• 画像や CSS、JavaScript を削ってもLCPが一定以下に下がらない
• First Contentful Paint は改善したのに 体感速度が変わらない
• 計測のたびに数値がばらつく

この現象は、設定や書き方の問題ではありません。
共用サーバーという環境そのものが持つ「初動の壁」に起因します。

ページ表示の最初に必ず通る「サーバー応答」

どれだけフロントエンドを最適化しても、ページ表示は必ずこの流れから始まります。

1. ブラウザがリクエストを送信
2. サーバーがリクエストを受信
3. PHP / アプリケーション処理
4. HTML を返却

この 最初の応答速度（TTFB） が遅い場合、その後の描画最適化は「後追い」になります。

共用サーバーでは、この初動部分に以下の制約があります。

• CPU が他ユーザーと共有されている
• 同時リクエスト数に制限がある
• PHP プロセスが待たされることがある

これらは、フロント側から制御できません。

■ なぜ LCP 改善が頭打ちになるのか

LCP（最大コンテンツの描画）は、「一番大きな要素がいつ表示されたか」を見る指標です。

• HTML が返ってこない
• CSS が解釈できない
• JavaScript の初期処理が始められない

しかし実際にはこの状態では、LCP 対象要素の読み込み以前に待ち時間が発生します。

共用サーバーでは、「LCP 改善 = 描画改善」ではなく「LCP 改善 = 応答速度の安定化」という側面が強くなります。

「改善しているのに速くならない」理由

多くの現場で起きているのは、次の状態です。

• 画像は十分軽い
• CSS も整理されている
• JavaScript も最小限

それでも、以下のような状況は起こりえます。

• 「TTFB が 600ms → 900ms → 700ms と揺れる」
• 「LCP が 2.5秒 → 3.1秒 → 2.8秒 と安定しない」

これは 作り方の問題とは限りません。処理の開始点が揺れているため、後続のすべてが連鎖的に遅れています。

共用サーバーの「不安定さ」は数値に表れにくい

PageSpeed Insights は平均的な挙動を評価します。そのため、以下のような問題は見逃されがちです。

• 特定時間帯だけ遅くなる
• 管理画面操作後に一時的に重くなる
• 他ユーザーの影響で応答が遅延する

これらは 数値ではなく体感で気づく問題です。

そして、この「体感のズレ」こそが共用サーバーでの限界を示しています。

フロント改善とサーバー改善は別物

重要なのは、フロントエンドの改善とサーバー環境の改善は競合関係ではないという点です。

• フロントを整えることで「無駄」を削る
• サーバーを見直すことで「揺らぎ」を減らす

共用サーバーでは、後者に踏み込めないという制約があります。その結果、「どれだけ丁寧に作っても最初の一歩が遅い」という状態が生まれます。

「これ以上は無理」ではなく「段階が違う」

ここまで来ると、「もう改善できない」と感じるかもしれません。しかし実際には、「改善の余地がない」のではなく「改善する段階が変わった」というだけです。

段階が変わったとはどういうことか？ この壁を越えるときに何を考えるべきか、共用サーバーから一段先の選択肢を整理します。