On Analyzing HAR file, looks like Job config history plugin actions are causing this slowdown. Brief look at this plugin code tells the history is not cached so each history item results in to read from file system. I could reproduce it locally where just couple of freestyle jobs with config history of in 30 or 40 resulted in almost 8 to 9 times degradation.
Marley Kudiabor is it possible for you to set max number of config history visible per page to lets say 5 or so to see if it makes difference. At least it will validate the theory. You can find it at Manage Jenkins->System Configuration -> Job Config History -> Advanced -> Max number of history entries to show per page.
At present going over favorited items (26 of them) have config history items all the way from 3 to 143.
Here are the size of job config history items per pipeline.
[17, 3, 7, 3, 11, 11, 4, 30, 143, 14, 4, 7, 3, 8, 4, 12, 13, 24, 4, 20, 4, 11, 9, 53, 17, 11]
On blueocean side of things: Actions could bring such performance issues as blueocean currently is fetching them eagerly, which is bad. To fix it we need to have UI provide filter using tree api of search (/blue/rest/search API). Prefetch is different, here it's server side generated HTML with generated favorite list, it needs to be fixed so that it processes UI provided tree parameters in /blue/pipeline/ HTTP call to generate list of favorites.