Reduce the amount of javascript on the merge request page
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
We have a lot of JS running on the merge request at any one time all of which has to be downloaded and parsed by the browser before the diffs app, or the notes app, can be booted up and rendered on the screen. We need to look at ways to reduce the amount of JS needed on the page but also try to get smarter on what we load and when.
Getting smarter
If the user navigates straight to the overview tab for example they don't need any of the JS or Vue components for the diffs app, they only need that JS when the user navigates to that tab. So what is the minimum amount of JS needed for us to boot up and start to render the notes app on the overview tab?
Same for the diffs tab. What is the minimum amount of JS to start rendering the diffs on the page?
Can we create a bundle for each tab with only the JS needed for that page? When the user switches tab load in the bundle for that tab.
Example
If we take the diffs app rendering a simple merge request with just text changes (no images or collapsed files) it will need to do something like:
graph TD
A[app.vue]
B[VirtualScroller]
C[diff_file.vue]
D[diff_content.vue]
E[diff_view.vue]
F[diff_row.vue]
A-->B
B-->C
C-->D
D-->E
E-->F
Prioritising these components over everything else on the diffs app would remove a lot of extra Vue components that aren't needed until the later. With these components we can fetch and render text diffs as quick as possible.
What about the rest of the JS? Well we can import them dynamically later when they are needed. The image diff component for example will never be fetched if the user isn't viewing a merge request with images.
Widget
The widget can have a lot of different components in it because of the amount of features it supports
Performance
Will this affect performance? It could do if we just start throwing dynamic imports everywhere. We need to think about this carefully and try to decide what components we are ok with loading on page load and what components we are ok loading later. It will be time consuming but going through each JS file and component that exists on the merge request and making a decision on whether or not it is critical we have it on first render. What could we get from it? A reduction in our mb's of JS on the merge request page.
A later issue
Once we have decided exactly what is needed for page load and first render etc. we should come up some 'budget' numbers and somehow track these. If the size of the JS goes up then we should be alerted and a decision should be made on whether it is ok for page load or whether it can be loaded later.