_How Lightning Web Runtime affects page performance, component development, and migration planning. _
A Salesforce Experience Cloud site can serve many purposes, from a customer support portal to an online store where distributors manage their orders. Whatever the use case, users expect pages to load quickly and the information they need to be easy to access.
The technology behind the site plays a part in that experience. Salesforce has traditionally used the Aura framework for Experience Cloud, but Lightning Web Runtime (LWR) provides a different approach to building and delivering websites and storefronts.
For organisations planning a new site or considering a move from Aura, it's useful to understand what LWR changes and what remains the responsibility of the development team.
What is Lightning Web Runtime?
Lightning Web Runtime (LWR) is a Salesforce technology for building and delivering web applications using Lightning Web Components (LWC).
Within Experience Cloud, LWR powers templates such as Build Your Own (LWR) and Microsite (LWR). Developers can create components using familiar web technologies, including HTML, JavaScript, and CSS, then configure them through Experience Builder.
The component model is an important distinction. Standard LWR-based Experience Cloud sites use Lightning Web Components. React and Angular aren't interchangeable alternatives within these templates, although Salesforce supports other frontend development approaches separately.
LWR also changes how the site delivers its components to visitors. Instead of loading everything dynamically, it prepares resources that can be cached and reused, reducing the work required when someone opens a page.
Why can LWR perform better than Aura?
The main difference comes from how the two runtimes deliver page resources.
In an Aura-based Experience Cloud site, Lightning components are delivered dynamically. LWR uses a publishing model in which components are prepared and served as static, cacheable resources.
These resources can also be delivered through Salesforce's content delivery network (CDN). By storing eligible files closer to users, the CDN can reduce the time needed to retrieve them.
That doesn't mean an LWR site displays only static information. Product details, customer records, and prices can still be retrieved from Salesforce when needed. How quickly updated information appears depends on the application's data access and caching configuration.
Salesforce describes LWR as a foundation for high-performance sites, but faster loading isn't guaranteed. Large images, unnecessary API requests, and poorly designed custom components can still cause delays.
For example, an ecommerce page might load its layout quickly while taking several seconds to display account-specific prices from an external system. In that situation, improving the integration may have more impact than changing the storefront technology.
LWR vs Aura: the differences worth knowing
Both technologies support Experience Cloud, but they differ in several ways.
Component development: Aura-based sites support Aura components and Lightning Web Components. Standard LWR templates use LWC, making the supported component model more consistent.
Publishing: Changes to component code can become available on an Aura site without republishing. In LWR, the site needs to be republished when updated standard, custom, or managed components should become available to visitors.
Available functionality: Aura has an established collection of templates and components. LWR provides lightweight templates and customisation options, but not every feature available in Aura has a direct equivalent.
These differences matter particularly when an organisation already has a customised portal.
A team might have invested considerable development effort in Aura components that support complex business processes. Moving to LWR would require reviewing those components, identifying suitable replacements, and testing the updated functionality.
For a new site, the decision may be simpler. LWR is a natural starting point when its templates and supported capabilities meet the project's requirements.
Salesforce maintains documentation covering LWR template limitations, which is worth reviewing before choosing an architecture.
When should you use LWR?
Salesforce recommends LWR for new B2B Commerce storefronts and encourages organisations with existing Aura-based B2B stores to consider migration.
LWR also works well for many custom Experience Cloud websites and portals, especially when teams want flexibility in component development and control over page performance.
Consider a manufacturer building a distributor portal. Buyers may need to browse products, access negotiated prices, and place orders. LWR can provide the storefront architecture, while Salesforce Commerce components and APIs support the relevant business processes.
An existing Aura portal needs a different assessment. If it already meets user requirements and depends on functionality that isn't supported in LWR, migration may not be the immediate priority.
The decision should consider the functionality the organisation needs, the effort involved, and what improvements the new architecture is expected to provide.
What does an Aura-to-LWR migration involve?
Migrating to LWR doesn't necessarily mean rebuilding every component.
Many Lightning Web Components developed for Aura-based sites can work in LWR without changes or with relatively small adjustments. Aura components, however, need to be replaced or redesigned using LWC.
Other changes may involve navigation, styling, component metadata, and data access. For B2B Commerce, storefront configuration also needs to be transferred and validated.
A sensible starting point is to review the existing site's components and dependencies. This helps establish which parts can be reused and which require additional development.
Testing should cover the complete user experience, including data access, permissions, navigation, and the business processes supported by the site.
The same principles apply to any Salesforce implementation: understand the requirements, assess the existing solution, and test changes before releasing them.
It's also important to distinguish an Aura-to-LWR migration from moving an older CloudCraze store to modern B2B Commerce. CloudCraze uses a different commerce architecture, so the project can involve broader changes to data and business logic. Our guide on moving off CloudCraze explains those considerations.
How do you know whether LWR is improving performance?
Performance improvements should be measured rather than assumed. For an existing site, record baseline results before migration and compare them with the new implementation. Test equivalent pages and user journeys under similar conditions.
Tools such as Google Lighthouse and WebPageTest can help identify slow-loading resources and other performance issues. Core Web Vitals provide additional measures of loading performance, responsiveness, and visual stability.
Testing can also reveal problems unrelated to the runtime. A slow API response, oversized image, or external script may affect the experience regardless of whether the site uses Aura or LWR.
Salesforce's Commerce storefront performance guidelines provide more detailed recommendations for LWR implementations.
Final thoughts
Lightning Web Runtime gives Salesforce developers a modern architecture for Experience Cloud sites and B2B Commerce storefronts. Its publishing and caching model can improve page delivery, while Lightning Web Components provide a reusable way to develop custom functionality.
For new B2B storefronts, LWR is the recommended Salesforce approach. For existing Aura sites, migration should begin with an assessment of current components, requirements, and expected benefits.
If you're planning a new Salesforce site or reviewing an existing implementation, explore Spyrosoft's Salesforce services to learn more about architecture, development, and migration support.
Originally published on the Spyrosoft blog. Read the full article: Levelling up your webstore with Lightning Web Runtime.
Top comments (0)