Why your Salesforce org feels slow, and what actually fixes it

The ticket says Salesforce is slow. It arrives with no page name, no time of day, no user and usually no record, and by the time it reaches anybody technical it has been repeated in a meeting by somebody senior, which gives it a weight it has not earned. The reflex is to start optimising.

That reflex is the problem. Slowness on this platform is a symptom shared by several causes with almost nothing in common. A record page rendering twelve components is slow for reasons that have no relationship to a report scanning a large object, which in turn has nothing to do with a laptop routing every response through a corporate proxy. Teams optimise the cause they can name fastest, which is usually automation, because automation is visible and somebody changed it recently.

#"Salesforce is slow" is not a finding

The complaint compresses at least five different experiences into one sentence. Opening a record page. Loading a list view. Running a report. Saving a change and watching the spinner. Searching. Each exercises a different part of the platform and each fails in its own way.

So the first job is not technical. It is turning a sentence into a finding, by asking a short set of questions and refusing to move until they are answered.

• Which page, exactly, and on which record.
• What action: opening it, saving it, filtering it, running something from it.
• Which user, and does it happen for the colleague sitting next to them.
• Every time, or at particular times of day, or only at month end.
• Since when, and did anything ship around then.

The answers usually collapse the problem into something specific and much smaller. One team, one page. One report, one week a month. That is a finding. Everything before it was an anecdote, and an anecdote will send you optimising a surface nobody was complaining about.

#Get evidence rather than anecdote

There is enough tooling here that guessing is a choice. Work outward from the cheapest.

Lightning Usage App reports page performance across the org, broken down by browser, and surfaces the slowest record pages. It is the quickest way to learn whether the complaint is one page or many, and whether one browser is over-represented, which is a strong hint that the cause sits on the client rather than in the org.

Org Check produces a configuration-level view: layouts, fields, automation and the accumulated weight nobody has removed. It does not measure a specific page load, but it reliably identifies the objects and pages that have been added to for years without anything being taken away. If you are following older guidance that names Salesforce Optimizer, that app was retired in Winter 26 and Org Check is where this analysis now lives.

Event Monitoring, part of Salesforce Shield, gives per-event detail for page views, report runs, API calls and more. Where it is licensed, it is the only tool that answers questions about a specific user at a specific time rather than about aggregates.

Browser developer tools cover everything the platform cannot see: the network waterfall, extension interference, and time spent on the client rather than waiting on a server.

Take the measurement before you change anything, and keep it. A performance fix with no baseline is an opinion, and opinions revert quietly.

#Symptom, cause, measurement, fix

The right-hand column is where the work goes. The third column is what earns you the right to do it.

#Record pages: the cost is the components, not the layout

A Lightning record page is not one request. Each component fetches its own data, and the page is finished when the slowest of them is finished. Related lists query. Report charts run a report. A custom Lightning web component calling an Apex method is a server round trip. A component from a managed package is a round trip you cannot profile.

This is why the page layout is rarely the culprit and the page composition usually is. Rearranging fields changes almost nothing. Removing four components changes a great deal.

Record pages get this way honestly. Every request over three years was "can you just add a component for us", each one individually reasonable, and nothing was given a removal date. The result is a page serving eight audiences and optimised for none of them.

Three moves are worth making, in order. Count the components, and for each one name who reads it and how often. Move anything genuinely occasional onto a secondary tab, since components on a tab that is not open are generally not fetched until the tab is opened, which is worth confirming by measuring in your own org rather than taking on trust. Then use Dynamic Forms in Lightning App Builder so fields appear conditionally, instead of every user seeing every field on every record type.

After that, remove things one at a time and measure again. Removing five components at once produces an improvement you cannot attribute, and an unattributable improvement gets undone by the next person who wants a component added.

#List views and reports, and why filters behave differently at scale

A filter either narrows the set before the data is read, or it does not. That single distinction explains most of the difference between a report that is fine and a report that is not, and it becomes visible only once the object is large. On a small object every filter looks equally good, which is exactly why this fault ships.

Some fields are indexed by default, among them the record Id, Name, owner, created date, the system modification timestamp, record type, and lookup and master-detail relationship fields, along with any field marked as an external ID or as unique. Filters on those can narrow early. Filters on other fields cannot, unless an index has been added for them.

Several common filter shapes cannot use an index at all. Leading wildcards in a text search. Negative operators, where the filter describes what a record is not. Comparisons against null on a field with no index behind it. Filters on formula fields whose inputs are not themselves indexed. None of these are wrong, and all of them are fine on a modest object. They are the reason a report that was acceptable two years ago is not acceptable now, while nothing about the report itself changed.

Where a filter genuinely has to run against an unindexed field at volume, the remedy is a custom index, and it is worth being accurate about what that involves. Custom indexes are requested through Salesforce Support, not enabled from Setup. So are skinny tables, which hold a set of frequently used fields and avoid a join that would otherwise happen on every query. Both are legitimate and both are effective. Neither is something you can try on a Thursday afternoon, so both belong in a plan, with the query pattern written down before the case is raised.

#Large data volumes are a distinct problem class

At a certain size an org stops having performance bugs and starts having a volume characteristic. The distinction matters, because the fixes differ in kind: you are no longer correcting a mistake, you are managing an amount.

Four things genuinely help, roughly in order of what they return for the effort.

Reduce what is queried. Narrower list views, fewer columns, tighter default date ranges on reports, dashboards that do not recalculate everything for everybody. Most orgs have at least one report that scans the whole of a large object to answer a question about this quarter.

Index what is filtered. Get the query patterns written down first, then take them to Salesforce Support as a case with evidence, rather than as a request for an index on a field.

Archive what nobody reads. Records from closed years are still traversed by every unfiltered report. Moving them into Big Objects keeps them retrievable, with Async SOQL available for querying that data in the background, without leaving them in the path of everyday work.

Partition the data. Divisions segment an org's data so that queries and reports operate over a subset. They carry real consequences for reporting and for users, and they are enabled by Salesforce rather than by you, so this is a design decision and not a tuning knob.

Two structural problems sit underneath all of it. Ownership skew, where one user or queue owns a very large share of records, makes sharing recalculation expensive. Data skew, where one parent record has an unusually large number of children, does something similar. Both degrade quietly, both worsen with growth, and both are far cheaper to prevent than to unwind, which is one reason they appear in the data model decisions you cannot cheaply undo.

#Automation, briefly

Automation on the save path is a real cause of slowness, and it is the one most teams reach for first precisely because it is the most visible. It is also the one covered in full elsewhere: how to tell a slow flow from a slow transaction, why single-record testing never finds the fault that matters, and what a debug log actually proves. If the complaint is specifically about saving rather than viewing, start at why your flow is slow and come back here once the save is accounted for.

#The client side, which gets dismissed too quickly

Every performance investigation reaches a point where somebody suggests the problem is the user's machine, and is not taken seriously, because it sounds like deflection. It is frequently true.

Browser version and browser extensions, particularly the ones a security team installed. Corporate proxies inspecting every response. VPN routing that sends traffic somewhere unhelpful before it reaches Salesforce. Virtual desktops with modest memory allocations. Machines on a four-year replacement cycle running a browser with forty tabs open. None of that is fixable in the org, and all of it presents to the user as Salesforce being slow.

The test is quick and it settles the argument. Same page, same record, in a clean browser profile with extensions disabled, then on a different network, then on a different machine. If it is fast in any of those, the org is not the thing to change, and continuing to tune it is wasted effort with a confident-sounding justification attached.

#The perception problem

A page that renders quickly and still makes somebody hunt for a field is experienced as slow, and they are not wrong. What people are timing is the task, not the paint.

The field they need sits in the fourth section. There are eleven related lists and the one they use is at the bottom. Two required fields on the layout stopped being required by the business in 2023 and nobody removed them, so every save is preceded by filling in something meaningless. Each of those costs seconds, repeated dozens of times a day, which adds up to more than most of the page load work anyone is arguing about.

None of it shows up in a performance tool. It shows up when you sit behind three people while they do the task they complained about and count what they touch. That exercise reliably produces a shorter list of higher-value changes than any amount of instrumentation, and it is also how the accumulated configuration nobody has audited comes to light, which is worth doing on a schedule rather than in a crisis: a technical debt audit you can run on your own org is the standing version of the same work.

#When the org is genuinely at the platform's limits

Sometimes the measurement comes back and nothing is wrong. The queries are selective, the pages are lean, the automation is clean, and the org is still slow because it is being asked to do something at a size it was not designed for.

That is a design conversation rather than a tuning exercise, and treating it as tuning is how a team spends a quarter achieving very little. The options are all projects: partitioning data, moving read-heavy analytics off the platform, revisiting the sharing model, splitting an object that has quietly accumulated several purposes, archiving aggressively into Big Objects, or accepting that a data model shaped for a smaller dataset now needs to change. Each carries a cost, and the honest work is putting those costs next to each other instead of continuing to look for a setting.

Whatever you find, change one thing and measure it with the method that found it. Then write down what the measurement showed, because the next person to hear that Salesforce is slow will otherwise start exactly where you started: with a sentence, and a guess.