vivek why would font files be served up so slow via stapler? 

Attached my screenshot from Firefox 57, where I am pretty consistently seeing 1s+ load times on .woff files.

Using a Code Valet build, fwiw:

1.4.0-beta-1-SNAPSHOT (private-2c915714-root)  · Core 2.95-SNAPSHOT (private-12/12/2017 21:29 GMT-jenkins)  · 2c91571  · 12th December 2017 03:37 PM

Oh, for context on my load times. These are on a Jenkins instance which has *zero* Pipelines or Jobs, so this is how long it's taking (~6s) to load the "Welcome to Jenkins, it's time to create your first Pipeilne" screen in Blue Ocean

I will investigate this further, but off the top of my head, each browser has a limit on how many concurrent background HTTP requests it will make against the same hostname. My recollection is that they're reasonably high (at least 8 in modern browsers?) but I wonder if that limit could be causing issues for us. I will have to do some research and see whether the timeline includes time the request is blocked by this limit, which could be driving the massive load time for fonts (and also explain why it appears fairly fast in Chrome but ridiculous in FFX).

rtyler if you could export a .har of your Firefox network snapshot it'd be helpful. I'm going to try to repro on my own anyhow.

I haven't yet figured out how to get a .har out of the Developer Tools in Firefox.

Right click anywhere under the "File" column and then "Save All as HAR"

I spent some time analyzing the .har that Tyler sent me privately, and also performing some throttled loading ("Fast 3G" speed) of the app locally in Chrome. The TL;DR is:

1. I don't think anything odd is going on with the fonts. I don't see any slowdown with them locally (throttled) or in Tyler's .har.
2. The rest of the staggered waterfall is a symptom really of how Blue Ocean loads assets which I know Keith is aiming to fix sometime "soon." In 1.4 this got slightly worse since JDL and CoreJS are split out from the main blueocean.js as their own bundles.

For those interested here's an explanation of the waterfall

1. Initial page loads
2. script tags (for JS) and link tags (for CSS) for the JDL, blueocean-core-js and blueocean are added to document body, triggering load of those assets
3. fonts are loaded as side-effect of JDL's CSS loading
4. SSE connection is initialized as blueocean-core-js initializes
5. i18n bundle for blueocean-web module (contained in blueocean.js) is loaded as that bundle initializes
6. blueocean-web init continues and programatically loads any bundles that contribute to "routes" XP: this triggers loading JS for blueocean-dashboard and blueocean-pipeline-editor because those plugins contribute routes. You can see this linkage by examining script tag within head written by preloader that dumps out js-extensions; "jenkins.main.routes"
7. Async loading of those plugins CSS and i18N bundles begin (note: not 100% confident whether this is triggered at same time as JS loads, as as a side-effect of the JS having loaded)
8. React bootstraps and renders the matching route which typically is "pipelines"
9. On initial render of pipelines screen, render of "top" extension point detects dependency on "blueocean-personalization" and loads JS bundle
10. (also possibly loads CSS and I18N)

I think there are some open questions about exactly what triggers CSS and I18N loading: I thought Tom had implemented a change to force it to be loaded at the same time as the JS bundle and block init of the JS until it was loaded (to avoid screen repainting) but I think this was either not implemented or may have bugs based on some of the screen flicker bugs we've seen and order of things in network panel.

I am closing this as I consider it done - I know kzantow will have all this in mind with future enhancements. Would be good for cliffmeyers to keep a mental/paper note of the findings here so we can revisit in in future (but any fixes will be intuitively obvious anyway...)