Salesforce LWR Experience Cloud: A Candid Architect's Guide

Lightning Web Runtime is Salesforce's next-generation framework for building Experience Cloud sites. Unlike Aura-based sites that render components dynamically at runtime, LWR takes a fundamentally different approach by pre-compiling and caching static content during the publish process.

Core Promises of LWR

How LWR Achieves Performance

The fundamental architectural difference between Aura and LWR lies in when content is generated:

Why LWR is Faster

The performance gains in LWR are real and measurable - Salesforce's official positioning is sub-second page loads - stemming from several architectural decisions:

1. Static Content Generation - Pages are generated at build time, not runtime
2. CDN Distribution - CDN caching serves content from edge locations globally (Salesforce is migrating its CDN domains to Cloudflare during 2026)
3. Reduced Server Load - No dynamic component rendering per request
4. Optimized Caching - All static resources are HTTP cacheable with long TTLs

The same publish-time model now benefits OmniStudio: since Spring '26, OmniScripts and FlexCards are GA on LWR sites with a strong load-time lift - though the republish caveat applies to them too.

This is where marketing diverges from reality. Based on real-world implementation experiences with enterprise deployments (78,000+ members, 120+ audience segments), here are the limitations that will impact your architecture decisions:

1. Record Pages: No Generic Record Detail Page

Unlike Aura templates, LWR has no generic record pages. This means:

• Record-specific components (Record Detail, Record Header, Record Banner) can only be used on object-specific pages
• You cannot display record details on a regular site page like you could in Aura
• If you want a "My Account" page showing user account details, you must create an Account-specific object page
• Creating a generic record display component requires building complex custom LWC

2. Audiences vs. Visibility: A Fundamental Gap

Aura's robust audience targeting system is replaced by Visibility Rules in LWR, which is significantly more limited:

3. Page Variations: Gone

In Aura, you could create multiple variations of a page for different audiences. In LWR, there are no page variations.

• Different themes or layouts require completely separate pages
• If one affiliation needs a blue theme and another needs gold, you need two separate pages
• Navigation between these pages must be handled through custom logic, flows, or separate navigation items
• Aura's automatic page variation selection based on audience is not available

4. CMS Collections: Limited Content Type Support

• Announcements - Still cannot be displayed using standard LWR components (data binding only)
• News content type - Enhanced LWR templates now include a News Detail page, closing part of the original gap
• CMS workspaces - Since Winter '24, all CMS workspaces can publish to LWR sites
• Carousel component - Not available out-of-the-box; requires custom development

5. Navigation: Merge Fields Don't Work in URLs

This is a significant limitation that affects dynamic record navigation:

• Merge fields like {!User.FirstName} work for component content
• The same merge fields do not work in dynamic URLs
• Creating a "My Account" link that navigates to the user's specific account record requires custom workarounds

6. Missing Components and CSS Changes

• Carousel and some CMS display components are still missing (Record Detail, previously on this list, is now GA - see the update above)
• Site-wide CSS editor is not available
• CSS must be migrated to sfdc_cms__styles folder in DigitalExperienceBundle metadata
• Must use --dxp styling hooks for consistent branding

Component Migration

The most significant migration effort involves components:

• Aura components cannot run in LWR - Period. They must be rebuilt as LWC.
• LWC components may need modifications for LWR-specific features
• Out-of-the-box Aura components may not have LWR equivalents

URL Structure

• LWR sites don't use the /s/ URL segment by default
• Plan URL redirects carefully to preserve SEO and bookmarks
• Audit all internal and external links

Page Layout Conversion

• Convert to Flexible Layouts
• Plan for creating separate pages where page variations were used
• Design custom navigation logic for audience-specific pages

An honest 2026 addendum: since that feedback was recorded, the platform has matured substantially - the Record Detail component is GA, component variations are GA, OmniStudio (OmniScripts and FlexCards) is GA on LWR, and 16 standard components are available without a Community license - so re-run this decision framework against the current release rather than taking the 2025 verdict at face value.

For Audience Targeting

Implement a custom visibility solution:

1. Create component variations instead of page variations - now GA in enhanced LWR sites with up to 15 variations per component and priority ordering
2. Use Expression-Based Visibility (piloted Spring '23, now standard in enhanced LWR sites - note that pilot-era rules are no longer functional)
3. Build custom LWC that checks user attributes and conditionally renders content
4. Consider using Flows for complex audience logic

For Dynamic Navigation

1. Create intermediate redirect pages
2. Build custom LWC components that query record IDs via Lightning Data Service
3. Implement programmatic navigation using lightning/navigation API

For Missing Components

Develop a reusable component library:

• Generic Record Display component (for pages where the GA Record Detail component doesn't fit - for example, unsupported objects like Task)
• Custom Carousel component
• CMS Content Display for unsupported types (such as Announcements)
• Dynamic Navigation Menu component

1. Conduct a Thorough Assessment

Before committing to LWR migration:

• Inventory all Aura components in your current site
• Document audience segmentation requirements
• List all page variations and their purposes
• Identify CMS content types in use
• Map dynamic navigation requirements

2. Plan for Custom Development

Budget for building custom components to replace missing functionality:

• Generic record display components (where the GA Record Detail component doesn't cover your objects)
• Custom navigation solutions
• Carousel and content display components
• Visibility/audience management logic

3. Consider a Hybrid Approach

For large existing sites:

• Build new features on LWR
• Maintain existing Aura site for complex functionality (no Aura retirement date has been announced as of August 2026)
• Gradual migration as LWR matures with each release

4. Stay Current with Releases

Salesforce enhances LWR with each release. Key improvements to date:

• Enhanced CMS workspaces (automatically enabled from Winter '23)
• Expression-Based Visibility (piloted Spring '23, now standard in enhanced LWR sites)
• Component Variations - up to 15 per component, visibility-rule driven (GA)
• Record Detail and Record List (LWR) components (GA)
• OmniScripts and FlexCards GA on LWR (Spring '26)
• 16 standard components without a Community license (Spring '26)
• AI-assisted Self-Service components and GA malware scans (Summer '26)
• Partial deployment capabilities

5. Document Your Decisions

Create an Architecture Decision Record (ADR) documenting:

• Why you're migrating (or not)
• Known limitations and accepted risks
• Custom development requirements
• Timeline considerations