The Short Answer
Poor Salesforce performance is a cumulative symptom: a Record Page with 14 components, three automations running on the same Save, a query scanning a million records, and an integration pulling data during peak hours. The only way to improve without wasting budget is to measure by layers, identify the dominant layer, and address it—then measure again.
The Five Layers and What to Measure in Each
| Layer | Typical Symptom | Measurement Tool | Common Solution |
|---|---|---|---|
| Browser and Network | Slowness only for some users | Lightning Usage App per user | Organizational latency, browser version, VPN |
| Screen and Components | High EPT on a key record page | EPT per Page, Debug Mode | Reduce components, lazy loading, Tabs |
| Automation | Slow Save, Timeout on bulk updates | Debug Logs, Flow Interviews | Consolidate Flows, move to asynchronous |
| Data and Queries | Reports crashing, List View stuck | Query Plan, Apex Jobs | Selective filtering, Index, archiving |
| Integration | Load peaks at regular hours | Event Monitoring, API Usage | Bulk API, execution windows, Throttling |
Working with Large Data Volumes
Above approximately one million records in an Object, the rules of the game change. Data Skew—for example, 200,000 Accounts linked to the same Owner or Parent—creates row locks and slows down any bulk update. The solution is to distribute ownership, not to add hardware, which is beyond your control anyway. Simultaneously, consider archiving: closed records from five years ago that no one reads make every scanning query more expensive.
Screens: Less is Faster
The average Record Page in an established organization accumulates components at a rate of two to three per year, because every stakeholder requests "just one more widget." Each Lightning component makes its own calls. Two actions yield the most significant gains: moving secondary components to separate Tabs that load only on click, and applying Component Visibility based on Record Type or role, so users only see what's relevant to them. Combining both reduces EPT by tens of percentages without code changes.
The Action Sequence That Works
Start with a week of measurement without changes to establish a reliable Baseline for five key screens and three key processes. Then, address the screens—this is the cheapest and fastest. In the third phase, consolidate automations by Object, and only in the fourth phase, touch queries and the data model. Integrations are handled concurrently if measurements show them to be the cause.
The logic behind this order is economic: the first layers are cheap and reversible, the later ones are expensive and require regression testing. More details on this topic can be found in Salesforce Health Check and Signs You Need a System Upgrade.
Common Risks and Preventive Actions
The biggest risk is optimization without a Baseline: You make ten changes, users still complain, and there's no way to know what helped. Measuring before and after every significant change is a prerequisite, not a luxury.
A second risk is addressing the loudest symptom. The screen most complained about isn't necessarily the slowest—sometimes it's just the one opened most often per day. A third risk is changing automations without test coverage: consolidating Flows is the action with the highest potential for silently breaking business logic.
How to Measure Success
Four metrics are sufficient: average EPT on the five key screens, Save time for the main business process, number of Timeout and Governor Limit failures per month, and the percentage of queries taking over five seconds. A fifth metric—supplementary and non-technical—is the number of performance complaints in the Service Desk, which should decrease with actual improvements.