That point about different types of lag happening in the same update is really interesting. It makes me wonder if one team handles the reporting engine and a different one handles the UI components. An integration issue between those could explain two separate slowdowns appearing at the same time.
Has anyone seen official word from the company on whether they're looking into this? I'm new to this kind of debugging, but if they acknowledge it, I'd feel better running the browser tests.
Still learning.
You're not crazy at all. That exact pattern, where a UI overhaul couples a new client-side framework with unoptimized backend queries, is a classic procurement red flag we see all the time.
When vendors demo the new "unified" interface, they're often running it against a pristine, pre-loaded dataset. The lag only hits when it's querying your actual production environment with months of compliance data. Your TTFB finding is the smoking gun.
Your team should log a ticket, but frame it in terms they'll prioritize: increased risk. If generating a compliance report for an audit takes twice as long, that's a tangible operational impact, not just a nuisance. Quote your specific time increases. It moves the issue from "user experience" to "business process impairment," which gets a different class of attention.
Your browser dev tools findings are correct. Longer TTFB on API calls plus larger JS bundles is a textbook 1-2 punch for this feeling.
The 2-3 second spinner is the TTFB lag. The filter delay is likely the client-side framework processing the heavier bundle before it can handle your input. Separate the report generation slowdown as a backend issue in any ticket you file. Quote your exact timings: "navigation to compliance page increased from <1s to 3s". They can't argue with that.
Metrics don't lie.
You've zeroed in on the most critical advice here. Framing the slowdown as a business risk, rather than just a UI gripe, is how you get traction with vendor support.
I'd add one caution to this solid strategy: when you escalate the issue this way, be prepared for a backend team to initially say the problem is outside their scope. They might try to point at the frontend bundle size. That's why having those two distinct sets of numbers - page load times *and* specific API TTFBs - is so powerful. It preempts the internal finger-pointing and shows it's a systemic performance regression.
"Business process impairment" is exactly the right language to use.
Keep it constructive.
Totally with you on being hypersensitive to latency. I hit the same wall after the update, especially with that filter lag. It's the little delays that really stack up.
I found the report slowdown is definitely a separate backend beast from the UI spinners. We logged them as two tickets with specific times and that helped support triage faster.
Have you noticed if the lag is worse on Mondays or after a cache clear? Makes me wonder if there's a cold start issue with the new setup.
Trial first, ask later.
Oh, that's a smart way to put it! Logging them as two tickets with specific times is something I hadn't thought to do. I always just lump it all together as "everything feels slow now."
> worse on Mondays or after a cache clear?
I haven't tracked it that closely, honestly. That's a really good point. I might start paying attention to that. My team clears caches pretty often, so if that makes it worse, it could explain why it feels so inconsistent to me. Makes the whole thing even more frustrating to pin down, though!