Workbench responsiveness¶

Notes on Workbench performance/caching from brainstorming meeting 2024-09-04

• Currently the store is our cache, and it caches individual objects (key is UUID)
  • When opening an object in a new tab, it might be easy to use postMessage to pass the current store contents to the new tab to speed things up
  • Each data explorer has its own store key, so (for example) we store "page of project listing" rather than "page 1 of project A listing with filters xyz"
  • We could start using the store to cache list responses (key is request URL with all params?)
  • We could pre-fetch and cache the next page of a listing before the user even clicks the "next page" button
  • Currently the store grows indefinitely, so if we use it more, we'll need an eviction strategy
  • We could save timestamps in the store so we don't re-fetch on every page view when navigating back and forth quickly
• In theory, web workers could implement an HTTP cache shared between tabs
  • Lisa has some experience with web workers that didn't go well (ended up bailing), but would be willing to look into it again
  • Tom hasn't tried it but remembers reading that the mechanics of installing/updating the web worker code is non-trivial
  • Would presumably be disabled for most of the test suite
• Collection file listings are slow because XML decoding is slow, and we don't use the store to cache them
  • We could start caching the (decoded) listings in the store
  • We could add a JSON format option to keep-web to skip XML encoding+decoding entirely (Workbench doesn't need to support arbitrary WebDAV servers, after all)