If you have ever clicked refresh on an SAP Analytics Cloud dashboard and watched the loading spinner go round and round for 30 seconds — this article is for you.
Slow SAC reports are one of the most common complaints from business users and consultants alike. The good news is that in most cases, poor performance is not a hardware problem or a licensing problem. It is a design and configuration problem — and it is completely fixable.
These 10 tips come from real enterprise SAP Analytics Cloud implementations. Not theory. Not documentation copy-paste. Real fixes that made real dashboards faster.
Why SAP Analytics Cloud reports run slow
Before jumping to fixes, it helps to understand what actually causes slow SAC performance.
Every time a user opens or refreshes an SAC Story, the following happens:
- SAC sends a query to the data source
- The data source processes the query and returns results
- SAC renders the results into charts and tables on screen
Slowness can happen at any of these three stages. Most performance problems fall into one of these categories:
- Too much data being queried — no filters, no aggregations, millions of rows
- Too many charts on one page — each chart fires a separate query
- Poor data model design — unoptimised dimensions and measures
- Live connection vs import — querying live SAP systems under load
- Browser and device limitations — too many elements rendering simultaneously
Now let’s fix them one by one.
Tip 1 — Reduce the number of charts per page
This is the single biggest performance fix in most cases and the one most people overlook.
Every chart, table, and KPI tile on your SAC Story page fires its own independent query to the data source. A page with 12 visualisations fires 12 separate queries simultaneously — every single time the page loads or a filter changes.
The fix:
- Aim for maximum 6 to 8 visualisations per page
- Split large dashboards into multiple pages — SAC Stories support multiple pages like PowerPoint
- Put overview KPIs on page 1, detailed charts on page 2, tables on page 3
- Users navigate between pages — each page only loads its own queries
A dashboard that went from 15 charts on one page to 5 charts across 3 pages will feel dramatically faster immediately.
Tip 2 — Use initial filters to limit data on load
By default SAC loads all data for every dimension when a Story opens. If your dataset has 3 years of transaction data across 50 countries — SAC tries to load all of it on startup.
The fix — set initial filters:
- In your Story, go to Edit mode
- Click File → Story Filters
- Set a default filter — for example Current Year only, or Current Month
- This limits how much data SAC queries on initial load
Users can still change the filter to see historical data — but the default load is fast because it only pulls recent data.
This single change can reduce initial load time by 60 to 80 percent on large datasets.
Tip 3 — Switch from live connection to import where possible
SAC offers two ways to connect to data:
| Connection Type | How it works | Performance |
|---|---|---|
| Live Connection | Queries source system in real time | Slower — depends on source system load |
| Import/Scheduled | Data copied into SAC on a schedule | Faster — SAC queries its own optimised storage |
Live connections to SAP S/4HANA or BW are powerful — data is always current. But they are also slower because SAC is querying a live production system that is processing thousands of other transactions simultaneously.
The fix:
For dashboards that do not need real time data — daily sales summaries, monthly financial reports, weekly KPIs — use scheduled data imports instead of live connections. Schedule them to run overnight so fresh data is ready every morning.
Reserve live connections only for operational dashboards where real time data is genuinely critical.
Tip 4 — Optimise your data model — remove unused dimensions
Every dimension in your SAC model adds overhead to every query — even if it is not used in any visualisation on that page.
The fix:
- Open your model in Modeler
- Review every dimension carefully
- Delete any dimension that is not used in any Story
- If you are not sure — hide it first, test performance, then delete
A model that went from 40 dimensions to 25 active dimensions will query significantly faster across every Story that uses it.
Tip 5 — Use aggregated data instead of row level data
SAC is not designed to display millions of individual transaction rows. It is designed to display aggregated summaries — totals, averages, counts, percentages.
Common mistake:
Connecting SAC directly to a transaction table with 10 million rows and then building charts on top of raw data.
The fix:
Create aggregated views or calculation views in your source system — SAP BW, SAP Datasphere, or SAP HANA — that pre-aggregate data before SAC queries it.
Instead of SAC querying 10 million transaction rows and summing them itself — it queries a pre-aggregated view with 500 rows already summed by month and region. The difference in query time is enormous.
If you use SAP Datasphere as your data layer — use Analytic Models in Datasphere to pre-aggregate before exposing to SAC. This is exactly what Datasphere is designed for.
Tip 6 — Avoid too many calculated measures in Stories
SAC allows you to create calculated measures directly in Stories — formulas that calculate on the fly when the report loads. These are convenient but expensive in performance terms.
Every calculated measure runs its calculation on every data point in every chart that uses it — at query time.
The fix:
Move complex calculations into your data model instead of Story level. Calculated measures defined in the model are computed at the database layer — much faster than Story level calculations.
If you absolutely need Story level calculations — keep them simple. Avoid nested calculations and calculations that reference other calculated measures.
Tip 7 — Enable SAC’s built in caching
SAP Analytics Cloud has a built in query cache that stores recent query results. When the same query is run again — SAC returns the cached result instantly instead of querying the source again.
How to check caching is enabled:
- Go to System Administration → Configuration → Analytics
- Verify Query Cache is enabled
- Set appropriate cache duration — 4 to 8 hours works well for most dashboards
This is especially effective for dashboards that many users open simultaneously. The first user triggers the query — every subsequent user gets the cached result instantly.
Tip 8 — Optimise your SAP BW or HANA queries
If your SAC connects to SAP BW or SAP HANA — the performance of your SAC dashboard is directly linked to the performance of the underlying BW query or HANA view.
Common BW performance issues that slow SAC:
- BW queries with too many free characteristics — limit to what is actually needed
- Missing aggregates in BW — work with your BW team to add appropriate aggregates
- BW queries without variable restrictions — always use mandatory variables to limit data volume
- Running SAC against BW queries that were designed for BEx Analyser — these are often not optimised for the query patterns SAC generates
The fix:
Work with your BW administrator to review the underlying queries. Enabling BW aggregates and restricting query scope typically delivers dramatic SAC performance improvements.
Tip 9 — Use the SAC Performance Analyzer
Most SAC users do not know this feature exists — but it is one of the most powerful tools for diagnosing slow dashboards.
How to use it:
- Open your Story in View mode
- Press Ctrl + Shift + P (or Cmd + Shift + P on Mac)
- The Performance Analyzer panel opens on the right
- Refresh your page
- SAC shows you exactly how long each query took — chart by chart
This tells you precisely which visualisation is causing your slowness. Instead of guessing — you can see that chart 3 takes 18 seconds and chart 7 takes 0.3 seconds. Fix chart 3 first.
This feature alone can save hours of performance troubleshooting.
Tip 10 — Schedule heavy reports to run off peak hours
For the heaviest reports — detailed financial reports, large planning models, complex multi-source dashboards — consider using SAC’s scheduling feature to pre-run reports during off peak hours.
How it works:
- Schedule the Story to refresh automatically at 5am
- When users open it at 9am — they see pre-loaded results instantly
- No waiting for live queries during business hours
This approach works extremely well for executive dashboards that are opened first thing every morning. The data is fresh from the overnight run — and it loads in seconds because all the heavy querying already happened while everyone was sleeping.
Performance checklist — quick reference
Use this checklist every time you build or optimise an SAC Story:
- Maximum 6 to 8 charts per page — split into multiple pages if needed
- Initial filters set to limit data on page load
- Live connection vs import evaluated — use import where real time not needed
- Data model cleaned — unused dimensions removed
- Aggregated views used in source system — not raw transaction tables
- Complex calculations moved to model level — not Story level
- Query cache enabled in system administration
- BW queries optimised — aggregates enabled, variables restricted
- Performance Analyzer used to identify slowest queries
- Heavy reports scheduled for off peak refresh
How much faster can you expect?
Based on real implementations applying these tips:
| Scenario | Before | After |
|---|---|---|
| Executive KPI dashboard | 25 seconds load | 3 seconds load |
| Monthly financial report | 45 seconds load | 8 seconds load |
| Operational live dashboard | 12 seconds load | 4 seconds load |
| Planning input form | 30 seconds load | 6 seconds load |
Results vary depending on data volume, infrastructure, and network — but applying even 3 or 4 of these tips consistently delivers significant improvement.
Key takeaways
- Slow SAC reports are almost always a design problem — not a hardware or licence problem
- Reducing charts per page and setting initial filters delivers the fastest wins
- Use the Performance Analyzer to identify exactly which queries are slow — stop guessing
- Move calculations to model level and use aggregated data sources wherever possible
- Live connections are powerful but slower — use scheduled imports for non real time reports
- Apply the performance checklist to every new Story before sharing with business users
Related articles on Data Cloud Insights
Published by the Data Cloud Insights team — SAP data professionals with hands-on enterprise implementation experience across Europe.
Pingback: SAP Analytics Cloud Planning: Key Terms Every Beginner Must Know (Part 4)