Salesforce usually feels slow for one of a handful of reasons. Record pages carry too many components, or automation stacks up on every save. Reports scan more data than they need. Data volumes grow very large or lopsided, integrations compete for the same records, or the user's own browser and network struggle. Occasionally it is a Salesforce service incident. The fix depends on which symptom you see, so diagnose before you change anything.
Is it Salesforce itself, or is it our org?
Check the Salesforce Trust site at status.salesforce.com first. If your instance shows an incident or degradation, the slowness is on the platform side and your team cannot fix it.
Find your instance name under Setup, in Company Information, then look it up on Trust. A platform problem tends to hit everyone at once, across every page, with no obvious pattern. A problem in your org tends to cluster: one object, one page, one team, one time of day or one kind of action. If Trust is green and the pain clusters, keep reading. If Trust shows a problem, note the incident number, tell users, and wait for it to clear before you start redesigning anything.
What should we measure before we fix anything?
Pin down which action is slow, for whom, and by how much. Without a baseline you cannot tell whether a change helped or simply moved the delay somewhere else.
- The exact action: opening a record, saving it, running a report, searching or loading a list view.
- Who is affected: everyone, one profile, one region, or one person on one laptop.
- When it happens: all day, at month end, or while a nightly sync is running.
- A stopwatch time for the same action on the same record, repeated several times.
- Experienced Page Time (EPT) where you can see it; the Lightning Usage App reports page load data for many orgs.
- Debug logs for slow saves, which show each flow, trigger and validation rule that ran and how long it took.
- Any error text users see, especially messages about row locks, timeouts or CPU limits.
Write these down in a short shared sheet. It becomes the evidence for which fix to try first, and the yardstick for whether it worked.
How do the symptoms map to causes?
Most complaints fall into a few patterns. Use the table to narrow the likely cause, then confirm it before you change anything.
| Symptom | Likely cause | How to confirm | Typical fix |
|---|---|---|---|
| Record page takes a long time to open | Too many components, tabs or related lists on one Lightning page | Run the page analysis in Lightning App Builder; compare EPT across pages | Move secondary content into tabs, trim related lists, split by record type |
| Save spins, then succeeds slowly | Several flows, triggers and rules firing on one object, sometimes repeatedly | Debug log of a single save, filtered to workflow and Apex | Consolidate automation per object, add entry criteria, stop re-entry |
| Save fails with a lock error | Integration or batch job updating the same parent records | Error text mentions locking; timing matches a sync window | Reschedule or batch the job differently, reduce parent contention |
| Report runs for ages or times out | Broad report type, no date filter, cross-object filters over large tables | Rerun with a narrow date range and compare | Add selective filters, simpler report types, scheduled snapshots |
| List view or search is sluggish | Filters on non-indexed fields, huge record counts, wide sharing | Test the same filter on a smaller subset | Filter on indexed fields, archive old records, review sharing |
| One user slow, others fine | Browser, extensions, device or network | Run the Salesforce browser speed test on that machine | Supported browser, fewer extensions, check the network path |
| Slow after an app install | Managed package adds components, triggers or callouts | Compare timing before and after; check the package's own logs | Configure or disable package features, ask the vendor |
Why do our record pages load slowly?
Usually because each page is asking for too much at once. Every component, related list and embedded report adds work for the browser and the server.
Lightning record pages invite accretion. Someone adds a chart, someone else adds three related lists and a custom component that calls an outside system. Each piece seemed small when it went in. Open the page in Lightning App Builder and use its built-in performance analysis, which flags heavy components and suggests changes. Salesforce has renamed and reshaped these Setup tools over time, so confirm what your edition shows.
- Put rarely used content behind tabs or accordions, so it loads only when someone opens it.
- Cut related lists to the ones people actually use, and show fewer rows in each.
- Use dynamic forms and component visibility rules, so each audience sees only its own fields.
- Question any component that calls an external system on load; that call sits in the critical path.
Why does saving a record take so long?
A slow save almost always means a lot of automation runs behind that one click. Flows, Apex triggers, validation rules, roll-ups and sharing recalculation all happen before the user gets control back.
The worst cases involve layers built by different people in different eras. A legacy Workflow Rule updates a field, which wakes a Process Builder, which fires a record-triggered flow. That flow updates the parent, whose own automation updates the children again. That loop is recursion, and each pass adds time and burns governor limits. Pull a debug log for one slow save and list everything that ran, in order. The length of that list is usually the answer.
The fix is consolidation. Aim for one clear entry point per object and timing, plus entry conditions that skip records needing no work. Use before-save flows for simple field updates. If old Workflow Rules and Process Builder are still in the mix, note that Salesforce ended support for both on December 31, 2025; our guide on moving them to Flow covers the migration itself.
Why are our reports and dashboards slow?
Reports slow down when they ask the database to scan large tables with loose filters. Dashboards inherit that, because each component runs its source report.
Common culprits are report types joining several objects and reports with no date range or an "All time" range. Filters using "contains" on text fields hurt too, as do cross filters over very large tables. Row-level formulas and bucket fields add work too. Try narrowing the date range and switching to "My" records instead of all records; if speed returns, you have found the pressure point. For dashboards, check how many components each one holds and whether they all need to refresh live. Some reporting is better served by scheduled refreshes or reporting snapshots that store results once.
Why are list views and global search sluggish?
List views filter data on the fly, so filters on fields Salesforce cannot use efficiently force a broad scan. Search can lag when indexes are catching up on large data loads.
Filters on standard indexed fields, such as record owner, created date or record type, perform better than filters on formula fields or long text. Admins can check a query's selectivity with the Query Plan tool in the Developer Console. Very complex sharing models also add work to every list, because Salesforce must check what each user may see. Search results can lag right after a big import while the index catches up; that usually settles on its own.
What are large data volumes and data skew?
Large data volume means some objects hold millions of rows. Data skew means too many child records are crowded under one parent, or too many records belong to one owner.
Account data skew is common with a catch-all record, such as an "Unknown Customer" account holding a huge number of contacts or cases. Each time a child record changes, Salesforce may lock that one parent, so busy users and integrations queue behind each other. Ownership skew is the same idea applied to owners. One integration user or departed employee owns a vast number of records. Sharing recalculation then gets heavy whenever roles or rules change. Salesforce's own guidance warns once a parent or owner passes roughly 10,000 records; confirm the current threshold in its large data volume documentation.
- Spread catch-all children across several parent records, or drop the parent link where it adds nothing.
- Assign integration-owned records to several owners, or place that owner outside the role hierarchy.
- Archive or delete records nobody needs online, following your retention policy.
- Ask Salesforce support about custom indexes for fields you filter on constantly.
Can integrations make Salesforce slow for users?
Yes. A sync job updating thousands of records competes with users for the same rows, and its automation fires on each update just as theirs does.
Look for timing patterns. If saves fail with locking errors at the top of each hour, check what syncs then. Setup's System Overview shows API usage against your daily allowance, though running out of API calls stops integrations rather than slowing users down. The usual fixes are smaller batches and records sorted by parent before loading. Run heavy jobs outside business hours, and bypass automation the integration does not need.
Could it be the user's browser, device or network?
If one person or one office is slow while others are fine, start there. Lightning Experience does a lot of work in the browser, so older machines and crowded browsers feel it most.
Salesforce publishes supported browser and hardware recommendations for Lightning Experience; check the current list in its help documentation. It also offers a browser speed test, reached at /speedtest.jsp on your org's Lightning domain, which reports an Octane benchmark score. Treat the exact URL as something to confirm for your org. Beyond that, check for heavy browser extensions, VPN routing that sends traffic the long way, and old laptops shared across too many open tabs.
Do managed packages and AgentExchange apps add overhead?
They can. Packages bring their own triggers, flows, components and callouts, and you cannot see inside all of their code.
If slowness started after an install or upgrade, compare timings before and after. Debug logs show which namespace is consuming time on a save. Many packages offer settings to switch off features you are not using; the vendor's support team should be able to say which. Removing an unused package is often the cleanest fix, after checking what data or automation depends on it.
When should we bring in outside help?
When the cause spans several layers, or nobody on the team can read debug logs with confidence. Slow orgs usually have more than one problem, and the fixes interact.
A structured review lines up the measurements, the automation map and the data distribution side by side, then ranks fixes by effort and risk. That is the core of our Salesforce optimization work. If the root issue is years of accumulated build, see our guide to reducing technical debt as well.
