LWRサイトのパフォーマンス・デバッグ術：Chrome DevToolsとSSR時代のボトルネック特定（Community Page Optimizerは使えない？）

SalesforceのExperience Cloudは、LWR（Lightning Web Runtime）への移行により、圧倒的なページロード速度を手に入れました。しかし、開発者やアーキテクトがパフォーマンスチューニングを行おうとしたとき、ある「壁」にぶつかることがあります。

それは、Auraサイトで定番だったデバッグツールが通用しないという点です。

⚠️ 重要：Community Page OptimizerはLWRでは使えません

まず、最も重要な事実をお伝えします。Auraサイトのパフォーマンス分析で必須だったChrome拡張機能「Salesforce Community Page Optimizer (CPO)」は、LWRサイトではサポートされていません。

これについては、Salesforce公式ドキュメント『LWR Sites for Experience Cloud』の “LWR Template Limitations” セクションに、以下の通り明確に記載されています。

Unsupported Features and Settings The following items are unavailable. (…)

• Salesforce Community Page Optimizer

つまり、LWRサイトの調査において、私たちは「CPOのきれいなダッシュボード」に頼ることはできません。代わりに、標準的なWeb開発と同様にChrome DevToolsを深く使いこなし、さらにSpring ’26以降で本格化するExperience Delivery（SSR: サーバサイドレンダリング）特有の挙動を理解する必要があります。

この記事では、LWRおよびExperience Delivery環境における、現代的なデバッグ手法を解説します。

【非SSR】基本のデバッグ：Chrome DevTools Networkタブの活用

専用ツールがない以上、基本にして最強の武器はブラウザ標準の Chrome DevTools です。LWRはSPA（Single Page Application）の性質を持つため（※SSR有効化前の場合）、Networkタブでの分析が鍵を握ります。

XHR (Ajax) リクエストの分析

LWCが表示される際、バックエンド（ApexコントローラーやUI API）への通信がボトルネックになっているケースが大半です。

• Networkタブを開き、フィルタを Fetch/XHR に設定します。
• ページロード時、またはボタンクリック時に発生するリクエストを確認します。
• チェックポイント:
  • 同じデータを何度も取得（Over-fetching）していませんか？
  • 1つのコンポーネントが表示されるために、直列（Waterfall）で複数のApexコールが走っていませんか？（Promise.all等での並列化を検討）

ウォーターフォールの確認

静的リソース（大きなヒーロー画像やサードパーティのスクリプト）が、First Contentful Paint (FCP) をブロックしている場合があります。NetworkタブのWaterfallチャートを見て、ロード時間が極端に長いリソースを特定し、画像の最適化や遅延読み込み（Lazy Loading）を検討してください。

【核心】Experience Delivery (SSR) 環境でのデバッグモード

ここからは、Experience Delivery（SSR） が有効化された環境におけるデバッグの話です。 これまでのクライアントサイドレンダリング（CSR）と異なり、SSRでは「サーバーでHTMLを生成」→「ブラウザで表示」→「JSが起動して対話可能になる（ハイドレーション）」というプロセスを経ます。

事実：本番環境でのデバッグモード有効化

『Experience Delivery Implementation Guide』によると、Experience Deliveryでホストされている公開サイト（Published Site）では、特別なURLパラメータを使用することでクライアントサイドのデバッグが可能になります。

手順（仕様に基づく）:

1. 公開サイトのURLの末尾に ?debug を追加してアクセスします。（例: https://www.mysite.com/?debug）
2. 注意点: 設定画面（Setup）にある「デバッグモードユーザー（Debug Mode Users）」の設定は、Experience Delivery上のLWRサイトではサポートされません。必ずURLパラメータを使用する必要があります。

このモードを有効にすると、以下の変化が起きます。

• フレームワークおよびコンポーネントのJavaScriptの最小化（Minification）が解除され、コードが読みやすくなります。
• 警告やエラーについて、より詳細な出力が行われます。

推測されるシナリオ：ハイドレーションエラーの特定

このデバッグモードが真価を発揮するのは、「ハイドレーション・ミスマッチ（Hydration Mismatch）」の調査です。

SSRにおいて、サーバーが返したHTML構造と、ブラウザ上でLWCが初期化された際のDOM構造が食い違うと、Salesforceは再レンダリングを強制したり、エラーを吐いたりします。これはパフォーマンスを著しく低下させます。

?debug モードを使用し、Chrome DevToolsのConsoleタブを確認することで、以下のようなメッセージを発見できる可能性があります。

• "An error occurred during server-side rendering"（サーバーサイドレンダリング中にエラーが発生しました）

このメッセージを展開することで、どのコンポーネントがSSRに対応していないか（例：window オブジェクトへの不正アクセスなど）を特定できるはずです。

上級テクニック：SSRレスポンスの「生HTML」を確認する

「画面には表示されているのに、なぜかGoogle botがコンテンツを認識しない」「初期表示が一瞬崩れる」。 こうした問題を調査する際、Elementsパネル（検証ツール）を見ても答えはありません。なぜなら、Elementsパネルは「JavaScriptが実行された後の現在のDOM」を表示しているからです。

SSRが正しく機能しているかを確認するには、「サーバーから届いた瞬間のHTML」を見る必要があります。

手法A：Networkタブでルートドキュメントを確認する

1. Chrome DevToolsの Network タブを開きます。
2. ページをリロードします。
3. リクエストリストの一番上にある、ルートドキュメント（現在のURLの名前がついたファイル）をクリックします。
4. Response または Preview タブを確認します。

ここに表示されているHTMLこそが、Experience Deliveryが生成してブラウザに送りつけた「真のSSR結果」です。ここにデータが入っていればSEOは安泰ですが、空っぽであればSSRが失敗し、クライアントサイドレンダリングにフォールバックしている可能性があります。

手法B：JavaScriptを無効化してリロードする

ドキュメントでは、もう一つのシンプルな確認方法が紹介されています。

1. Chrome DevToolsの設定（Cmd+Shift+P → “Disable JavaScript”）でJSを無効化します。
2. ページをリロードします。

この状態で表示されるコンテンツは、純粋にSSRによって描画されたものだけです。もし画面が真っ白になったり、重要なメニューが消えたりする場合、そのコンポーネントはSSRに対応できていない（クライアントサイドでのみ描画されている）ことがわかります。

CLS (Cumulative Layout Shift) の撲滅

最後に、LWR/SSR環境で特に注意したいWeb Vitals指標である CLS（視覚的な安定性） についてです。

SSRで初期HTMLが返ってきた後、クライアント側で connectedCallback 等が走り、追加のデータをフェッチして画面を書き換えると、コンテンツがガクッとずれる現象（レイアウトシフト）が起きます。

これを防ぐための、LWC開発におけるベストプラクティス（推測される実装例）を紹介します。

対策：min-height で領域を予約する

データ読み込み中であっても、コンポーネントの高さが変わらないようにCSSで領域を確保します。

悪い例（データが来るまで高さ0）:

<template>
    <div if:true={data}>
        <c-content-tile data={data}></c-content-tile>
    </div>
</template>

改善例（スケルトン表示または高さ確保）:

/* myComponent.css */
.container {
    /* コンテンツが表示される予定の最小の高さを予め確保する */
    min-height: 300px;
}

<template>
    <div class="container">
        <template lwc:if={data}>
            <c-content-tile data={data}></c-content-tile>
        </template>
        <template lwc:else>
            <lightning-spinner alternative-text="Loading" size="medium"></lightning-spinner>
        </template>
    </div>
</template>

SSR環境であっても、非同期でデータを取得する部分は必ず存在します。こうした地道なCSS対応が、ユーザーの体感速度とGoogleの評価（Core Web Vitals）を大きく向上させます。

まとめ

LWRとExperience Deliveryの登場により、Salesforceサイトの開発パラダイムは大きく変わりました。

1. CPOは使えない：Chrome DevToolsが主戦場になる。
2. SSRのデバッグ：?debug パラメータでハイドレーションエラーを監視する。
3. 生のHTMLを見る：NetworkレスポンスやJS無効化で、サーバーの仕事ぶりを確認する。

ツールは変わっても、「計測→特定→改善」のサイクルは同じです。新しいプラットフォームの仕組みを正しく理解して、高速なサイト体験を作り上げましょう。

参考URL

LWR Sites for Experience Cloud

Improve LWR Site Performance with Experience Delivery