When you look at Jira using Chrome DevTools there are these big batch.js and batch.css files (up to 5MB in total) that are different for every type of Jira view (dashboard, agile board, issue detail, issue search, …) so the first few page loads might be a bit slow but then they all should be cached as they don't change until you update your Jira and everything should be smooth. Except that wasn't what I saw, they seemed to be reloaded every hour or something.
Naturally I blamed Jira, and wasted hours Googling for batch.js not being cached, but eventually came to the conclusion that it can't be Jira's fault, and it isn't. Turns out it's the Google Chrome's cache backend that's used on Linux (and only there). There are three issues with it:
1. it's limited to cca 320MB even if you've got 1TB free space
2. entries are evicted by age times size, ignoring number of hits
3. media files such as 2MB youtube fragments use the same cache
The result is that watching youtube for a while evicts all cached batch.js. To make this bearable, I enabled gzip in the reverse HTTP proxy in front of Jira, which brought batch.js down to 500KB so that it's smaller than the youtube fragments and isn't evicted sooner than those. Still, few hours of watching youtube and not visiting Jira evicts it. Increasing the cache size using "google-chrome --disk-cache-size=2000000000" helps as well.
Oh and here's the link to Chromium issue tracker: https://bugs.chromium.org/p/chromium/issues/detail?id=617620 :-)
But my key anecdote is about loading the notifications sidebar after the page has loaded, there shouldn't be any customizations in there. But I dunno, maybe Jira gives managers a bit too much rope with which to hang their development teams.
This reinforces for me that JIRA should always be self hosted.
In previous job we used jira cloud and it was terrible.
Meanwhile my browser can load, render, and scroll a 4000 line colored diff in less than half a second (e.g. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...)