WLN javascript routing design choice

Hi

I am learning the way javascript files are downloaded to the client side, so please correct me if I am wrong.

- Each vertical has a file called Cobalt.${vertical}.Common.js file.
- This contains a list of all javascript files for the vertical.
- This file is read at runtime and the files are resolved when ever a vertical's page is loaded; downloaded for all pages that the vertical owns that is.
- So, no matter how many pages a vertical owns, all the javascript files defined under the vertical are downloaded for each page.

I know they are no real worry about number of files downloaded here. Never the less, my question is, why vertical based routing and not page based routing and hence saving on render time and resources ?

To be more precise

Common file currently takes an array of relative urls

    var includes = [];
    includes.push("/External/Laconic/laconic.js");
    includes.push("/Platform/js/v1/Alerts/Cobalt.Alerts.Utils.js");
    includes.push("/Platform/js/v1/Alerts/Cobalt.Alerts.Constants.js");
    includes.push("/Platform/js/v1/Alerts/Cobalt.Alerts.ListItemRenderer.js");

The page based routing could replace the array with a map like this


{
    "page url 1":[
        "javascript file 1",
        "javascript file 2"
    ],
    "page url 2":[
        "javascript file 3",
        "javascript file 4"
    ]
}

Website code could then read the common file and get the array of javascript files that are needed for a particular url from each vertical. This would reduce the number of javascript files loaded for each page by a significant percentage.

Find more posts tagged with

javascript

refinitiv-internal

Accepted answers

Ryan Morlok

One component of this design decision is that those common files you mention are used to create an aggregate JS file. As you noted, when this file is loaded in CI (or when you append /debug on the JS URLs on the routing page in higher environments) the script actually loads each individual file, however generally file is used to create a combined JS file that is the concatenation of the minified versions of all the JS files listed.

This combining is done at static content build time, and the idea is that once the user has loaded this file once, it is cached forever (we change the path of static content as new builds roll through) so we take the hit to load it once and then it doesn't have to be loaded for each page.

All comments

Ryan Morlok

shaggyalien

Did know about the minification and combining of javascript files into one file, but I guess there is not really a performance issue here to fix.

Wonder how the combining works though, are all the StaticContent javascript files combined to make one giant file or are there any splits what so ever?

shaggyalien

By "Cached forever" I am guessing you mean Akamai ? If so, depending on cache setup on client, isn't the client downloading this giant file every time the cache is cleared ? Well, I guess atleast during a single session, only the initial download is slower and the consecutive ones don't need a javascript download as they are cached on the client.

Ryan Morlok

There are multiple bundles (and in some cases bundles that include other bundles). I'm not sure exactly how the different bundles are broken down.

When I say cached forever, I mean that the cache control headers are set to a long time, and we assume that if we ever need to change a file, we change the URL to that file so that we don't care about the old version being held in Akamai and/or the browser cache.

EXPLORE OUR SITES