Lightning Experience Performance & Page Architecture

A Lightning record page is a dependency graph—not a layout

JSBC Labs3 November 20268 min read

A tidy canvas can still be an expensive page

Lightning App Builder makes composition feel visual: place a record detail, add related lists, drop in custom components and align everything into tabs. The resulting page can look disciplined while initiating a wide dependency graph of record reads, metadata requests, related-list queries, Apex calls, component rendering and client-side state. Users experience the combined graph, not the elegance of the canvas.

The JSBC Labs position is that a record page is a runtime architecture. Every element should justify the work it adds to the initial interaction. Salesforce identifies visible component count, heavy related lists and large Record Detail configurations as common page-performance risks. Treat those warnings as design feedback: the page is loading too much of the business domain before the user has expressed intent.

Design the first screen around the next decision

Start with the user's most frequent decisions, not the object's complete schema. A service agent opening a Case may need status, entitlement risk, recent contact, the next action and a small set of controls. They do not need every historical list, administrative field and diagnostic component before they can read the subject. Progressive disclosure makes the page faster because it also makes the task clearer.

Create an explicit initial-load budget: essential components, essential fields and permitted data requests. Move secondary investigation, reporting and administration into non-default tabs, accordions or actions. Salesforce documents that components in non-default App Builder tabs and Accordion sections are excluded from Performance Analysis, reflecting their deferred role. Accessibility still matters, so validate that deferral does not make important information difficult for keyboard, screen-reader or low-vision users to reach.

Map component cost before optimising code

Inventory every standard component, managed package, Visualforce surface, Flow and custom LWC on the page. For each, record when it instantiates, which fields or lists it requests, whether it calls Apex, what metadata it loads and whether another component requests the same information. This exposes duplicate fetches and hidden coupling that are invisible in App Builder.

Use the Analyze action in Lightning App Builder as an early guardrail, then test by removing one component at a time to isolate expensive branches. Salesforce's troubleshooting guidance recommends this process of elimination. Do not rewrite an LWC first simply because it is custom: a standard related list with broad relationships, an oversized Record Detail or an embedded legacy page may dominate the load. Optimise the measured branch, not the most politically convenient component.

Make the page share a data contract

Independent components should not become independent data silos. Lightning Data Service caches and shares record data across components, deduplicates requests and progressively loads fields. Components using the same record can therefore reuse a managed client cache instead of each issuing a bespoke Apex query. UI API also applies CRUD, field-level security and sharing to its responses.

Use LDS or UI API where the object and interaction are supported, and request only the fields each component needs. When Apex is necessary, consolidate truly shared reads behind a deliberate page-level service or cacheable contract rather than several near-identical controllers. Avoid requesting an entire layout merely to obtain a few fields; admin changes can expand that payload without a code change. A component's data contract should be explicit enough to measure and stable enough to govern.

Defer work; do not merely hide it

Visual absence and runtime deferral are not always the same thing. Place occasionally used components in containers that Salesforce documents as lazily instantiated, such as non-default tabs, or load them through actions when the user asks. The official LWC performance guidance recommends lazy-loading data a user may never need. Confirm the behaviour in the actual host, because console workspace tabs and App Builder tabs do not have identical loading semantics.

Inside custom components, fetch secondary data only when its region becomes active. Paginate collections, cap query results and avoid loading large option sets for closed panels. Conditional rendering should follow a meaningful state or user action, not trigger a chain of server calls immediately after the first paint. Deferral succeeds when it removes work from the common path, not when it shifts the same workload a few milliseconds later.

Treat details and related lists as budgets

Record Detail can quietly inherit every field on a page layout, including fields rarely used by the persona viewing the Lightning page. Salesforce recommends reducing large layouts and specifically flags pages with many detail fields. Dynamic Forms or focused related-record components can expose a smaller working set, but splitting fields into decorative sections does not help if every section and field still participates in the initial request.

Related lists multiply cost through row retrieval, relationship complexity, actions and rendering. Put the one or two lists that drive the next decision on the primary surface and defer the rest. Prefer Related List—Single or quick links when they express the real task better than a full collection. Set a row and column budget, then test with records that have production-scale children; an empty sandbox account is not a performance test.

Measure the population, not one developer laptop

Salesforce measures Lightning interaction with Experienced Page Time, the time until a page is meaningfully interactive. The Lightning Usage App identifies heavily used and slow desktop record pages, while Lightning Experience Insights includes P75 EPT so teams can see the slower experience affecting a meaningful portion of users. Those population measures are more useful than a single fast load after the browser cache is warm.

Segment results by page, browser, device, app and persona. Console navigation can reuse open tabs and make averages appear faster than first-time loads, while geography, network and virtual desktops can expose different bottlenecks. Test from representative locations and hardware with production-shaped records. Keep secure browser caching enabled in production unless policy requires otherwise; Salesforce warns that disabling it has a significant performance impact.

Govern the dependency graph as the page evolves

Record pages accumulate because each request is locally reasonable: one more score, list, banner or helper. Establish page ownership and performance budgets for initial components, server trips, fields, related-list volume and P75 EPT. Require an existing dependency to be removed or deferred when a new one consumes the budget. Activation by app, record type and profile should reflect genuinely different work, not copy the same overloaded page into more variants.

Include App Builder analysis, representative EPT testing and critical-task checks in release validation. After deployment, watch usage to confirm that deferred areas are actually used; retire components that add cost without supporting decisions. The goal is not the smallest possible page. It is a page whose initial dependency graph matches the user's next action, whose secondary work is intentionally deferred and whose performance remains measurable as the org changes.