Twenty-two seconds to two tenths
A dashboard took between eleven and twenty-two seconds to load. Every intuition about why was wrong, and the fix was the opposite of the instinct.
- 23 individual reads
- 5,754 ms
- One batched read, same data
- 251 ms
- No-op request vs full read
- 2.78 s vs 2.48 s
- Eight routes, after sharing one read
- 206 ms
- End to end
- 11–22 s → 0.2 s
- Verification diff
- 1,628 cells, 0 differences
What it was not
It was not computation. Every metric in the payload computes in about 80 milliseconds combined.
It was not data volume. All twenty-three sheet tabs hold 280 rows between them.
It was one round trip per tab, twice over — once to read the values and once to ask how many rows there were.
What it actually was
Twenty-three separate reads cost 5,754 ms. The same data in a single batched call cost 251 ms.
Separately, one calendar function was being called twice per payload — directly, and again inside another function that opens by calling it. About nine seconds, for the same answer computed twice.
The batched reader was diffed against the old one cell by cell before it was trusted: 1,628 cells, zero differences. That mattered because the two APIs return different types for the same cell — one gives typed numbers and dates, the other can give display strings — so the render options are chosen rather than defaulted.
The floor, and why it inverts the strategy
A request that does literally nothing costs 2.78 seconds. A complete dashboard read costs 2.48. The cost is the mandatory redirect and container start, not the work.
That inverts the usual instinct. When something is slow the reflex is to make it do less, and here that buys nothing at all. The goal has to be making FEWER requests, not lighter ones.
Every page was making its own, so each tab switch paid the floor again. Sharing one cached payload across all eight routes took the combined render to 206 ms.