【意外と知らない】LWRとAuraで何が違う？「公開」プロセスの決定的な差と注意点

Experience Cloudの開発において、AuraサイトとLWRサイトの決定的な違いのひとつが「公開」のプロセスです。

Auraサイトではコンポーネントの修正が即座に反映されることが多い一方で、LWRサイトでは「コードをデプロイしたのに画面が変わらない」という現象が起こります。 これは、LWRがパフォーマンスを最大化するために採用している独自のアーキテクチャによるものです。

本記事では、LWRサイトにおける「コンポーネントの静的化（フリーズ）」の仕組みと、それに伴う開発フローの注意点について解説します。

Auraサイトの「動的」な挙動

まず、従来のAuraサイト（カスタマーサービスなど）の挙動をおさらいしましょう。

Auraサイトでは、コンポーネントは動的に配信されます。 これはつまり、開発者がカスタムコンポーネント（LWCやAuraコンポーネント）のコードを修正・保存すると、サイト自体を「公開」しなくても、その変更が即座に本番サイトに反映されるケースが多いということです（※設定変更などを除く）。

「コードを直したのに画面が変わらない？ あ、キャッシュか」といった経験はあっても、「サイトの公開ボタンを押し忘れていた」というケースは比較的少なかったかもしれません。

LWRサイトの「静的」な挙動（フリーズ）

一方で、LWRサイトはパフォーマンスを極限まで高めるために、新しい公開パラダイムを採用しています。

ドキュメントにはこう記載されています。

LWR sites take advantage of a new publishing paradigm, where components are frozen at publish time and served statically at runtime. （LWRサイトは、公開時にコンポーネントが凍結（フリーズ）され、実行時には静的に配信されるという新しい公開パラダイムを採用しています。）

ここが最大のポイントです。LWRサイトでは、標準コンポーネント、カスタムコンポーネント、管理パッケージのコンポーネントなど、あらゆるリソースが「公開ボタンを押した瞬間」の状態で固められます。

開発フローへの影響：必ず「公開」が必要

このアーキテクチャの違いは、日々の開発フローに直結します。

• Auraの場合: コンポーネントの修正 → （即時反映） → ブラウザリロードで確認
• LWRの場合: コンポーネントの修正 → エクスペリエンスビルダーで「公開」 → ブラウザリロードで確認

LWRでは、たとえ些細なバグ修正であっても、サイトを公開しない限り、その変更はエンドユーザーに届きません。 「コードはデプロイしたのに直っていない！」と焦ったときは、まず間違いなくエクスペリエンスビルダーでの「公開」忘れが原因です。

なぜこの仕様なのか？

「毎回公開するのは面倒だ」と感じるかもしれませんが、これには明確なメリットがあります。それがパフォーマンスです。

コンポーネントを静的なリソースとしてコンパイル・配置することで、サーバーサイドでの動的な処理を減らし、CDN（コンテンツデリバリネットワーク）などを通じて爆速でユーザーに画面を届けることが可能になります。LWRサイトの軽快な動作は、この「事前ビルド・静的配信」によって支えられているのです。

まとめ

• Auraサイト: コンポーネントは動的。コード修正は即時反映されることが多い。
• LWRサイト: コンポーネントは公開時に静的化（フリーズ）される。変更には必ずサイトの「公開」が必要。

これからLWRサイトを扱う際は、「コードを変えたらサイトも公開」を合言葉に開発を進めていきましょう。

参考URL

New Publishing Model for LWR Sites