The Case Page That Takes Nine Seconds
340 service agents work in a Lightning console split view on Case. p50 record page load is 9.2 seconds and p95 is 21 seconds; agents open about 60 cases a day each. The Case record page has 14 related lists, six of them filtered by owner and all showing eight columns; two of those related lists query objects with 3 million and 800,000 rows. Three custom components each call Apex on load and render a chart. Two lower components are marked for lazy loading but only render when a tab is clicked. The org is Enterprise Edition on a recent release. Legal says Settlement_Amount__c must be visible only to the Legal Reviewer profile, including in reports, list views, and the API.
1. Which three changes cut the most load time, and how do you know before you make them?
Read the worked answer
Measure first. Use the browser network waterfall plus Lightning Inspector (or Event Monitoring's Lightning Page View and Aura request metrics) to split server time from render time. If the wall clock is dominated by XHR latency and there are 17 parallel requests, it is a query problem; if the components come back fast and the paint is slow, it is a render problem. Guessing here produces a redesign that fixes the wrong half.
Most likely top three, in order of return:
- Related lists. Fourteen related lists are fourteen queries plus fourteen renders, two of them against objects with millions of rows. Reduce to the three or four agents genuinely use, cut to the two or three columns that matter, and move the rest behind a navigation to a filtered list view or a single on-demand component. Filtering by owner does not make a related list cheap - it still runs a query.
- The three on-load Apex components. Collapse them into one
@AuraEnabled(cacheable=true)call, or replace them withgetRecord/LDS where the data allows. Make the two below-the-fold components genuinely lazy (render on tab selection, wire only then) rather than "marked lazy" but wired on load. - Layout and payload size. Trim the page layout, and use Dynamic Forms where available to load only the sections in view. Confirm whether any component class is
without sharing, which changes both query cost and what the user can see.
Cheap wins to check too: pinned primary tabs in the console split view force full page renders.
2. How do you satisfy the Legal requirement, and why is a component visibility rule not enough?
Read the worked answer
Field-level security is the enforcement boundary. Remove Settlement_Amount__c from every profile except Legal Reviewer, and grant it back through a permission set so access is explicit, grant-based, and visible in the audit trail. FLS follows the running user through the UI, the API, list views, and reports - which is exactly the surface Legal named.
A visibility rule is cosmetic. Component visibility rules and Dynamic Forms visibility rules decide whether a field is rendered. The value still travels to the browser inside the record payload, is still returned by SOQL for any integration user with access, and is still filterable in a list view. An agent with devtools or a report can get at it. It is a layout tool, not a security control.
Two caveats worth stating out loud. First, admins can grant themselves permission sets, so if Legal means "hidden from admins too," FLS is insufficient and you need a separate object with a restricted sharing model (potentially with Platform Encryption for the value at rest). Second, if the field is referenced by a roll-up, formula, or validation rule, hiding it does not hide its effects - check what it feeds before declaring it sealed.