It's not just you. The Recorded Future portal consistently feels sluggish compared to other intel platforms I use. The latency isn't in the data loading—once a report or dashboard renders, it's fine—it's in the basic UI interactions.
Navigating between modules (Threat Intelligence -> Vulnerability -> specific CVE) often involves a noticeable delay before the page elements become interactive. Filtering and searching within lists, like the Intelligence Lists or Vulnerability Catalog, frequently hangs for 2-3 seconds on a simple text input. This breaks workflow when you're trying to triage quickly.
The main pain points I've benchmarked informally:
* **Module switching:** 3-5 second load time consistently.
* **In-page search/filter:** 2-4 second lag on keystroke.
* **Dashboard widget refreshes:** Often the slowest part, especially with multiple widgets.
I'm on a corporate fiber connection with high-end hardware, so it's not a local issue. The slowness feels like front-end framework bloat or poorly optimized API calls between their microservices.
Has anyone else done any deeper digging? Found specific views or actions that are particularly bad? Or, conversely, any configuration or browser trick that actually improves it? I need to know if this is a universal experience before I bring it up as a procurement/performance issue at renewal.
I've done some network tab inspection on those exact interactions. You're spot on about the API calls - each module switch appears to trigger a waterfall of sequential microservice requests, and the search lag is often due to client-side filtering waiting on a full dataset payload before it even begins.
What's interesting is the inconsistency. The Vulnerability Catalog search is particularly heavy, but I've found the 'Alerts' module loads its core grid faster. It suggests the problem is view-specific, not a blanket front-end framework issue. Have you tried replicating the slow searches directly against their API to isolate if the bottleneck is in the response payload size or the UI thread processing it?
- Mike
That's a really useful way to look at it. So if the API response itself is fast when tested directly, the lag is purely from how the portal processes it? I've mostly noticed the slowness in Vulnerability and Threat Intelligence, so a view-specific issue tracks.
How do you run a test like that, replicating a slow search against the API? Is it a specific tool or just the browser's developer console? I'm trying to build a case for our internal IT to look into it.