A screen is slow to load
Two patterns account for nearly every slow screen here, and both are about query count rather than query speed: work that costs one statement per row, and work the application does in memory over a slice of rows. Measure statements at two workspace sizes and the pattern names itself — a count that grows with the data is the one that gets worse on its own.
What a screen is actually doing#
Screens are plain ES modules with no build step, so the browser fetches them directly, and the styling is 56 ordered layers behind a single index. Their data comes from one service per screen — the same service for both audiences, reached by different paths — which then reads through the workspace kernel and the database's own row-level security. A screen is therefore rarely slow because of rendering. It is slow because of what it asked for.
The two patterns#
| Pattern | Signature | What it does over time |
|---|---|---|
| A statement per row | Statement count rises when the workspace has more records, not when more people are using it | Gets steadily worse, then becomes an incident on a day nothing changed |
| Counting in the application | A fixed slice is read — a few hundred rows — and counting, filtering, searching and paging happen in memory over it | Gets slower *and* starts giving wrong answers once the business outgrows the slice |
The measured reductions on this codebase show what the first pattern is worth fixing: the Owner's customer list went from 5,574 statements to 3; the triage strip from 83 to 11; the workspace console from 89 to 17; Home from 133 to 15. The number to insist on is not the smaller figure but the word beside it — flat with page size. Eleven statements at twenty rows and eleven at two hundred will not become an incident later.
The second pattern is the more dangerous one, because slowness is its mild symptom. The conversation list once read 400 rows and did the counting, filtering, searching and paging in Python over that slice; on a 430-conversation workspace the Closed tab read zero and page five was empty. A slow screen of that shape is also a wrong screen.
What Connect completed#
The request ran and returned a complete answer for the query it made. Slowness here is not truncation: nothing was dropped to make the screen appear, and the rows you eventually see are the rows the query selected. Isolation was applied throughout — the allowlist, the workspace kernel and row-level security all ran, and none of them is what made it slow.
What Connect did not complete#
It did not cache the result for your next visit, and it did not tell you which of the two patterns you hit. There is also no partial render: a screen either has its data or is still waiting for it, so a long wait looks identical to a stall until the rows arrive.
What you can do#
Narrow the view before widening the investigation — a filter, a folder, a smaller page.
Result If a narrower view is instant and a wider one is not, the cost is per row rather than per request, which is already half the diagnosis.
Note the exact route, the workspace, and roughly how many records it holds.
Result Record count is the variable that matters. A report without it cannot be reproduced by anybody whose workspace is a different size.
Check whether the numbers on the screen are also wrong.
Result A headline count that disagrees with the list underneath points straight at the second pattern, and that is a correctness bug rather than a performance one.
What an administrator can do#
- Count statements for that screen at two workspace sizes. The ratio between them is the answer; the absolute number is not.
- Look for a headline number that could have been counted in the application rather than by the database — those are where wrongness and slowness arrive together.
- Check whether the screen is one of the ones already reduced. If a screen that was made flat is slow again, something new is reading per row inside it.
When to escalate#
Escalate when the slowness scales with the number of records rather than with the number of people using the product, and especially when a count on the screen disagrees with the list beneath it. Both are structural. Escalate too if one audience is slow and the other is not on the same data, since that points at the path rather than the query.
Questions#
Would a faster machine fix this?
Not for either pattern. A query count that grows with the data grows on faster hardware too; work done in the application over a fixed slice keeps giving the same wrong counts however quickly it runs.
Why is the first load after a release slower?
The browser fetches the modules and the stylesheet layers again, because there is no build step bundling them. That is a one-off cost per release, and it does not grow with the size of the workspace.
Is a slow screen ever a sign of a data problem?
Yes — the second pattern is exactly that. If the tab counts, the pager or a headline total disagree with what the list shows, treat it as incorrect first and slow second.