 and mobile technology for last four years, I have been, I have delivered quite a large enterprise, and as part of it, you know, somewhere in last one month and a half years I came across the fact and I really realized that it's a fairly complicated beast to aim, so I went a bit deep and that is the experience that I'm going to share with you guys here. So, you know, if you are impatient and you don't want to go with me, you can always refer the slides here and the app that I'm going to show you as part of the presentation is, can be found here, I will again share the link at the last slide as well, so don't have to worry about the app. Slides, if you want to hurry up, you can take the slides right away on your mobile and strategy. My Twitter username, if you want to follow me, I regularly post on Twitter. So, let's start. So, I hope all of you know what Webpack is. Who knows what Webpack is? Or use Webpack? Okay, quite a few, awesome. And those who did not raise your hands, but use CRH, create, react, type. Awesome. So, all these guys, you did not raise the hand earlier, but you use create, react, type. That means you are using Webpack, just don't know it. Okay? So, that's the beauty of create, react, type, type. It abstracts away all the complexities of Webpack, but at the same time, when it abstracts away all the complexities, then whenever you want to do something specific, you're going to have a little bit hard time. So, thankfully, create, react, type has an eject functionality by which you can eject the entire configuration, including Webpack configuration, and then you can go deep dive as to how I'm going to show you in this particular session. So, for those who do not know what Webpack is, this is a quick primer for you. You're a developer all around you. Angular developers, React developers, new developers, all of them really love Webpack, and all of their CLIs are using Webpack as their base build system. Why? Because there are a lot of features that are present in Webpack. So, one of the key features that is, you know, there, and which is loved by developers is a versatile loading system. Now, what is versatile loading system means, even, right? So, basically, it can read and understand a lot of different types of files. So, if you look at, you know, predecessor to Webpack, Gulp, Payble, etc., Gulp and Grant, etc., right? They were spaghetti of plugins. Here also there are a lot of plugins, but the core Webpack itself also can understand the JavaScript files, CSS files, image files, like PNG, JPEG, JIF, SVG, you name it, font files, PDF files, you know, all these type of files are something that Webpack can load from file system and can understand them, and so it can process them. What do you mean by process? So, the processing would be essentially bundling some of these files together and also splitting some of these files out. So, I'm talking two different things, which are, you know, opposite of each other at the same time, really. So, let's say I have written an application having 100 JavaScript files. I can bundle them all into one, or I can bundle them into one and then split that one into five, right? So, bundling and splitting. This is the most biggest power of Webpack, probably, is that it allows you to bundle, not just our system files, it allows you to bundle CSS files, it allows you to transform SCSS, less, stylus, different styling files, again, bundle them together, or you can then split them again if you want to. You can take JPEG, JIF images, or SVG images, create sprites out of it. So, all these bundling and splitting in is the true power of Webpack, and that's why Webpack is so powerful and is loved all over the world. Thirdly, it also gives you, you know, built-in cache busting, such things. So, those who have debt with releases, you will know that, you know, the moment you release the application, you know, new files are not reflecting to the end users, and then everybody's having pancake calls now. So, don't have to worry about it anymore once you have Webpack. Your files will always have uniquely different names every time you release them. So, your old file names that old release users are born in. So, you don't have to worry about it. So, we are going to, we are going to talk about this bundling and bundling tuning in the forthcoming part of the talk. And the second part, which is, again, very, very cordial, is the pre-shaking and verification. So, if I have hundreds of files written, obviously, you know, with lots of ports commented because this does not work right now. This used to work earlier, I don't want it now, but I don't know to delete it, etc., etc., right? Or I have a job, jquery.js, I forgot to write jquery.min.js, etc., right? So, it will automatically minify for you. You don't have to find out the minified version of minify. So, it will do minification for you and it will also do pre-shaking for you. Now, somebody, I forgot to show what pre-shaking means in Manjula in the morning, in Nepal. So, basically, if you have five functions in your JavaScript and if you are only referring to two of them in your other parts of the application, you can intelligently understand that only those two functions are really required for you in the runtime. So, it will drop the rest, so that the dry news will fall down. You don't need them, let them go. Same thing. Lastly, it is highly customizable and plug-able. It is easy to write a plug-in to enhance the function that is not available, but you want it. So, that will be the key reason why the ecosystem is very thriving here. About 250 logins exist for Webpack and a lot of new things are getting written added to Webpack ecosystem. That's why Webpack is so popular and being used. But if we use all that goodness, does that mean we can rest in peace? No. Of course not. Just because it has a lot of configurability, it does not make it a smart system. So, it has some algorithm, obviously. It tries to apply that algorithm and there are thousands of projects, hundreds of thousands of projects getting written. So, not every project turns out to be right. Then, all these projects are using different different libraries. Those all are written, maybe sometimes in past, sometimes new. So, every library has its own source. So, the system is not a smart system. So, sometimes there is a little bit of nudging here and there. You need to tell Webpack because you tried, but you know, you will do it this way, you will do it that way. So, then it will do it correctly for you. Why is it important? Because if you don't do this, then you are going to get big bloated bundles created by Webpack. I said Webpack is two copies of a bundly. But that bundles can sometimes be created in an incorrect fashion and you get the biggest big bundles. So, you know, you are loading your homepage and I think Manjula again mentioned that her time to interact was 8 seconds or something and 440 kb was her bundle size. So, that is a very good recent bundle size, I would say 440 kb. But what if we have 2.5 mb of bundles size? You know, 1 mb takes about 10 seconds on a slow 3G network. So, if you have 2.5 minutes, 25 seconds the user is not able to do anything. That's ridiculous. Nobody is going to stay on your application then, right? So, loaded bundles is absolute noodle for everybody, right? And all of you, whoever are developing with Webpack now that you know Webpack is there incorrect reactance, right? Check what is your bundle size, yeah? And if it is really big, then you really, really need this session's content for it. Okay, so that's what we are going to do. We are going to try and fix this big bloated bundle. Obviously, there is no one formula that fits all here. I'm going to show you some specific examples and hopefully that will inspire you to look at other cases whatever you are going to deal in your situation. So, I start with my product's experience first to just give you how this is important, the bundling 100 to be. So, this is how my Angular application, yeah, I'm not a reactor actually. So, this was my Angular application before I started tuning, yeah? So, it was about 2.5 months in my development with my team and I had total application size of 5.73 MP non-GZIP, okay? And it's okay because my main applications were only these two. These are the ones which are getting downloaded on the home page. So, it was not terribly bad, but still 5 MP was too much for me. So, I started looking into what is happening. I went and did a lot of research and pilot tuned it and this is the after I have done my theory, this was the effect that I got about 2.6 MP without GZIP. So, it's about 700 MP GZIP, which is okay. Which is not terribly bad. And again, I still had the AOT compiler, something Angular forcefully injects in my sometimes it injects. So, I need to remove it so it will save me about 5 MP. So, I'm just close to getting there. So, but that was the thing that I could save almost 50% of my JavaScript that was so what I realized was 50% of JavaScript that was getting shipped to the browser was useless. It was not even getting used, right? And that is something I hope not for me. So, I'm going to show you how you can also you know look at your applications bundle and do similar access test. So, in order, how do you go about it? In order to do this the most important tool is already built into your webpack system. So, if you are using webpack, you have that tool and that tool is called JSON, okay? Webpack hyphen JSON. Now, those who are using createreactor at this juncture createreactor does not have a way to pass this particular parameter to webpack directly. So, only way out for you is to do a separate clone, eject it and then run with the JSON pack. In Angular CLI word and new word, thankfully you can pass the JSON pack already and you can create the bundle report. Basically, it creates a bundle report for you in a JSON format and that formatted report is really not really usable or comprehensible for the user, I mean any user. So, then there are couple of tools that people have written which can pass that JSON and create a meaningful visualization for you. So, why three three tools? Because they offer different type of output for you and we are going to see all the three briefly. So, instead of reading through here I am going to show you. So, here is the webpack's own tool, webpack analyzer, webpack.github.io analyzer. So, as you can see I have loaded a JSON file here. The JSON file is something that gets created by the webpack and it tells me that there are three chunks and fourteen has had 164 modules in it etc. and I can see here all the chunks. There are three chunks, it gives me details for each some chunk size and it also tells me all these 165 modules that we spoke about here are all the 165 modules that are there. And the most important page probably I like out of this is the hint which seems to be good in this particular demo app that I have but in my actual production app I had pages full of hints here because I know a lot of duplication. So, basically I was using let's say Moomin.js in this chunk and that chunk and that chunk. So, I was pushing the same JavaScript into three chunks or to the end user. So, he said why are you doing that? Can you take it out and move it into a common chunk so that it does not get repeated. Those are the type of hints that this particular analyzer is very useful page for you to use. But what I don't like about it is it doesn't give me very good bird's eye view about the sizes. So, that is where I really like this visualizer from Chris Bateman. So, it gives you what is known as sunburst chart. So, you can select the chunks, you can see all the chunks and you can see individual chunks. For example, this is my vendor chunk here and it tells me now that 100% of vendor chunk is from the old modules only. So, everything in vendor chunk is from the old module. Out of that 23% is my load-dash analyzer. And, you know, by eyeballing I can see what things are, you know, are there. Open layers is about 20% etc. So, it is a very beautiful representation of, you know, where am I spending large chunks in large parts of my chunk are going. Right? And this is another library called Thors bundle analyzer. I like this one also because it clearly tells me which library, where is it, which is the largest straight away. There is OLJS, there is D3JS. And, you know, my application code is here, the blue code. Yeah? This is my application's code. Okay. So, those are the, by the way, while we are here this will be the demo that I am going to use because the next slide will show that we just come from here. So, yeah, that's the next slide. So, I made a very simple app for demonstration because obviously it's a, you know, it's not a real-world app. But I just, you know, took five pages or five components, yeah, and one header. So, the first page or the home page only uses bootstrap to create one table button that's all. And to lay things out and also the top nav and all that. Then there is this movement.js page using movement.js to just do something. Because it's a demo, obviously. I use openlayers to create the map and I purposefully am, I have throttled the connection right now. So, then I use another page to use loadash pick function. Yeah. Just to demonstrate that I am using loadash and one D3 page. Yeah, that's, that's my application. Essentially, my application uses ViewJS, it uses D3, it uses movement.js to openlayer and loadash. Okay, those are the things my application depends on. Yeah. And then we were seeing, this is, this is how the thoughts bundle analyzer look like. Yeah. So, obviously, you know, I started thinking, boss, why is there, I have such a big openlayer sjs sitting in my tour, right? Then I get this D3.js looks terribly big. This movement.js, okay, there is movement.js library, but what is this big item from movement.js? That is the local builder. Yeah. If you zoom in and see there, it has Russian and Armenian and Italian and all that. I am not supporting those languages but it's still there in my application. I did not ask for it, but it's still there. Right? So, that's where Webpack has gone wrong. Yeah. Then there is also load.js, which is fairly big for me, right? So, those were my leads that I could get from, you know, analyzer. So, that's what you guys need to do. You need to somehow create this and load it up and try out, right? And last time, last and most important thing that I realize here is that I have only one render.js file. We need everything that I need for this application to work is there in one js file. But really do I need openlayers D3 in my home page? I don't need it. But it is still there. It is going to get downloaded. Right? So, first and foremost thing that I need to really do is for lazy loading. Strip out everything and anything that I don't need on my home page. So, my home page performance will go better. Okay. So, from this point onwards now you will actually go a little bit deeper into the code now and I'm going to show you how small small changes in your code or configuration files can lead to, you know, removing these issues. Yeah. So, first let us attack the biggest problem, lazy loading. Yeah. So, this is how my, sorry, I don't know whether I'm thinking. Okay. So, this is how my Vue.js file looks. Yeah, I know that you guys don't, I don't expect you guys to know Vue.js, but it is very similar to how React would have done. So, I have components, my components, movement page, load-page, all those components and I have a router which loads all these things. Right? But what is important to note here is that I have statically imported them here in JavaScript, statically. That means when the code parsing happens via Webpack it is going to load all of them and hardwire them into the application. What I'm going to do is I'm going to change out dynamic import rather than static import. Now, dynamic import is not a JavaScript thing. It's something that is Webpack has given value. So, normal, non-Webpack applications are not available. So, instead of, so I remove, so anything that is in the red is removed, by the way. Anything in green is added, yeah. So, I removed all these static imports and I go for this import with the curly brisk. That is the dynamic import facility. This is exactly same facility that is available in React Router as well. So, if you are using React and if you are not doing lazy loading, this is how you need to do in your React applications. Use dynamic imports. Immediately whatever is here will be created as a separate chunk for you. So, and actually it's a movement page or component referred movement, yes. That means now movement is not going to come in your application. So, that is the kind of benefit you are going to get. In this dummy app, this is the benefit that you are going to see. So, before I, the earlier application, home page chase was 358 kb and after it is 39 kb. So, like 90 percent input. That's a huge, so that's why you have to attack if you are not using lazy loading. That should be the first thing that you should always attack. Move on to open layers now. So, this is my open layers. Open layers is a chart, sorry, mapping library, you know, Google maps, right. So, this is how I was using it. Open layers, import OL from open layer and then OL had variety of functions. OL.map, OL.tile, OL.protection, OL.view, etc., etc. So, this is the typical code of creating a simple map for you. But obviously, since it is import OL from open layers, it is bringing the whole layers library, right, which is not a ES2015 library. Open layers, the original version is a common JS based library. Now, this statement probably is going to stump some of you guys. So, just ignore what I am saying. Just whenever you are Googling, you find out libraries within ES2015 compliance. And open layers fortunately has a library called OL. Same codebase, but exported as ES2015. So, we have to start using the OL library now. That is the key thing that we have to change. Once we start using the OL library, yeah, I removed the import OL from open layers and instead I used, I started referring from OL, slash, layer, tile, OL, slash, map, etc. Now, why this is better? Because here I am specifically saying I want this module out of your OL library, that module out of your OL library and that's why it is only going to take those many things, so you have to pre-shake everything else. And that's why if you want to use pre-shaking, you must need, you have to have ES2015 based libraries. And this is one example where I could fortunately find an ES2015 library, so I used it and the result is that otherwise it was 46kb library for me, now it is 86kb only. That is the benefit that I want. Same thing you will be able to see in case of D3. I am sure for maybe 50% of you would have been exposed to D3. And typically this is how you would have used it. The older version is D3V3 if you have used D3V3 was always important like this, start as D3V3. Now D3V3 again was a common JS based library and D3V4 is a ES2015 based library. And now in V4 they have also split everything out into individual modules, separated out and that is why I am saying because I do not want your D3, rather just give me D3 selection because that is all I really need right now for my requirement. And I change my code like this. I remove the original start as D3 and I just import one function. There was a lot of talk about pure function. So this is just a pure function so everything else just goes away. You don't need anything else. I then just use that new function that I imported everything. That is also a highlight that I wanted to underscore in all these stages that the changes are minimal. It's not like you are rewriting your app but you are getting benefits. So that's why it's a very important activity that you should be doing in my opinion. And this is the improvement in this dummy app. Don't go by the numbers because of course you are not just using D3 select. You are using many more functions so you will not get such kind of benefits such as 85% benefit from 71 pp to just 9 pp. Now, these two cases that I showed earlier to you is where using the ES2015 and reshaking could help me to optimize my bundles. But there are other cases where you don't have ES2015 library. They say low-dash. Now that segment is half pro. I come to that. But low-dash is common just like ES2015 library. Whole bunch of you use low-dash I'm sure. So if you have something like this import and underscore from low-dash then obviously the entire library is coming. But since it's a common just library even if you do something like this import from low-dash pick it will still import the entire library because that's how ES2015 works. In fact, it's not able to do cliche if the library is not ES2000. So this statement can mislead you. Sorry, I'm switching times. Even if I have done this why am I still getting the whole low-dash? Because low-dash is not a ES2015 library. And now I said half true because low-dash-ES there is a library called low-dash-ES which is ES2015 library. You can use it. But that will only serve you if you are the only one who is using low-dash. Let's say you had a library import third party library which was using low-dash your low-dash-ES is not going to be useful because that low-dash is still getting used. No option. So that's why you have to nudge webpack in a different way now. And that's why the plug-in ecosystem really comes handy. And if you look at the plug-in ecosystem and loading this low-dash model replacement plug-in rather than writing this low-dash webpack plug-in which is a plug-in written by low-dash guys themselves. And all you need to do is with the webpack configuration file you need to give the reference to that module. Now this webpack configuration file those who use create-reactor you will not find it. Those who use Angular CLI you won't find it. You must eject. And then only you will find this particular part. So, but yeah sometimes you know benefits outweigh the AS that has been given because see here from 23kbm down to 3kb. So that means there is a benefit of doing eject and then going to some configuration. Second such example is movement jays. Now if you remember I had shown you a screenshot I have just blown it up for you. So you can see Russian and I don't know EL, NL, I don't even know Italian. Yeah, lot of languages which I am not supporting really. Then why do I need to have movement jays course translation in all those languages. Even my own course translation in those languages is not there really. So, but again that's how movement and webpack are not really ready to talk to each other. There is a long thread on movement jays because issue where people are saying why don't you fix it then they say no that's how it works. Webpack should fix it. Yeah. So, yeah it happens that to open source languages don't talk to each other nicely. So thankfully there is a written plugin from webpack itself which can help us. It says context replacement plugin and it says whenever I come across a part that which says movement search of else I only want to include these languages. So then you will drop everything else and only takes English, Hindi, and my only problem is obviously you have to add as and how you grow. So that is one more example where you know ES2015 thing did not came into your way or did not help you with your plugin and I am sure that you will find in your application some such problematic libraries and then you will have to find out the right plugin for LPE or you can roll up your own plugin that's also not a very difficult thing to do in webpack. So again, the benefit was I came down from 92 kb to 18 kb. Now 18 kb is pretty much the movement jays library because hardly any maybe one kb is just the one. Now those were some examples of javascript being optimized. Here is another example of CSS being optimized. So I was using bootstrap as I showed on the first page I was just using bootstrap button right. So I started up with bootstrapmin.css in my style directly in bootstrapmin.css Now bootstrapmin.css is bringing a lot of things, actually these many things. I don't expect you to read. I just want to explain you that for me the blue things were sufficient but since I had brought the bootstrapmin.css there was no way to pick and choose and that's why we should rather go into a scss mode. Scss or stylized CSS sorry stylized stylized scssing ok so if we use that then we can write a custom file to pick and choose individual bootstrap components. Now bootstrap on npm there are two bootstrap there is one bootstrap version 3 there is bootstrap 3 and then there is bootstrap-sass now once bootstrap 4 comes out which is pretty close I believe they are in beta 3 now then everything will be sass only so then you don't have to maintain two different components but so you can use this bootstrap-sass library import it and then you can individually import only what things you need so that's how the original the entire file looks like and that gives me benefit of about 10kb more because the bootstrapmin file was 20kb minify and this is it now I have only 9kb with my instruction ok so with those different quick demonstrations here is how you know my application overall looks like this is before the old application oh I did show you the application sorry I didn't comment it to show you the old and new application so if you look at the application this is the before application you can see that and I am purposefully on slow 3g right now so see now it is still downloading downloading 11.45 seconds it took for you know the whole page to download the original untuned version of the application and as you can see as I move to the other pages there is no nothing getting downloaded anymore that means the entire application is already there now I can just plug out and still work with the application but if you look at this application this is the after tuning application so it finished in 5 seconds and it also got only 41kb instead of 349kb and as I move to movement yes it will download a new it will download a new right so that is the lazy loading parts that we saw so with that we can quickly see the report now so this is before so you can see that the vendor was to envy the total 3 chunks and all of them had initial flag meaning they are going to get download at this time right but if you see the new one I got 4 more new bundles which do not have initial flag these are the 4 bundles for the other 4 tabs on my application and my overall home page is only now 241kb and is it so that is what you know is the difference that you can achieve relatively without a ping and just for the fun this is how the new application you know the stats yes one looks like in the bundle analyzer now so this is my this is my old dot yes the old old dot yes now it is all small small modules instead of one monolithic yes so you may get different because you may have different requirement but yeah so that so it definitely is using now yes 2015 and you know things like that alright so quickly summarizing what did we learn today so if you know you should be looking at your webpack just one final to optimize it and one way to optimize is do lazy loading using import function as we saw in the first lazy loading page we should do pre-shaking and you know we should utilize pre-shaking for that you have to first choose a library which is yes 2015 enabled right and which is every three and open less also you should really look at anything anywhere you are using this kind of construct whenever you say import start from that means you are bringing everything there is no pre-shaking even if you are using pre-shakeable library since you wrote import start done you are not using pre-shaking yeah whenever this is not possible try to do specialized calling using some plugins the way we saw it in case of movement.js and load.js and also definitely go for scss files in order to only include whatever you need in the style world alright so that was this summary thank you so much best of luck for your tuning journey you can follow me on github twitter video everywhere follow me and he orders thanks