 splitting then we will look how webpack works internally and what things webpack is providing out of the box to improve the bundle sizes yeah. So I am a frontend engineer at birda.com you can follow me on twitter at athishabhad. So first we will see what this talk is not then we will cover what I am going to talk about so this is not a performance checklist we are not going to discuss that what steps should we use to optimize our assets our fonts or how should we write a better code how to reduce react under cycle so it is nothing about that we are not going to cover any of the network performance that is how do you optimize your code parsing on aws should you use a cdn or not and we are not going to discuss any of the chrome profiling our speaker and the previous talk did a fantastic job to do that so then why you guys are here and why you guys are listening to me so first we will see what performance is and what makes is the key criteria then we will focus in the second part on the latest version of the webpack which helps to solve a lot of performance problems then we will see how we can reduce the bundle size so our like 30% of the talk will be focused just on that code splitting part how internal code splitting works and then we will discuss what we did at bird eye which helped us a lot to improve our bundle sizes so this is a platform on which I work so this is a very heavy JavaScript application which has its own set of performance problems so it is like creating a complete desktop application on the web so all the things which you are seeing on the left are complete module in itself there is a lot of functionality which we are serving it's a tool so it was having its own set of performance problem prior to migration like six months back if you see at our stats we were our meaningful paint was around 6000 milliseconds performance wise we were down so it's a lighthouse matrix we were down to 26 and everything was because we quickly build upon the things time to interactivity was going around 10000 seconds then we tried to optimize this so now we will see what is performance I hope by now everyone is aware that what performance is and what it matters so I will quickly wrap it up so there is a famous code this Jacob Nielsen is a famous evangelist he did a very good survey he says that if your website is not loading in 0.1 second that is like 100 milliseconds users tend to feel that something is Jackie in your website and they tend to lose the focus if your website is taking somewhere around 1 second to load and there is no special feedback is given to user I mean let's say website is getting to load and you are not showing any pop up or something then user tend to feel that this website is not perfect I should go to another website to do my job and worst is if you are using 10 second then user will not go back so these are the real surveys Jacob Nielsen did I was researching a lot to prepare my presentation so these are the codes from that a very famous CDN Akamaya revealed that if your website is taking somewhere around 2.5 to 3 seconds to load 40% of the shoppers are always going to your competitor website that is true for all the retail website so if Flipkart is taking like 2.5 seconds to load people would go to Amazon so 40% of the shoppers were doing that again SEO is also impacted so Google says that if the page is 2% slower that means you will be having 2% fewer search impressions which means 2% fewer ads which is directly impact on your revenue if your website is SEO friendly so I was working with the times of India previously and we did a lot of SEO optimization and then we figured out that our main revenue was this ad impressions only so how just minimal performance tweaks helps to increase the revenue that's a code for if someone is a product manager in some kind of organization and finally so if you and there is a competitor website to make a customer believe in you you should be at least 20% quicker than your competitor that is a hard known fact so by now I think everyone believes that performance is important and there are various various surveys which are done around this and why this thing is difficult to achieve I'll quickly cover 2-3 things because web these days is supporting lot many functionalities then it was supporting like a year back or maybe year and a half back so it's like a moods law if so if you are thinking from a web like a year down the line you will see whatever you do at least your code base will be increased by 1MB despite of doing all the optimization your code base will be increased and there are modern JavaScript framework like React or there are various frameworks which gives developer a lot freedom but that comes at a cost of keystrokes so you are making a writing a lot more code which will always lead to some sort of matrix to be fallen short because they are giving you something but they are taking a lot thing if everyone is given the freedom then mistakes will happen anyone who have played Doom video game so so very popular video game if you are like from the 90s get used to play a Doom video game so every year our web page increased to extent it's like throwing a Doom video game on the wire so you can believe that you are throwing a Doom video game and then making the browser work to parse it and serve it to you and then again after an year you are throwing another additional Doom video game which is happening for all 95% of the website this was a very popular tweet which was very popular around this thing now we have believed that performance is difficult this is where thing which is important so how we should think to solve the performance goals so firstly to think about the performance it's not something which will I mean which is a one-time activity this is something which always comes at a cost of like you have to compromise certain needs so if you are doing server side rendering you are compromising you are faking the user so firstly you need to understand that what things need to be optimized on the network and that is one thing then second thing is after you have optimized your network like you have decided that I will be using Akamai CDN or maybe I will be using some sort of images or some other mechanism then comes your code parsing part how your browser is parsing that code so what optimizations can I make at the browser level to make the code parse and after parsing what optimizations can I make to make the layout flow very easily so now I will be focusing only on this code parsing part because other people have covered this two topics very beautifully so for browser if you look JavaScript is the number one candidate for performance optimization so even if your JavaScript is 100 KB bigger than your competitor you need to fix it you need to have some sort of mechanism to load it a different way or probably don't load that feature because that is the number one browser takes time to parse JavaScript and people are shipping a lot unused code we will see now these should be the goals 200 KB I mean looking why these seem very very unrealistic like 90% of the code coverage I hope if anyone has looked at its code coverage is anyone doing 90% of the code coverage is anyone here or you are doing so anyone have used this version 4 of the webpack which was released previously okay quite a few people so this webpack was a few guys know it was released purely to solve the performance goals so it is solving a lot of performance issues out of the box it has various plugins to do that so we did a lot work on webpack previously around like six seven months we invested on webpack and we were really happy to see the results now I will be like diving into code splitting so before focusing on the webpack code splitting I just want to showcase a little demo it will not be a big profiling so this thing is only available in Chrome so if you guys are not using Chrome you can probably take some notes so this is my bird eye website so I will just show how to just find out your unused code so just hit a command shift P or then type show coverage and hit this little reload button so here it shows your all these unused bits you can see even after optimization like 64% of the vendor bundle 59% of our application bundle is unused and I have looked into various various websites numbers are lot more so this is how you can look into your code coverage then you can probably also figure out what is that thing which is not needed on the page so all the red things which are over here so here if you can see we are using some date library which is probably not needed for this view this will be needed when you click a button so load it asynchronously so this is how you can figure out so after figuring out you need to split the code so 90% of the websites are shipping like 60% of the unused code which is the thing which we will be addressing now now code splitting so if you go by this naive definition of code splitting like splitting the chunks very simple it's like creating separate pieces of JavaScript and then loading them on demand and asynchronously so I was doing a soul search that from where did this code splitting so it's not a very new concept so any java developer out there heard of gwt google web toolkit various people would be familiar with this gwt so they were the ones who started this concept of code splitting gwt then webpack is using the same fundamentals from the gwt and and it is building on top of it so just to now showcase the code so the thing which I showed you my screenshot of the website so these are all my different different modules you can see listing over here dashboard over here my social pages here so there are various functionalities which I am serving so webpack takes this as its starting point so that is my router if you are using react it would be like similar to your react router or maybe any json router webpack it starts to look into this and then it figures out that let's say my listing is dependent upon these are my child so I only need to parse these children's when I am going to a listing page and similar is with other so let's say you are on a listing.js these are all your import statements and that is your home.js these are your import statements to the home so webpack has a very good algorithm which you can configure what it does is it tries to find out the chunks or the import statement which are common in these two modules and if these chunks are lesser than a given threshold which depends upon your configuration you can make it like 30 kb or whatever 30 300 kb it creates a separate chunk for that and which will be loaded on demand so this threshold is kept in a criteria because loading another chunk is not always a good idea because loading another chunk you will be making another tcp call and tcp calls are heavy it's always it will be a three-way handshake so you first need to figure out that do I really need to separate out this chunk if you really need then just think about it because tcp calls are also heavy so you have to figure out and webpack says that if something is around 30 40 kb then make a separate chunk so after this synchronous chunking your output would be like if your app is somewhere around 1.4 mb it will split it into all these chunks and these will be or the chunks will be which are separated by the still day are the common chunks so this is very simple like everyone can configure this synchronous code splitting and at least you can achieve this so now comes a very beautiful part which was just supported in this version of the webpack that is asynchronous code splitting which means that it's not that you are separating out your files but in a particular file if some code is used on some user interaction you can probably load that code when user clicks on that button so I'll definition of asynchronous code splitting so I'll wrote a very small sudo code to just portray all our like general UI use cases so I imported something called as a listener then the important thing to note in this third line that it's not an import statement it's a call to a function which when called then it will call this import statement so it's a similar concept of a promise so now let's say that on a click of a button you want to show a pop-up then you want that the code of this pop-up should be loaded when it is required so you did something which could be anything and then you call this function it returns a promise and then you can do your task so this is where like frameworks which are making you to use all the components like in react everything is component so you can probably do this that if you are scrolling then when my user is at like 70% of the height call this component don't load the code upfront this is asynchronous code splitting which is very very beautiful this is what is loading the code dynamically it's using the concept of promises and loading the code dynamically so previously on Christmas we wanted to include a Christmas theme on our main page which would be available if user is doing some sort of interaction so instead of like importing this Christmas sass file or Christmas javascript file upfront we splitted the code in this and we made a separate xhr call to load the Christmas theme so this way your single file will be splitted into multiple multiple chunks and will webpack will be taking care of loading all these chunks so if you see the output of a simple file it will be like instead of one bundle that is like too much around like for us it's like 70 75 bundles which we are supporting and we are pushing on the wire so these are my modules and the things which are used see just the id number all the others for for the pop-up it's like id somewhere 6 23 for some other module for tooltip you may these are all the separate separate things which webpack has generated and you can then load this thing on demand popular plugins are again split chunk plugin if you are using webpack for you would be aware of then for css a css extractor and it's a very popular bundle analyzer which i think mincy also told about the bundle analyzer that how it beautifully creates a bundle of all the things so very so here you can configure how you want to do your synchronous code splitting asynchronous code splitting so here you tell that what chunks you want to optimize and what should be my threshold to load i mean if you can also configure that if your tcp is taking like more than five calls then probably include that bundle up front because five calls is too much so screenshot of a bundle analyzer which so here you can firstly you need to see that on what file so let's say on my surveys file these all are my small small chunks and now i further want to asynchronously split the chunks how can i do that yeah now we will see how internally webpack is working to build these chunks so what is happening under the hood so we'll see how does webpack do code splitting internally how chunks are getting created and then how chunks are getting called so that let's say 10 years later webpack is not there there is some other tool so if you you can use the same concept and you can achieve the same thing your website will not break so this is a screenshot of my bundle so webpack ships this code webpack uses json p callback for splitting the chunks so here in this json p it takes all the modules as an array and the id is over here so here on this line chunk cache it creates a chunk it creates a mapping out of it and then so now it's not just a module cache it's a chunk cache also so if you are wondering that what happens something small as a module gets called multiple times so if user is clicking multiple times or a small tool tip is used everywhere so there's a it is available in your chunk cache webpack will be loading it through it then this function for module id in more module so it basically here checks if this module id is associated with this module or not if it is associated it will do a json p fetch so this is the most important function if you want to understand code splitting it's internally it's very very simple you just need to go through the code so webpack require dot e require and sure yeah it's doing a json p fetch after fetch whenever you need it's just adding the script tags on your file so initially your index file will be only having your critical code then when you need that code webpack will be injecting these script tags in your head simply when it's it's a very simple vanilla javascript everyone would be aware of and then it calls these thing asynchronously yeah so it's doing some very very knife thing it's nothing out of the box so if you don't want to use webpack because it's a difficult beast to conquer it's very very when you are switching versions it's it becomes very very tedious to just support the webpack so you can probably use the same concept which webpack is using just calling the asynchronous script tags and you will all be done by this bundle splitting your bundle sizes will be reduced to a lot and finally webpack includes this code at the footer so if you inspect any file which is generated by webpack and code splitting is on in the footer you will see this code is there and then it will judge your requirement and then it fetches the bundle so what did we achieved after doing all these things I mean our bundle sizes score bundle size was 1.4 mb to 540 still it's a lot bigger than the goal which I showed 241 kb css got reduced to 60 kb from 183 and meaningful pain from 6000 ms to 1200 ms that was something which really helped us to improve a lot of things as a product team saw the lighthouse profiling so these were the stats finally we got so our performance from 22 went to 97 just by doing this bundle so that's why I was emphasizing a lot on code splitting so if you are doing performance that is the only one thing if you do it beautifully if you do splitting and chunking beautifully 90 percent of your job of profiling is done because none other thing like people say that rendering is taking too much time it doesn't matter because browsers only take time to parse JavaScript so that was one activity with like 22 to 97 on it so on a concrete re-note I would say that if you want to achieve this this is not a one-step process it is a tedious project process because when you split the things things will break and will take a while to like mature on it so what you can probably do is what we did was we added this as a pipeline in our CI CD so let's say today my bundle sizes that is 1400 MB so I'm not targeting that I will go to 200 Kb's straight away I'll say that in too much time I'll be reducing 200 Kb's and I put a hook in my PR so if someone is submitting a PR and he is increasing the bundle so it's his responsibility to just maintain that 1200 Kb's so once I achieve 1200 Kb then I will figure out from 1200 to 800 how what optimizations I can do to go from 1200 so this is something which you can do and there are various tools which claim that they are supporting this but to be very honest I have looked into all the tools nothing is giving code splitting they are formulating the name in some some different way so if anyone is familiar with ember islands anyone from ember have used ember js okay so familiar with ember islands okay so they say that they support code splitting but when you look deeply it's like loading your code in iframes so there's nothing called as splitting other than webpack as of now parser says that we are supporting splitting with zero config it's again faking it's putting the code in the same bundle and yeah thanks for like listening to me you can follow me on twitter if you like like to thank you