Why reports get slow
Every component runs its own query. A page with fifteen charts is fifteen queries, and the page is only as fast as the slowest one.
The usual causes, in rough order:
- Too many components on one page
- A large or unaggregated source
- Blends, which query each source separately
- Custom SQL doing heavy work per chart
- Community connectors with slow APIs
Extract data
Add → Extract data creates a static, aggregated snapshot of a source, up to 100 MB, on a refresh schedule.
This is often the single biggest improvement available. Instead of querying a large BigQuery table live, you query a small pre-aggregated extract. The cost is that data is only as fresh as the last extract.
Aggregate upstream
The general principle: do the heavy work before Looker Studio sees the data.
A summary table in BigQuery, or a Sheet holding aggregated rather than raw rows, makes every chart faster at once. A report over a million raw rows will never be fast, however it is built.
Practical reductions
- 1Split dense pages — five focused pages beat one page of twenty charts
- 2Remove charts nobody looks at
- 3Replace blends with an upstream join where possible
- 4Lengthen data freshness so results are cached longer
- 5Limit default date ranges — 28 days rather than all time
Check the real cause
Before optimising, load the report and watch which components resolve last. It is usually one or two, and they are usually a blend or a community connector — not the thing you assumed.