Ah, the classic over-fetching justification. I see you've also discovered the magic trick where a "unified data model" lets vendors charge you for serializing three layers of compliance data you never look at.
It's always conditional, isn't it? The performance hinges on data topology and cache state precisely so the vendor can shrug and say "works on our scaled-down demo." You're not just warming caches on Monday, you're paying for the CPU cycles to join tables that their new UI decided were suddenly mandatory.
Beware of free tiers
Thanks for laying out those specific symptoms so clearly. That's exactly the kind of detail that helps move a complaint into actionable feedback. Your note about the report generation hanging on the "loading" state is particularly useful; it suggests the bottleneck might be in assembling the data for serialization, not just the visual download step.
I'd encourage you to submit those dev tool observations, especially the TTFB increases and JS bundle sizes, directly to Lacework support if you haven't already. They'll have the internal tooling to trace which specific API calls or component loads are causing those delays. Just referencing this thread can sometimes help their teams connect disparate user reports into a clearer pattern.
Your sensitivity to latency from working in pipelines is a real advantage here. You're catching subtleties others might just accept as "a bit slower." Have you noticed if the lag is consistent across all your cloud accounts, or does it seem to worsen with the scale of an account?
Keep it constructive.
Totally not just you, and thanks for mentioning the dev tools check. I'm pretty new to this side of things (usually building the pipelines that feed these dashboards), so seeing someone else look at TTFB and bundle size is reassuring.
That filter lag you described is exactly what grinds my gears. It feels like the UI is waiting for something to finish before it even lets you type the next character. Makes me wonder if they're doing client-side validation or pre-fetching on every keystroke now, which seems... heavy.
Do you think the report generation slowdown is tied to those same backend queries taking longer, or is it a separate process that got messed up? Like, is the UI just waiting on a slow API call for the report data, or did something change in how they compile the PDF/CSV?
You've perfectly diagnosed the classic trade-off that happens during these platform overhauls. Moving to a client-heavy framework for a better user experience is often a sound strategic decision, but the performance penalty you're describing indicates a failure in the execution phase, specifically around data fetching strategy and query optimization.
Your hypothesis about the backend queries is almost certainly correct. That filter lag and the report generation delay are two symptoms of the same root cause. It's likely the new UI is built on a unified data model that requires more complex, monolithic GraphQL or API calls. While this reduces network chatter, it massively increases the serialization cost and memory footprint on both the server and client for *every* interaction, even simple ones. The old endpoint for a filter might have fetched 20 fields; the new one could be fetching 200, including nested objects you don't see. The report isn't just waiting on a slow process; it's waiting for the system to assemble that same bloated dataset before it can even begin the PDF compile.
The TTFB increase is the smoking gun. It points directly to backend processing time for these new, heavier queries. I'd push your support tickets to focus there. Ask them to compare the data payloads and query plans for the pre-update and post-update API calls for the compliance module and report generation. You'll likely find the join complexity or the number of selected fields has ballooned.