 People that are here already, I guess, I mean, if you guys want in, you can go out for a tea or coffee break or maybe I can start off with some open ended questions that I have from my side and to grab a better knowledge about what kind of audience I'm serving. So, I mean, does anybody need to go out or should I start my questions? It's a normal poll and there'll be more of a discussion sort of thing. So that's what I intend to have before I kickstart with the performance. Okay. So when you don't actually raise your hand, I assume that you are saying yes that you want to be over here and not go out for a tea or coffee break. So let me start off with this as to how many people have actually measured their page load time and know it by heart as to what it is for today? How many of you just with a show of hand can tell me actually as to how much time their page is actually loading. So the people who have actually raised up their hand, can anybody tell me who has less than five seconds of their page load time? I'm talking about the total page load time. I'm not talking about the start-ender time for now. It was less than five seconds, but around four points something. Okay. And what about the start-ender time? Okay. Okay. Okay, so I actually can give a context because we are still having a lot of time, maybe 20 minutes. Through some interactions that I had so far with the people outside of this particular room, people were actually thinking that maybe it will also discuss about the page load performance. Though in my talk I'll be specifically, I mean discussing more about the rendering performance and not the networking performance per se. So maybe I can have a discussion as of now regarding the networking performance. And in case you guys, anybody has any specific questions regarding the same, you can have it already. So first of all, let me actually give you a glossary for the same as to when I say it's start load time and the start render time. What do you mean by start render time? Okay, so let's make it a bit interactive and let me ask anyone of you who can actually describe me as to what is the start render time. Can anybody give me a small set of, a small definition for the same, saying as to what it basically describes? The start render time. Anyone? Okay. Yeah? Okay. Okay. So is it the entire HTML or is it some part of HTML? After the head completes. Okay, so how much portion of the HTML? How much portion of the HTML then? Or to put it in similar words, okay, so this is close to the answer above the fears. The thing is that it's the first pixel that touches your screen, the first paint operation that happens, that basically describes your start render time, which is also the DOM content loaded, as you can see in your networking panel. So first of all, with a show of fan, how many of you actually use Chrome, Chrome DevTools? Okay. The rest of you, I assume, might be using Firefox, I guess, for debugging, right? Any other tool apart from this, when it comes to first of all debugging it on your local like how much time it is taking up for your page to load? Any other tool apart from this? On your local, when you have to test it out on local. Yeah, Weisler will be online, and when you only deploy it, only then will you be able to actually see it, right? Okay, so using their APIs, I guess, you give your HTML and then, that's another way, okay? Anything apart from this? Okay. I haven't used Spiddler, but what all data will it give you? Oh, sure, okay. The networking timeline and the blocking resources or something of that sort, right? Okay. So regarding networking performance, I mean, there's a key thing that I'll actually mention at most of the times is to make most of your things asynchronous. I mean, whatever you can make it asynchronous. But what I mean asynchronous is that there should be nothing that will be blocking, that will be render blocking, basically, that when your page is getting loaded up and it is getting started to paint, there shouldn't be any resource for which the browser has to stop your rendering or to display the first pixel onto your screen, it has to load for that particular resource. When you're done with this particular thing of making everything asynchronous, most of your job has been done. And I mean, most of the optimization has been taken care of in regard to the start and the time. Apart from that, when it comes to image optimization and something of the other sort, regarding the page load time per se, so that is how you can accomplish a start pixel render time. So I guess each one of you have understood the difference between the two as to what is page load time and the start render time, right? So now, I mean, most of you will be able to go back and do it by yourself. Making it, okay, how many of you actually use page speed insights to know as to what score is of your website? Okay, one or two hands, three, four, five, six, okay, 10, around 10. And what is the score that you try to touch upon? Is it 90, 80? Okay, you try to make it 90. Have you put in an automation tool that allows you to see as to if it drops below 80, it gives you an alert? Maybe grunt task, yeah, I mean, mostly that is also we use. Okay, okay. Anybody who's having this practice in place in their deployment process? Okay, one more hand. So page speed inside is one. Maybe web page test is another that you can actually touch upon. How many of you have actually used web page test? I mean, at most of your deployments, to see as to what the score is of web page test or is it just about page speed inside? No one actually uses web page test for knowing about their performance? Is it so? I'm able to see just three hands for now. Okay, I guess web page test is not that popular or might be because of some sort of complexity that people think of, but yeah, it's a great tool anyway. And it gives you a lot more insights as compared to page speed inside, which is a set of rules that actually tell you whether you are breaking any of them or not. So there's what page speed inside the, but as she said that to monitor her web page performance, she actually uses page speed inside and has a grunt or a gulp task to run in to actually tell whether the page speed score is below a certain threshold or not. And that in case it triggers up and brings up an alert to her, she can basically understand whether the deployment that is going to, I mean, run in production, whether it's performance or not, in terms of the networking performance. I'm not talking about the rendering performance for now. So that is what, I mean, everyone should have in if possible, yeah? Okay, in the Chrome Dev Tools, okay. So yeah, this is the other way. So maybe you are starting up by a Selenium Web Drive or anything of that sort and then running it up by yourself. Sure, yeah, that's another thing that you can do. Page speed inside also provides you an API with which you can send in the HTML. Get to know whether it's performance or not, whether these are render blocking resource or not. It will load it up by itself and let you know about the things. That can be a failure. So that is one part of it. I guess I have consumed like 15 minutes for now. There's 15 minutes that is left before I start off this conversation because otherwise people will be missing in upon that thing. So in case you have any other question apart from this, let's try to pitch it up and let's discuss them. Any specific questions for now? For minification of CSS and JavaScript, or it is about compression of images? CSS and JavaScript minification, right? So when you say about that, it's totally upon using the automated tools, automated tasks like available in Granted Gulp. So that is what I use by myself. And yeah, that is pretty comprehensive to give you any of the options that you want in case of minification. So there are several options that you can also pass in as to what level of minification or compression do you want to do with your CSS and JavaScript files. So it's pretty comprehensive. Have you tried that upon by yourself for now? Or facing any issues if you have? Okay, I'm not aware of what the Microsoft community is using for now, but Granted Gulp have their automated tasks that is a contribution by the community itself, which does the minification. A lot of things are involved in it and there will be hardly some difference in the minification that is happening through those tasks as compared to what is available via the tool that you prescribed. So yeah, I mean, okay. I mean, I'm not aware of such issues, but maybe it totally depends upon the configuration of the tool that you're using. So I haven't faced such issues when using Grunt tasks. So that's what I can say, but maybe when using that particular tool that you have just suggested. I mean, yeah. So it is a task, it's an open source tool by the name Grunter Gulp, whatever you want to choose. And you can simply use that and it allows you to actually install the tasks using NPM module. So yeah, that's how you can use it. And it will run irrespective of what the environment you're having, whatever backend you're having. It will run irrespective of that. Unless and until it's a build task. So maybe you'll have to trigger that particular automation task after you're done with the build of your own environment. Yep. Any other question? Yep. Okay. Okay. What kind of testing framework do you want to... Okay. Okay. Sure, yeah. Okay. So first is, I mean, when it comes to performance testing, you either have some tasks that we just discussed about Grunt, which allows you to actually couple with the PageSpeed inside API and then passing the HTML and see whether it's having a block in resource, or I mean, those rules, apply those rules and see if any of them are failing or not. So what is that? In case you want to monitor your PageSpeed performance from the ground up, as the static user monitoring, okay, I'm not going into the real user monitoring because that's a bit expensive to have in. But in case of static user monitoring, maybe PageSpeed inside is something that you can look up for and automate it with the Grunt task as we discussed before. Along with that, there's also WebPageTest.org as I discussed before, and they have their API as well, which is having a Grunt task as well. So you can simply use that and they provide you, I mean, data for most of the things, regarding your page load time and whatnot. And they run it on a couple of different locations so you can specify all of them. Or in case you are having a need which requires a lot more requests, thereby surpassing their public API limit, so you can basically have a private instance of your own of WebPageTest.org and run it by yourself. So maybe that is something that you can think about or explore. Yeah. Yeah. Yeah, everything. Okay. True, true. So when it comes to actually, I assume that you're talking about a single-page application, is it? So when it comes to that, we are actually, I mean, having in a similar situation where we are having a single-page application, there's a single JavaScript file which is built with a concatenation file then comes under minification and then it's how it's deployed to our servers. So when it comes to that, it's not actually that you can display a lot onto your WebPage, but what we do is basically have it render blocking, that is load it asynchronously. That way we'll be able to at least display the loader to your user for now, though it has to be something that should be done, I mean, in modules, I would say. So when, yeah. So we have, so we basically load our JavaScript asynchronously so that it does not block the particular piece of HTML which basically displays the loading screen. So at least that is something that you should really have and because at least on mobile or whether say about desktop because the size of that particular JavaScript is quite huge considering a single-page application, a person won't be able to see any pixel on his screen till maybe 5 to 10 seconds, right? Depending upon the size of that particular JavaScript. So why do we actually wait your user for 5 to 10 seconds without even telling them that your site is going to load or not? So that is what the thing is about optimization for the start render time. So most of the people say that when it's about start render time, it's just about starting to display the content which can be consumed by the user. But for me, it's also about as to how fast you can deliver to a non-technical person to understand that your website is not broken and it's going to load in after some time, okay? I mean, that is still understandable by the non-technical users, but when it comes to actually making them wait for 5 to 10 seconds, I mean, a person won't be able to differentiate whether your application has stopped working or is it still loading in some way or because of some process. So that's what I'll be saying about this. Any other questions? Yes? Okay, I'm not aware of the score to be changing that drastically with every page refresh on PageSpeed inside, okay? It might be on WebPageTest. I'm not very sure about it as well because I haven't seen it by myself. If it does flicker on the range of 1 to 2 or maybe 5 to 10, maybe that is something that you can actually ignore. But if in case it happens more than that, then maybe there is something on the server side that is happening depending upon the logic that you're having onto your further particular request. So that can actually basically might be triggering a particular if condition or something of that sort which displays a different content at one request and another on the second request. So, okay. So for the PageSpeed inside, I'm pretty sure that they remove all of their caches whenever they do a PageTest. So yeah, that is already in place. A better judge will be you yourself. If you want to actually automate this particular process, you can... I'm not actually sure about the open source projects that allow you to actually parse your HTML and then tell you whether there's a render blocking resource or any of those rules that are there in PageSpeed to actually tell you with a grant task that you can run locally. But there are... I guess you can follow the hashtag VEPR and there are several resources and several open source projects that people actually discuss and maybe there you can find something of this sort. Though there are many contributions made both in the rendering performance and the networking performance as well. So maybe you can look forward to that. Next item is browser perf. I'm not very sure whether it even allows you to see for your browser performance, for your networking performance via grant tasks that can run locally. But you can do it by yourself via Chrome DevTools or any other browser DevTools that you use. We are at 3.25. I still have five minutes left. Any other question? Okay. How many of you use Google.com to see whether your connection is working or not? Just be true to yourself. And for those who don't, which website do you use for testing it? Sorry? Testing of network connection? Okay, Facebook is another. Okay. Hack and use. Sure, yeah. True. Okay. So what do you guys think is the reason behind you actually opening up Google.com to see whether it's working fine or not? Sorry? It's fast, it's light, yeah? So why not make your application work it that way that people actually start hitting up your application every time they do it? So basically, I mean, I'm not very sure if it can be taken up to that level. By that level, I basically mean whether people will be opening it up or not. That basically depends whether they have hit their mind or not, which comes down to the fact as to what is the probability that people will be opening up Google.com as compared to your site, right? But yeah, I mean, this is something that one should really optimize for, that when your customer is actually opening up to just check whether their net is working or not, and just see for your website if it opens up, and that gives an indicator. So I guess that will be just overridden by the fact that service workers are now in place and you can even operate offline, right? So how many of you have explored the offline feature via service workers? How many of you? Even a demo will work. Okay, have you heard of it? This concept, the service workers allow you to actually make your website go offline. Okay, a couple of yes. Okay, three, four. Is it that the requirement hasn't come in so far or you don't think, I mean, it's worth the deal? It's worth being offline. I mean, for the people who have actually raised up their hand, so I know now. So for now, so maybe I understand that your requirement hasn't come up so far, but for now, what I can say is that if a web application has to go the same way that a native app has, maybe service workers is the best way to go forward with because it allows you to do exactly the same thing that you want to do via web applications, via native applications, right? That is, you are still available even when the network is offline. So something to explore then. Okay, we have still two minutes left. Any other questions? Yes. About the, about the fold content, above the fold content. Oh, yeah. Okay. You actually asked as to how we can optimize the above the fold content. Is that what you asked? Okay. So first of all, what I'll advise or, I mean, it totally depends upon your situation as to what kind of application you have built in. So I'm not very sure about that, but it's a jQuery application. It's a single-page application of what? Okay. So in case it's not a single-page application, maybe, I mean, there might be some, I mean, HTML that you can render along with some sort of styling with which you can display to your user on the first page for the start render, okay? And then load both of the scripts asynchronously. I won't even ask you to actually make it load some way faster than the other. I would actually recommend you to load them asynchronously after you're done with the start render. And once you are done with that, I mean, whatever resource you want to load in after that, it's your own wish. Yeah. But it shouldn't be blocking your, I mean, HTML parsing and the further processes that are involved in making your page render onto the user screen. Okay. So now we are through. We are at our time slot, which is 3.30. So let me connect my screen and get started. Okay. Can we have the projector open? So hello, everyone. The topic of this particular talk is performance beyond page load. I hope you are at the right position. And I have actually mentioned the things that I'll be covering in my talk, which is specifically the rendering performance. I'm not touching upon the networking performance for now because I thought that it will cater better to the audience of JQueryConf. Thanks to the JQueryConf guys who have allowed me to actually present it over here. So this is about me. I love to have tracks. So in case you want to have any sort of discussion, I'll be happy to have it. Apart from that, my Twitter handle is at the rate of poor one resource, Saxena. So in case you have any sort of questions during this entire talk, or even after you go back home regarding the application that you are currently working upon, you can simply ping me and maybe I can help you with that as well. What comes in next is the companies that I've worked in past, which consists of Slideshare, DirectEye, and now Wingify. All of them have actually contributed significantly in the way I perceive performance. I'll be discussing more at the end of this particular talk. So maybe we can wait till then. But yeah, that's about my background for now. So let's kickstart the talk. So first of all, let's just see some data. So let's take a look at our survey stats and we'll have a better understanding as to why, whether we actually require rendering performance to be taken care of or not. So according to a survey for a particular, by a Googler, what happened was that he actually asked for some insights from the users themselves to tell whether, I mean, what is the most required feature among the set of features that you are able to see for now, news automatically available in the morning, notification of content, or the others. So as you can see, the top most is a smooth navigation rate. So it's all about that. I mean, people are not even asking you for pinging them by a service worker and provide you a notification. What they're asking you is to render your existing application at 60 FPS. I mean, have a smooth navigation running. That's all what they want. Okay? So that is the reason that I'm currently having this particular conversation with you and this particular talk. So I'm pretty sure that a lot of you might say that you are not impressed, right? Are you? Are each of you impressed? I assume you're, you being sitting over here say that you are impressed, but I'll think of, I mean, one or two percent of you who don't think that way. So there's this other case study by Facebook in which at EdgeConf 2012, they said that when they reduce the frame rate of their web application, it reduced their customer interaction or it reduced the engagement of their users on Facebook. So it's something that you should really consider that if your rendering performance of your web application is not awesome, people might be losing or your engagement with the audience might be reducing. So what is smooth interaction? I'll actually start from the basics I'll be pitching up to the advanced topics. So let's start small. Okay, there's something with the projector. Maybe I need to reconnect. So regarding the smooth performance of your web page, the devices refresh the screens at 60 frames per second or they refresh the screens 60 times a second. Now what happens is that when you're refreshing the screen at 60 times a second, you have got just 16 milliseconds to render a single frame from your web application. If you exceed this particular 16 millisecond window, when you exceed this particular frame, your JavaScript is continued and you actually see a performance glitch in your web application, which is basically defined by the term jank. So how many of you have actually come across janky web applications before? Janky web applications? Okay. No other? Okay, so I guess we are all in sync with the kind of things that we have encountered before. Moving on. When failing to meet the frame budget, actually it's not just about 16 milliseconds but it boils down to less than 10 milliseconds when you have to complete the entire operation starting from JavaScript to coming into styles and then applying the different operations when you're rendering your web application. So it comes to just 10 milliseconds from 16 milliseconds because the rest of the time is taken by the browser to render your page and it's not in your hands to actually optimize it. It comes into running performance. So there are several aspects related to it. There are different sort of interactions. There are animations. So I'll be covering them one by one and that's how I'll be going in. So let's start with as to... I mean what are the things that we have to take care of when we actually render our application? So 16 milliseconds and a lot and in a nutshell, the things that we have to do are this. Starting from the JavaScript, you have to apply the styles then after which the layout operation triggers up which is followed by paint and composite. Okay? This is what happens and in the 10 milliseconds that you have, you have to take care of all of them. What I'll be telling you mostly are the best practices so that none of your JavaScript operations or the CSS operations make you exceed this 10 millisecond window that you have got. So first of all, let's understand as to what each of these component means. Okay? So we know about JavaScript and styling, right? So let's start off with the layout then. When you mean layout, layout basically means that you are modifying the structure of your application or any of your... when a web page element undergoes some kind of size change then it basically triggers a layout operation. This is what you can see. I've basically made a border color red and trying to display as to what is the layout of the different elements onto a particular web page but this is amazingly huge because some elements have got a kind of layout that they shouldn't have which is exceeding the size that they should have in because they don't need to interact for that particular space that they have consumed. The kind of CSS properties or the CSS properties that trigger a real layout are these, which is basically related to the size or the positioning of an element. That's what you can understand from that. Coming next is paint. Paint operation is basically triggered when there's a layout that happens and then there's a pixel which gets, I mean, positioned to a different location from its own space but apart from that there's a redraw that happens for that particular operation. So that is how you define paint. I guess it's a bit complex but try to define it why these CSS properties which is color, when you change a color it only triggers a paint operation and not a layout because its position or, I mean, place or size hasn't changed, right? So that is how you can understand a paint operation. After that is composite. Composting is basically after you're done with the layout and paint operation when you have to mix all the layers that you have generated so far in the web page. It comes down to the composite operation to render them together onto the user screen. So that is what happens in the composite operation. The CSS properties or if you want to see as to how your web page is segmented into different layers this is an overview for that. Next comes in what are the tools at hand that we are going to use in to actually see as to how our page is performing specifically for the rendering performance, okay? The first one that comes in is the FPS meter. I've just given the definition for the frames per second which is we want to have a 60 FPS frame rate and to actually gauge your frame rate you can simply open up your Chrome Dev tools and you can press the escape button and it allows you to actually see or let me just display as of now. So are you able to see the four options that we are having over here? One of them is show paint rectangles, composite layer borders. The third one is the show FPS meter. This is what I'm talking about. Now whenever you do some sort of interaction with this particular page you are able to see the frame rate going below and up, right? So this is something that you should really look out for when you're doing or scrolling onto your web page or doing some sort of animation. This is something that you should really see or consider to monitor your web page performance specifically the rendering performance. Then comes in profiling with the timeline. This is another tab on the Chrome Dev tools. I'm not sure about how it is placed on the Firefox Dev tools but yeah you can find a similar one there as well. So this is what you can see. This is basically a performance audit that I did earlier for a website by the name materialof.com when actually doing some kind of interaction with this particular page and when I recorded this particular timeline for this page this is the graph that I saw. Over here at the bottom you'll be able to see there's two lines. The above one describes, I mean represents the 30 FPS the other one represents 60 FPS and once you go above that it's basically a janky experience. When you go above 60 FPS it's basically a janky experience. So basically timeline is the other tool that you should really consider when it comes to monitoring your rendering performance. Comes in next is show paint rectangles. This is another quite awesome ability that you have with the Chrome Dev tools which allows you to actually see as to how many elements or what are elements are getting repainted every time you're doing some sort of interaction with your page. So over here what you are able to see is that there's a kind of green color right onto the entire web page. So what is represented by this is that the entire web page is getting repainted every time I was doing some sort of interaction. So I'll be showing this particular thing I mean in my performance audit as well so you will be able to see as to how you can do it by yourself but simply going over here and enabling show paint rectangles is it now visible? Yeah, so now you can simply enable or disable it from the Chrome Dev tools. There's how you can enable or disable it. When you see over here just the scrolling bar is getting repainted onto this particular page. Nothing else is getting repainted but onto that particular application the entire page was getting repainted. I'll actually tell you as to what are the different issues with that particular page that one can encounter while actually performance auditing your own application. So let's move back. So what are the things that we intend to achieve when I say smooth interactions onto your web page? First of all is a smooth scrolling, right? Whenever you're scrolling onto a particular application might be a native or a web application you are able to see that I mean that is the best way to actually see whether there's a jank happening or not, right? I'm not sure if you have come across an animation first of all which is janky even before seeing whether a scroll is happening to is able to proceed smoothly or not. So first is smooth scrolling. So I've listed down some of the things that can actually make you make your scrolling janky but I'll actually say it again that these issues are not comprehensive but these are some of the issues that I actually see in most of the web applications when I'm performance auditing them. So the first of all is garbage collection event. I guess we had a session yesterday regarding the memory leak so you must have been acquainted with what are the different things that comprise of or trigger a memory leak and because of which the garbage collection even triggers up which takes its own time until the time it runs it does not allow your JavaScript thread to execute, okay? The next thing that comes up is JavaScript triggered operation which further trigger which take a lot of time for the processing so one of them is layout thrashing. I'll be discussing it further in my slides. The next thing that comes up is so there are some libraries that we discussed yesterday for example even famous which allows you to actually have a very smooth scrolling even saying that you can have a frame rate of 60 FPS but there are even conditions where just with the styling itself you can make or you can trigger a janky experience or you can enable a janky experience for your user just with the plain CSS, okay? So I'll be even talking about that. When I say that what happens is that there is a lot of repainting that is happening onto the user screen. So there are some CSS operations that can allow you to have it and thereby making it janky. The next comes in in smooth interactions is smooth animation. When I say smooth animation I basically mean that you are animating different objects onto your web screen and during that you are able to see some sort of janky experience and most of these operations or the janky access is triggered when you are doing some sort of other processing or you are triggered some kind of another operation while you are executing your animation. So the key point to note is that when you are doing a single animation you might not want to trigger any other thing in parallel because that might make you exceed the frame rate or the 10 millisecond window that you are already having in, okay? So there was this another person that came to me sometime back and he was actually displaying me a particular animation that was running in when a person clicks onto the slide view and it was blurring the other page and what was happening was that that particular sliding out of the side view was janky but that was because of the reason that the other effect that it had onto the other part which was not animated that was the reason behind the animation which was being janky. So I would ask you that once you are through with the animation do consider making any other operation onto the DOM specifically once you are through with the animation, okay? I'll be discussing the same in the slides further but just keep those things in mind. The next thing that comes up is smooth interaction. So another thing that you should really want to have in is avoid synchronous operations. That is something that you should really, I mean, try not to have in for example when you are doing a dollar dot Ajax and you are passing an option which says async false it basically freezes your screen, right? Until that particular async call is not done. So maybe this is something that you should never have in at all. Comes in next what are the different best practices related to the networking performance, I mean, running performance. So first is avoiding memory leaks. I guess I mean most of you have been acquainted with it but it's mostly attributes to the different frameworks that we are using and what are the different sort of operations involved in that or the best practices involved. For example, if your framework allows you to create views and corresponding models. So when the model get deleted maybe you actually forgot to delete your views as well. So that basically creates a memory leak and you'll be able to encounter it. And if you don't then maybe jank is something that will haunt you. Okay? So this is something that you should really consider. Comes next is reducing DOM calls. So I basically assume that you all must be aware of what the DOM is. Now reducing DOM calls basically means that reading and writing operations onto the DOM they should be really avoided if possible. Or whenever you want to have it, have it in batches is what I intend to say. If you don't you can basically trigger out a layout thrashing which I'll be discussing in the next slide. Okay? But avoid having in a read and write operation onto the DOM. Now because it's a jQuery conference an example that I have to give you is basically a dollar body. Now how many times you might be referencing to it right? But what you can do is you can basically cache it in variables and then reference them to it again and again whenever you want to. Or when you are actually writing some sort of thing inside a loop you might want to extract it out after the loop and instead inside the loop you can do a string concatenation and after the loop you can write it in one go. So that is what when I mean reducing DOM calls. Then comes in forced synchronous layout. What is this? This is basically that after you have done a DOM write you are actually doing a DOM read. What basically happens is that when you have done a DOM write and after that you are doing a DOM read the browser has to actually do the recalculations again to understand whether you change the property or not of which element you are reading. So because of that there's a reflow that happens. So you have to actually avoid this particular thing by either moving your read before your write or in case you want to have your read after write then basically batch all of those operations because in case you do something of this sort in a loop it basically will trigger layout thrashing. Now I have a small demo to display. So let's go on over here. So this is the example of a library by the name FastDom which allows you to actually batch or read and write operations. So this is something that you should really look out for. I'm not sure if it will be able to load in properly. I mean till the time that we have got. So let's allow it to load in async and let's come back to it when it's done. So this is what it does. It uses the request animation frame in the background to first of all get all the read and write operations and inside its request animation frame it basically loops in over all your reads and writes in batches and then it does it that way. Instead of I mean doing it every time you request for it every time you request for a read or write. Comes in next is what are the different potentials for bottlenecks. So I have I mean most of the times when you actually perform a sorority of websites you'll be able to see that when you're actually scrolling there's a repaint that is happening. How many of you have actually seen it by yourself? Okay. One or two, five, six, ten hands. Okay. So let's see it by ourselves. Okay. So this is like an example that I wanted to display. So when we've triggered a force synchronous layout and we started so you will be able to see I mean a sort of janky jankiness, right? So this is something that when you have your layout crashing this is a kind of animation that you'll be able to see but when you run it with FastDrom which is bashing your reads and writes the way you see it is this. It's less I mean better as compared to what was the last version, right? So this is something that you can, really look out for. FastDrom is the name of that library but if you don't want to use it what I'll suggest to you is to bash your DOM I mean DOM reads and writes. Coming in next was the different kind of scroll bottlenecks. So let's see over here. So this is time.com. I intend to audit again but just for the sake of actually telling you as to how you can see for yourself as to whether there's some kind of scroll bottleneck or there or not. You can do it by yourself which is by simply enabling this particular thing. Here in place is everybody able to see this thing. So this is show potential scroll bottlenecks in the same position that you see show paint rectangles. When you see this you are able to see that there's a repaint that is happening onto a scroll. So first of all the scroll event listener is there in place and there's some sort of action that is associated with that particular listener, okay? So that is why the entire screen is getting repainted every time you do a scroll. Coming back. This is something that you should really look out for. This basically says that first of all via JavaScript you have triggered a write operation which is followed by a read operation and which triggers a forced synchronous layout. So until and unless you put in a request animation frame and you don't actually batch it you will be actually coming across a jankiness in your web applications. So this is something that you should really look out for or even implement when you are trying to avoid jankiness on your web application. Comes in next is debouncing your input handlers. So how many of you understand that, okay, so you must have used scroll event listeners, right? And you understand as to how many times it fires every time you do a scroll. So debouncing it is really helpful by what I mean debouncing is that you trigger it only a few amount of time as compared to whenever a scroll event listener or the function associated with your scroll event listener is triggered. You can do the same via request animation frame to debounce it. This is an example of what happens when you're not debouncing your input handlers. So there's a touch that is triggered onto the screen of your mobile device and the composer thread gets that particular event listener. The next thing that happens is that because you have associated or you're listening to the touch move listener, your JavaScript gets executed, which is associated with that particular listener. Now let's say that if it is taking 50 milliseconds, okay, 50 milliseconds is quite huge. If it is taking that much amount of time, the scroll is blocked for that particular user. He won't be able to do anything. He won't be able to do anything. So that basically means that you are coming across jankiness on your application. Comes next is reducing paint areas. So first of all, I mentioned before that whenever you're scrolling, I mean, your paint shouldn't get repainted, right? It's just about the new elements that are getting upended up. There's no way that your existing element should get repainted because of it. So that is something that you should really look out for. But apart from that, when you're interacting with a particular element, it is just that element that should get updated and not the entire screen. So let me actually give you an example as to what I basically am trying to convey. So let's go on back to our Chrome Dev tools. I guess the best way to give a demonstration will be Google.com. Okay, so this is taking some amount of time, but till then I can basically tell you as to what you don't want to have in, okay? So you are able to see some show paint, I mean, you are able to see green patches, right? Each one of you is able to see that. What basically that means is that that particular element is getting repainted. Now, because it's a GIF, it has to get repainted, okay? Because there's a new thing that has come up and browser needs to repaint it. But when I actually scroll this particular page, you can see the entire page is getting repainted, right? There's not that specific GIF image is getting repainted. It's the entire page that is getting repainted. So this is something that you should really not have in your web applications. It is also, I mean, it can trigger paint storms. So what I meant by paint storms is that there might be some kind of processing that you're executing or some kind of operation that you're executing in your JavaScript that triggers a paint operation to happen on your entire web page. If it is doing something of that sort, you will be able to see as to what I displayed just before, which is a paint of the entire screen. When something of this sort happens, jankiness is something that you'll really encounter, okay? So comes on next as to how we can run animations at 60 FPS. The first one is GPU acceleration. I mean, the way GPU acceleration, I mean, there are the different concepts involved in this. So first of all is that you trigger operations via CSS, you don't write via JavaScript. How many of you are actually into the practice of changing styles via JavaScript? How many of you? I mean, just be true, okay? Some couple of fans, but this is an anti-pattern that you should really want to avoid. What basically happens is that first the JavaScript, I mean, when it allows you to do that particular operation, it goes to the CPU, which then uploads all those operations to the GPU during which rasterization process is what kicks in and which basically delays or adds up to the amount of time in which you have to render that particular screen. So in short, you'll want to avoid writing CSS rules via JavaScript is what I intend to say, okay? Yeah, inlining style is different. By what he means is that style block, which is having the CSS rules and not actually having the inline styles with each element, okay? So next comes in, okay, how many of you? Yeah. So other way, you can have an element which is having a style attribute along with that. Yeah, so that is having a style block in place and having the CSS. So the other one is via JavaScript that you have a particular element. Yeah, element.offset top or something of that sort. So any kind of property that you are changing via JavaScript is something that will trigger this operation to take place, okay? And you really want to avoid it. Yeah, modifying the classes is another way that you can achieve, yeah, to avoid this particular thing, yes. So the next concept that is quite popular these days and is discussed a lot is GPU acceleration via Canvas. So how many of you have actually read that particular case study by Flipboard, which actually uses Canvas to, I mean, render their DOM, okay, one or two hands? Okay, so what they do is basically use, I mean, hardware acceleration, which is something of this sort as we can compare and basically have their entire DOM be replicated inside a Canvas. And any sort of interaction that you do is on the Canvas and because it is hardware accelerated, it is having much better performance as compared to the normal DOM. Though this practice comes with a lot of, I mean, it has its own cons and it has its own pros, the pros being that it's because it's hardware accelerated, it has much better performance as compared to your normal DOM when you're doing some sort of interaction. Though the cons of it are that it comes even down to accessibility. For example, not everyone can see your DOM, right? I mean, so there are some special people who actually have to read that particular DOM. So what Flipboard does is it basically creates another DOM which is not visible, but it has all of those contents that you are able to see inside your Canvas so that people can even read that particular thing. So you have to take care of it by yourself when you're implementing it in your own project. The other thing apart from that is Canvas is not hardware accelerated on every device. So there are even other mobile devices on which Canvas is not hardware accelerated and your application won't run as performant as it runs on other mobile devices which are having a better hardware, okay? So if you want to actually render your application in the same way on every device, maybe that is something that's not possible. Comes in next is JavaScript animations. So we have used, I mean, we saw yesterday the famous library which does it quite brilliantly. I mean, running animations at 60 FPS. The reason being that they triggered the CSS properties that allow it to be GPU accelerated or totally driven by GPU which is the reason for it to be run at 60 FPS. So maybe this is something that also you can consider. Though there's this other practice that you can actually use by yourself to run your animations at 60 FPS, which is that when a person clicks onto the particular element or when it does some kind of interaction, for example, a touch on a mobile device, there's a 100 millisecond delay in which you can do some sort of processing that you want to, okay? And when your animation runs in, you don't do actually anything during that particular time. And when you're done with the execution of your animation, you do any other operation that you want to after that. So I'm just repeating myself when I said before that when you're doing some sort of animation with any of your element, you don't do anything in parallel because that can affect the layout of that particular page and might trigger some repaints on that particular web page in the applications of yours, okay? So there's another library by the name cta.js built by one of my coworkers, Kushar Grigore. And he applied the same concept by using a different element to first scale up to a particular position to which he wants his element to move. And once you're done with the calculation till which position you want to move in, then you trigger the animation. So I guess if you go and check out by yourself the source code of it, you'll be able to better understand that. Come in next is the CSS animation. Not sure if you actually want to see the demo of it, but yeah, CSS animation is basically using the GPU again and not triggered by the JavaScript. So this is something that you should really look out for. The next thing that comes up is style calculations. So how many of you have actually seen as to what sort of operations happen when you use a CSS property? How many of you have... Or maybe even just use CSS triggers by yourself? Okay, one or two hands. Not a lot of people are actually... Okay, three. Or maybe five in total, right? So csstriggers.com is another website that you should really look out for when it comes to seeing as to what sort of operations are triggered by a particular property. So as I discussed before, that width and other such properties which are responsible for changing the layout or the size of a particular element triggered the layout operation, which is followed by the paint and composite. And then there are properties which allow you to just trigger paint and composite. And the other property by the name transform allows you to just do a composite operation which is much less as compared to what layout triggers, right? So maybe you'll want to... So when you are actually listening to maybe a scroll event, transform, I would first of all suggest that don't do some kind of DOM read and write because that will itself incur some amount of time for its operation. But in case you have to, maybe the property that you might want to go with is a property that just changes the composite operation or that just triggers the composite operation and not the layout of paint. So over here you can see there are different properties and associated with them in different colors are the kind of operations that they trigger. So for example, if I now type over here, background color, you can see that it just triggers the paint followed by composite. And when I change, when I trigger a transform, it basically does just the composite operation and nothing else. So this particular operation, I'm not talking about the core functionality or what they do, but it is more performant as compared to doing a background color upon a scroll, okay, in the most simpler terms. Then comes in Web Animations API. How many of you have actually read this spec or have used it by yourself? Okay, one hand. Okay, just one. Okay, so Web Animations API is the other standard that has been introduced and is going to follow up in different browsers and you'll be able to use it by yourself. I guess I should actually share the demo of it because it looks real promising. So using the Web Animation API, you can do the same thing that you actually currently do via CSS, but you can actually control it in a much efficient way via JavaScript. So it gives you much better control. So this is the demo of it. This uses Web Animations API and you can check out its source code. I have already published my slides on slideshare.net. You'll be able to actually go to that and I'll be sharing in the link afterwards. But as you can see, the animation that is currently there is running at 60 FPS. There's no jank that you are experiencing as of now and it is using Web Animations API. Comes in next is GIFs and performance. First of all, GIFs and performance don't go hand in hand. I'll actually want to open up a website by the name 9gag.com until the time I can actually tell you as to why GIFs and performance don't go hand in hand. As you can see as of now, I have triggered this particular feature in Chrome that allows you to see as to what part of this particular web page are getting re-rendered. As I mentioned before, that because it's a GIF, this particular element, which is the GIF itself, is getting repainted. So in case you have some sort of this application where you are having several GIFs on your web page, maybe you don't want to leave it as it is. You want to do something the way 9gag does. So what you can see as of now is that there's a GIF, but let me open up the Chrome Dev console and what you are able to see is that only this particular thing is getting repainted. But what if when I go over here, as you can see for the above image, the one that was just getting repainted, it has stopped getting repainted. So when a particular image is in focus, only then you should actually make it animate or whatever thing that happens with its re-rendering. It's fine till that point of time when it's in focus. When if it is not, why are you actually getting it repainted? It will add up to the repaints that are happening on your web page and it will be making you exceed your 10 milliseconds window. So this is something that you should really look out for. Come's next is the performance audit for the website that I just displayed, which is materialup.com. So let's go upon that and let's just see as to what is happening. So first of all, what you're able to see is that a slider came up when I was just scrolling. When I scrolled up, there was a slider which is in place. Let's just see as to what is the styling for that particular slider, for that particular header. So this is that particular element. So as you can see, the CSS property, are you able to see that it's position-fixed? So there's this rule or there's this thing that happens with position-fixed elements, that they get repainted every time you do a scroll or every time you navigate, I mean, you go up and down because they're fixed onto your webpage, that particular thing gets repainted. Now depending upon the size of that particular element, either your entire page will get repainted or it will be just that particular element gets repainted. But when there are several elements that get repainted onto a particular page, depending upon their size, there's an action taken by the browser, which is by the name Union of Damaged Regions. Has anyone heard of it before? Union of Damaged Regions. So what happens is that when there are several elements that are getting repainted, the browser tries to optimize it and tries to get a bigger element or a bigger portion of the area to get repainted instead of repainting several elements individually. What I wanted to say is that in case you're having a position-fixed element, see for it that it doesn't get repainted. What you can do basically is say, will change and followed by transform. What this does is it basically promotes that particular element onto its own layer. As of now you can see that that entire screen is getting repainted, but there's a different reason behind that. But earlier, you were able to see a special focus onto the header. But now it's not because we have implemented this particular CSS property which basically tells the browser that, hey, this particular element is getting repainted, so maybe you want to promote it to its own layer. Now you might be thinking that why doesn't browser does it by itself? I mean, why is it left upon us to take care of it? But there are different concepts involved in that. For example, anti-aliasing for a particular text, in case you do that. So for higher DPIs, that is retina screens, a browser already promotes these position-fixed elements into its own layer. But when it comes to your normal screens, for example, your MacBook Pros or anything which is not retina, in that point of time, you have to take care of it by yourself. So in case you are able to see that it is significantly contributing to your FPS, then maybe WillChangeTransform is a property that you will want to have on top of those elements. Then comes in time.com. Not much about time. The only thing was that, I mean, it's a reaping that is happening every time you do a scroll. So this is something that you should really avoid, that the event listeners that you are listening to or the events that you are listening to, you're not doing a lot of operations in them. Because if you do, it can make you, I mean, skip your frame and trigger a jank onto your web application. So that is about it. So thank you. Thanks a lot. Any questions? Yeah. Sorry? Yeah, yeah. True. It's very true. And if you actually see the different talks that have happened before and in IO 2015, I mean, the Chrome Dev tool is doing, I mean, most of the things by itself. But when it comes to your own business, maybe you'll have to look deeper into it, right? So what was discussed yesterday in maybe in the famous talk was that I mean, there are some things that have been done by the developers themselves with the use of library that allows you to do, I mean, or use the GPU acceleration for performing animation. Because, I mean, at most of the times, you can't leave it to the hands of browsers, right? Because you don't actually understand at what point of time this particular spec which is in discussion will actually come in and will be available to most of your users. So these are the different things that you have to think about yourself because it is you who are handling your business and not the people in charge of the browser, right? But obviously, this is something that really should be considered by the browser themselves. True, true, yes. Exactly. So in support of your, I mean, your views, I'll say that all of these practices that I just said, they are mostly a kind of hacks that you have to inculcate in your application, right? It can be a different strategy altogether as you thought about, I mean, what is that thing that was using Canvas hardware acceleration? So in that particular case, Flipboard. So maybe that's a different strategy altogether when you're using a famous library. This is something of a strategy. But when you think about these practices, maybe you can relate it to hacks. But yeah, I mean, this is something that even the browser team is currently working upon. But till that time, all these things are taken care of or, I mean, made performant. Till then, I mean, we have to take it by ourselves because it's our businesses, right? Any other questions? Okay, one more. Yeah. Yes? Sure. Okay. Okay. Okay. Okay. So what I'll say is that, I mean, Request Animation Frame does not actually think about as to how many frames it can do it or, I mean, trigger your particular thing. It does not actually say that it will be doing it 60 times a second. It basically sees a lot of other different things that are involved. For example, on your mobile device, depending upon the battery person that is left on that particular device, if it's in the range of even 15 to 20%, it starts reducing the Request Animation Frame count because at then, when you're doing an animation, it's using a lot more memory, a lot of power as compared to when it is being slow. So at times, you might want to leave it to the browsers themselves to optimize it because you don't actually want to consume a lot of battery, right? I mean, so there are several factors involved. It is not just this, but it's better to leave that decision upon to them. Yeah. Any other questions? Yeah. Sorry? Frame is basically the window that you have got in which you have to basically re-render your page. So that is, I mean, 16 milliseconds is the window that justifies your frame. Okay. So basically, when you... Okay. Have you seen this other... I won't say that a toy, but there was this other thing where you were actually... I guess it's by the name Bioscope, right? In which you are able to see... In which through a hole, you are able to see a picture running in and what happens on top of it is that there is a man who is running a particular movie or anything, okay, and what he tries to does it, he tries to run it fast. So the way it happens is that there's this concept involved with the name which is by the name Persistence of Vision. So in that, the... If you have to see different frames, right? Because what is happening when you are rendering a particular picture is that there are different screenshots that you are seeing. When there are 60 frames in one second, you are actually able to see a continuous operation or an animation, okay? When there are 10 frames, you are able to see that there is a discontinuation between them. So that is how you define a frame. Was this the answer? Okay. Any other question? Yep. Okay. Okay. So as I mentioned before, when I said about the CSS properties or the CSS operations that get triggered via JavaScript. So what... So let's start with the CSS only. When it happens... Sorry. Okay. So when you start off with the page load, okay. So maybe I would recommend that... I'm not sure about the time as of now. It's 4.17. Maybe I have exceeded my time, but I can contact with you and then I can tell you more. But for everyone else who wants to know it, there's this Chrome tracing tool that you can use by yourself, which actually delivers every frame and every paint that you can see by yourself. Apart from that, timeline is also the one that we'll actually allow you to see as to what all operations are happening when your page is getting loaded. So there's how I can tell you about that. I mean, in that particular time. So thank you. Thanks a lot for the kind audience. I hope I answered most of you.