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!
Tracking the cache clears is a great idea. In our setup, I've seen the lag spike exactly after deployments that nuke the CDN cache, especially for the new JS bundles. It's like the app has to warm up all over again.
If you start logging, I'd check if the UI filter lag gets better on the second click. That often points to in-memory caching in the new framework, which would explain the inconsistency.
measure twice, ship once
You're definitely not alone, I've noticed the same spinners. That feeling when you click and wait, it really breaks your flow.
Your dev tools check is a good idea. Seeing heavier JS bundles makes sense for the filter lag. I'm new to Lacework myself, but I've seen this pattern before where a UI update feels snappy in a demo but drags in real use.
Do you think the longer report generation time is tied to the same backend queries causing the navigation delay, or is it a completely separate process?
That's a good tip about the fresh browser profile. I'll have to try that.
Separating the report generation as a backend issue makes sense. But if the new UI is making more complex API calls to generate the same report, couldn't that also be part of the same root cause? Like a poorly optimized call from the new frontend?
Your dev tools check is spot on. The heavier JS bundle is likely a new client-side framework rendering components that used to be server-side. That shift often creates the exact filter lag you're describing, as every keystroke triggers a client-side re-render instead of a simpler form submission.
You asked if the report generation slowdown is tied to the same backend queries. It's probably related, but not identical. The navigation spinner indicates a slow *initial* API call to fetch the page's core data. The report generation hanging suggests those same API endpoints, when asked to process, aggregate, and serialize a much larger dataset for the report, are now struggling under the new query patterns. The frontend might be requesting data in a less efficient structure than before, which only becomes painful at report-scale.
I'd log the two as separate tickets, but link them. The root cause is likely a single backend deployment with poorly optimized database queries or inefficient serialization for the new UI's data shape.
every dollar counts
Logging tickets by symptom type like that sounds really effective. Do you find "initial load" versus "interaction lag" splits the responsibility clearly enough between frontend and backend teams, or does it ever still cause friction?
That split can help, but you're right, sometimes it gets messy. We saw a case where initial load was fine, but the first filter interaction was brutal. Backend team said it was frontend's hydration blocking the thread, frontend said the API response was massive. The real culprit was a new GraphQL query on that first interaction fetching way more nested data than before.
So the split works for triage, but you still need someone looking at the entire request/response chain to see where the handoff creates the bottleneck. Does your team have a dedicated performance role, or is it more ad-hoc?
Yeah, that TTFB increase you're seeing is a huge clue. I've seen this exact pattern when a UI migration adds a new GraphQL layer or switches to a more chatty REST pattern. The heavier JS bundle often means they're fetching dependencies on demand now, but the initial API call to populate the page might be pulling in way more nested data than the old endpoint did.
We had a similar issue with a different platform. It turned out the new "unified" view was making a single call that joined data from four separate tables that used to be loaded independently. Great for reducing round trips, but terrible if that join isn't optimized. Your report generation taking longer might be suffering from that same inefficient query, just on a larger dataset.
Infrastructure as code is the only way
The Monday/cache-clear pattern you're noticing is a classic symptom of client-side hydration and cold start penalties. If your team clears caches frequently, you're essentially forcing every user session into the worst-case performance scenario for a client-rendered UI. The inconsistency you feel comes from the app warming its in-memory caches (like component state or API response caches) on the fly.
You might want to check if the performance degradation scales with the size of the dataset loaded on that initial page. A cache clear on a page viewing a single asset will feel different than one on a dashboard with hundreds. That could explain why it's hard to pin down.
Show me the numbers, not the roadmap.
That cold start penalty on Mondays is a great way to frame it. I've measured this exact pattern in our internal monitoring. You can see a distinct TTFB spike for the first user hitting a particular view after a deployment, with latency dropping asymptotically as more users hit the same endpoint and warm the underlying service caches.
Your point about dataset size scaling the degradation is critical. It often isn't the raw record count, but the complexity of the joins in that initial payload. We traced a similar dashboard slowdown to a new GraphQL query that, while fetching the same "number" of assets, was now pulling in three levels of nested compliance data that wasn't rendered on the initial view. A cache clear meant paying that serialization cost for every field, not just the visible ones.
This makes pinpointing the issue harder, because the performance hit is conditional on both the cache state *and* the specific data topology of the page you're loading.
—Alex