# Performance Guide ## Overview Avonni Dynamic Components are fast by default. This guide explains how first-load performance works on the Salesforce platform, and what you can do to keep your components fast as they grow in complexity. *** ## Understanding First-Load Performance When users open a page for the first time, they sometimes notice a delay before the component appears. This is expected behavior — and it happens at the Salesforce platform level, before Avonni code runs. ### Why is the first load slow? When a Lightning Page is accessed for the first time, Salesforce compiles all components that make up the screen on its servers before sending it to the browser. This compilation is a platform-level process that Avonni does not control. Once compilation finishes, the result is cached at the org level and shared across all users and browsers. That's why the second visit — whether for the same user or another user in the org — is much faster. The cache expires after **12-24 hours of inactivity**. Pages that aren't visited often, or orgs with low daily traffic, will trigger a full recompile on the next access. ### Why are certain screens more affected? Avonni components are loaded dynamically. Salesforce can't bundle them together in advance — each one is fetched and compiled individually at runtime. The weight is inside the components themselves. Avonni components are built to support a wide range of configurations and options, so each one carries a large set of underlying building blocks. A component like the [**Data Table**](/dynamic-components/components/data-table.md) supports sorting, formatting, many column types, and more — all of which must compile before the component can appear, whether or not a given screen uses every option. The more capable the component, the more there is for Salesforce to compile. This is why a screen with even a few feature-rich components can have a noticeable cold load: it's not the count of components that drives the time, it's how much each one can do: | Component | Cold Load (first visit) | Warm Load (cached) | Difference | | -------------- | ----------------------- | ------------------ | ------------------------ | | **Data Table** | \~33 seconds | \~6 seconds | \~5× slower on cold load | On a cold start, the heaviest components account for roughly **98% of total load time**. ### What Avonni is doing about it Because the slowdown stems from how much our components contain, the fix has to come from our side. We've instrumented the loading process to identify exactly which components drive the time, and we're working on two tracks: * **Reducing dependency weight** — auditing the import trees of the heaviest components and removing what they don't need. The less each component carries, the less Salesforce has to compile. * **Deferring hidden components** — components that aren't immediately visible (inside tabs, collapsible sections, or off-screen areas) — can be loaded on demand instead of upfront, reducing the initial compilation footprint. These changes will bring first-load times down within the limits of what the Salesforce platform allows. Warm loads are already fast — these efforts target the cold-load experience. {% hint style="info" %} #### **Need to explain this to someone else?** Whether it's a client, a stakeholder, or an end user asking why the first load feels slow, point them to this section. The behavior is at the platform level and affects every Lightning component built on Salesforce — not just Avonni. {% endhint %} *** ## Telling First-Load from Runtime Slowness If a page feels slow, first figure out whether you're seeing cold-load compilation (platform behavior) or runtime slowness (configuration). The two require different responses. **Quick test:** 1. Open the page and wait for it to fully load. 2. Hard-refresh (Cmd/Ctrl + Shift + R). 3. Note how long the second load takes. If the second load is fast, the original slowness was Salesforce cold-load compilation. That's expected — the cache is now warm, and the next user will benefit. If the second load is still slow, the issue isn't compilation. Open **Developer Tools → Network tab**, filter by `aura` or `apex`, and inspect the requests. A high request count or a slow-running query points to a component configuration issue rather than a platform compilation issue. Reach out to support so we can help diagnose the issue. {% hint style="warning" %} #### Important A slow **first** load on a freshly cached page is usually Salesforce compilation, not your configuration. A slow **warm** load almost always points to a query design or component structure issue. Different symptom, different fix. {% endhint %} *** ## Need Help? If you're stuck on a specific performance issue, two ways to reach us: * [**Community Group**](https://trailhead.salesforce.com/trailblazer-community/groups/0F9KX000000iFxO0AU?tab=discussion\&sort=LAST_MODIFIED_DATE_DESC) — ask the Avonni team and other admins on the Trailblazer Community. * **Direct support** — email with your component config, a screenshot of the Network tab, and a description of cold-load vs. warm-load behavior. The more context you share upfront (component setup, the page it lives on, whether the slowness is on first load or every load), the faster we can pinpoint the cause --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.avonnicomponents.com/dynamic-components/resources/performance-guide.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.