Thanks for the report. FWIW: This is a result of a combination of the page refreshing to see if the In Review lock has been removed and a cautious/blind script reload strategy. (Your screenshot doesn't show it but there should be repetitive POST calls to dataset.xhtml happening as well.) Despite the fact that datasets stay In Review for a relatively long time, we treat the In Review lock the same way as we do for normally short-lived ones like Ingest or Publication locks - by refreshing the page every few seconds to see if the lock is gone. Whenever the page is refreshed, the scripts are reloaded/rerun to assure the display is correct (in case the partial page reload covers a part the scripts affect - metadata fields, search facets, the summary section, etc.). In general, we want the scripts to reload for that reason, but with In Review locks, I don't think the parts of the page where the scripts run get reloaded.

One useful option for In Review locks (and perhaps even other lock types like Ingest with large files or publish with many large files where the lock may stay for an hour+) would be to slow down how often the check for the lock is made, and/or do a check that doesn't involve updating parts of the page.

W.r.t. the ext. vocab scripts in particular - there might be a way to check to see if relevant parts of the page are affected before requesting that they get reloaded, versus sending them for any reload.

In terms of overall effect, the extra reloading should be minor in that the scripts should be cached by the browser, and, if there's no new field written into the page that they would affect, they do a quick check and stop.

My guess is that we probably won't want to fix this in the current UI but will aim for a different approach in the SPA. If anyone is interested in making changes now, I'd suggest making the page refresh slow down as the lock remains for a longer period. (That would probably be simple and be a general performance boost/reduce load on the server, whereas trying to only load the scripts when needed may be trickier and probably wouldn't affect performance much.)

Thanks for the explanation, it's much clearer now.

Of course it's not a priority, I just noticed it by chance while working on external vocabulary. The page stayed open for a while and the memory used by Firefox was swollen and the PC's fans were spinning (or maybe it was just Windows).

FYI - since QDR uses 'In Review' I went ahead and added an exponential backoff to the refresh in #11269. I picked a 5 second start time that backs off to 8, 11.6, ~16 seconds, ... off to a 5 minute max refresh time.