Workbench responsiveness » History » Version 1
Tom Clegg, 09/04/2024 07:16 PM
1 | 1 | Tom Clegg | h1. Workbench responsiveness |
---|---|---|---|
2 | |||
3 | Notes on Workbench performance/caching from brainstorming meeting 2024-09-04 |
||
4 | |||
5 | * Currently the store is our cache, and it caches individual objects (key is UUID) |
||
6 | ** 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 |
||
7 | ** 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" |
||
8 | ** We could start using the store to cache list responses (key is request URL with all params?) |
||
9 | ** We could pre-fetch and cache the next page of a listing before the user even clicks the "next page" button |
||
10 | ** Currently the store grows indefinitely, so if we use it more, we'll need an eviction strategy |
||
11 | ** We could save timestamps in the store so we don't re-fetch on every page view when navigating back and forth quickly |
||
12 | * In theory, web workers could implement an HTTP cache shared between tabs |
||
13 | ** Lisa has some experience with web workers that didn't go well (ended up bailing), but would be willing to look into it again |
||
14 | ** Tom hasn't tried it but remembers reading that the mechanics of installing/updating the web worker code is non-trivial |
||
15 | ** Would presumably be disabled for most of the test suite |
||
16 | * Collection file listings are slow because XML decoding is slow, and we don't use the store to cache them |
||
17 | ** We could start caching the (decoded) listings in the store |
||
18 | ** 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) |