With a hard refresh https://ci.blueocean.io/blue/pipelines/ took 6 seconds to load.

Theres a decent delay when pages loading but I'm not sure how long is acceptable.

Also the empty state flashes up when opening a pipeline which is a little jarring

http://d.pr/i/1bPZC

brody yes the empty state flash is known and being fixed.

I guess acceptable was more in your judgment compared to other rich web apps that are on the other side of the world, that you use (blue ocean has to reload more than is relistic, as there are daily deploys belowing away any caching).

6 seconds seems ok if a hard refresh - that seems like it is using the cache still somehow (if you use incognito, surely it is more like 20 to 30 seconds?)

In that pie chart, what is "scripting"?

These are the scripting culprits

Incognito didn't take much longer. I tried in a diff browser and took < 12s.

I ran it through Pingdom which took 3.25s
https://tools.pingdom.com/#!/1ilTA/https://ci.blueocean.io/blue/pipelines/

When doing https://github.com/tfennelly/generator-blueocean-usain I see that the generated javascript bundle is f***ing huge .... 1.2Mb for a simple extension. We need to dig into this again and see what's bloating things now.

tfennelly good point, I opened: https://issues.jenkins-ci.org/browse/JENKINS-39048 for this - but if you think its the same thing, just close it as a duplicate of this ticket (there are likely a few things going on). FYI dashboard is currently at 1.7meg (which wouldn't be surprising if 1.2 is stuff bundled in that isn't specific to the actual plugin).

michaelneale Personalization is about 1.9Mb

phwoar...

This ticket has morphed a bit. We have fixed the serious bloating of some of the bundles e.g. personalization is now back down to 0.6 Mb (from 1.9Mb). However, we are looking into the possibility of more completely externalizing dependencies (react etc) into bundles formed from an entry module that lists all the JS in the package Vs just listing the "main" entry module (module listed in "main" property of package.json). With that then we can hopefully do 2 things:

1. Completely remove all dependencies (react etc) from our "app" bundles, which will hopefully reduce them in size considerably. No sneaking into the bundle through the back door
2. "Install" dependencies (react etc) in the browser localstorage. Once "installed", these bundles never need to be downloaded again. Not sure if there's actually a big win to be made here Vs just relying on the browser cache (via cache control headers). What would certainly be eliminated is the "if-modified" requests that are made (fairly sure ... forget exactly) if you hit the hard reload in the browser + the full reload requests that would be made on a Jenkins restart (after adjunct and static URLs change). I think we might need to try this out to see if that makes a worthy improvement.

agree tfennelly to both points. Hard to say about local storage but worth a try.
Reducing size == reducing computation too. The most problematic thing now is mostly the cold load time (as it is often cold, eg after a restart where the URI changes for assets) - I am not sure if #2 helps with that (curious though)

Closing this and opening JENKINS-39646.