Not verified hands-on. This article was written from primary documentation rather than reproduced in an org, so it carries no tested-release badge. If you run it and something differs, say so in the comments and it gets tested and corrected.

A slow record page is usually slow because of how many things it asks the server for, not because of how much is on screen. Every component with its own Apex controller is a round trip, every related list is a query, and a Visualforce page embedded in an iframe is an entire second page load inside the first. Run the Analyze tool in the Lightning App Builder before you start guessing, because it tells you which of those you have too many of.

Start with Page Analysis

The App Builder has an Analyze option that inspects the page you are editing and reports on what is known to cost time: component count, field count, related lists loaded, and components flagged as expensive. It is free advice from the platform about the platform.

Treat its output as a list of suspects rather than a verdict. It cannot see how expensive your Apex is or how much data a given user has, and both matter more than component count on a badly built page.

Too many components

Each custom component that calls Apex issues its own request. Ten components means ten requests, which the browser runs concurrently against limits you do not control, and the page is not usable until the slowest one returns.

Three things help, in descending order of effect.

  • Remove components. The most reliable optimisation is deleting the thing nobody looks at. Ask which components users actually read before assuming they all earn their place.
  • Use tabs and accordions. Components inside an inactive tab are not rendered until that tab is opened, so heavy content below the fold costs nothing on load.
  • Mark controllers cacheable. A method annotated @AuraEnabled(cacheable=true) can be served from the client cache on the next visit. Without it, every navigation back to the record pays full price.
@AuraEnabled(cacheable=true)
public static List<Contract> activeFor(Id accountId) {
    return [SELECT Id, ContractNumber, EndDate FROM Contract
            WHERE AccountId = :accountId AND Status = 'Activated'
            ORDER BY EndDate DESC LIMIT 20];
}

Also prefer Lightning Data Service over Apex where the data is a record you can name. Two components reading the same record through LDS share one fetch. Two components reading it through separate Apex methods do not.

The cost of a related list

A related list is a query, and the page runs one per list. Twelve related lists on an Account layout means twelve queries before the user has clicked anything, several of which will return nothing on most records.

The number of related lists is still governed by the page layout even when the page uses Dynamic Forms, so this is a layout exercise. Cut the list down to what people use, reduce the columns on the ones that survive, and consider the Related Lists Single component for the two or three that genuinely matter rather than rendering the full set.

The rest of the usual suspects

  • Embedded Visualforce. An iframe with its own page lifecycle, its own controller and its own view state. Replace with a Lightning web component where you can.
  • Report charts. Each one runs a report. They are useful and they are not cheap. Two on a record page is usually one too many.
  • Managed package components. You cannot optimise them, but you can decide not to put four of them on your busiest page.
  • Visibility rules at scale. Hundreds of individually placed fields each carrying a rule adds up. Put the rule on the section.

Measure like the user, not like an admin

Test as a real profile with real data volume. An Account with three contacts tells you nothing about the same page on an account with four thousand. Watch the browser’s network panel: the count and duration of the framework requests are the whole story on most pages.

The Lightning Usage App gives you aggregate page timings across the org, which is the right tool for finding out which page to look at first.

Frequently asked

Does hiding a component with a visibility rule make the page faster? Yes, for users the rule excludes. A component that does not render does not call its controller, which makes visibility rules a genuine performance tool as well as a tidiness one.

Is a one-column page faster than a three-column one? Not meaningfully. Layout arrangement is rendering, and rendering is rarely the bottleneck. The number of server calls is.

Should I combine several components into one? Often yes. One component making one Apex call for everything the page needs beats four components making four, at the cost of reusability.

Why is the first load slow and the second fast? Framework resources and cacheable Apex results are cached client-side after the first visit. Optimise for the cold load, because that is the one a new user experiences.