Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-38013

Profile and minifi blue ocean loading

    XMLWordPrintable

    Details

    • Similar Issues:
    • Epic Link:
    • Sprint:
      pacific, atlantic, 1.0-b05/b-06, indian, arctic

      Description

      It is worth investigating the where the load time is for blueocean, and then consider optimising.

      Minification is a logical third step (although this will bring other challenges).

      In scope:

      • Investigate loading/profile loading
      • Optimise loading
      • Minification if necessary

        Attachments

          Issue Links

            Activity

            Hide
            michaelneale Michael Neale added a comment - - edited

            Tom FENNELLY just thought I would park this in case you feel the need for speed. I also recall you saying something once about ajuncts being "slow" to serve data (which may be a part of things as bundles get bigger)

            Show
            michaelneale Michael Neale added a comment - - edited Tom FENNELLY just thought I would park this in case you feel the need for speed. I also recall you saying something once about ajuncts being "slow" to serve data (which may be a part of things as bundles get bigger)
            Hide
            jamesdumay James Dumay added a comment -

            Tom FENNELLY it looks like resources such as icons and fonts get reloaded often too. Could you investigate that as part of this? Ideally we would only bust the cache on these when the Blue Ocean version changes.

            Show
            jamesdumay James Dumay added a comment - Tom FENNELLY it looks like resources such as icons and fonts get reloaded often too. Could you investigate that as part of this? Ideally we would only bust the cache on these when the Blue Ocean version changes.
            Hide
            michaelneale Michael Neale added a comment - - edited

            As mentioned in an email, on resources:

            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....

            this may be another possibility to improve things - perhaps cache headers, or something else. The way jenkins works is these js things don't ever need to be checked if they are modified (I think).

            Show
            michaelneale Michael Neale added a comment - - edited As mentioned in an email, on resources: 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.... this may be another possibility to improve things - perhaps cache headers, or something else. The way jenkins works is these js things don't ever need to be checked if they are modified (I think).
            Hide
            tfennelly Tom FENNELLY added a comment -

            Btw Mic (Michael Neale) ... are you Aussies seeing a better page performance since we added the cache-control header?

            Show
            tfennelly Tom FENNELLY added a comment - Btw Mic ( Michael Neale ) ... are you Aussies seeing a better page performance since we added the cache-control header?
            Hide
            michaelneale Michael Neale added a comment -

            Tom FENNELLY subjectively, yes. Perhaps Brody Maclean can comment too - as he uses it daily to verify things.

            The time to displaying content is still quite slow (even with cache warm), ie noticable (this is also the same even without network latency, interestingly, so that is probably search related).

            The cold load time (ie when not in cache) is just diabolical though - no where near acceptable.

            Show
            michaelneale Michael Neale added a comment - Tom FENNELLY subjectively, yes. Perhaps Brody Maclean can comment too - as he uses it daily to verify things. The time to displaying content is still quite slow (even with cache warm), ie noticable (this is also the same even without network latency, interestingly, so that is probably search related). The cold load time (ie when not in cache) is just diabolical though - no where near acceptable.
            Hide
            tfennelly Tom FENNELLY added a comment -

            Michael Neale

            The cold load time (ie when not in cache) is just diabolical though - no where near acceptable.

            I assume you are talking about ci.blueocean.io there? Doing a few laps of the globe getting JavaScript.

            Show
            tfennelly Tom FENNELLY added a comment - Michael Neale The cold load time (ie when not in cache) is just diabolical though - no where near acceptable. I assume you are talking about ci.blueocean.io there? Doing a few laps of the globe getting JavaScript.
            Hide
            michaelneale Michael Neale added a comment -

            Tom FENNELLY yeah that is clearly part of it, but you try it yourself and see if it is "reasonable" for you (is it?)

            Show
            michaelneale Michael Neale added a comment - Tom FENNELLY yeah that is clearly part of it, but you try it yourself and see if it is "reasonable" for you (is it?)
            Hide
            brody Brody Maclean added a comment -

            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

            Show
            brody Brody Maclean added a comment - 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
            Hide
            michaelneale Michael Neale added a comment -

            Brody Maclean 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"?

            Show
            michaelneale Michael Neale added a comment - Brody Maclean 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"?
            Hide
            brody Brody Maclean added a comment -

            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/

            Show
            brody Brody Maclean added a comment - 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/
            Hide
            tfennelly Tom FENNELLY added a comment -

            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.

            Show
            tfennelly Tom FENNELLY added a comment - 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.
            Hide
            michaelneale Michael Neale added a comment - - edited

            Tom FENNELLY 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).

            Show
            michaelneale Michael Neale added a comment - - edited Tom FENNELLY 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).
            Hide
            tfennelly Tom FENNELLY added a comment -

            Michael Neale Personalization is about 1.9Mb

            Show
            tfennelly Tom FENNELLY added a comment - Michael Neale Personalization is about 1.9Mb
            Hide
            michaelneale Michael Neale added a comment -

            phwoar...

            Show
            michaelneale Michael Neale added a comment - phwoar...
            Hide
            tfennelly Tom FENNELLY added a comment - - edited

            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.
            Show
            tfennelly Tom FENNELLY added a comment - - edited 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: 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 "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.
            Hide
            michaelneale Michael Neale added a comment -

            agree Tom FENNELLY 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)

            Show
            michaelneale Michael Neale added a comment - agree Tom FENNELLY 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)
            Hide
            tfennelly Tom FENNELLY added a comment -

            Closing this and opening JENKINS-39646.

            Show
            tfennelly Tom FENNELLY added a comment - Closing this and opening JENKINS-39646 .

              People

              Assignee:
              tfennelly Tom FENNELLY
              Reporter:
              michaelneale Michael Neale
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: