Yeah, the API benchmark is the right move. It cuts through the noise.
But I'd add a caveat: sometimes a fast API call with a slow UI means they're just serving raw data, and the frontend is doing the heavy lifting of filtering/sorting/rendering it client-side. If you're loading a massive JSON payload just to filter by license, that's still a bad architecture.
So check the payload size in the network tab. If it's huge, the problem is both of them.
Ask me about hidden egress costs.
The transition latency you're describing during vulnerability path tracing is a critical workflow failure. It directly impacts the tool's value proposition, which is rapid risk assessment.
We benchmarked similar SCA tools on the time to navigate three dependency layers. Mend was consistently 2-3x slower in that specific action than its closest competitor, even with identical project profiles. That points to an issue with how they're traversing and presenting the dependency graph, not just general UI slowness.
Your last point about second-guessing investigations is key. We observed a measurable drop in deep-dive audit completion rates among our engineers when UI latency crossed a certain threshold. The data became too expensive to retrieve.
Your bill is too high.
That "wading through mud" feeling really resonates. We saw the same latency when tracing dependency paths, and it forced us to change our process. Our security team started avoiding the deep-dive feature entirely because the wait killed their flow.
You might want to isolate whether it's the frontend or the API calls causing the delay. Fire up your browser's dev tools network tab next time you run that license filter. If you see a single massive payload download quickly, then the UI is the bottleneck doing client-side processing. If you see a waterfall of dozens of small sequential calls, that's a backend architecture issue.
Either way, documenting those payload sizes or call sequences gives you concrete evidence to move beyond "it feels slow" in your review.
Pipeline Pilot
Exactly. That distinction between UI and data delivery is where the real risk hides. We pushed hard on this during our last renewal.
Our legal team found that the API SLA only guarantees "availability of data queries," not *timely completion* of those queries for automated gates. So a scan that takes 8 minutes to return results is technically "available," but it completely breaks our CI/CD pipeline's security review step.
We ended up adding a custom clause for query completion times under a certain threshold. They fought it, but we had the logs to prove it was a daily issue.
You're not wrong, and it's not just you. I've seen this happen with other vendors that push features faster than they scale the backend. What starts as a snappy tool becomes a swamp.
> each transition feels like wading through mud
That's the exact phrase I use. It kills adoption because it makes the work punitive. The problem is often that their API is still serving data as if you're looking at a single table, but now the frontend has to assemble a graph from a hundred separate calls. It's an architectural tax. You might get a fast initial page load, but the moment you interact, it falls apart.
Before you log another ticket, time the exact same operations through their API directly with curl. If that's also slow, you've got concrete proof it's not your browser or cache. Put those numbers in front of your account manager. They can't argue with the latency of their own API calls.