Code Splitting Pattern With Vuejs & Webpack
The initial request of retrieving the site is a scary thing, as we retrieve the whole JavaScript files & CSS Files.
Most of the websites currently may take long time at its initial request due to requiring the JS,CSS files. You got to ask yourself a question, is the user going to use the whole css and js files at once within the page you are currently viewing ?
Your answer is going to be “Definitely no”
Then you got to ask yourself whether we really need to give the whole JS files to the user at once or not, as this may affect the performance.
I guess your answer might be like “ I don’t know other way to prevent this, but I think minifying the js files would be a good solution”
Alright, I’ll cope with you, You have a high scale project containing of too many components, services etc..
I’ll assume that the bundle’s size now is like 1mb or something, That’s still remaining an issue to the user as he’s going to require 1mb file at his initial request.
From the business aspect, we have lost a customer, because the customer wouldn’t wait for your site to load for long time, maybe I can wait you for like 3–5 seconds, unless that, I’ll just close the website.
The statistics mentions that the initial request of most of the websites takes around 15 seconds as an average, That’s just a disaster.
Of course that depends on the internet speed, the amount of files being transferred from server to the user, geographical location etc..
Let’s assume that your customer is going to visit your homepage, which contains of Contact,Services Pages and your news feed .
There is no need to load the contact , services component until the user reaches them right?, but unfortunately you did because you bundled your whole js at once, and we have this component right now.
same goes for the news feed, we shouldn’t receive them until the user reaches this component even though It’s at the same page.
Credits for Anthony Gore for the image as It explains it really well.
In order to solve that, why not to explode your bundled JS file using webpack, and let the user receive the components on-demand only which is going to save you much time during your initial request.
This article covers the following 3 aspects
1-Routes : Always
2- Components : Temporal
3- Life-cycle : Conditional
Routes
Within your routes.js file, you always import the vue components that’s in charge of some route , that affects your performance horribly as you have imported these components without bearing in mind whether you need them or not,so the more components you have, the less performance you are going to have. which we really don’t need in business.
so your code might look like this .
as mentioned earlier , you import whether you need them or not, in order to overcome this issue, we are going to use the import in promise format.
It might be surprising to use it in this format, but import returns a promise, which we can use and since Vuejs doesn’t have a problem with calling the components asynchronously , then everything is fine so far.
“import() calls use promises internally. If you use import() with older browsers, remember to shim Promise using a polyfill such as es6-promise or promise-polyfill.”
therefore, we can import the components only when we call for them , that’s done by using promises.
“As import() returns a promise, it can be used with async functions. However, this requires using a pre-processor like Babel and the Syntax Dynamic Import Babel Plugin”
just by mediating this, you might think that’s really hard to accomplish, but the bright side here is that Vuejs is the first framework that crafts the developer experience with webpack in mind and that makes it really easy to do, Let’s take a look.
Note : You can do that also in other frameworks such as React.
and that’s it, we are going to use these constants we made, and webpack is going to handle this behind the scenes . On-demanding a specific component,It’s going to retrieve it via ajax request, as we are going to examine this later.
what we have done so far is called Lazy Loading Routes, you can visit the vue-router docs for further details.
It’s always preferred to use the lazy loading routes, as you don’t need to import every single component at once, but import them only on-demand
Components
Within a parent component, you may import a couple of components that includes your basic inputs , or listing
The following example mentions that you have a couple of components that contain of like button, create comment input, and indexing the comments which contain of other child components.
Again, we have imported them without bearing in mind whether we are going to use them or not, I mean perhaps the user is currently viewing the Post Page, but he hasn’t reached the comment input yet , nor the like-button , if so, why to import them and use them, perhaps the user isn’t going to reach there which means in essence that we have imported useless components and that’s why we should use it temporally , in order to overcome this , again we will import them using the method we did earlier.
You might be wondering, how the heck are we going to retrieve this component from our application , when we only reach it.
Well That’s where webpack comes into the ball, as it’s going to send an ajax request to the application inquiring whether the required component exists or not, If it exists, we retrieve it and show it to the user, unless that we won’t retrieve it, as It’s on-demand component.
That means in essence that your main bundled JavaScript file isn’t going to be bundled at once, but It’s going to be exploded into chunks, you retrieve what you need only on-demand via ajax request, so that’s good for the initial request as you won’t require your whole application at once.
Hash: a3f7446ffbeb7fb897ff
Version: webpack 4.7.0
Time: 316ms
Asset Size Chunks Chunk Names
index.bundle.js 7.88 KiB index [emitted] index
vendors~lodash.bundle.js 547 KiB vendors~lodash [emitted] vendors~lodash
Entrypoint index = index.bundle.js
[./node_modules/webpack/buildin/global.js] (webpack)/buildin/global.js 489 bytes {vendors~lodash} [built]
[./node_modules/webpack/buildin/module.js] (webpack)/buildin/module.js 497 bytes {vendors~lodash} [built]
[./src/index.js] 394 bytes {index} [built]
+ 1 hidden moduleIf you remember , during your npm run build/dev, your whole code is trans-piled into a single file which may be a large one, but now as shown above, the file is extracted into chunks, you use your bundled main file, and whenever you require a child component, you retrieve its bundle by its chunk name as mentioned above.
so what happens if you are the homepage, and you require another page that doesn’t exist within your main bundle, such as contact page for example, an ajax request is emitted to the server as the figure shows below.
LifeCycles : Conditionally
Another good candidate for code splitting is anything that is shown conditionally. such as modals , tabs, drop down menus etc…
Let’s assume that you wish to show the register modal form only when the user clicks on the register button as udemy does and many other sites. Well I would assume that your register form is a component that we are going to use later.
why to import it if the user has no intention to use it ? , although It’s conditionally showing as it awaits the user to click on the button, but again it’s imported.
In order to overcome this one, we will just follow the component with the if directive, and use the promise to call for the register modal form.
as simple as that, when the user clicks on the modal, your logic should set the show property to true, then webpack is going to send an ajax request requiring this component and then it’s going to be viewed for the user.
That just has saved much time from the initial request, also it boosted your performance significantly.
you can see more examples here at this repository
TIP : This helps with SEO , as google disqualify the websites with low performance.
Hopefully you enjoyed this one, and it helped you . Happy Coding ! :)
Still here ?
Don’t forget to follow me for reading more of our articles.
More where this came from
This story is published in Noteworthy, where thousands come every day to learn about the people & ideas shaping the products we love.
Follow our publication to see more product & design stories featured by the Journal team.
