There were few underlying issues. One being related to how favorites were rendered (affects logged in user with long build history) and the other had to do with unnecessary and expensive data returned as part of latestRun field.

Fix is in review stage and should be merged soon. See https://github.com/jenkinsci/blueocean-plugin/pull/1638 and  https://github.com/jenkinsci/blueocean-plugin/pull/1635.

jimklimov Ill close this against the issues quoted by vivek (likely to be the cause).

However, would be great to capture a HAR file of specific page loads and capture a support bundle to help us diagnose these problems. We know there are optimizations to be make but we need specific info

Added HAR and respective screenshots (console is rather empty and uninteresting, but load times are spectacular).

UPDATE: Added somewhat redacted support data.

Statistics-wise, at the moment there are about 40k builds stored in history (and yes, much of the time spent in rendering BO can be Java walking the filesystem to find and parse all that build data):

[root@jenkins2 jenkins/jobs]# sync; echo 3 > /proc/sys/vm/drop_caches
[root@jenkins2 jenkins/jobs]# find . -name build.xml | wc -l
39847

real    12m40.689s
user    0m12.259s
sys     0m36.710s

and 94 known "users" (many of which were auto-registered from upstream/3rd party projects' commits that were built here; about 20 actual internal users). Listing $JENKINS_URL/view/Masters/asynchPeople/ or going into the active users and listing builds they are associated with at $JENKINS_URL/user/myusername/builds also takes several minutes, at least first time after a filesystem cache flush for cleaner results (and comparably long with a "dirty" cache too).

The system is a KVM VM, has 4Gb RAM assigned and about 1.3Gb of that is free. I'll try bumping it to 8Gb so more FS (meta)data can be cached, at least...

vivek - jimklimov has provided some HARs and a support bundle, so it should be possible to see the problem he is experiencing now.