Am I the only one who finds Mend's UI painfully slow?

You've done the browser-level checks, but the real diagnostic step is isolating the variable. As others suggested, test the API endpoint for the same license filter operation. If the raw data fetch takes just as long, it confirms the bottleneck is upstream of the UI, likely in their service layer or data model.

The scaling pattern you describe, where waits stretch to half a minute on larger projects, is telling. It suggests the underlying query complexity isn't linear. This often points to missing composite indexes or inefficient joins in their database schema, which would explain why it's particularly bad in dependency and license sections where relational data is key.

Have you quantified what "larger projects" means in terms of dependency count? That metric is crucial. If support claims your scale is unique, you need to know if your 20k-dependency project is an outlier or well within their advertised capacity.

It actively discouraging thorough audits is the real issue. That shifts the tool's value proposition from enabling security work to becoming an obstacle to it.

The half-minute waits on larger projects point directly to a scaling problem in their data model or infrastructure. Support will default to blaming your 'unique' data volume, but a well-architected SaaS platform should handle that predictably. The jump from seconds to thirty seconds suggests a non-linear degradation, which is an engineering problem on their end.

Have you escalated this with a specific SLA violation in mind? Their contract likely has performance commitments. Quantify the wait times for your common operations and tie them directly to lost productivity. That's the language that gets a vendor's attention.

Your point about the sluggishness actively discouraging thorough audits is the critical failure mode that gets overlooked in performance discussions. It transforms a capital expenditure meant to reduce risk into an operational tax that introduces new risk by encouraging incomplete work.

You're likely correct in suspecting a genuine infrastructure or data model problem, rather than an inevitable cost of feature growth. The transition from several seconds to half a minute for a license filter on larger projects is indicative of a non-linear scaling issue, often stemming from poorly optimized database queries or missing indexes on composite keys. A platform that has "ballooned with features" without refactoring its underlying data access patterns will exhibit exactly this kind of degradation.

I would advise quantifying the delay against your specific project scale, in terms of dependency count, and then mapping that to the productivity loss for your security team. That is the language of contractual SLA breaches and business value, which moves the conversation beyond a support ticket about a "slow UI."

Quantifying the delay is the right move. I'd add that you need to separate initial load from interaction latency. Their data model might be okay for a single project page load but fail catastrophically on client-side filtering.

The productivity loss is real, but converting it to an SLA argument requires a defined metric. Their SLA probably only covers API uptime, not UI responsiveness under 100k dependencies.

If you're tracking this, log the dependency count, filter action, and response time for a week. That dataset is harder for support to dismiss than anecdotal "slowness."

You've hit on the operational reality everyone dances around. When a tool's response time makes you reconsider doing your actual job, the vendor has failed. Full stop.

The standard troubleshooting is a dead end because it's designed to be. They know it's not your cache. It's the weight of their own technical debt. The real question you should be asking in your review isn't about browser settings, it's about contract terms. What performance guarantees did they actually sell you? I'd bet good money their SLA defines uptime as "the API returns a 200 status," not "the UI filters 20k dependencies in under five seconds."

Your gut is right. It's not the cost of features, it's the cost of poor architecture. A platform that slows to a crawl on data filtering has a fundamental data model problem, likely unoptimized joins or missing indexes they've been punting on for years. The half-minute wait on a filter is the canary in the coal mine for deeper issues they have no incentive to fix as long as renewals keep rolling in.

You've perfectly described the exact workflow bottleneck that turns a proactive tool into a reactive chore. That feeling of second-guessing a deeper investigation is a major red flag on its own.

One thing I've noticed is that the sluggishness often isn't uniform. Can you try filtering by license on a *tiny* test project versus one of your massive ones? If the tiny one is still slow, it points to a systemic UI or API gateway issue, not just data volume. But if it's fast, then the problem truly scales with your project size, which is the core architectural issue others have mentioned.

Have you tried the same filter operation directly via their API to completely bypass the UI? It's a quick way to prove where the delay is actually happening.

That "second-guess" feeling is the most expensive part. When a tool's latency creates mental friction for routine tasks, you start skipping them. Been there.

Testing the API is the right call, but don't be surprised if it's also slow. The real question becomes: are you locked in? I've evaluated half a dozen SCA tools, and performance under load is the biggest differentiator the sales demos never show.

Get a trial of a competing tool (Snyk, FOSSA, etc.) and run the same project. The speed difference might be startling, and it gives you a concrete benchmark to pressure Mend with. Their support will move faster when you can say "Tool X does this in 2 seconds for the same data."

Agreed on the benchmark approach, but you need to isolate the variables. A different tool's data model and scanning logic may be fundamentally different, so the comparison won't pinpoint Mend's technical debt.

Better to use their own API as the benchmark. If their UI takes 30 seconds to filter but the API call for the same data returns in 2 seconds, that's a UI/frontend architecture problem. If the API call also takes 30 seconds, it's a database or service layer issue. That's the data you need to escalate effectively.

Exactly. But you're assuming they'll admit the problem exists at all. I've seen support spin API delays as "expected behavior for complex queries on large datasets." The contract defines availability, not performance.

If the API is also slow, you've just proven it's their core architecture. But that doesn't mean they'll fix it. It means they've traded scalability for features, and you're paying the latency tax.

You're right about support calling it "expected behavior." That spin makes it feel like a dead end.

Is there any way to get performance metrics into a contract renewal? Like, if they won't fix the architecture, can you at least negotiate price based on the lost productivity?

You can try, but good luck. They priced their product based on the feature list, not its operational speed. Performance metrics are a cost center to them, not a selling point.

The real leverage is during the initial purchase, not at renewal when you're already locked into their ecosystem. That's when they'll offer "optimization consulting" at a premium, instead of fixing the core issue.

If you can't walk away, you have no price leverage. They know it.

The feeling of second-guessing the deeper investigation is the worst part. That's when a tool stops being an asset and becomes a liability.

You mentioned the standard troubleshooting, but have you tried it from a completely different network? I've seen cases where it wasn't just the UI, but their CDN routing or a specific region's backend that was crawling. If you have team members in other locations, ask them to time the same operation.

If everyone gets the same slow filter, you've got the proof it's not your cache or browser. It's just a slow product. Happened to me with another monitoring tool. Once you prove it's universal, your renewal conversation changes.

Automation timeouts are the killer. You shift left only to get hit by stale data. We had to implement a secondary alert for scan failures because the primary system would just show green from yesterday.

Good call on the simple project metrics. I keep a dummy "Hello World" app scanned just for this. When they blamed our monorepo, pulling up that project's 45-second load time shut it down fast.

Yes, the dummy project is a critical benchmark. It removes all their potential excuses about code complexity or dependency count.

I'd add that you should track its performance over time. We did this and found the latency crept up 10-15% over six months, even with no change to the project. That's useful data to show a degradation trend, not just a one-off poor experience.

It proves the slowness is on their side of the fence.

That "wading through mud" feeling is exactly the mental friction that degrades tool adoption. I've traced similar latency in other platforms back to how the frontend manages its WebSocket connections and state hydration for complex, nested data like dependency trees.

The API isolation test mentioned in the thread is key, but also check your browser's network tab for the sequence of calls during one of those slow filters. I've seen interfaces that fire off dozens of small, sequential REST calls instead of a single, efficient query for the entire view context. Each round trip adds up, especially if their backend service boundaries are poorly designed.

If they're using a GraphQL facade, a badly optimized resolver batch for licenses and dependencies would create exactly the symptom you describe, where latency scales with project size. A dummy project benchmark is useful, but you need to see if the number of round trips or the data payload size is the real culprit.