The Staff Center view for New HQs takes 25 seconds to render on a server with nothing else running. The list it produces is about 15 rows. Support staff open it first thing in the morning to see who is new. Twenty-five seconds is not a number you accept for that.
I opened the ticket expecting a layout fix. The title said responsive design and the file it pointed at was StaffCenter.asp. When I loaded a profiler trace to understand what was actually executing, the first thing I saw was the New HQs section resolving through a FULL OUTER JOIN against the session log table.
the query was answering the wrong question
The session log table logs session activity across the platform. Every customer who has ever logged in, every page they navigated to, every action that generated a session event is in there. It grows every day. It is not the table you use when you want to know who signed up recently. The right table for that question is the customers table, which has a signup-date column and nothing else you need to discard. The join to the session log table was not answering “who signed up recently?” It was answering something much larger, pulling rows across the full session history, sorting them, and returning a short list from the top.
Above the New HQs list, the RecentListAdd widget had a different problem. It was running unbounded COUNT(*) queries to populate tooltip labels on hover. No date range, no scope, nothing limiting the count to a recent window. Every Staff Center page load, the widget would ask the database to count the full contents of several tables and embed those numbers in labels that appear when a user hovers and disappear when they move away. The count was never wrong. It just had no business being recalculated on every page load to power a tooltip.
This is feature debt that accumulates invisibly in a 25-year-old codebase. The original developer probably saw the COUNT(*) as fast at a thousand rows. At ten thousand it was still fine. By the time the tables grew large enough to make it slow, the connection between the hover label and the latency was completely invisible to anyone reading the page in a browser.
what the fix actually required
The New HQs rewrite stopped using the session log table as the source and pulled directly from the customers table with a filter on the signup-date column. The Staff Center does not need session history to show who signed up recently. It just needs to know when they signed up. Once I removed the join, the view dropped from 25 seconds to around 500 milliseconds on the same data set.
The RecentListAdd fix was to stop computing the count on demand. Whether you cache it or remove it from the tooltip entirely depends on whether the tooltip is worth keeping, and in this case the answer was no. Neither the table structures nor the server were the problem. The queries were doing more than the screens required, and nobody had traced the latency to the SQL causing it.
HomeTeamsONLINE is a 25-year-old ASP-classic application I inherited when I bought the business. The Staff Center has accumulated queries that made sense on smaller tables and have quietly gotten slower since. Finding them requires actually running the queries and measuring them, not reading the code and guessing. A slow page is the signal. The profiler trace is the map.
giving the agent real access
While I was working through this ticket, I granted BEN AGENT the same Staff Center login I use. This sounds like housekeeping but it changes the diagnostic shape. If you are debugging an admin interface with an AI agent and the agent cannot log in, you end up in a relay pattern where you describe what you see in screenshots and wait for suggestions. That relay adds a layer of lossy translation between the real surface and the reasoning.
Once the agent had access, it could navigate to the slow views directly, observe the actual rendered state, and trace the SQL through the ASP source with full context about what the page was trying to show. The diagnostic path was faster because the agent was operating on the same evidence I was, not a description of it.
There is still a manual step. The agent runs in a Chrome profile I maintain separately at G:/AI/state/chrome-claude, and getting it into a session-authenticated page requires me to log in once on its behalf. The cookie persists across sessions after that. The one-time cost is low and the ongoing gain is not having to relay screenshots.
Claude can make it faster to inspect and rewrite gnarly legacy code. The constraint is not speed on the code-reading side. It is whether you notice where the code is solving the wrong problem at high cost. I had to load the profiler trace to see the FULL OUTER JOIN. Claude could have suggested fixes for the layout issue without that trace, and every suggestion would have been irrelevant to the actual latency.
I did not audit the rest of the Staff Center during this ticket. Several other paths run similar aggregates on tables that have grown past the point where those aggregates are cheap. I do not have numbers for all of them. What I know is that the specific COUNT(*) in RecentListAdd was running on every page load, for every Staff Center user, against unscoped table counts, to power a tooltip.
A slow internal page is rarely a scale problem. It is usually one query answering a much bigger question than the screen ever asked.