-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
In case of a lot of traces the UI hangs for a bit #1980
Comments
The browser should cache those, shouldn't it? |
It does not look like it uses the cache. |
Might be some missing cache control headers... |
Indeed. I'm reading about the Stay tuned... |
Now that caching is enabled, the opening still takes a long time. There seem to be two consecutive "batches" of thumbnail requests delayed by about 9 seconds. Until the second batch is completed, the track list does not respond to the user. The images requested of the first and second batches are identical |
I'll add those in the backend API definition, it won't be configurable, but it shouldn't change much. If you think there should be other numbers let me know before I commit and close this issue. |
I've added cache control, but the problem is in the UI when syncing the traces. |
Testing this locally shows good improvement, but I think my machine runs faster. |
What is the problem this feature will solve?
It takes more than 10 second for the "My Recordings" list to be ready., i.e., the spinner stops.
What is the feature you are proposing to solve the problem?
Allow the client to cache the pictures it receives from the server
What alternatives have you considered or tried?
None
Additional information
The text was updated successfully, but these errors were encountered: