Spring '26版: Experience Delivery (SSR) 導入の分かれ道。LWRサイトのレンダリング戦略をどう決める？

この記事はバージョン Spring ’26 において執筆しています。
現在の動作と異なる場合がありますので、ご認識おきください。

Salesforce Experience Cloudの歴史において、Spring ’26 は単なる機能追加のアップデートではありません。これは、Webサイトのレンダリングアーキテクチャそのものを再定義する、過去最大級の転換点です。

その中心にあるのが、Experience Delivery です。

これまでのLWRサイトは、クライアントサイドレンダリング（CSR）を前提としたシングルページアプリケーション（SPA）でした。しかし、Experience Deliveryの登場により、Salesforceはついに本格的な サーバーサイドレンダリング（SSR） へと舵を切ります。

本記事では、この新インフラがもたらす技術的革新と、それに伴う開発パラダイムの変化、そして「あなたのプロジェクトで採用すべきか？」という導入判断の基準までを徹底解剖します。

なぜ今、SSR（サーバーサイドレンダリング）なのか？
1. CSRの限界と「Core Web Vitals」の壁
2. Experience Deliveryがもたらす世界
Islands Architecture（アイランドアーキテクチャ）：静的な海と動的な島
1. 開発者が制御する3つのレンダリングモード
開発者への影響：SSR対応コーディングの鉄則
Experience Delivery (SSR) を「採用する」か「見送る」か？の判断基準
結論：System of Actionへの準備
参考URL

なぜ今、SSR（サーバーサイドレンダリング）なのか？

CSRの限界と「Core Web Vitals」の壁

従来のLWRサイト（CSR）では、ブラウザが空のHTMLを受け取った後、大量のJavaScriptをダウンロード・実行して初めてコンテンツが表示されていました。

課題:
初回表示（FCP）や、メインコンテンツの表示（LCP）までの待機時間が長く、SEOや直帰率に悪影響を与えやすい構造でした。
Googleの評価:
Core Web Vitalsのスコア改善には、JavaScriptの実行時間を削るか、レンダリングを早めるしかありません。

Experience Deliveryがもたらす世界

Experience Deliveryは、Salesforceの専用Node.jsエッジサーバー上でLWCを実行し、完成されたHTMLを生成してCDNにキャッシュします。

爆速の初期表示:
ユーザーは、ブラウザがJavaScriptを処理するのを待つことなく、即座に描画されたページを見ることができます。
SEO完全対応:
クローラーはJavaScriptを実行せずとも、完全なHTMLコンテンツをインデックス可能です。Salesforce公式データでは、ページロード時間が最大 60%短縮 されるとされています。

Islands Architecture（アイランドアーキテクチャ）：静的な海と動的な島

Spring ’26のExperience Deliveryにおける最も重要な技術概念が、Islands Architecture です。

これまでのSPAは、ページ全体をJavaScriptで制御していました。しかし、ヘッダーやフッター、静的なテキストまでJavaScriptで描画するのはリソースの無駄です。 Experience Deliveryでは、ページ全体を「静的なHTML」として扱い、その中にインタラクションが必要な部分だけを「動的な島（Island）」として配置します。

Islands Architecture のイメージ（Gemini Nano Banana が生成）

開発者が制御する3つのレンダリングモード

LWCコンポーネントごとに、以下のどのモードで動作するかを js-meta.xml の <capabilities> タグで定義します。

モード	動作	適したユースケース	js-meta.xml 設定
SSR Only	サーバーでHTML化。JSはクライアントに送られない（ハイドレーションなし）。	静的テキスト、画像、レイアウトコンテナ	`<capability>lightning__ServerRenderable</capability>`
SSR with Hydration	サーバーでHTML化し、クライアントでJSを結合（ハイドレーション）して機能有効化。	フォーム、カルーセル、メニュー	`<capability>lightning__ServerRenderableWithHydration</capability>`
CSR Only	サーバーではプレースホルダーのみ。クライアントで全描画。	ログイン後ユーザー固有のデータ表示、ブラウザAPI依存機能	設定なし（デフォルト）

開発者への影響：SSR対応コーディングの鉄則

SSR環境（Node.js）ではブラウザ（DOM）が存在しません。そのため、これまでのLWC開発の常識が通用しない場面が出てきます。Spring ’26に向けたリファクタリングのポイントは以下の3点です。

① connectedCallback のポータビリティ（移植性）確保

connectedCallback はサーバーとクライアントの両方で実行されます。ここで window や document にアクセスすると、サーバー側でエラー（500 Internal Server Error）が発生し、ページ全体がクラッシュします。

❌ アンチパターン（SSRでクラッシュ）

connectedCallback() {
    // サーバーには 'window' がないためエラーになる
    this.winWidth = window.innerWidth;
    document.title = "My Page";
}

✅ 推奨パターン（SSRセーフ） import.meta.env.SSR フラグを使用して、ブラウザ固有の処理をガードします。

import { LightningElement } from 'lwc';

export default class ResponsiveComponent extends LightningElement {
    connectedCallback() {
        // 共通ロジック（データ加工など）
        this.initData();

        // ブラウザ環境（クライアント）でのみ実行
        if (!import.meta.env.SSR) {
            this.winWidth = window.innerWidth;
            document.title = "My Page";
        }
    }
}

② renderedCallback はクライアント専用

renderedCallback はSSRプロセスでは実行されません。DOM操作やサードパーティライブラリ（Chart.jsなど）の初期化は、必ずここで行うように移動させてください。

③ データフェッチの同期化：getServerData フック

SSRは「一回の同期的なパス」で処理されます。従来の connectedCallback 内での非同期処理（PromiseやApexコール）は、完了を待たずにHTMLが生成されてしまうため、データが空のままレンダリングされます。

Spring ’26では、コンポーネントのレンダリング前にサーバー側でデータを取得するための新しいフック getServerData が導入されます。

// SSR用データフェッチの例
export async function getServerData(context) {
    // サーバーサイドでAPIを叩く
    const data = await fetchSomeData(context.params.recordId);
    return {
        props: {
            productData: data // コンポーネントの@apiプロパティに注入される
        }
    };
}

Experience Delivery (SSR) を「採用する」か「見送る」か？の判断基準

ここまで技術的な詳細を見てきましたが、LWCを好まれる皆様にとって、Experience Delivery（およびLWRサイト）は「諸刃の剣」のような側面があります。制約と価値のトレードオフを整理しましたので、Spring ’26時点での導入判断の参考にしてください。

なぜ「制約が多い」と感じるのか（デメリット）

従来の Experience Delivery なしのLWRサイト（カスタマーサービスなど）に比べると、開発者への負担や制約は明確に存在します。

SSR（サーバーサイドレンダリング）の厳格さ
Experience Delivery の肝は SSR ですが、これにより LWC のコードは「サーバーでもクライアントでも動く（アイソモーフィックな）」記述が求められます。window や document オブジェクトへの安易なアクセスがエラーになるため、既存の LWC 資産をそのまま使えない（リファクタリングが必要な）ケースがあります。
開発スキルの要求
「コードベース（SFDX, LWC）」のアプローチがより強くなるため、手軽に構築したい場合にはオーバースペックに感じられるでしょう。

それでも「使う価値」がある理由（メリット）

制約を受け入れてでも採用する価値は、以下の点に集約されます。

圧倒的なパフォーマンス
これが最大の理由です。SSR により、初期表示速度（FCP/LCP）が劇的に向上します。特にモバイルユーザーや、SEO を意識する必要がある公開サイト（コーポレートサイト、ランディングページ、ヘルプセンターなど）では、この速度は直帰率に直結するため、非常に大きな武器になります。
SEO（検索エンジン最適化）
SSR は Googlebot などのクローラーに対して、完成された HTML を返すことができるため、従来の SPA（シングルページアプリケーション）構成よりも SEO に圧倒的に有利です。皆様としての視点でも、このメリットは大きいはずです。
LWC のポテンシャルを解放
Spring ’26 では、LWC 内での GraphQL サポートなどが強化されています。これにより、複雑なデータ取得を効率化でき、開発者がコントロールできる領域が広がります。「LWC のコード作成」を好まれる皆様にとっては、標準Web技術に近い形で開発できる点は長期的にはメリットになります。

Spring ’26 時点での判断基準

Experience Delivery は強力な機能ですが、すべてのページで無条件に有効化すれば良いという魔法の杖ではありません。SSR特有のコーディング制約やコストを考慮し、適材適所で使い分ける必要があります。以下のマトリクスを参考に、ページごとのレンダリング戦略を決定してください。

比較項目	Delivery あり (SSR)	Delivery なし (CSR)
主なレンダリング	サーバーサイド(Edge) HTMLを生成してからブラウザに渡す	クライアントサイド (Browser) JS読み込み後、ブラウザで描画する
最大の強み	FCP (First Contentful Paint) 初期表示が爆速。SEOに強い。	インタラクティブ性画面遷移や複雑な操作が滑らか。
SEO強度	最強クローラーに完全なHTMLを渡せる	普通〜弱いクローラーのJS実行能力に依存する
適したデータ	静的〜準静的データ記事、カタログ、FAQなど「誰が見ても同じ」情報	動的・個別データマイページ、ユーザー固有のダッシュボード
開発難易度	高い (制約あり) アイソモーフィックなコード記述が必須	標準的従来のLWC開発手法がそのまま通用する

基準1：「最初の1秒」がビジネス価値に直結するか？

最も重要な問いは「ユーザーは白い画面（ローディング中）を待ってくれるか？」です。

採用すべき (SSR):
一般公開されるランディングページ、ECサイトのトップ、公共サービスの案内など。これらは、表示速度が遅いとユーザーが即座に離脱（直帰）してしまいます。「表示速度＝売上・信頼」の直結する場合、Experience Delivery の導入価値は最大化されます。
見送るべき (CSR):
契約者専用ポータル、社内申請フォームなど。ユーザーは「ログインして作業する」という明確な目的があるため、最初の数秒のローディングを許容してくれます。

基準2：表示データは「誰が見ても同じ」か？（キャッシュ効率）

Experience Delivery の真価は、生成したHTMLをCDN（エッジサーバー）にキャッシュすることで発揮されます。

採用すべき (SSR):
ブログ記事や物件詳細ページのように、「Aさんが見てもBさんが見ても同じ内容」である場合。一度生成されたHTMLはキャッシュされ、2人目以降のアクセスは爆速になります。
見送るべき (CSR):
「ようこそ〇〇様」といったヘッダー情報や、未読メッセージ数など、「ユーザーごとに表示内容が異なる」場合。サーバーでHTMLを生成してもキャッシュが効かず、SSRのメリットが半減します。

DXforce Point for Developers

SSRでもユーザーごとの出し分け（パーソナライズ）は可能ですが、「Islands Architecture」を用いて動的な部分だけをクライアントサイドで水分補給（Hydration）する高度な設計が必要になります。

基準3：開発チームはSSRの制約を受け入れられるか？

技術的な側面です。Experience Delivery を有効にする場合、LWCのコードはサーバー上（Node.js環境）でもエラーなく動作する必要があります。

window や document オブジェクトへの安易なアクセス禁止
サードパーティ製ライブラリ（jQuery等）の読み込みタイミングの厳格化

既存のLWC資産を大量に流用したい場合や、開発スピードを最優先し、厳格なSSR対応コードを書くリソースがない場合は、あえて標準の LWR (CSR) を選択するのも賢明なアーキテクチャ判断です。

まとめ：サイト全体で統一する必要はない

重要なのは、これらを「サイト全体で統一する必要はない」ということです。

Islands Architecture（部分ハイドレーション）の技術や、認証の有無によるキャッシュ仕様の違いを利用することで、「トップページはSSRで高速化」しつつ、「マイページは従来のクライアント処理（CSR）を中心にする」といったハイブリッドな構成が可能です。

「速さ」が必要な場所には投資をし、そうでない場所は効率を重視する。これがこれからのLWRサイト設計のスタンダードになるでしょう。

結論：System of Actionへの準備

「制約」は、高いパフォーマンスを実現するための「規律」のようなものです。もし皆様が「一般公開向けの高速なサイト」を作ろうとされているのであれば、その制約と戦う価値は十分にあります。

Spring ’26で開発者体験（DX）も向上しています。まずは小さな公開ページ（ランディングページなど）で、SSR 対応の LWC の挙動を試してみることから始めましょう。lwr audit コマンドを実行し、自社のコンポーネントがSSRに対応可能か（ポータビリティがあるか）を早期に評価することが、次世代のSalesforce開発への第一歩です。

次回は、「実際にどう実装すれば、理論値であるロード時間60%短縮を実現できるのか？」 というエンジニアリングの深層に踏み込みます。