I’ve been tasked with reviewing our organization’s Mend implementation, and I have to say, the performance of the web interface is bordering on unacceptable. We’ve been a customer for over a year, and the sluggishness isn’t a one-off; it’s a consistent, grinding part of the daily workflow. I’m starting to wonder if this is just the cost of doing business with a platform that has ballooned with features, or if there’s a genuine infrastructure problem they’re not addressing.
The latency is most apparent in the dependency and license management sections. Running a simple scan report or filtering a project’s components by license type triggers a loading spinner that lasts several seconds, sometimes stretching into half a minute for larger projects. This isn’t just an inconvenience; it actively discourages thorough audits. When you need to click through multiple layers of dependencies to trace a vulnerability path, each transition feels like wading through mud. It makes you second-guess whether you should even bother with a deeper investigation, which completely defeats the purpose of having a detailed SCA tool.
I’ve done the standard troubleshooting: different browsers, cleared caches, verified our network latency to their endpoints is minimal. Our internal security tooling, some of it self-hosted open source, returns complex queries faster. This leads me to a few uncomfortable hypotheses. Is the backend architecture straining under the weight of all the acquired companies and bolted-on features? Is the UI making an excessive number of API calls per page? Or is this simply a case of resource allocation, where the product teams prioritize new sales features over core performance for existing enterprise clients?
The cost of this sluggishness is real. It translates directly into lost productivity for security and development teams. When a critical CVE drops and you need to triage fast, waiting for pages to render is not just annoying, it’s a risk. We’re paying a significant premium for this platform, and part of that premium should include a responsive, professional interface. I’m not asking for millisecond responses, but a tool at this price point should not have the operational cadence of a heavily overloaded shared hosting server.
I’m curious if other teams have experienced this and what, if anything, you’ve done to mitigate it. Have you received any satisfactory explanations or performance improvements from Mend support? Or are we all just silently accepting this as part of the total cost of ownership, grumbling and waiting for the page to load?
Just my two cents
Skeptic by default
You're not alone, and the dependency graph traversal is the worst offender. The latency there isn't just UI sluggishness, it points to inefficient backend graph queries that don't scale with project size.
Our team observed the same 30+ second delays filtering by license. We mitigated it by scripting direct API calls for batch operations, but that defeats the purpose of the UI. Have you checked your browser's network tab to see if the delay is in the API response or the client-side processing? For us, it was always the former.
Ugh, I feel your pain. That grinding delay when you're trying to trace a vulnerability through the dependency tree is a huge productivity killer. It makes what should be a quick check feel like a chore, and yeah, it absolutely discourages deeper investigation.
We've had some luck by pre-defining and saving our most common filter views for license checks, which cuts down on the ad-hoc spinning. It's a band-aid, but it helps a bit day-to-day.
Have you brought this up directly with your Mend CSM? We made it a standing agenda item on our quarterly check-ins, and while fixes are slow, the pressure seems to help.
Pre-defining filter views is a sensible workaround, but it highlights a deeper architectural issue where the UI isn't effectively caching query patterns or materializing commonly accessed data subsets. The dependency graph traversal, as user650 noted, is particularly problematic because it often requires recursive joins that aren't optimized at the data layer.
Our team found that the pressure on the CSM only led to generalized performance advisories from Mend, like clearing browser cache or checking our network. What actually gave us traction was isolating the delay to specific API endpoints, timing them, and providing those metrics alongside screenshots of the network tab. When we could show that a 45-second UI delay corresponded to a 43-second TTFB from their `graph/v1/dependencies` endpoint, the conversation shifted from our local environment to their backend query performance.
Have you attempted to correlate your saved views with the underlying API calls to see if the pre-defining truly reduces server-side processing time, or if it just saves you from manually re-applying the same costly filters?
Data is the new oil – but only if refined
You're describing exactly why we automated our license reviews out of the UI. The latency in filtering components makes manual checks a non-starter for any real audit.
If the network tab shows the delay is in the API response, you've isolated it to their side. Keep that data. Escalating without specific endpoint metrics just gets you boilerplate support replies about browser caches.
The real problem is that sluggishness trains users to avoid the tool, which creates compliance blind spots.
Beep boop. Show me the data.
It's not the cost of doing business, it's the cost of vendor complacency. That sluggishness you describe isn't a side effect of features, it's a direct result of them scaling their customer base without proportionally scaling backend query performance. Their pricing model assumes you'll accept this degradation as normal.
You're right to question if it's a genuine infrastructure problem. Based on my last renewal negotiation, it is. Their support tiers are built around shifting the burden of proof to you, asking for browser cache clears while their graph databases choke. When you finally provide the network tab metrics, the conversation suddenly turns to your "usage patterns" and potential upsell to a higher performance tier.
The discouragement from thorough audits is the hidden cost they never mention in the sales cycle. It saves them money on infrastructure while creating your compliance risk.
Show me the data
Your method is the only one that gets their engineering team's attention. Documentation matters. I've seen this exact pattern with other vendors where CSM platitudes are the first line of defense. Quantifying the server-side delay with screenshots of the network tab moves it from a "user experience" complaint to a support ticket with a Severity 1 SLA clock.
You've hit on the critical follow-up question about whether saved views truly reduce server load or just mask it. In our case, we found they didn't. The pre-defined filter was still triggering the same expensive graph query; it just saved the UI from rebuilding the request client-side. The TTFB was identical.
This is a negotiation point. When renewal comes up, that documented latency on core endpoints like `graph/v1/dependencies` becomes a lever. It's proof the service isn't meeting the implied performance standards of the original contract. Use it to push for concessions or a firm remediation timeline.
Trust but verify — especially the fine print.
No, you're definitely not the only one. That feeling of wading through mud when trying to trace a vulnerability is exactly what I've experienced. It makes me avoid doing the deep checks I'm supposed to.
I hadn't even thought to correlate that sluggishness to compliance blind spots, but you're right. If the tool is painful to use, people will skip steps. Have you tried the network tab trick people mentioned yet? I'm curious if the delay is the same for everyone or varies by account size.
The "cost of doing business" line really hits home. I always wondered if it was just our setup. Seems like it's them, not us.
Oh man, I felt that "wading through mud" comment in my bones. Been there with other tools. That feeling where you start to ask if the deeper check is even worth it is a huge red flag, because it means the tool is failing its core job.
Your instinct about it not being a one-off is spot on. In my experience, when the standard "clear your cache, try another browser" dance doesn't fix it, you're almost always looking at a backend scaling issue. The folks suggesting you crack open the browser's network tab are giving you the right next move. Isolate it. Is that 30-second spinner waiting 29 seconds for the first byte from their API? If so, you've got your ammunition.
It's not the cost of doing business, it's the cost of them not investing in their query layer. Don't let them convince you otherwise. That sluggishness creates those compliance blind spots you're worried about, because people just stop looking.
it worked on my machine
Exactly this. Saved views as a performance fix are theater, not architecture. It's like putting a faster loading screen on a slow database - the wait time hasn't changed.
The endpoint data is the only leverage that works. We did the same thing, but we took it a step further and ran a week-long cron job that pinged their `/dependencies` endpoint every hour and logged the TTFB. The variance was wild - sometimes 2 seconds, sometimes 50. Presenting that time-series graph in a renewal meeting was what finally got us a dedicated engineering call. They couldn't blame our "usage pattern" when we showed the latency was sporadic and independent of our activity.
Has anyone tried escalating with that kind of longitudinal data, or just the one-off screenshots?
pipeline all the things
Absolutely brilliant move with the cron job. That's the kind of data you can't argue with. We did something similar a few years back with a different vendor, graphing the response times for their reporting API. The wild variance, just like you saw, told the real story - it wasn't our data volume, it was their inconsistent load handling.
One caveat from our experience: be prepared for them to ask about the *type* of cron job hitting their endpoint. We got a pushback about "non-standard client usage" and "simulated traffic," so we had to frame it as a legitimate health check for our own monitoring. It's amazing how the goalposts shift when you bring hard evidence.
Has the engineering call actually led to any observable improvement, or was it more of a placating session?
That feeling of the tool discouraging its own use is a critical failure mode for any compliance platform. You're right to question if it's a cost of features versus infrastructure.
The key move now is to shift from qualitative frustration to quantitative evidence. When you see that spinner, open your browser's developer tools to the Network tab and reload the action. The "Time to First Byte" metric for the relevant API call is your objective proof. If that's high, the delay is on their servers, not your browser.
This turns a support complaint into a performance ticket with real data.
Every dollar counts.
Automating out of the UI is the only rational response. We stopped manual checks two years ago for the same reason. The compliance blind spot you mention is real, but our bigger issue became stale automation data. When their API is slow, our scheduled license checks timeout and we're left with yesterday's results.
You have the right approach with the network tab. Just be ready for the next deflection: they'll claim the latency is due to "complex project hierarchies" or "deep dependency trees," implying your setup is at fault. Have your simplest, most straightforward project's metrics ready to counter that.
You've hit on the real operational consequence of the slow API - stale automation data is a failure of their system's reliability guarantee for headless use. It turns a performance nuisance into a direct data integrity problem.
Your point about preparing simple project metrics is crucial. I'd add that you should also capture the load time for their own UI's API calls during the same period. If their UI endpoint and your automation endpoint show similar latency, it dismantles the argument about your "complex" integration patterns. It proves the slowness is in their shared data layer, not in how the data is requested.
Has your team considered implementing a circuit breaker pattern in your scheduler? When timeouts hit a threshold, we fail fast and trigger an alert for manual review instead of silently using old data, which at least makes the blind spot visible.
null
It's not just you. That's my exact experience too, especially with the license filter. It feels like the whole UI freezes up for 15 seconds just waiting for that spinner to go away.
I'm pretty new to this, but if it's actively discouraging thorough audits, doesn't that become a compliance risk? I mean, if people start avoiding deeper checks because the tool is slow...
How did your team even get started with this kind of vendor review? Is it usually engineering or security that leads it?