 So, all right, so let's start. Can everyone hear me back there? Okay, awesome. All right, so let's quickly start. So whenever we talk about our applications, we usually sort of talk about the features that our application provide. But it is the fact that most often than not, our application is judged based on the performance of the application, which is not sort of the feature, but it's not a functional aspect of it, but the non-functional aspect of it. So, in modern time, performance matters a lot. So, today I will talk about one of the things that you can do to actually improve your web and mobile application performance. And since it's Singapore CSS, so yes, we will talk about CSS. All right, so critical rendering path. So, critical path, this terminology is not new. Like this terminology is like probably a century old. People usually use this critical path terminology to describe the project, the project management aspect, like how to sequence things to get things done. So, but in the context of application, web application, critical rendering path is the amount of processing or the series of steps required to actually convert your resources like HTML, JavaScript, CSS into actual pixels. So, I mean, usually like the loosely translated thing is like how fast the page or your mobile app load when you are accessing it for the first time. There are sort of similar terminologies people use like above the fold, first impression, but the most important thing about critical rendering path is that it actually determines the perceived performance of your application. It may or may not be your application actual performance, but it is the perception that user get while accessing your application, which is pretty important because first impression is pretty much the last impression. All right, okay. So, we will talk about something like this. So, the first one is the optimized critical path rendering. So, as you can see that in 1.5 seconds, both show both sort of unoptimized and optimized ways, both show the same page, but it is the thing that matters before that on the optimized rendering path, you can see that from the start, you can see something sort of appearing on the page. So, it gives like sort of a perception that okay, application is working. It's not like okay, blank page and then all of a sudden boom, you get everything. So, let's see how we can do that. All right. So, before we go, it's like just a quick one-on-one on how browser actually go through the whole process. So, everything starts with HTML. So, HTML is like the thing that you write. So, what browser do, like first when you request the HTML, the HTML is transferred to your browser and then based on your HTML, we create document object model. It's like we take the tokens from HTML and then based on that, we create this whole tree. And there is another thing which is CSS on. So, just like your HTML, CSS is also a resource and then you can also parse it. You can also extract the tokens and create somewhat a similar sort of a tree, but more related to CSS. So, the reason this relationship is important, the thing that I want to stress is that we need to understand how this thing work so to better understand where we need to sort of optimize things in order to get the best out of our application. So, JavaScript also comes into the picture because when your browser goes through, your HTML, it actually looks for your JavaScript. Again, yeah, if it is async or deferred, then it will sort of not, it will ignore it. In the first bus, it will probably load it later, but generally it will sort of load the JavaScript as a resource and CSS as a resource as well. And based on these two combination, we create a render tree. Render tree is the visual as nodes of your DOM, which also contain your CSS styles. And then the layout, layout actually sort of deals with the actual, how your nodes will sort of place in the layout. So, this layout and this layout is different. So, after that, the actual paint, the rendering happens. So, the reason this is important is because unlike DOM, which is more of a iterative sort of a build as you start picking things, CSS on built in one go. So, when your page load, it actually looks for all your link tags or all your style tags and start creating CSS on. Again, I'm just trying to sort of go through it, but there are things that your browser can ignore based on the media tags and all that. But generally it needs the everything, your all the CSS to be loaded in order for it to proceed to that rendering tree and the other stuff. So, if you have some, so that is why we call it like it blocks the rendering unless and until the CSS on is built properly. And just imagine like if you have some external CSS files and maybe if I hope you don't have like a lot of external files if so, then please change. But if you do, so it will add extra mills. And if you have like some like network issues, then you can pretty much just imagine like how slow your first rendering can be. So, this is a problem. I mean, for web developers like damn, this is a problem. So, this is where critical comes to the rescue. This is sort of a wrapper library that Andy Usmani created. I mean, he's sort of a well-known sort of a figure. The way I understand critical is like critical is sort of a pretty wrapper over another utility which is Penthouse. And that Penthouse actually uses Puppet here, which is another, it is a web automation utility from Google to actually create, extract the CSS which is important for your first render and then sort of extract it out. And what critical do is actually put that CSS in line. Put that CSS in line. So, during your first render, your browser will not make an extra call for the external CSS, and which is pretty neat. I mean, I don't know how much time we have but we can talk about like how this, so Penthouse is the key. So Penthouse actually create that logic. It contained that algorithm to extract that critical path CSS and how it created, we can talk about it. I can show you later. All right, first let's go to demo. All right, so yeah, that's the one. Okay, so I am using two different pages, one with the normal page and the other one with the critical changes. If you want to know the code, so this is like a really simple code. Can everyone see this screen, right? So, a really sort of a normal page, like we create all the time, you have the link tag in the head and then all of this fancy JavaScript and all that. So, let's quickly see how the normal, this application loads. So, in order to sort of show how things work, I'm just doing a quick profiling. So, we'll do like some one-on-one profiling as well. Awesome, all right. So, yeah, it's taking some time. I have added a throttling on the network just so that we can get this idea that how much actually it takes. All right, okay. So, I'm sort of right now interested in just the loading events. So, I'm looking at the loading events. So, first it is, if you look at these events, you can see that we are trying to fetch the HTML because HTML is like the absolute starting point. And then after we get the HTML, at some point of time, we are, okay, wait. So, it's using loading other resources and then see. So, we are also loading main, the CSS file as well. And only after that, there is an event called paint. So, this means we are waiting for CSS, we are waiting for the CSS to come and then we create CSS on and then only then, so this is the first paint and just note down the time. So, it's taking like pretty much two seconds, more than two seconds for the first render. Okay, so let's sort of same settings for critical magic. All right, so let me try to do a profile. So, all right. So, the thing to notice here, again the same HTML call. And since we are not loading CSS, so it's not blocking the rendering. So, the first paint is 700, 800 mils. I mean, that's like a huge improvement. I know like I did the throttling, but just to prove a point. So, all right, so after I run this utility, so this is how it looks like. So, you have all the critical CSS part extracted and put it there. But the question is like, your CSS will contain a lot of style. What we are doing with the rest of the styles? Okay, so there is a trick for it. So, it is loaded in the end. So, there are two ways to do that, depending on which browser you are using. So, this strategy will work for most of the browsers. So, you are actually adding all the CSS in the end. So, it's not blocking your main sort of first render, but you will eventually load it. It's more like it becomes more like a async JavaScript loading kind of a thing. So, yeah, so that's how it works. Let's quickly go back to, okay. I wanna play this thing here. All right, so quickly let's look at the concern. So, when I start playing around this thing, so I noticed three things that actually was a concern for me. The first thing is like the utility, the penthouse, and especially the wrapper over it, critical is mainly for progressive web apps or mainly for very simple applications. But if you're talking about the enterprise applications, most of the pages requires authentication. So, the way they are sort of generating this critical CSS, it's actually opening up the actual page. So, if you are using, if your page is behind some authorization, it needs some authorization, you will not reach there. So, you need to do some sort of coding to work around that. And yeah, for some reason I have some extra time to do that, so I don't know. So, you need to do some custom coding here. So, you need to sort of go into the puppeteer and say that, okay, we don't need your browser, I will create my own browser and I will do my own authentication. So, either you can go directly to your authentication or maybe you can run some scripts and put your authentication token in your local storage or your cache, whatever strategy that you are using. So, this is one of the things that probably people will not be able to use it right away. Another thing is, which is similar, is that most of the people, they use some sort of single page application framework like AngularJS and all that. So, the problem with Angular, like single page frameworks are like, they are not very, very good at putting things right away at the top because, for example, for Angular, it actually waits for your DOM event like DOM content loaded to actually start your main module and only then it actually start putting data. So, even if you are using this type of critical CSS for just to get the first render, you will see the render but you will see some tags that are not sort of evaluated by Angular, which can be sort of a, I mean, you don't want that, right? Again, so they have the plugins for both Gulp and Grunt. I use Grunt, I face some issues. So, I need to do my own Fork on Puppeteer and the Penthouse, a lot of peace. All right, so key takeaways, really quick. Two things, the first one I'm borrowing it from Eli is don't go for the optimization first. First, measure and then optimize. There might be things that will be important for you based on your scenario and there will be things a lot of people will say. So, first measure, the profiling is one sort of a tool that can help you. Another one is the page load Google Utility that can help you a lot. The other thing is every bit counts. So, the amount of data you are putting on the network, it counts. Every bit of effort you are making to improve your application counts because there is no one strategy to solve all your performance issues. All right, so if you are interested to know, so these are all the links that I followed to actually explore this idea. I will share this slide on Meetup and if you have any questions regarding that, you can ask questions on Twitter or you can be someone like Chris who asked me a question about food on Twitter. So yeah, you can do that as well. So, all right, so yeah, that's it. Thank you. Thank you.