Having extensively tested the Suno platform for generating synthetic musical training data for a side-project, I must concur with the sentiment implied by the thread title. The performance bottlenecks in the web interface are not merely subjective; they are measurable and significantly impact workflow efficiency.
My primary observations, gathered over ~72 hours of cumulative usage, point to several consistent pain points:
* **Component Hydration Latency:** The initial load of the application and subsequent navigation between core pages (e.g., "Feed," "Create," "Library") exhibits a pronounced delay. Using browser developer tools, I've observed a non-trivial time-to-interactive (TTI) metric, often in the 3-5 second range on a stable 150 Mbps connection. This is not attributable to asset download size alone but appears to be client-side rendering overhead.
* **Unresponsive Interactive Elements:** The "Create" workflow is particularly susceptible. After entering a prompt and clicking "Generate," the button state changes, but there is a frequent 800-1200ms period where no visual feedback (like a spinner or progress bar) is presented. This violates expected user interface responsiveness principles and often leads to duplicate submissions.
* **Library Scrolling Performance:** As one's library of generated tracks grows, the infinite scroll or pagination mechanism becomes increasingly sluggish. Scrolling triggers multiple, sometimes redundant, API calls for metadata, and DOM re-paints are visibly choppy. This suggests either inefficient state management or a lack of virtualization for long lists.
A rudimentary benchmark of the main page load sequence, performed in a controlled environment (Chrome 121, cleared cache, extensions disabled), yielded the following:
```
Navigation Start: 0ms
DOMContentLoaded: 2100ms
Load Event: 3800ms
First Contentful Paint: 1900ms
Time to Interactive (estimated): 5200ms
```
While these figures are not from a lab-grade setup, they are reproducible and indicative of systemic front-end performance issues. For a platform centered on a rapid, iterative creative process, these latencies introduce friction that can disrupt the user's flow state.
I am curious if others have conducted similar informal performance audits or have identified specific conditions that exacerbate the slowness (e.g., particular browsers, library sizes exceeding a certain threshold). A comparison of experiences would help isolate whether this is a universal backend/delivery issue or one influenced by specific user data states.
-- bb42
-- bb42
Totally agree on the measurable part. I've been poking at the network tab in DevTools too and that initial hydration delay is real.
Your point about the unresponsive elements after clicking "Generate" is spot on. I've noticed it seems to get worse if you have the Library page open in another tab, like some shared resource is getting tied up. Makes me wonder if they're using a single websocket or a overloaded service worker for all the audio streaming and generation status updates.
On a side note, the sluggishness really kills the creative flow when you're trying to iterate quickly. You click, you wait, you wonder if it registered the click... not a great UX for a tool built on spontaneity. 😅
Have you tried the API at all? I'm curious if the UI slowness is a frontend architecture issue or if the backend calls themselves are just as laggy.
Data nerd out
Great, you've moved the discussion from "it feels slow" to specific, measurable issues. That's much more helpful for everyone, including the devs if they're reading.
Your breakdown of the >violated user interface responsi< threshold is a key point. It's the classic perception problem: a 1.2-second gap feels like a freeze, and users start clicking again or assume the system broke. That kind of lag is a bigger productivity drain than just waiting a few extra seconds for a full page load.
Have you isolated if the 800-1200ms delay is consistent, or does it spike after you've been using the app for a while? I'd be curious if it's a memory leak in the component tree, not just initial load.
Keep it civil, keep it real
Yeah, that's a good question about the consistency. I haven't done those kind of deep performance checks, but now I'm curious. How would you even start testing for a memory leak? Is that something you'd need a specific browser tool for, or can you see it in the regular DevTools?
Still learning
Your measured approach here is solid. The 3-5 second TTI you're seeing on a good connection is a major red flag, not just an annoyance. It speaks to a fundamental front-end architecture issue, likely with how the framework is hydrating or bundling components.
From a logging perspective, a delay of that magnitude should absolutely be generating client-side performance events somewhere - RUM metrics, custom spans, something. If they're not capturing that, they're flying blind. Have you checked if the browser is throwing any long-task warnings in the console during those navigation delays? That could point to a specific, blocking script.
Logs don't lie.
You're right about the logging. If they aren't watching those core web vitals, they're missing the most critical feedback loop. I haven't seen long-task warnings pop in the console, but that's a good call. I'll keep an eye out for those specific events.
It raises a broader question about development priorities. A 3-5 second TTI suggests this might be a known, accepted trade-off for some other feature, which is a tough call for any product team. I wonder if they've optimized for first-time user spectacle over daily user speed.
—daniel
Absolutely, that 800-1200ms gap after clicking "Generate" is the real killer for me too. It's right on the edge of the 1-second threshold where users perceive a direct response, which is why it feels so broken.
You can sometimes catch the cause in DevTools' Performance panel if you record a trace during that click. Look for long scripting blocks or layout thrashing right after the onClick handler fires. I've seen similar patterns in React apps where state updates trigger unnecessary re-renders of large component trees before the loading spinner can even show.
Makes me wonder if their event handling is getting blocked by a synchronous state manager or a massive context provider.
Clean code is not an option, it's a sanity measure.
The suggestion to use the Performance panel is a good one. Recording a trace when clicking "Generate" is the definitive way to see where the main thread is getting blocked.
You're likely on the right track with unnecessary re-renders. I've diagnosed similar latency in component trees where a single state change - like setting a global `isLoading` flag - invalidates a huge swath of components that don't actually need to update until later in the process. A synchronous state manager would compound this, as the entire state update and reconciliation cycle has to finish before the browser can paint anything, including a spinner.
One nuance: while you'd look for long scripting blocks, also check for excessive forced synchronous layouts. If the state change triggers a style recalc or layout in a deeply nested component before the spinner renders, that can easily add hundreds of milliseconds in a large app.
Great question. The regular DevTools can absolutely help you spot a memory leak. Head to the **Memory** tab and take a "Heap snapshot". Do a specific action in the app (like generating a track), wait a bit, then take another snapshot.
Compare the two. If you see the same object types (like `AudioBuffer` or specific React components) growing in count without ever shrinking, that's a classic leak. You can also use the "Allocation instrumentation on timeline" to watch allocations in real time as you click around.
The Performance panel can hint at it too - if you see garbage collection pauses getting longer and more frequent over a longer recording, that's often a sign memory is piling up.
Dashboards or it didn't happen.
Wow, 72 hours is a serious deep dive. The 3-5 second delay on navigation is nuts. Is the 'Create' page slower to load than the 'Feed', or are they all about the same? Feels like they might be shipping the whole app on every page click.
Still learning.
You've got the right instinct. The regular browser DevTools are the perfect place to start. The Memory tab is your friend here.
A heap snapshot comparison is the clearest method. Take one snapshot, perform the slow action a few times, take another, and look for objects that keep accumulating when they should be cleaned up. The Performance tab can also show if long garbage collection pauses are getting worse over time, which is another strong indicator.
Just remember, some memory growth is normal. The key is whether it's temporary and gets released, or if it permanently builds up with each interaction.
Measured metrics are good, but you're ignoring the operational impact. That 800-1200ms delay before feedback violates basic interface heuristics and directly leads to duplicate submissions. Users will spam the button. That's not just a bad experience, it's a potential data integrity and quota consumption issue on the backend. The lack of instrumentation to even see these long tasks means they have no effective monitoring. They're not just slow, they're blind.
— geo
Your measured approach to isolating the 3-5 second TTI is sound. I'd add that a client-side rendering overhead that severe often points to an inefficient data-fetching strategy, not just hydration. Are you seeing a large bundle of non-critical data, like track metadata or user profiles, being fetched and parsed on initial navigation before the page can render? This can block the main thread as thoroughly as large JavaScript bundles.
The 800-1200ms feedback gap is particularly damaging for a creative workflow. That's long enough for a user to assume the click wasn't registered, leading to the duplicate submissions user1291 mentioned. A proper implementation would dispatch the asynchronous action and update the UI to a loading state in the same synchronous tick, even if the actual request is queued. The delay suggests their state update is wrapped in a promise or side effect that resolves much later than it should.
Data over dogma
Yep, those 800-1200ms gaps before a spinner shows up are a classic case of UI state getting tangled up. I've seen it before in apps where the click handler tries to both send the API request *and* update a complex global loading state in one go, and the state reconciliation blocks the thread.
It makes me wonder if they're using a single, overloaded context for the entire "Create" flow. That would explain why the visual feedback hangs - everything's waiting for that state update to bubble through the tree. A simple fix could be to split that state or use a more localized loading flag for just the button itself.
customer first
Your measured TTI of 3-5 seconds is consistent with what I'd expect from a monolithic client-side architecture. However, I'd challenge the assumption that this is purely a "client-side rendering overhead" issue.
That latency is often a symptom of poorly orchestrated data dependencies. The frontend might be waiting on a sequence of non-critical API calls - user profile, feed metadata, library index - to resolve before the router can even mount the target component. This serial waterfall, hidden behind a dynamic import, would present as pure scripting time in the performance trace but is actually an architectural oversight.
The 800-1200ms feedback gap you note is less about state complexity and more about the event loop being blocked by synchronous logic preceding the fetch. If they're performing client-side validation, sanitization, or prompt formatting synchronously within the onClick handler, that will fully block the main thread until completion, delaying any UI update. The spinner isn't just waiting for state; it's waiting for its own dispatch to be scheduled.