{"id":5214,"date":"2019-02-12T19:46:41","date_gmt":"2019-02-12T18:46:41","guid":{"rendered":"https:\/\/monodes.com\/predaelli\/?p=5214"},"modified":"2019-02-12T11:47:45","modified_gmt":"2019-02-12T10:47:45","slug":"vue-js-app-performance-optimization-part-1%e2%80%8a-%e2%80%8aintroduction-to-performance-optimization-and-lazy","status":"publish","type":"post","link":"https:\/\/monodes.com\/predaelli\/2019\/02\/12\/vue-js-app-performance-optimization-part-1%e2%80%8a-%e2%80%8aintroduction-to-performance-optimization-and-lazy\/","title":{"rendered":"Vue.js App Performance Optimization: part 1\u200a\u2014\u200aIntroduction to performance optimization and lazy\u2026"},"content":{"rendered":"

For the series, I will never stop learning<\/p>\n

While mobile-first approach becomes a standard and uncertain network conditions are something we should always take into consideration\u2026<\/p><\/blockquote>\n

Vue.js App Performance Optimization: part 1\u200a\u2014\u200aIntroduction to performance optimization and lazy\u2026<\/a><\/em><\/p>\n

<\/p>\n

\n

Vue.js App Performance Optimization: part 1\u200a\u2014\u200aIntroduction to performance optimization and lazy loading.<\/h1>\n
\n
\n
by Filip Rakowski<\/a><\/div>\n<\/div>\n<\/div>\n
\n
\n

While mobile-first approach becomes a standard and uncertain network conditions are something we should always take into consideration it\u2019s harder and harder to keep your application loading fast. In this series I\u2019ll dig deep into Vue performance optimization techniques that we are using in <\/strong>Vue Storefront<\/strong><\/a> and that you can use in your Vue.js applications to make them loading instantly and perform smooth. My goal is to make this series a full and complete guide on Vue apps performance.<\/strong><\/p>\n

Part 1\u200a\u2014\u200aIntroduction to performance optimization and lazy loading.<\/a><\/p>\n

Part 2\u200a\u2014\u200aLazy loading routes and vendor bundle anti-pattern.<\/a><\/p>\n

Part 3\u2014 Lazy loading Vuex stores and single components\u200a\u2014\u200asoon<\/p>\n

Part 4\u2014 Lazy loading libs and finding smaller equivalents\u200a\u2014\u200asoon<\/p>\n

Part 5\u200a\u2014\u200aMaking use of Service Worker cache\u200a\u2014\u200asoon<\/p>\n

Part 6\u2014 Prefetching<\/p>\n

How Webpack bundling works?<\/h3>\n

Most of the tips in this series will focus on making our JS bundle smaller. To understand while it\u2019s crucial first we need to understand how Webpack is bundling all of our files.<\/p>\n

While bundling our assets Webpack is creating something called dependency graph<\/strong>. It\u2019s a graph that links all of our files based on imports. Assuming we have a file called main.js <\/code>specified as an entry point in our webpack config it will be a root of our dependency graph. Now every js module that we will import in this file will become it\u2019s leaf in the graph and every module imported in this leafs will become their leafs.<\/p>\n

Webpack is using this dependency graph to detect which files it should include in the output bundle. Output bundle is just a single (or multiple as we will see in the later parts) javascript file containing all modules from dependency graph.<\/p>\n

We can illustrate this process like this:<\/p>\n

\n
\"\"\/<\/a><\/div>\n<\/figure>\n

Now when we know how bundling works it becomes obvious that the more our project will grow the biggest initial JavaScript bundle will be. The bigger it\u2019ll be the longer it\u2019ll take to download and parse it so user will see something meaningful later. The longer user will wait the more probable it is that he\/she will leave our website.<\/p>\n

In short words bigger bundle = less users. <\/strong>At least in most of the cases.<\/p>\n

Lazy loading<\/strong><\/h3>\n

So how we can cut off bundle size when we still need to add new features and improve our application? The answer is easy\u200a\u2014\u200alazy loading and code splitting<\/strong>.<\/p>\n

As the name suggests lazy loading is loading parts of your application lazily. In other words\u200a\u2014\u200aloading them only when we really need them. Code splitting is just splitting the app into this lazily loaded chunks.<\/p>\n

\n
\n
<\/div>\n
<\/div>\n<\/div>\n<\/figure>\n
\n
\n
\n
\"\"\/<\/a><\/div>\n<\/div>\n<\/figure>\n

In most cases you don\u2019t need all the code from your Javascript bundle right after user visits your website. Even if we will have 3 different routes in our app no matter where user will end up he\/she always needs to download, parse and execute bundle with all of them even though only one is needed. What a waste of time and energy!<\/p>\n

Lazy loading allows us to split the bundle and serve only the needed parts so user is not wasting time to download and parse code that\u2019ll not be used.<\/p>\n

To see how much of the JavaScript code is actually used in our website we can go to the devtools -> cmd+shift+p -> type coverage -> hit \u2018record\u2019. Now we should be able to see how much of the downloaded code was actually used.<\/p>\n<\/div>\n

\n
\n
\n
<\/div>\n
<\/div>\n<\/div>\n<\/figure>\n<\/div>\n
\n
\n
\n
\"\"\/<\/a><\/div>\n<\/div>\n<\/figure>\n<\/div>\n
\n

Everything marked as red is something that is not needed on current route and can be lazily loaded.<\/strong> If you are using source maps you can click on any file in this list and see which of it\u2019s parts were not invoked. As we can see even vuejs.org<\/em> has a huge room for improvement ;).<\/p>\n

By lazy loading proper components and libraries we managed to cut off the bundle size of Vue Storefront<\/a> by 60%!<\/p>\n

Ok, we know what lazy loading is it\u2019s and that it\u2019s pretty useful \ud83d\ude09<\/p>\n

It\u2019s time to see how we can use it in our Vue.js application.<\/p>\n

Dynamic imports<\/strong><\/h3>\n

We can easily load some parts of our application lazily with webpack dynamic imports<\/a>. Let\u2019s see how they work and how they differ from regular imports.<\/p>\n

If we will import JS module in a standard way like this:<\/p>\n

\/\/ main.js\nimport ModuleA from '.\/module_a.js'<\/pre>\n
ModuleA.doStuff()<\/pre>\n
It will be added as a leaf of a main.js in the dependency graph and bundled with it.<\/p>\n
But what if we will need ModuleA<\/code> only under certain circumstances like a response to the user interaction? Bundling this module with our initial bundle is a bad idea since it may not be needed at all. We need a way to tell our application when it should download this chunk of code.<\/p>\n
This is where dynamic imports can help us! Now take a look at this example:<\/p>\n
\/\/main.js\nconst getModuleA = () => import('.\/module_a.js')<\/pre>\n
\/\/ invoked as a response to some user interaction\ngetModuleA()\n  .then({ doStuff } => doStuff())<\/pre>\n
Let\u2019s take a quick look at what happened here:<\/p>\n
Instead of directly importing module_a.js<\/code> we created a function that returns theimport()<\/code> function . Now webpack will bundle content of dynamically imported module into a separate file and unless the function will be invoked the import will not be called and file won\u2019t be downloaded.<\/strong> Later in the code we downloaded this optional chunk of code as a response to some certain user interaction (like route change or click).<\/p>\n
By making a dynamic import we are basically cutting off the leaf that will be added to the dependency graph and making the separate one that will be downloaded when we decide it\u2019s needed (which implies that we are also cutting off modules that are imported inside <\/strong>module_a.js<\/code> ).<\/p>\n
Let\u2019s see another example that will better illustrate this mechanism.<\/p>\n
Let\u2019s assume we have 4 files: main.js<\/code>, module_a.js<\/code>, module_b.js<\/code> and module_c.js.<\/code> To understand how dynamic imports work we need only source code of main<\/code> and module_a<\/code>:<\/p>\n
\/\/main.js\nimport ModuleB from '.\/mobile_b.js'\nconst getModuleA = () => import('.\/module_a.js')<\/pre>\n
getModuleA()\n  .then({ doStuff } => doStuff()\n)<\/pre>\n
\/\/module_a.js\nimport ModuleC from '.\/module_c.js'<\/pre>\n
By making module_a<\/code> a dynamically imported module we are cutting part of the dependency graph with module_a<\/code> and all it\u2019s children. When module_a<\/code> is dynamically imported it loads together with modules imported inside of it.<\/p>\n
In other words we are just creating a new entry point for the dependency graph.<\/p>\n
\n
\n
<\/div>\n
<\/div>\n<\/div>\n<\/figure>\n<\/div>\n
\n
\n
\"\"\/<\/a><\/div>\n<\/div>
This how our dependency graph and bundles will look like with given setup.<\/figcaption><\/figure>\n
Lazy loading Vue components<\/span><\/h3>\n
We know what lazy loading is and why we need it. It\u2019s time to see how we can make use of it in our Vue application.<\/p>\n
The good news is that it\u2019s extremely easy and we can lazily load whole SFC along with it\u2019s css and html with the same syntax as previously!<\/p>\n
const lazyComponent = () => import('Component.vue')<\/pre>\n
\u2026that\u2019s all you need! Now the component will be downloaded only when it\u2019s requested. Here are the most common ways to invoke dynamic loading of Vue component:<\/p>\n