Performance is poor.
Closed this issue · 7 comments
An audit by Chrome rates performance 16/100.
Tasks
- Add filters as a batch
- Add records as a batch
- Add fields as a batch
- Look into other areas for performance improvements
- compress (gzip) spectrum requests once we are in staging/production environment.
What is your sense of the time (back-of-envelope estimate) investigating the causes will take?
Everytime a record, filter, holding, field, or anything stored in application state is loaded in, the front end has to see if the UI should also be updated. DOM updates are the most costly. What I think I need to do is instead of adding one filter, field, record, and so on at a time is look for ways to add those in batches.
Add field, check and update UI, add field, check and update UI...
vs.
Add all fields, check and update UI.
Back of envelope estimate this would take two weeks of focused time. Or longer if for some other unknown reason performance is poor.
@bertrama Running Chrome's audit tools. Would it make sense to compress Spectrum requests?
The application was freezing as it loaded thousands of filters one at a time. Commit 044d92c loads them all at once, fixing that problem.
@jonearley Getting api responses gzipped might require changes to the apache configuration; we'd have to work with A&E for that. Since we're using a legacy configuration in development right now, I'd rather wait until we have a staging environment and work on it there.