Why your CRM Analytics dashboard loads slowly, and how to cut page-load queries by a third

Most slow CRM Analytics dashboards are not slow because of data volume. They are slow because of how the dashboard JSON was built, and the fix is usually invisible to the people complaining about it. Here is what actually causes the lag, in the order I find it most often, plus the result of a recent teardown where this cut the dashboard JSON by 53 percent and page-one load queries by 37 percent, render-identical.

This applies across every vintage of the product: Wave Analytics, Einstein Analytics, Tableau CRM, and what Salesforce now calls CRM Analytics.

Every step on page one runs on load, whether a widget uses it or not

This is the big one. When a dashboard page opens, the runtime executes every step assigned to that page. Not the steps a visible widget needs. Every step. Over eighteen months of a dashboard built by committee, you end up with steps added for a one-time request, steps that feed a widget someone later deleted, and steps duplicated because two builders solved the same problem a week apart.

Each of those is a live SAQL query firing on every page load. None of them render anything. Users wait for them anyway.

The fix is not glamorous. You walk the step list, map each step to the widgets that actually bind to it, and delete the ones that bind to nothing. On the teardown I mentioned, a third of the page-one steps were feeding zero visible widgets.

save nodes with fields: ["*"] quietly return nothing

In the data prep recipe, a save node configured with fields: ["*"] looks like it grabs everything. In certain pipeline configurations it silently returns zero rows. The step still fires. The query count still goes up. The widget downstream just renders blank.

Teams almost never trace this back to the recipe. They assume it is a permissions problem and go chasing security predicates, or they assume the filter is wrong. It is neither. Name the fields explicitly and the rows come back.

If you have widgets that load but render empty on first hit, check this first.

Widgets that force a full dataset scan when they only need an aggregate

A number widget showing a single total does not need to scan the dataset row by row. But if the underlying step is written as a row-level query instead of a group by all aggregate, that is exactly what it does. Multiply that across a KPI strip of eight tiles and you have eight full scans where you needed eight cheap aggregates.

The number widget in CRM Analytics is really a chart widget with its visualization set to number, and the step behind it should be a single-row aggregate. Rewriting those steps is often the single highest-leverage change on an executive summary page.

Duplicated SAQL across a step family

When several widgets share a near-identical query with one small variant, builders tend to copy the whole step and tweak it. Now the runtime compiles and runs five queries that differ by one filter. A single parameterized step with a binding, or a faceted step the widgets share, collapses that into one.

This is where bindings earn their keep. The trap is that a binding written carelessly throws a parse error that propagates to every sibling widget sharing the step, so the cleanup has to be tested against every widget on the page, not just the one you edited.

What the cleanup is worth

On the most recent teardown, the combination of the above removed dead steps, renamed the silent zero-row save nodes, converted KPI tiles to true aggregates, and merged a duplicated step family. The dashboard rendered pixel-for-pixel identically to the original. The JSON dropped 53 percent. Page-one load queries dropped 37 percent. The team did not have to explain a single visual change to their executives, because there were none.

That last point matters more than the percentages. The reason these dashboards never get cleaned up is that nobody wants to risk changing what leadership sees. A teardown that is provably render-identical removes that risk.

Want this done on your worst dashboard

I do a flat-fee teardown on a single dashboard. You export the dashboard JSON, which means no org access and nothing touched on your side. In 48 hours you get back a step-by-step audit, a list of what to remove and why, and a prioritized fix list with the expected query reduction, written so whoever does the rebuild can act on it directly.

It is $249, flat. If your execs are quietly complaining about load times and nobody has the bandwidth to dig into the JSON, that is exactly the gap it closes.