 OK, so regarding my talk, let me just start till my screen comes up, and then we can have some demos after that and some live performance orders that you can actually see and do something by in parallel with me, if possible, and I'll be making you go through with every step that I actually perform, and you can learn from the same and apply the same in any web application that you want to. So let me start with the topic itself, which is JS performance deep dive. But when you talk actually about the performance of a web application, a performance of a web application is divided into two parts, I mean one is front end and the other is server side. I mean focusing upon the front end itself because it's a front end conference. Over here it will be segmented into two parts, which is one is networking performance and the other one is rendering performance. Mostly I'll be focusing upon the rendering performance, but because we can't actually go to the rendering part till we actually load the entire page, I'll be first focusing upon the networking part. I'm not able to actually show you a live demonstration, but OK, let me just go through the steps that we actually follow. So in networking performance, OK, even before that I actually wanted to know as to how many of you are core developers, can you just please raise up your hand and just let me know. OK, I mean a lot of you, OK. And what about product managers, like the engineering managers and the product managers? How many of you? The show of hand? OK, I mean very less, but no worries. What I wanted to know is that when you are actually thinking about performance, you actually want to see that you actually need to not only have it as part of your deployment process when your application is ready and ready to ship, you should actually think of it that way, that you have to make or deliver a great experience, a performance experience and that's how you should proceed. So it basically starts from the initial stages itself and having a great communication with your team is something that you should really look out for and have it continuously over the entire period of your application lifecycle. So each one of you, whether you are a product manager or you are a developer, I expect both of you to actually think about it the same way as the other. Just let me see if the display is working fine and I'll be going on with the demos after this. Yeah, finally got it. OK, maybe I don't need to actually worry about, I had actually all the demos opened up so that I can save it, but maybe it took all of my RAM maybe and that's why it crashed, so I had to restart it. So just let it load and OK. So now that we have gathered enough details about what are the audience sizes and stuff, let's just pour our hands into the actual thing. So let me ask you a small question that when the internet is not working and you have to load the first site to actually see whether it's working or not, what actually do you use? Is it Google? Actually open Google just to test whether it's working or not. OK, so I mean most of the majority I would say is actually using Google. What is the reason behind it? I mean, it's pretty obvious. First of all, it's the default search engine that we use, but apart from that, it's its speed, right? That it loads blazingly fast. That's what we actually love about it, right? And the thing that first loads, it's not even the sign or the logo of the company Google, but the actual text box over which you have to put in your query. So that is the best part of it. I won't be just displaying it. What I'll be actually thinking, I mean, displaying you is how you can actually monitor your page performance or actually see as to how a page is loading. So let's grab onto it, do a fresh page load. And what we are seeing is that a fresh request has been made again to the Google service, and it has come back. And what we are able to see is that over here, we saw a waiting time of some seconds, I mean 6.3 seconds, and after that a content download of 3 seconds. It might be because of the latency or because of the bandwidth, because we are having a slow internet connection. But apart from that, when I tested it on my, or if you test the same on web page test or any other testing application, you'll be able to see that they are able to deliver the first content or they are able to deliver the HTML to your web browser in under 500 milliseconds. And when I say that, it's an average of 300 milliseconds that they are able to give you back. It consists of a DNS resolution which is done by the browser itself depending upon the probability of you opening Google.com or not. And apart from that, it's also the response time that they actually take to serve in that particular thing to your web browser. So actually seeing the source code of it, there is a lot of things happening over here. First of all, it's the minification of content which is making us actually not able to understand any of it. But apart from that, it's for the performance optimization that you grab less data. And it is also GZIP and stuff of that sort has already been done. So if you have to take inspiration about how you want to load your web application, it should be an objective to have your start render time under 500 milliseconds and your page load time less than one second. Because the thing is that if you have this particular aim to have it on your desktop device, then trust me that when you go to your mobile and load the same thing on a 2G or a 3G connection in any place in Bangalore or in major cities, you'll be able to see it actually having a 2 to 3X, I mean the same time that you actually saw it on desktop. So that is because of several reasons which includes latency, the slow network connection and stuff of this sort. So that is what your aim should be. Getting on, let's start with this that when it actually comes up to making a performance audit, what are the actual things that you need to have or that you need to know about? One of them is, I mean, okay, how many of you use Chrome for debugging purposes? The show of fan? Okay. I mean, I guess everyone, the majority I would say. Okay. So this is going to be very fruitful to each one of you because I'll be using Chrome Dev tools by myself and that will help you actually grab an understanding as to how it's done. A special part of it is profiling. So that is what you actually say when you say that you're going to do a performance audit, you're actually going to profile it and you're actually going to see as to what components of it are taking what time and how you're going to optimize it or what is the issue that is actually coming across which is hampering your page speed or whatever be. Okay. This is a timeline graph of material up.com. What you're able to see is that there are different frames and a lot of them are exceeding 60 FPS by what I mean 60 FPS. I guess most of you must be understanding that that you are able to deliver a jank free experience in the most simplest words that will be the thing that you are able to deliver a jank free experience to a user. When you see anything above 60 FPS, it basically means that it has started to strutter on the client side and you need to take care of it. If you don't, then your user will be seeing a janky or he'll be able to experience jankiness on your web page or your web application, whatever be. The next thing comes up is show paint rectangles. Let me just actually also display to you as to how you can actually see it. Okay, taking a lot of time, but if you want to actually see the settings to enable it, this is it, that is show paint rectangles. If you turn it on, whatever component of the web page actually gets repainted, will be displayed to you in this green bar as I'm hovering over it. So the state of it is changing for some reason, even though you're not able to actually get that feedback as to what the changes, but maybe something is happening on to the input elements or to the buttons. So that is how you actually enable show paint rectangles so that you're able to actually see that what is getting re-rendered or repainted onto the browser. This is an example of a screenshot that I took of that particular website material up I'll be talking in depth about it in the future, but that's what you can see that when you have turned show paint rectangles on, this is something that you can observe. So what we are able to see is that the header which comprises of showcase market and collections link, that is getting repainted while I was actually scrolling, and there was also this an image which was getting repainted. Can anybody think of why it's getting repainted or not? Let's actually find out by ourselves, but let's move on. What about the FPS meter? I just showed you on the timeline that if your frames exceed 60 FPS or they are not able to perform all the calculations or the operations in under 16 milliseconds, then it is actually creating a janky experience for your user. So what you should really think about is that when you're actually using your application, you should even use the FPS meter to understand whether you actually crossed 60 FPS while you were doing the operations or not. When you actually see a jerk or let me just go over there and display it to you. So this is it, the setting, show FPS meter. If you turn it on, you are able to get it on the right-hand side top. And there, whatever interaction you do, you'll be able to see as to whether it's under 60 FPS or not. So let's say that we just type in JS channel and we are able to see that yeah, it dropped to about 6.8 or 30. But what I'll say is that don't actually just go about the numbers, which is like 6 or 10 or 30. It's about the interaction. It's also about the interaction. Because what's happening is that at that point of time, there might be a lot of processing that's happening. But if there's no interaction with the actual user, then it does not mean that it's going to be a janky experience. It's just that in that particular time frame, the amount of JavaScript or the processing took a lot of time to make it exceed your frame rate. So coming back, this is how it's displayed. Let's grab on to the performance audits. So what do you mean by performance auditing? Performance auditing is basically auditing your networking and rendering performance on your client's side and displaying the same. And actually trying to find out what the issue is because of which your networking performance is suffering or your rendering performance is suffering, which is like jankiness for the rendering part. Let's start it. We already did it for Google.com, right? So let's proceed on to the other thing, which is Smashing Magazine. Smashing Magazine has a great score. So how many of you actually know PageSpeed Insights? Use PageSpeed Insights in their day-to-day work, okay? So some of you. So, okay. Smashing Magazine has a PageSpeed score of 99 on 100. What that basically means is that the number of rules that are listed in PageSpeed Insights to make your page load in the best way possible without breaking any rule that is among the best practices. So that is how you're rated upon. And Smashing Magazine does a great job over it and is able to score 99 out of 100. What the different tool comprises of is whether you have blocking CSS, JavaScript or not and in the head section, whether you have optimized your images or not. Images take most of the part if you have a page, right? So whether they are compressed or not. Apart from that, there are several other factors what we'll be auditing. So while we are not able to get that particular score, actually see it for perforated.com. It's a small project by us and it has got 100 or 100 PageSpeed score. We have done most of the optimization. So let me start with the actual source code of this perforated.com. Let me zoom it so that everybody is able to read it. The first few sentence lines actually tell you that there's a DNS prefetch. So there are some resources that I'm loading from fonts.googleapis.com and some other domains as well. What happens is that when you're loading these resources every time the DNS prefetch allows me to make the DNS resolution just after I've got the HTML. And because these are in the head text, they are like done in parallel. The DNS resolution for these domains are done in parallel instead of making them wait the resources without actually loading the resources after doing a DNS lookup at the time of their downloading. After that, as you can see, you won't be able to find any resource, any JavaScript or CSS resource in the head section. This is the head section and you won't be able to see any style sheet or something of that sort. What you'll be able to see is a style tag in which I have put in my critical CSS. So what is the critical CSS? Critical CSS is the least required CSS that you want to have on your page when it loads. So in case you're not having any CSS in the head and you are actually having your HTML in the body, what will happen is that when your browser starts parsing your HTML, it will start parsing it and rendering it to the user without any styling. But when it has no styling, it looks ugly, right? Because CSS is the one that makes it beautiful. So this is the least minimum CSS that's required for actually styling the part of your page which will be visible to the user, which is in the viewport. So this is the CSS for that. Let's move on. Apart from that, I have all the images that are optimized. But apart from that, the CSS or the JavaScript that I'm loading, I'm doing it asynchronously. So whatever thing you have in, you want to have it downloaded onto your web page or downloaded as part of your resources asynchronously and not synchronously. What does that mean? It means that it's not render blocking. When I say about render blocking, it's basically that when the page is loading, it does not actually wait for those resources to come in even before actually displaying the first pixel of your web page onto the user screen. So that is how you actually make it asynchronous. You can just see the source code and visit it by yourself and actually see all those things. What I was focused upon is to actually tell you that what are those things that hamper your networking performance of a web page and how you can optimize it. There are several guides, and even PageSpeed Insight allows you to make it a performance progressively with every score that you gain out of 100. And that's how you can even make your web page have it like load or decrease the start render time under 500 milliseconds and have the page load time under one second. So that is how you do it. The next comes in a smashing magazine. We already saw it. Google IO 2015 is also a key contender in this and it has got a great website. But what we are focused upon to see in Google IO 2015, it is not the networking performance actually because when I saw that I actually saw the CSS in the head and even JavaScript of web components inside it. But it's actually, I mean, what you should learn from it is how they are actually tackling the rendering performance. So there are several blog posts that have been written by the people who actually made this particular website. What I'll be doing as of now is like just telling you or just seeing as to what all things happen when you do it or whether we are able to see that it exceeds a 60 FPS while we are making an interaction on this particular web page. So it starts with recording. So this is a recording of the timeline. Let me just zoom it as well. And we are doing some interactions on the page. It's a single page application. So that's what we are able to see. Oh, I'm so sorry. I was actually on the network tab and I was actually supposing that it actually saves all the data regarding to networking regarding rendering performance, but it was actually saving for networking networking performance. So let me just record it once again. So as you can see that there's a buffer that's happening. I mean with every interaction and it is storing all the events that are happening over there. And what you can see is that at the time of a link that we clicked in, you can see JavaScript processing over there. But apart from that, everything related to paint, regarding to paint of your web elements onto the web page or regarding an interaction that we just did, none of them actually exceeded 60 FPS. So that is how you actually have a timeline which is smooth and does not actually make your users' experience janky. So regarding what are the tactics that are involved into getting a similar timeline for your web applications? We'll be discussing in detail, but let's move on for now. And let's start exploring what are the concepts related to rendering performance and even how you can achieve something of this sort in your web applications. To start with, I have a pull request to actually refer to which was for JS Channel. It was not regarding their web performance, their rendering performance, but it was regarding their networking performance. And let's grab onto that. For some reason it's taking some time, but let me assure you that what are the things that were involved in that? So basically it required concatenation, minification, optimization of their images and whatever their loading on, whatever the resources are loading on that particular web page, load asynchronously. So that is what was all in the pull request. You can actually go back and see for yourself. So what is the critical rendering path? As I told you before that the critical CSS is basically the least amount of CSS that is required to style your web application when it loads for the first time. Critical rendering path allows you to actually see that there's no rendering or blocking resource onto a web page when it's actually loading. And everything that you're doing is asynchronous. This is the timeline of how a page is rendered onto your screen. It consists of we first making a request, getting the HTML, getting the response and then at the browser actually parsing that page, actually grabbing onto the entire CSS, all the CSS and the JavaScript resources that are inside the head. And if they're inside the head and are not loaded asynchronously, then they're parser blocking. And first the browser has to actually load them and then display the first pixel onto the screen. So the next step that comes onto is style calculations. So how many of you have actually tried by yourself to actually see that how many, I mean how the CSS properties are affecting your page or what kind of performance impact that they're actually having? With a show of hand, can you just tell me? Do you actually, okay, a couple of hands? Do you guys actually think about it when you're programming or it's after you have created your application then you actually go into like analyzing them? So after building the application, right? So that's what I can say that when you're having this experience of going, that when you complete or done with your application and then you're analyzing your application to see whether it's performing or not, that's like the first phase. After you're done with it, then sort of becomes a habit of yours that you know that this particular CSS property is actually costing you a lot when it comes to repainting or doing a re-rendering of your elements onto a webpage and that's how you actually progress. So CSS triggers give you a great help. Let me just load CSS triggers as well. And over here we can see that there are several CSS properties and what you're able to see is how they affect or what all sort of operations happen when you actually use a property. So let's take an example of Align Content over here. You can see that there are three operations that is layout, paint and composition that are triggered when you use a CSS property. I'll be explaining them just after this particular slide and that's how you will be able to even use that or understand those concepts. But apart from that CSS triggers is a great tool that you can actually see when you want to actually know about the CSS properties and how they're impacting your rendering performance. So what is the pixel pipeline? So most of the things start with JavaScript. I mean the interaction of the page, right? What happens after it is that JavaScript has made some modifications to your DOM and or maybe changed some CSS operations or and like consequently changed your DOM and the CSS operations are then rendered onto your DOM or they affect your DOM and they are categorized into three parts or the sort of operations that they perform eventually are categorized into three into three which is layout, paint and composition. The layout operation is the one that affects how your web elements are positioned onto your web page. That's what layout is. These are the CSS properties that affect just the layout or layout be consecutively even triggers paint and composite operations. The next one is paint. When you're done with the layout part the pixels that have been impacted they are actually repainted and that's how they are actually passed on to the GPU for re-rendering and then comes the composite layer. So before that the CSS operations that just trigger paint and composition eventually are these CSS properties which is color background background color and stuff of that sort. And after that we come to the composition where each individual layer which is forming the entire web page after that is re-rendered the specific layer it gets composited into one and is then rendered onto your web page which is composting. So what are the difference performance bottlenecks that we actually see or which we actually encounter while we actually writing our application code? The first one comes to our mind is memory leak. How many of you have actually encountered memory leaks in your web applications? I'm sure many of you must have done it right but with the memory leaks most of my experience actually tells me that they are very specific to the frameworks that you're using. Most of us are actually using like a framework, right? For writing a single page applications or whatever interaction or when we are writing any JavaScript we are maybe using backbone or Angular or Ember. So they are having their own bottlenecks or they are having their own optimizations to take care of when you actually want to deal with memory leaks. For memory leak you can again go back to Chrome Dev tools and see a timeline for yourself as to how it is happening in your page and actually grab on to that. There are some events that actually tell you that when our garbage collection is triggered but actually understanding as to how it is triggered is very specific to some of the frameworks if you're having a vanilla JavaScript you'll be able to grab it easily. But if I take an example of backbone so when you're actually manipulating a model there are several views that are related to it, right? When you actually delete a model you have to take care of the fact that you even have to delete the corresponding view. So if you don't actually delete a view that view will remain in the memory and will be eventually be garbage collected. That garbage collection will trigger an operation which will be out of your scope and you won't be able to control it. And if it takes more than 16 milliseconds then it will eventually make your page appear janky while being at your client side, right? So that is about memory leaks. Let's proceed on to avoiding forced synchronous layout. What I actually mean about that is that when you're having a JavaScript and you have made some sort of write operation and if you do a read operation eventually after it what will happen is that this sort of a buffer that you can think of in the simplest of language and when that buffer gets full or the write operations are written into those buffers after that if you do a read operation of the DOM what the browser has to see is whether it did some sort of operation on the layout part because of which the next CSS the next property that I'm reading from the DOM gets changed or not. So that will trigger a forced synchronous layout, right? Okay, sure. So what I actually mean is that when you're writing your JavaScript code there might be an instance where you have manipulated your DOM for example, there's an element that you changed the CSS property corresponding to that particular element. After that, if you do a read operation for the same element or maybe another element onto the web page the browser doesn't know that whether it this CSS property that you're actually reading it effect. It was affected by the right operation that you did earlier or not. So in that particular particular process the browser has to trigger a layout so that it actually understands that what is the correct CSS property for that particular element that can be the position of the particular element, right? So that is how you actually trigger a forced synchronous layout that can be a CSS property which is specifically a layout operation. Okay, might be like the offset top if you have to actually see the position of that particular element is it clear now? Okay, next comes in layout thrashing. Layout thrashing is consecutively forced synchronous layout that actually makes you do a layout thrashing. There's a small example that we can see. So what you can actually see is that there are several balls that are moving like from left to right and right to left and vice versa. But it seems janky, right? It's not that performant. So let's just see as to what happens when we are actually doing it or what is actually happening. So let's just dive into the source code of it. Let me zoom this. Yeah, sure. Is it readable now? I want to actually focus upon the synchronous function, okay? Yeah, just a second. Are you able to see the sync function now? Read the top offset. It's in the comment line. Let me just do it a bit more. That will actually become non-readable so but I have it this way, okay? So let me just select it and that is what I aim to display. This is a function which actually does a right, okay? But after that, when you're done the right, it actually makes a read which is the element and a property which reads its offset top. So that is how we actually trigger it. If you're having something of this sort in a loop when you're dealing with a lot of objects, it actually triggers a layout thrashing or that is what the, I mean, the phenomena that you will say that this is actually layout thrashing. But it is actually four synchronous layout which is done multiple times. That is what it actually means. So how to avoid layout thrashing? There are several ways that you can do which is consecutive DOM read and write operations actually trigger them, right? So why not do it in batches? So you do, so you have a read operation and you have a write operation but do them in batches. Do all the read operations in first and then do all the write operations after that. So there are some libraries that have been developed by some developers, one of them is FastDrom. It allows you to actually combine all your read operations and process them in batch and have your write operations processed after that. So that is how you do. The code is simple to understand and you'll be able to take care of it after that. So next comes in, what are the potential bottlenecks regarding to scroll? So when you're scrolling, it's actually the janky behavior that you're actually seeing. But what is the reason behind that? The reason behind it, when you're actually scrolling, there are several times that that function gets executed. In case you're doing some kind of JavaScript operation that takes a lot of time. At that point of time, your frame or your 16 millisecond window will get exceeded and you won't be able to complete that and that is how you actually come across something of this sort. What you can do in this case is basically debounce using a request animation frame. That is the best way possible and even avoiding to have an event triggered or some sort of JavaScript operation to happen in the scroll event is something that you should really look out for. Yes, that is what it's actually in the pixel pipeline that when you're having an input handler, you have a right operation and after a read operation comes in and it's inside the request animation frame, that is how you can avoid it. But in case you don't have it, then it will be a four synchronous layout. Four synchronous layout. Debouncing input handlers is another thing. It's not just about the scroll event, but it's also about how you are actually taking care of or what you are actually doing when you're actually listening to the other events. For example, key press or a mouse move or something of that sort. So even debouncing them is really helpful because you don't want to have your JavaScript operations use more than 16 milliseconds. So what happens is that you're having two threads. One is compositor, the other one is your main thread. When a user touch happens, it's actually committed to GPU and whenever some kind of interaction is taking place, this is what happens. But in case you're having a user touch and there's some sort of operation that you have binded to the touch move event, it will be synchronous and you'll have to wait till that particular operation is completed. In that case, the scrolling is blocked because it's actually your move event, right? It's a touch move event. So you better take care of it as to what sort of JavaScript operations that you are performing while you are actually listening to those events and are executing it in them. So that is something that you should really look out for and the timeline is the best way to actually deal with them. The next moving on is reducing documentary flows. It allows you to actually take care of the fact that whenever you are doing some sort of change to the DOM, it actually happens to that particular element only and should not or must not affect the entire webpage, right? For example, if I'm dealing with a click operation on a particular button, if it triggers a repaint on the entire webpage, then it basically shouldn't happen, right? Because I just interacted with that particular button. In case it is opening a pop-up, then I should actually see only the pop-up area to get re-rendered. I shouldn't actually see the entire webpage to get re-rendered, right? So that is what you should really look out for. Next comes in is simplifying paint complexity by what I mean is that sort of CSS styling or the CSS rules that you are writing, they should be really performant. When you actually say that they are performant, I actually want to quote this particular line from Lune, Rune, Lisvain, which says that roughly 50% of the time used to calculate the computed style, half of it is actually inside, half of it is actually used to figure out as to what the CSS selector is. So if you have to give you an example that when you're writing a CSS operation for a particular element, that is just a single element, right? You would actually use an ID for writing a CSS rule for that. And you won't actually do a generic thing, for example, which says that in that particular body tag, find this particular element inside which there is this element of mine, which is a single element. So instead of doing, I mean, having your CSS rules make out a chain, you would actually want to reference to it in a single goal, which is by using an ID, right? And there, you can even use classes. ID is more performant as compared to classes when you are actually referencing to those elements, but it totally depends upon the use case of yours. But what I'll be, what I want to actually say is that don't have it nested. I mean, don't add in more of complexity if you can avoid it. If you can avoid it, then just do it. But don't add it unnecessarily. The next thing that comes up is reducing the number of elements styled. By that, I mean, when you're actually having a webpage and you're writing the HTML code, you might be having different divs and anchor tags and spans and whatnot, but reducing them to the place where they're actually required for styling purpose or whatever other thing that you want to do while interacting with them or for their display. Just do, or just have those elements which are required and not unnecessarily have different tags because the more the number of elements that you have on your webpage, the heavier it is for the browser to actually take care of it. Then comes in reducing the complexity of CSS Selectors as I just mentioned before. It was among the best performances or the best practices that you must adhere to. The next comes in, so this is an example of it that a CSS selector which is having a class box and is referring to the last child. So instead of doing that, what you can actually do is, if possible, I mean, it totally depends upon the use case I would again mention. But if possible, why not have a final box title for the same thing, right? Easier to understand, easier to improvise upon or modify whenever you want to. Then comes in reduced paint areas, as I just mentioned before. Reducing paint areas and when you have to actually see as to what the part of your screen is getting re-rendered, the paint on rectangles option in your developer console will help you to actually understand as to what are the different parts of your webpage are getting re-rendered and what you have to take care of or not. Then coming on to avoiding large and complex layout, it's again the same thing about the HTML elements that you're having in your webpage or the elements that you're affecting when you're doing some sort of operation. So this is what you should really understand that if the interaction of webpage is very specific to a part that your user has interacted with, then the operations should be limited to that particular element only and not to the entire webpage. So in case you don't do that, you might actually see something of this sort in your timeline which actually displays the paint pixels and compositing taking more than 60 FPS or you're taking more than 16 millisecond in your case. Next comes in GPU acceleration. So how many of you have actually read that article by Flipboard where they actually used a canvas to make a replica of their DOM and have most of their and have the entire thing rendered onto the canvas? How many of you have actually read that thing? Okay, just a couple of hands. Did you actually use it by yourself or are actually into the process? Can just anybody know? I mean, just say. Whether, sir, you. Okay, so a couple of people. So when you're doing this thing, what is the reason behind it? So canvas is hardware accelerated. The reason that it will be performant is that most of the devices, whether it be mobile or desktop, it allows your canvas to be hardware accelerated and perform better in cases as compared to DOM. So that is one part of it. Avoiding paint storms is the next issue that crops up. You should really avoid it. Paint storming is basically painting several portion of your elements when you're scrolling or you're doing some kind of interaction. That is about it. And how to perform animation at 60 FPS? I'm sorry I'm going a bit fast because I have some less amount of time. But yeah, regarding the JavaScript animations, you can see something of this sort, that there is a timeline and you have to perform your animation at 60 FPS. So what will you do? There are different things or different calculations that are happening. They can happen or they can be processed via GPU or it can be handled by you yourself when you have that amount of time. What I actually mean is that if you want to find out as to how much x coordinates or y coordinates, you'll actually have to go through when you're actually moving your element from one place to the other. Even before making that animation, you can do something of that sort before running your animation. And once you do that, it will be a jank-free animation that happens. In 100 millisecond, I have actually demonstrated this particular timeline for just the touch devices. Those touch devices have 100 millisecond window where when a person actually touches the screen, if he is able to see or get an interaction under 100 millisecond triggered, that is how he feels that it's not janky. So that is what you should aim upon. There are several libraries that allow you to, I mean, make your animation under 100 or perform that particular operation under 100 millisecond and allows you to have a 60 FPS animation. I would recommend you to just explore cta.js library, which is one of my, by my colleagues, and it performs a similar operation and allows you to render your animation at 60 FPS. Going forward, CSS animations are really prescribable as compared to JS, but if you don't have any option, then that is the way to go if you want to have it. The second comes in is the web animations API. So I actually wanted to display a comparison between the two, and it's almost no difference. What is happening at the background is one of them is CSS animation and the other one is web animation using web animations API. Regarding the source code, I can surely share the presentation and you'll be able to look into that. But web animations API is seriously promising and allows you to have or deliver a better experience as compared to what you can, what you're actually seeing while taking care of it via JavaScript or CSS. Then comes in GIFs and performance. Trust me, they don't go hand in hand. They actually, when it's a GIF image getting rendered onto your web page, every time you see a different picture onto that GIF image, that portion of the screen gets re-rendered. Can you imagine this? For example, let's take the case of materialup.com. I won't be able to perform this live right now because I have less time. But if you go over there and you just actually see as to how many times GIF image gets rendered, you'll be shocked. Plus, when you do a scroll, their header actually gets repainted and because the GIF images are also getting repainted, it's actually the entire page that gets re-rendered. Coming on to next, what about promotions, right? Everybody likes promotions. So, who should we actually promote? I mean, the fast performance or the good performance, right? So that is what it actually even happens in your DOM. For example, you are able to see a particular element having a lot of re-renders. What you should actually do is promote it. Promote it to its own layer so that it's just composited at the end and is delivered for re-rendering. How you can do it is that if there's a moving element, you can simply use the classes. WillChangeTransform or TransformTranslateZero, which will allow you to... I mean, it's a sort of hack that you have to inculcate into the operations that you're having in. And this will promote it to a layer of its own. So why not promote everyone, right? I mean, we can't because that will be a serious overhead. There will be several layers that will be onto your webpage and compositing them will actually take a lot more time. So that is how... That is what we don't actually do. The next comes up is performance audit for MaterialUp. But if you do it by yourself, you'll be having a similar experience. I would urge you to actually do or allow ShowPaint rectangles from your console and just see as to what all parts of your webpage are getting re-rendered. That way, you'll be able to understand as to what... As to how you should actually think upon that when you're having several elements and getting re-rendered, how does it affect your timeline or your rendering performance? So that is what I actually wanted to say. Okay, so small thing about me. My name is Apur Saxena. You can follow me at the redapur underscore Saxena. If you have any sort of... I mean, feedback or you have any question regarding performance, we can actually have it. A small thing about the companies that I've worked with, it's Slideshare, Directive, Wingifair. The reason I put this slide is because these companies actually helped me to understand more about performance and to take it in the application deployment process, specifically Slideshare, because whenever they used to have their meetings, which were bi-weekly meetings, they used to actually discuss the page load performance of their application. And that used to happen every two weeks. So that is how we actually start a discussion of this sort regarding performance with their developers. So in case you are a product manager or you are a developer yourself, you might actually want to have this sort of discussion as part of your meetings, right? It will make it more, I mean, happening, right? I mean, because meetings sometimes get boring, but I guess discussing about performance is really happening. And I guess that is what you can take care of. I mean, take from this particular piece from me. And apart from that, we are doing great work in Wingify as well. So in case you want to be a part of it, just happened to come to us and we'll have a great discussion after that. Yeah, in case you have any questions, I'm done. You mentioned about tools like Faston, CSS Trigger, page speed inside. But then most of it sounds manual, like you're looking at timeline and all those stuff. So it looks like there is need of some toolkit to automate this. Sure, yeah. With scans, your HTML, CSS, JavaScripts and pinpoints, okay, this is bad and you have to take care of it. True. Are you aware of anything like that? Yes, sure. So when I talk about page speed insights, they have their awesome API that is exposed to you. What you can do or several companies even do as of now is that have it part of your deployment process. For example, when you did a deployment, you actually run it, you run your particular page on page speed inside and grab the score of it. If it's less than what you want to have in, for example, you have your current page speed score as 100 on 100 and if it becomes 99, they'll ping you and they'll say that there's some issue with the deploy that you just did. That is just a meter, right? I mean, it is going to give you a number. But then would it pinpoint what is going bad in your code? So not exactly, but it can actually point out the things that are happening or the rules that are breaking up. So that is how you can actually think about it. If you want to actually get to the pinpoint, I'm not sure if it exactly does that, but there are several other tools as well, like web page test. It allows you to have a great benchmarking of the web page that you want to do a performance score on and gives you the exact details of that. So that is what you should explore. And they also have an API and allows you to even have a private instance of your own that you can run by yourself. One more question over there. Service workers, I love it. First of all, the reason behind it is that they allow you to be offline, which is something I really admire and one should really have it for most of their applications. Specifically, if you're having a website that publishes several articles, I would love to have them while my connection speed is not that awesome. So definitely service worker is one of them and there are several other things that are coming up with service workers for example, having your web animation API be made available to the service workers because they currently don't have any access to the DOM. So something of these sorts are happening and I really look forward to them. Cool. Thank you very much, Shupu. It was a nice session. A great round of applause for the GS channel. I mean, I really commend their execution so far and it's been a great experience. Thank you. Thanks a lot. Thank you.