 Hello. Hi. Didn't you have your lunch properly? I cannot hear you properly. Hello. So I am Swastik Parik and I work as a senior UIUX developer at QED42. I have with me today, Sakit Kumar, that is UIUX lead at QED42 only. And our session will be art of debugging using Chrome DevTools. So before I start on, is my voice clear at the back? Can you hear me, guys? Okay. So today we'll be focusing on front-end rendering performance and what all criteria and variables and what all parameters that we should be focusing on to increase the performance and know the grades and pits where rendering gets a jaggery experience and where you need to focus and, you know, just to make your site more performance. So you know about the speakers I want to know about my audience also. So who all are front-end developers here? Raise your hand. Who all are project managers? Nobody. And who all are back-end developers? I'm sorry, guys, that presentation won't be so much informative for you guys because you'll be focusing mainly on front-end rendering, but you can still sit and watch the session. Nice. So we'll be focusing on front-end developers and the project owners and the project developers and the project managers that wants a good user experience. So the product that we'll be working on, they want a good, they want really about a good product that is a good user experience. So talking about a successful application. What is a successful application? Anybody want to answer this? What do you think a successful application is? What makes an application successful? Anybody? Raise your hand, stand up. User-friendly. User-friendly. What else? Performance. CQR. CQR, yes. But what about the... So you're thinking about, through the developer perspective, you're not thinking about a project manager perspective because you don't have any project managers over here. So if you want to deliver a successful application, there is an ROI associated with every application. So you invest some amount and you expect a return from it. So if you want to deliver a successful application, what you'll do is you'll create your application and make it powerful using a good hardware, let's say 2GB RAM you're using and some high RAM at the back end, good servers and casting, that all you're using. But what about the ROI? So if you have invested such a big amount on your hardware and you don't have a proper ROI from it, then what happens? So it won't be called a successful application for the project manager because the ROI is not there. But if in the less ROI when there's less hardware and you have to work with 500 MB RAM, the application cannot be performant enough. So what we have to focus here is the sweet spot where the application is performant enough and it should give a proper ROI so that it's successful about both project managers and developers. So as I told you, we'll be focusing on the front-end performance only here. So I want you to know about the rendering process before we actually hop onto the variables and parameters that are responsible for performance. So whenever you request a resource from the server, what all processes happens? What all processes a browser goes through to fix them? So basically we are basically talking about more of a browser rendering process here. So how browser wants the response is there then how browsers paint it over here and what you see in your applications. So this is what we are talking about here. So after these slides, we'll have a demo session and due to the scarcity of the time, we will be moving very fast on the slides and focusing more on demos. So the rendering process. So if any one of you have ever opened DevTools and opened the network tab, you must have seen a layout like this. So whenever you hit a URL, all the resources that get loaded on the page shows up in the network tab. On the right-hand side, you can see there is a blue and orange and green box in which there is a timeline type structure. That is the time that resources actually took to get rendered on the page. By rendering, there are two phases. First, the request response that happens between server and client and the second of all, the browser rendering. How browser renders it. So whenever you request a URL, whenever you request a resource from a server, this all process happens at the back end, the browser. So whenever you hit a URL on the browser, it actually redirects you to the app cache where it search for a cast copy of the resource that you are looking for. If it finds it in the app cache, then it hops on to the request response phase and it requests the resource from the app cache and app cache response with the resource. And it's pretty clear if you don't find it in app cache, then you have to do a DNS lookup, then create a TCP connection to the server and then do request and response. So modern browser, what they do is they expose all those variables and all those breakpoints where you can actually find out how much time that each phase took. So as you can see at the top, you're seeing start time, redirect start time. I'm not sure whether you'll be visible at the back, but I can read it for you. So it's start time, redirect start time, redirect end time, like this. Every phase has a start time and an end time. And all modern browsers actually expose these data. So you can actually see those data into console and figure out which phase is taking part time and where you need to focus on. Right? So moving on. Now we have the HTML and CSN on all the resources in our browser, but we still have to render them. So how browser actually renders all the data on the website. How it actually populates each pixel with the proper color that it should be. So the process through which the browser goes and renders the content on the screen, that's called a pixel pipeline. So how it actually happens. So when the HTML DOM gets built and the CSS gets fetched when the DOM event fire, when the DOM is complete, there are some JavaScript that actually alters the DOM or there are some CSS styles that we actually apply or we add some CSS class that actually applies some CSS properties to the element. So what happens initially after the DOM event gets completed, all the alteration has been acknowledged by the browser so that a new HTML DOM has been created. After the DOM gets created and the property has been fetched, all the style calculation has been done by the browser. Now style calculation we mean that all the elements, so we actually overwrite some styles, we actually have selectors where multiple styles and multiple selectors are getting applied to an element. So browser actually do some parsing and calculates the whole styles that need to be applied on the element. After the style calculations layouting happens. So, just a previous slide. Layouting, in layouting what happens is the CSS styling and the HTML DOM gets combined and a render tree is created in which there is element to style mapping. And it creates different frames and it actually finds out which element will take what dimensions and where it should be located on the screen. So this process is called layouting. The next process that happens is paint layers are superimposed onto each other and a single layer has been created. After that paint process happens in which coloring and box shadows, all the properties that are related to aesthetics of the website that gets rendered. After paint and layouting, composition happens in which a final layout is rendered on the screen. By compositing you can assume compositing as rendering different layers at the different level of the browser. So you must have seen that if you give a Zend index mode to an element it will be superimposed on the element that has less Zend index. So this part is done in the compositing phase. Next slide. Taking a deep dive into the process as you can see HTML passed into HTML DOM CSS styles get passed into style rules and these both DOM gets attached and render trees get created in which layouting, painting content is done. This is a typical flow of a Wapkit engine. Firefox uses Gecko engine and other browsers like Safari and Chrome uses Wapkit engine. This is a flow of Wapkit engine. Gecko and Wapkit has the same application but they have different terminology associated with it. In Gecko you will find layouting as a reflow text and your painting is repainting. It's more or less the same. So after the DOM gets created and the user is interacting with the website, there are some events that get fired up like clicking mouse over or scrolling. So these events actually repaint the whole website and sometimes actually trigger layouting and composing also. So if there is some JavaScript that is actually changing some property or there is some CSS class that is actually changing some styling this process gets started and initiated again. So there are some CSS properties that triggers layout, that triggers paint and that triggers composing. You can find those properties on CSS3triggers.com and figure out which property triggers which part of the pixel pipeline. So if you change the property that is related to layout it has to go through the whole the process. All the JavaScript calculation will be done then after styling painting and composing. And if you are changing a property that is related to paint, the layouting process has been skipped. And in case of composing, layouting and painting both process gets skipped. So you have to take care whenever you are actually applying some new style, make sure that CSS and the JavaScript that you are applying should change least priority component of the pixel pipeline. So it will be very best if you are changing something that related to composing so that your new frame, the new refresh frame that happens on the browser comes very fast because it's actually skipped two process and it will take less time. So that should you take in mind. Next slide. So we are talking about performance and when you are talking about performance we talk about speed. So do you guys think there is a specific time frame that defines a website to be a slow or fast or any task to be slow or fast? Who says yes? Who says no? And everybody else is sleeping. Wow! So this is a bit contextual thing. You cannot say whether it's slow or fast on a fixed time because it actually depends upon the task that you are doing. So for example if you are on a mobile device and you are actually triggering the click event it will take some time to respond because the click event gets registered on your hardware. The hardware actually triggers to the OS of the mobile the OS of the mobile actually forwarded to the browser and the browser actually acknowledges it. This takes time. So in this process it will take around 100 milliseconds or 60 milliseconds or 70 milliseconds. That is the least time it will take. But in case of animation, that CSS animation that's happening every screen refresh if it will take around 50 or 60 milliseconds the frame per second will be around 18 and 20 frames and it will give you a jaggery experience. So in that case 60 milliseconds is very slow. So you see 50 milliseconds or 60 milliseconds or any fixed timeline is not the parameter that you should think about that makes your site fast or slow. It's about the task you see. So Achille did a small research and they figured out that if a user spends some time on your website and if it requests something from the browser and if the browser responds in a specific time frame what user human mind thinks about it. Excuse me. So if the response gets to the user in less than 100 milliseconds then the user will think it's really fast and if the response is around 1 millisecond then the user will get out of context and start seeing other things and if it takes more than 10 milliseconds then the user will open a new tab and do Facebook. So what you should target about is to respond and load the content as fast as you can at the front end. So for this to set the guidelines the developers all around the world came out with this rail model. So the rail model actually break down the user activity into key actions like drag, drop, tap, click and it defines the standards of performance goals for these user actions or should be the performance criteria for it. And it defines a basic layout where all developers and designers can come to a reliable platform where they can think about the area which has the maximum impact of work. So rail model as you can see it's break down into four parts response, animation, idle and load. So what does response says? So whenever user do some activity if it clicks on the browser or if it clicks on this mobile screen there's a response that the website gives right? And that response should be as fast as it could be and the rail model defines that the response should be under 100 milliseconds. So whenever you initiate a click event or whether you do some user activity on the website suppose a mouse over or whatever or you know if you click on something and some part of the DOM gets deleted that all action should be responded under 100 milliseconds. If you talk about animation so here animation we are talking about the CSS and JavaScript animation that happens on the website. So these animations should happen so I want to highlight here the human eye perception so it's like that human eye cannot figure out the difference if the frame rate is more than 60 FPS or 70 FPS because we cannot figure out the difference if in any moving thing if it's moving faster than 16 milliseconds per frame. So what rail model says that your animation should be around 60 FPS the refresh rate should be around 60 FPS. So if you're doing some animation in the CSS styling that gets updated taking time more than 20 millisecond or 25 millisecond then it'll come around 40 FPS and then you'll feel a jaggery experience and you'll probably think that the website is not that smooth and responsive enough. Idle state so if all background processes that are very high time taking processes and that need a proper resource all should be prioritized when the website is idle. So when the user is not doing anything with the website. So that you actually preload the data or lazy load the data and all the background activity should be breaking in the chunks of 50 milliseconds because you want to prioritize other events like suppose you're having a background activity and in that background activity suddenly user clicks on something and expect response in 100 millisecond then actually the process thread should stop after 50 milliseconds and give the priority to the response event. You get the idea? And the last component is load load is pretty clear it says that you should deliver the content in 100 millisecond. So first of all whenever you click on a browser whenever you click on any link when the website gets loaded on the browser for the first time all the content should get loaded in 100 milliseconds so you should load the data in 100 milliseconds. That are the four components and four pillars of the real model. Next slide. So it depends upon the OS and the hardware. So we are not actually discussing about the hardware and the back-end thing we are actually focusing on the front-end thing. So basically our target is our script, our code should not take more than 100 milliseconds to respond to a particular user event. Similarly it should not take 100 millisecond to more than 1000 millisecond to load the data. Yeah, JavaScript. So basically we are talking about the once the server has responded that respond event has been done. So I think your question is like if I have made a very good and responsive website by it's breaking an I-8 and I-7. Obviously it will break because you are actually working with a... Yeah. So by loading the content I meant the rendering process. We are actually focusing on the rendering process. The time it takes till the HTML DOM and after the CSS DOM and HTML DOM gets ready and before the site gets painted on the browser. That should take 100 millisecond. Yeah, so the devices won't respond but I'll show you how we can keep ourselves... See, the browser will respond. I'll show you the thing and how we can... So I think we should wait for the demos to come in because basically it's our target that we should do this in this much time and it all depends on your content. So if you are trying to load thousands of frames on a single site on a single web page, it won't but if it's about a single image it will and if it keeps our code structured and properly and prioritizing what task is important for the user it will... In fact, it might not be the... it might not be the... into that cap of 100 millisecond but it won't... Again, it won't be... user would know. Very slow device. He will... So I think you are actually getting confused so the loading time is actually related to the rendering process and after the DOM gets ready and it actually paints the website then the time frame should be of 100 millisecond. We are not talking about device specific this is the ideal case that should happen. It will never happen around 100 millisecond but this is the ideal case which you look forward to. So since we have seen that all four components of... Yes. I would say it's a perception of the user to think that something is happening. It necessarily may not have anything mean loaded because if you see Facebook, if you open the app it actually shows some placeholders and you feel like something is happening but it takes a lot more time but the user does not get frustrated that it's a blank page. So you must have had progressive rendering like Angular does. It does not load the whole website in a single go. It actually renders some component. The loading concept here actually means about this. The first load that happens the first painting that happens should happen under 100 milliseconds. So prioritizing all those things all those four models are equally important but they are actually specific about the kind of website that we are dealing with. Some websites are content websites which actually focused about the content they have. So in that case load and idle time would have more priority. We have to more focus on load and idle time but for mobile native application if you are looking for a website that should open in mobile or some ionic website then we should focus on user activities like response and animation. So it depends upon context to context. For some websites the idle time and load component should have a higher priority and for some websites the response and animation should have a higher priority. So basically it's the user perspective again here. So if we are on a new site where the content is more important so the components here RAL, the response animation does not mean that much for the user but for him that loading loading of content, the content is most important part for him. Similarly when he is on an application or a mobile device or mobile app and for him the response from that application is more important for him than the content which he is looking. Though the content is very important as well. If he sees you might have I guess for a particular application you click on a button and if you don't see any response you try to click twice or thrice assuming that you might not have clicked it properly. So this is where that user perspective comes in. So you should actually respond, no the R model of RAL you should actually respond in 100 seconds so that user actually thinks about that browser actually acknowledge your user activity that whatever you have done on it. And again coming to this event in case of event not all tasks can be categorized into individually response and then animation load but all the user events are some sort of composite actions like if you click on something user expects a response like here in this zip on clicking of menu there is the response of that click and then animation is happening and then the load of that menu content is there. So basically it's a composite action comprising of all the three steps. So now the basic question here is what is more important if we try to if we follow RAL and so what should be our target to achieve that my user should not have any jaggery experience or so from I think user is doing something he is clicking on of clicking something and he is expecting his first expectation would be that he should get some response a response to his event is clicked so first target is to give some response and animate so to the animation happens after that and then that load content is loaded so first priority is the response to that user so how we target is how we structure this event or our JavaScript first we will give the response to this user and that will be capped into 100 millisecond we will target it into 100 millisecond and then we will load the content over there ok. I want to highlight one more example over here so suppose you have a website on which there is a link and when you click on the link there is some Ajax request that goes to the server and actually get some data and it renders on the web page so there are two pages that through which you can implement it so whenever you click on the link the Ajax request gets initiated and the browser waits for the Ajax request to complete after 5 or 10 seconds the Ajax request gets completed and then it actually renders it on the website or the other method should be whenever the user click on the link as soon as it clicks on the link a proper model with empty data gets pop in and there is a loader text that comes in and after 5 millisecond when the Ajax request gets completed it actually loads the data on the website so what do you guys think is the first phase will be more performant or more fast or the second phase obviously the second phase because actually user got the idea that website is actually responded in 100 millisecond so that's the whole idea of this response animation load so as I told you that we will be moving fast on slides and focusing more on demos so we will be starting with demos so for example if I take this so window is quite small so this so in this demo I will be showing you how that when we talk in our slide that once we load is it okay if I decrease the resolution screen we have to reduce the resolution is it okay is it visible at the back no I will have to revert it okay I will try to do so on a particular website when we load when we do a reload going on network tab so basically this is for what all events happen when we do a reload so you see all the resources are downloaded and then in chrome in chrome we have this blue line and then red line so this blue line says that this is the first meaningful frame of the website where the user can start interacting to this website so now so from this so this is the network tab and from here what we can get is if we try to reduce this gap from the start of the load to the first meaningful frame if we try to if we decrease this timeline my user would get out faster interactive session means he can start to interact with the site more quickly so here basically the first meaningful frame appeared at 543 so this DOM content loaded 543 second so if so here this this is for the back end users if they can structure their back end and if it can be if we reduce this timeline our user can get a better experience so so in just 2-3 hours before I was in that big pipe buff by Piyush and we actually checked that this DOM content loaded section increases by so this timeline decreases by around 2-3 seconds if we use big pipe and our user can start to interact to the website 2 seconds before even for a single block content so I think but I yeah that we need to have a big pipe implemented that I don't have right now but yeah so if we also our browsers are so open nowadays that they exposes all the information for the resources they are getting so if we go to there is this APN if we if we try to get this information win so get entries by resource get entries by resource type get entries by type and if you get inter-resource it will give you all the resources which have been downloaded over this side and if you open so basically for each resource we give that timeline when that redirection starts then dns lookup then tcp connection and then start and response end happens so here is the timeline for this the resource which I can so the resource which we are talking about is here some so the css file basically and so we can get the time to download to basically render our resource over here if we if we subtract this respond end with the start time we get that exact amount of time which it took to basically paint it over the browser so now what we can do is if there is a resource from back end which is taking too much of time we can basically get the information from here and then basically if that resource is stopping that first meaningful content first meaningful frame to appear so we can get that information from here and then we can print it I so I have so for example oh it's open here yeah I've just there were too many resources on that page so it might be just one image this is the single resource which we are downloading here and then I've written a java script to basically get the time how much how much time it took to paint it over the browser so basically this was the time it took to fetch this resource and paint it over the browser so this is basically this is how we can get the information of a particular resource now how many of you have used timeline in the chrome this chrome timeline nobody yeah so basically this is this tab gives you all complete information of what happens from the time it starts loading to the time or it gives you all information about all the javascript all the CSS all the painting all composites all layout recalculation everything happening so basically if we utilize this tab properly we can get all information and if some problem is happening I'll try to debug and show you how we can basically get that information and select what to do over this so first that swastik talked about that javascript layout paint and composites so I'll demo that first so this is a simple most simple example I could do basically I'll be showing you so this side what it does is there is this click event and then some CSS changes is there so I'll show it basically start the recording I'll start the recording and then try to click stop the recording so this is this is where I can it even takes the screenshots and we can let's zoom in here and this green line shows where the click event happened and how much time the click event took to respond and how much time it took to layout and you know paint and render and how much time the pixel piped and took you can see it over there click event happened here and then these yellow line these yellow bar shows where exactly what all functions have been so these yellow line yellow means where the javascript run then this violet line if we zoom in more so these yellows are for javascript these violet are for recalculate you can see the recalculation of styles this is being marked here and then compositing composite layers so these are the activities which the browser did and in these time range it took so for that click event it took around you can see 2.3 milliseconds and then to call that function basically you can drill down into it and get more information about your javascript and what css and css is triggering and if you find any issue you can basically so it has the same color code that you seen in pixel piped and where the javascript was shown by yellow color the style and layouting shown by violet color the painting combulting was shown in the green color it holds the same color code and if you select a particular function it gives you the information about it and where from it it was triggered so you can even click here and then you can see so basically that click event is from this javascript and it's doing is changing the width of the body and on the second click it again changing so basically I'm just changing the width of the width of the body now and on timeline this function triggers this calculation and so this recalculates, recalculation of style happened and it took around 0.9 milliseconds then after that this earlier update that layer tree was updated so and it took around 0.06 milliseconds and then layer composition which took around 0.13 milliseconds and lastly that paint activity happened and we had we had this so with one click first click we had this information this last frame and when we check in paint profiler these were the this is how it happened so basically painting so here we are doing checking the paint profiler after composition of layers how this now painting is being done so it will start with this save activity then that a clip rectangle came in then again the second clip rectangle came in and then the first frame first rectangle was painted of the color and then the second so this is how you can check basically step by step which all functions of the browser have been called to show the paint profiler and how this paint happening now so this you see the complete process of you say a particular user event where JS was called and then some down manipulation happened and then CSS and then was done so so basically this demo is to understand what processes happen when we so if you saw that slide where that webkit chart was that how and STML passes STML passes that DOM do we have shops so for example if we have like please let us know if it's not visible at the back we can increase the font size no I think we have to use the screen okay or we can hop into the next example or we can use this so basically this is the markup and then what STML parser does is it parses all the tags in this markup and creates a DOM tree so DOM tree is DOM tree is something like this is this is body then our div then another div where we have one h1 and one here p tag here we have span it's a simple tree where there is a parent to children relationship all I think this is visible this tree structure is at least visibility so basically this is the we can say this is the DOM tree and each tag has its own node this comes into DOM similarly there is CSS parser CSS parser converts all of the CSS which was loaded which was downloaded and it creates a CSS DOM so if you have so this symbolizes similar body CSS so all the styles for body then for that div then for this div and so you get me this is the tags and these are the styles for each tags so basically this is the DOM tree and this is the CSS DOM tree and DOM and CSS DOM now so this is the parsing phase after parsing what happens is these both the trees DOM tree and CSS DOM tree they are merged and a render tree so if we add this we get a render tree and this is similar to it's also a tree structure so that render tree would be body plus CSS body CSS CSS and all so basically that render tree is built and now so suppose this is our render tree now with all the tags and then CSS as well now for each node their render tree has been made now for each layer for each node layers are created so basically this this would be body and then layer for this div basically all the DOM elements which has some styles and everything it is painted over it is basically marked over the DOM like and then all the so basically these are the separate layers now after and this phase is so basically this phase is layering and then all of these layers are composited and painted in a single layer not a single layer basically a renderable layer and for all these things so when we saw this in the timeline all these functions so basically after the layers are created each layers are pulled into a single and it is painted in these steps you could see here a better example I could show you is of a paint could be so this is a very long right and then if we go to timeline so you see so for each I think this is a but yeah I can I think you can see that each of the items are being painted and these are the functions these are the functions being called for each clip rectangle, draw rectangle and all so this is how our browser functions you can see this painting happening so since this is a very long frame very big frame you can see from here so it would take much time now so I think everybody is clear with how our browser paints and I will come with I will show you one more demo where we can basically debug our JavaScript and get to know so this example is about the design of this table and so and what I am doing is for one I am using a bubble sort custom JavaScript function and the other I am using browser default sort function so and we will see we will see in the timeline we start the record and we sort it and then we sort it between both you see this is the timeline recording and you can clearly figure out which which click event took more time from the timeline so obviously the first click took more time than the second one and you can easily so this is so in my series script for the one one sort one function we called a bubble sort function and this is what this timeline shows with this so actually for the first click the JavaScript run it took around if you see it took 470 milliseconds you can see it from here it took around 470 milliseconds and for the second one the default the sort function it took around one sort two it took around 77.7 milliseconds so you can see the difference of the so basically the both are of sorting and so this is how we can debug and get which function is taking more time in our timeline and we can basically if you check the if you check the layout timing the time which it took to after the JavaScript the time it took to this was same and the time it took to for both the function it was same but for the function it took time so we now know the problem was the problem is in our JavaScript we need to work on the function which is taking more time not the the issue is not with the CSS so I will show you one more yeah so basically here I have written a small script for yeah see so what I am doing is I am inspecting which I am targeting all the box all the titles from these three selectors so basically all the three selectors if you see are targeting the same same elements but I have written this script to basically get the time how much time it took for that selector to select that element and compile it so if and when I click this button that JavaScript runs and see if you can see the time taken for each of these so now we how many of you are aware of BEM BEM modifier block element modifier writing CSS classes so see the second one is in BEM model and we are targeting direct classes not using any of the pseudo classes here for this and even for this here we are using pseudo classes so if you go to there is this CSS triggers it even mentions that for pseudo classes that the browser has to go to that element the parent element to compile it so and so if we are targeting box nth class child so that to compile this CSS class basically browser has to go to the parent box class and then the nth child it has to get that nth child to give this so basically the time taken for this is this much and but if we give a single class for each of the direct classes and like we did in the second selector where we target the direct not the not the pseudo classes so it took less time so even through this we can get to know these small things makes makes difference in our CSS and the whole of the painting and rendering process so I think if we implement these small changes we can actually make our front end more faster so I think that should be okay so we are done with that more than we will be taking questions now so any questions I see like the value of this kind of tools that identify the bottlenecks on the rendering process essentially once you get to compile that you never want you didn't mention what kind of actions you should actually take in order to fix those performance or enhance the performance overall so in this case in general to provide these enhancements to the performance so you are talking about enhancing the performance using the small right? we already have this set of data and we know the bottleneck by why it is how it works so I will take an example in this case I have already given you a colour box example where actually preload the data just to make sure that the user does not get that zanky experience and does not wait for the website to respond same happens in JavaScript so if you are having a CSS selector very lengthy and you are using IDs then classes then obviously the classes will take more time so you have to be a proper architecture before you actually start the application so rendering process just the real model in the rendering process just give you the guideline where you should follow but not the proper ways to do it so it totally depends upon you how you do it if the CSS selector should be proper the JavaScript logic should be minimal you should always preload the data and always prioritize the background process at the idle time these type of things you need to take care of so one of the recommendations would be to use BEM selector or BEM classes I think we can make out more of the so like for animation we should prefer CSS animation for work, JS animation which basically if you do it via JS we go through all the processes and CSS dance homes take next time so there is one more thing called flip if you have ever encountered it just google it so what flip does it add the flip is first, last, inverted play so it uses CSS transform and it reduces your rendering process time and actually enhances your animation model so you should look out for it on google so basically what flip says is for any animation to do it first, last, inverted play like you create that first frame and visualize your last frame and even create it through JavaScript and then what you do is just invert it like so you actually reach to the last frame and you invert the CSS and you play the animation so that it get back to the first frame looks like to the user that it actually move from first to last not from last to first so you have to search for it so basically it says this because we know that if we transition from here to increasing that so browser will have to calculate each and every pixels and then render it but if we know exactly that this is our first frame and we even tell our browser we inform that this is the end calculations and then we animate it from this point to that point through CSS not through JavaScript doing 1111 so that would be more smooth animation that would be even into that 20 frames per second animation in fact I should suggest you should do Google because you will find out proper blocks stating the proper theory and practicals so that you will get a proper idea because there are endless recommendations for doing stuff for particular activity there is a way and in that way is good for a particular scenario but that won't be that good for a particular other scenario it all depends on the context of so you should use CSS animations like CSS transform, CSS animation property then using JavaScript that's my key suggestion to you any other questions no questions so for is there any any tool that use frame by frame action in slow motion like what we see in the Selenium there is no tool built I think yet but you can always see it in the DevTools in Chrome DevTools we can inspect each frame you can see it always see it in the DevTools there is no application built for it so that you can actually create an animation for frame to frame but you can always see it in the Chrome DevTools so this part of the technology we still have not gone forward through there is no application that is related to I think if you find on Google you can find those plugins where you can use that thing and I think you will find a plugin that will do more or less the same you are talking about if we have time I will just show it that flip effect the difference between if we do a particular animation from JS and if we try do it using flip for example if we animated this so this gives me a very janky you can see actually see the frames moving in a janky manner and if we isolate and now you see the difference so this is the difference between JavaScript animations and CSS animations and even about that CSS properties I will show you one more thing like see in this timeline so if we record this and we try to do scrolling we see that our frame per seconds the duration is 34 milliseconds which is quite it's two times of 16 minutes FPS is around 29 but if we do a small modification in here like if we go to our elements tab and then so if you go to CSS triggers it says that this box shadow property is very expensive so it takes too much time for browser to actually implement the box shadow property so what I did is I just removed this box shadow property and I will try to run this timeline again do some scrolling and then we check in here so if you see that the frames they remain same so if you see that it's just reduced to 2 to 3 milliseconds so if you change just a single property you can have that much of a difference so it's simple and clean you should not use many CSS properties just to have a good user experience so basically it improves very little but yeah it does make some impact over that so you should go with a simple and clean approach because you are actually planning to have a good user experience but the user will feel as an expert and eventually gives a bad experience of your application so you should try to make it simple and clean so then again some would be not use background box shadow and you could use some alternative it is done for these many these many blocks you can see so the number of blocks here are too much so that's why a single CSS property is affecting the complete so when the paint activity will happen it will happen for each of the box and then it will compile up to a big amount 0.1 milliseconds for a painting activity where it used to take around 0.09 or 0.06 0.06 milliseconds and you are now saying it brings about 1 millisecond difference so again so this is a big impact any other questions no we are done with it people are getting annoyed you have to attend other sessions thank you for being so patient and listening to us so we have these free gave by stickers you can always come here and grab those if you want to thank you guys thank you very much