How to Reorganize a Monolith JavaScript Bundle

josh
3 min readJun 27, 2017

Summary

I recently needed to optimize the page load times for a website sorting out and organizing all the JavaScript dependencies. They were all packaged into two bundles giant bundles. Below are some tips on doing this type of thing.

The bundles that ran on every page.

Create New Bundles

  • Bundle by page or function i.e Homepage or BootStrap.
  • This creates an initial framework for organizing your dependencies that can be changed later depending on what makes sense.
This is an example of what I started with and changed as I went along.

Prcoess for Organizing

  • First oraganize things that are obvious like third party dependencies and Angular libraries that will load on every page. ``` misc-libs``` and ```and fee-libs``` are two examples. Even better to just do it by purpous. This gives you an initial base for the layout template.
  • Open unfamiliar libraries and find key functions or <div> classes or ids and use them to search the code base for references to give an idea of what views they are used in.
A div label and a function name that I used to find use in the code base
  • After this, starting with the most important pages, copy likely and known dependencies into the view to bypass the bundling process. This saves time by not having to constantly recompile the ```bundleConfig.cs``` file.
  • You can then begin testing the page in Chrome for Visual Errors or Console logs that give an indication of what is missing. Unless you have tests its just a trial and error process with a lot of investigative leg work to be done.

Final Thoughts

If your company doesn’t have test already setup, you are stuck having to go through each page and test functionality looking for errors visually or in the browser console. By the end you should have something like the example below. All this enables you to have purpose-built packages that make sense, reduce load times, document the dependencies directly in the code, and can dramatically reduce the cost of future change. My end result would have been better were it not constrained by earlier front-end design decisions.

Example of better organization

--

--