How do you architect Lightning pages for performance?

Lightning page composition affects render time directly. Architecture matters.

Composition guidelines:

1. Minimise component count.

Each component costs render time. 30 components = noticeable lag. Prefer 5-10 carefully chosen.

2. Use Standard components first.

lightning-record-form, lightning-datatable, lightning-card, etc. Salesforce-optimised; better than reinvented.

3. Lazy load.

Components in collapsed accordions / non-default tabs render only when shown. Use if:true gates with <template>.

4. Cache `@wire` data.

cacheable=true Apex methods. LDS for record data.

5. Tabbed layouts.

Default tab loads only its components; other tabs lazy-load on click.

6. Component-level filters.

Show/hide components based on user, record type, profile, criteria. Don't render what users don't need.

7. Reduce DOM size.

Long lists virtualised (lightning-datatable virtualises). 1000-item lists rendered manually = slow.

8. Static resources for heavy assets.

Images, JS libraries cached at CDN.

9. Avoid synchronous Apex on render.

@wire is async; no blocking render. Imperative Apex blocks; defer until user-triggered.

10. Optimise custom LWCs.

• Avoid heavy connectedCallback work.
• renderedCallback runs every render; keep tight.
• Memoize expensive computations.

11. Profile.

• Lightning Performance Analysis identifies slow components.
• Browser DevTools Performance tab.
• `performance.measure` for custom timing.

Component-level architecture:

• Container components — own state, fetch data.
• Presenter components — stateless, accept data via @api.
• Decoupled — easier to swap, test, optimise.

Standard vs custom:

• Standard tested at scale; usually faster.
• Custom needed for specific UX.
• Replace custom with standard when feature parity arrives.

Common pitfalls:

• Building a "dashboard page" with 20 components, each fetching independently. Cumulative latency dominates.
• Mobile not tested — what's fine on desktop crawls on phone.
• No performance budget — pages get slower with each iteration.

Architect role: define page composition standards, performance budgets, review process.

The senior insight: fast pages happen by design, not by accident. Without deliberate architecture, Lightning pages drift toward bloat.