michaelneale I looked at this last week, the issue is mostly due to the API times. After some discussion with vivek fetching all the data using the traditional Jenkins object model results in reading a lot of data from disk, potentially including all the runs for all the jobs and more to find the latest and branch count, etc.. At a minimum, we can restrict it to the page asked for, ideally we can use some other optimizations to speed it up significantly more.

kzantow good to know, yes I suspected.

Maybe shoudl leave this open as a place holder for any other investiation related to JENKINS-38253

kzantow as shown by Vivek, the slowness at least in the case of dogfood is NOT due to search and fetching of data from disk

FYI the specific slowness that seems to impact is the last 25% of the worm. I am not sure if this is still script loading or something else (I would love to know) - usually its when loading wihout the cache (but even with...)

I also took a look, even when loading with a warm cache:

Request URL:https://ci.blueocean.io/adjuncts/e4de3771/io/jenkins/blueocean/blueocean.js
Request Method:GET
Status Code:304 Not Modified
Is still nearly a second in time - which seems excessive. Is there a way to not require the not modified - as there is no way it would be modified as the adjuuncts uri makes it unique....

michaelneale yes, there's an "easy" way to optimize resources, in general, using unique urls (already done) and far future expires headers and omitting the etags.

kzantow right - https://github.com/jenkinsci/blueocean-plugin/pull/551 is a PR by tom that sets the cache headers. Will give it a try.

Here are some gifs I made to get a baseline against the roughly equivalent "classic" screen, where blue ocean isn't as snappy as it needs to be:

1) main dashboard:
http://www.giphy.com/gifs/26ufkjzMWkd09D4hW

2) Activity screen:
http://www.giphy.com/gifs/l3vR23VQ30SGdeDAc
(this isn't exactly one to one, as blue ocean is showing across branches).

(ie cold load time to displaying something, ANYTHING, is beyond terrible, its just dire).

3) showing pipeline results:
http://www.giphy.com/gifs/l0MYNT0wNlpnRmNUI
(once again, not quite the same, but a fair comparison I think).

The most prominent bad UX is on cold cache load of course, but I thought I should point out these others.

michaelneale Setting the cache control header has eliminated the if-modified requests. Reports are that the performance has been better since. More work to do on reducing the bundle sizes (ongoing - separate ticket). Maybe ye can close this ticket now?

tfennelly in my screencasts above, it still hasn't improved in each case - ie classic is still faster on a remote connection.

However, the general feel (which is mostly snappy, just not the loading) and cold loading has improved a bit, but cold loading is still quite bad.

Will keep this open to re-check things when JENKINS-38013 is closed. kzantow has marked this as in progress so will check in if he has looked at things (otherwise moving this to the backlog).