Hey folks, has anyone else noticed significant lag in the Semgrep Cloud UI recently? I've been integrating it into our CI/CD pipeline for a few months now, and while the CLI is snappy, the web interface has become painfully slow the past couple of weeks.
My typical workflow involves checking the findings dashboard after our monorepo scans. Lately, it takes 5-7 seconds for the page to become interactive after load, and filtering results by language or severity has a noticeable delay. This is happening across browsers (Chrome, Firefox) and from different networks.
A couple of data points from my setup:
* We're scanning a Python/Go monorepo with about 500k lines of code.
* Using the Team tier.
* The slowness is most apparent on the project findings page and when navigating rule boards.
I'm curious if this is a wider issue or something specific to our account/scan size. Has anyone found any workarounds, like adjusting the browser's resource limits or using certain UI settings? The API itself seems responsive, so I'm leaning towards a frontend optimization problem.
--builder
Latency is the enemy, but consistency is the goal.
I've run into similar performance degradation on the Team tier with a comparable codebase size, though ours is primarily TypeScript. The lag when applying filters, especially by severity, became a real bottleneck for our security review triage.
What I found is that the delay seems directly tied to the volume of findings being rendered on the initial page load, not just the total lines of code. We had a rule set that was generating a high number of low-severity informational findings. When we temporarily disabled those rules in the project's dashboard settings, the UI responsiveness improved markedly during filtering operations. It's a suboptimal workaround, but it pointed to a frontend rendering issue with large datasets.
Have you checked if the sluggishness correlates with a specific spike in your total finding count? The API remaining fast while the UI bogs down suggests the data fetch isn't the primary culprit.
Your note about the API being responsive while the UI lags is a strong indicator. I've seen this pattern before with analytics dashboards that try to render too much client-side data before applying filters. It's a frontend architecture problem, not a general service slowdown.
One diagnostic step is to check your browser's developer console network tab while loading the findings page. Look for a large, monolithic JSON payload being fetched on initial load, versus smaller, paginated requests. The 5-7 second TTI you mentioned is typical when the main thread is blocked parsing and processing that initial dataset.
Since you're on the Team tier, have you opened a support ticket linking to this performance profile? Vendor pressure from multiple teams reporting the same bottleneck is often the fastest path to a UI optimization fix.