あなたのサイトが遅い理由

DevToolsを開いて3つのプラグインを変更し、フィールドデータを見ずに再デプロイするなら、余計なステップで推測しているだけです。遅さはビジターの体験です。コードに触れる前に、実際のユーザーからの数字で証明してください。

PageSpeed InsightsまたはSearch ConsoleのCore Web VitalsのChrome UX Reportフィールドデータから始めてください。モバイルでLargest Contentful Paint、Interaction to Next Paint、Cumulative Layout Shiftの75パーセンタイルが必要です。Lighthouseからのラボスコアは単一ページロードのデバッグに役立ちます。これはGoogleがランキングに使用するメトリクスでも、列車のWi-Fi接続でバイヤーが感じるメトリクスでもありません。

最初の10分で取得する内容

遅いページのURL。デバイスクラス（スマートフォン優先）。問題が初回訪問か再訪問か。ログイン済みページとパブリックホームページが異なるかどうか。見られるならTTFB。診断パネルのLCP要素名。このような短いリストは通常、誰かがフレームワークを議論する前に正しいレーンを指しています。

キーテイクアウェイ：フィールドデータがサイトが遅いかどうかを決める。ラボデータはレバーを見つけるのに役立つ。その順序を決して逆にしないこと。

コンテンツが表示される前にページが遅い場合、通常はサーバーです：高い初期バイト時間、キャッシュされていないデータベースクエリ、毎回のPHPまたはNodeレンダリング、または単に電力不足のホスト。コンテンツが表示されてからジャンク、停滞、またはシフトする場合、それはフロントエンドです：画像、スクリプト、フォント、レイアウト。

有用な分け方：TTFB約0.8秒未満は、オリジンがほぼクリティカルパスから外れていることを意味します。マーケティングされているページで1.2秒以上の場合、画像コーデックについて執着する前にホスティング、キャッシュ、またはサーバーレンダリングコストを修正してください。大規模サイトの場合、診断はこのサイトのCore Web Vitalsチェックリストと、LCP、INP、CLSフィックスガイドで独自のプレイブックを取得します。

キーテイクアウェイ：最初にレーンを名付ける。サーバーの仕事とフロントエンドの仕事には異なる人員と異なるツールが必要です。

私が見るコマーシャルサイトで実際の問題になる頻度の高い順:

1. サイズが大きすぎるヒーロー画像

2MBのPNGまたはトリミングされていないCMSアップロードがLCP要素になっているケース。解決策：適切なサイズにする、モダンフォーマット（WebPまたはAVIF）を使う、width と height 属性を指定する、実際のLCP URLをプリロードする、CDNから配信する。1つの優れたヒーロー画像の修正は、10個のマイクロな調整よりも効果的です。

2. 初回ペイント時に不要なJavaScript

タグマネージャー、チャットウィジェット、A/Bテストツール、未使用のフレームワークハイドレーション、「念のため」のクライアントコンポーネント。解決策：サードパーティをdefer または削除する、マーケティングルートで配信するJSを減らす、インタラクティビティアイランドは小規模に保つ。

3. ホスティングとキャッシュミス

共有ホスティング、ページキャッシュなしのコールドWordPress、すべてのパブリックURLで実行されるNext.js SSR、またはすべてをリビルドするISRパターン。解決策：WordPressの場合はマネージドホスティングまたはエッジキャッシュを使う、アプリフレームワークの場合は適切な revalidate ポリシーを持つ静的またはISRにする。

4. レンダリングをブロックするフォントとCSS

5つのウェイトを持つディスプレイフォント、サードパーティのCSSファイルからインポートされている、テキストをブロック。解決策：サブセット化する、自分でホストする、font-display swap または optional を使う、フォールドの上部用に重要なCSSをする。

5. 制限されていないサードパーティ

ピクセルがさらにピクセルを挿入する。対策：インタラクション後またはアイドル時に読み込む、コンバージョンテストで価値を証明しないものはすべて削除する。

6. 遅延コンテンツによるレイアウトシフト

予約スペースのない広告、埋め込み、画像。対策：アスペクト比ボックス、予約スロット、既存コンテンツ上への UI 挿入を避ける。

重要なポイント：「フレームワークが遅い」というクレームのほとんどは、フレームワークの仮面をかぶったこれら6つのいずれかである。

すべてを同時に最適化しない。フィールド診断またはラボ診断で LCP エントリを開き、LCP である要素（通常はヒーロー画像またはヘッドライン）を見つけ、その1つの要素を高速化する：適切なサイズ、プリロード、CDN から配信。再測定する。次にクリティカルパス上で実行される JavaScript を削除する。再度測定する。

マーケティングサイトの実践的な順序：LCP 要素、次にサードパーティ JS、次にフォント読み込み、次にキャッシュと TTFB、次に CLS クリーンアップ、最後にマイクロ最適化。最初の2つの後で終了することが多く、商用サイトを CWV の合格帯に押し上げる。

WordPress 注釈：プラグインダイエットとマネージドホスティング上の実際のページキャッシュは、エージェンシーが認めるより頻繁にテーマ書き直しを打ち負かす。Next.js と Astro 注釈：パンフレットを SSR しない。公開ページは Static または キャッシュされた HTML、認証されたプロダクトサーフェスはサーバーワークを予約する。詳細は Next.js vs Astro vs WordPress ガイドに記載。

重要なポイント：測定された1つの LCP 改善は、1週間の推測的リファクタリングに勝る。

WordPress

ページビルダーがすべてのウィジェットCSSをすべてのページで読み込んでいる。キャッシュされていないWooCommerceテンプレート。重い関連投稿クエリ。何年もかけて肥大化したオートロードオプションテーブル。対策：エッジでHTMLをキャッシュする、プラグインを削減する、ビルダーの下部セクションを遅延読み込みする、データベースのオートロード肥大化を修正する。

Next.js

ページ全体をラップするクライアントコンポーネント。連続的なawaitの滝。間違ったローダーを通す画像。個人化しないページでISRまたはSSRを使う。対策：デフォルトではServer Componentsを使う、可能な限り静的にする、ルートごとのJSバンドルを監査する。

Astroおよびその他の静的スタック

通常は高速だが、プロダクトアプリのサイズのSPAアイランドを再導入したり、巨大なCMSメディアをホットリンクしたりすると低下する。対策：アイランドを小さく保つ、パイプラインで画像を処理する、静的サイトにWordPressの習慣を貼り付けない。

重要なポイント：修正をスタックに合わせる。プラットフォーム変更はパフォーマンス改善の最初のステップではない。

モバイルの実際のユーザーで第75パーセンタイルで測定されたターゲット：Largest Contentful Paintが2.5秒以下、Interaction to Next Paintが200ミリ秒以下、Cumulative Layout Shiftが0.1以下。Time to First Byteは約0.8秒以下に保つことで、サーバーがクリティカルパスから外れます。

これらを達成すれば、合成的な虚栄スコアが何を言おうとも、訪問者やGoogleが処罰するような形でサイトが遅くなることはない。これより速いのはポーランドです。100を追い求めるのではなく、プロダクトを出荷する。

このタスクをチェックリスト形式で行いたい場合は、Core Web Vitalsチェックリストを使う。メトリクスごとの詳細な対応が必要な場合は、LCP、INP、およびCLS修正ガイドを使う。ビジネスケースがリビルドの場合は、リデザインデッキではなくパフォーマンスの柱から始める。

重要なポイント：フィールドCWVに合格することは「遅いのか？」の終了ラインであり、完璧なLighthouseスクリーンショットではない。

LCP要素が明白で、サードパーティが少なく、ホスティングをコントロールできているなら、DIYで十分だ。フィールドデータが正直な2回の修正サイクル後も赤いままの場合、スタックがチーム内の誰も所有していないハイブリッドの場合、または収益ページがあと1週間の推測的な変更に耐えられない場合は、ヘルプを呼び込もう。

外部の人間にとって有用なブリーフ：重要な3つのURL、フィールドスクリーンショット、LCP要素の名前、ホストとCDN、削除を許可されていないタグのリスト。そのパッケージによって、曖昧な「サイトが遅い」が1スプリントの仕事に変わる。

会話が完全なリデザインに転じたら、一度立ち止まろう。パフォーマンス作業とリデザイン作業は、リデザインに明示的なCWV予算がない限り、相性が悪い。ビジネスがまだそれに依存しているなら、現在のテンプレートを先に修正しよう。

重要なポイント：2回の修正失敗またはオーナーが不明確という状態が、DIYと有料パフォーマンスサービスの境界線だ。