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

Profile and minifi blue ocean loading

    XMLWordPrintable

    Details

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

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