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.

Most slow Experience Cloud sites are slow for one of three reasons. The template is an Aura one when it could be LWR, the home page fires a separate Apex call for every component on it, or nobody has looked at the images. Fix those in that order. Caching helps, but caching a page that takes four server round trips to assemble only makes the second visitor’s experience tolerable, and the first visitor is the one who leaves.

Template choice is the biggest single lever

Aura-based templates such as Customer Service and Partner Central ship the Aura framework to the browser and assemble the page client-side. LWR templates render on the server and serve static assets through the CDN, and the difference on a first, uncached, mobile visit is not subtle.

You cannot convert an existing Aura site to LWR. It is a rebuild, which makes “we will move to LWR later” a sentence to be suspicious of. If the site is mostly public content with a small authenticated area, LWR is almost always right. If it depends on Aura-only features you cannot replace, you are staying where you are.

The caching layers, from outside in

  • The CDN. Switch on the Salesforce CDN for Digital Experiences in Setup. It serves static resources and, for public pages, cached HTML from an edge location rather than from your pod.
  • Public page caching. Anonymous pages can be cached for a configurable duration. Raise it as high as the content allows. A knowledge base that changes weekly does not need a sixty-second cache.
  • Platform cache. Apex results that are expensive and shared across visitors belong in an org cache partition rather than being recomputed per request.
  • The browser. Static resources get long cache lifetimes automatically. Anything you inject through head markup does not, unless you host it sensibly.

The guest user cache is a separate decision

Platform cache entries are not visible to guest users by default. If you want an anonymous visitor to benefit from a cached result, the entry has to be written into an org partition with visibility set to all:

Cache.OrgPartition part = Cache.Org.getPartition('local.SitePart');
List<Product__c> cached = (List<Product__c>) part.get('featured');
if (cached == null) {
    cached = ProductSelector.featured();
    part.put('featured', cached, 3600, Cache.Visibility.ALL, true);
}

Two cautions. Everything you put there is readable by every anonymous visitor, so it must contain nothing user-specific. And the immutable flag matters: an immutable entry cannot be overwritten by another request, which is what you want for reference data and wrong for anything that changes.

Images

This is where the easy wins are, and it is the part nobody is assigned. A marketing team uploading a 3000-pixel hero image into a component that renders it 600 pixels wide is the single most common cause of a slow home page.

Use Salesforce CMS image content rather than raw asset files where you can, because CMS serves resized variants suited to the requesting device. Set explicit width and height so the browser reserves space and the page stops jumping. Compress before upload, not after complaint.

What else makes a site slow

  • Component count on the landing page. Each custom component with its own Apex controller is a server round trip. Ten components, ten trips, executed in parallel against the same concurrent request limits.
  • Uncacheable Apex. A method without cacheable=true cannot be served from the Lightning Data Service client cache, so every navigation re-fetches it.
  • Third-party scripts in head markup. Analytics, chat widgets and tag managers are render-blocking unless loaded asynchronously.
  • Audience rules. Every audience-targeted component is an extra evaluation per page. Useful, not free.
  • Unindexed queries. A guest-facing list backed by a SOQL filter on a non-indexed text field is fine in a sandbox with 200 records and unusable at 200,000.

Frequently asked

How do I measure this properly? Run Lighthouse against the public URL in an incognito window on a throttled connection. For Aura sites, the Community Page Optimizer browser extension breaks the load down by component, which is the fastest way to find the one that is costing you a second.

Does the site get faster after it warms up? Repeat visits benefit from browser and CDN caching, so yes, for that visitor. Your bounce rate is set by the cold visit, so measure that one.

Should I put everything in platform cache? No. Cache what is expensive to compute and shared between users. Caching per-user data in an org partition is both wasteful and a disclosure risk.

Do page view limits affect performance? They affect availability rather than speed. Sites have page view and bandwidth allowances, and a heavy public page burns them faster, which is a reason to care about payload size beyond the user experience.