 All right, so let me get started with today's presentation on on web performance. As I said, this is not a prescriptive conversation. This is a conversation of understanding how fundamentally the web works and applying those concepts to your own websites and all. I'm going to use the the weirdest tool for presentation, which is a Google sheet. Tejas, can you confirm if you can read and see the sheet? I can, yes. Okay, so I'm assuming that everyone else can also. So I'm going to use this. I've just jotted down some notes. It's expected to be like a free form, freewheeling chat. It's not a very formal presentation. I start with what is web performance. I'm not going to touch upon the point that web performance is important. The reason I'm not going to touch upon the point where performance is important is because it's almost an established fact and the fact that you're curious and interested in this. That's why you're here, but there are going to be lots of things around the web, but that web performance is important. But what exactly is web performance is something that people understand differently and interpret differently all the time. Now, I want to point out three factors. There is speed, there is scalability and stability that in more or less contribute to web performance. And inside speed, there is a point on, there are two aspects whenever there's a website. There's a server which has all the website code and there's a client and when I say the client, that is a user's browser that is accessing that code or accessing that website. So there are two aspects of speed always. One is how fast the server is able to generate that page and send it to you or how fast the backend speed works. And there's another aspect to it that once the code reaches your browser, how fast can the browser process that code and show it on your screen, on your browser, whether you're on a phone, on a tablet or a laptop or a desktop, whichever device it is. It's a little unfortunate, I would say that there is a immense emphasis in the community around the front end performance only, which is how fast that the server, how fast the page generation can happen on a browser. That's the part that has extreme amount of conversation that is there. Very little conversation around the server generation of the page, but I'm going to touch upon that also. I'm not excluding anything. I'm also going to a little bit touch upon the scalability and stability aspects. The idea is that one aspect of web performance or your website performance is how much of a traffic it's able to handle as well. If you can say that your website has a good performing site, if you are able to double the traffic and still the server runs stably and it's able to scale essentially. Web performance consists of all these things. How fast is an individual user's experience, an individual page request experience also under load, under real life conditions where there are too many people trying to access the site, how much is the server able to scale as well as remain stably running. All that is web performance. Yes, performance is important and I won't get into, as I said, the reasons for that there's a lot of literature out on the world, internet around it. I want to touch on some myths out there before I get into the details. One is that there is no one right way of saying there's a performance. There are going to be several different strategies of making sure that a website is performing well, is fast as the speed aspect of it or is able to handle a lot of load. Even to have a same objective or a same goal established, there are different ways around it and there is no one right way. There's also no one single defined user. That is, you can't say that, oh, my user is a mobile user because the person could be in a desktop, person could be in a bad network area, a person could be in very different environments. There's also no single predictable part because web is one of those spaces where there are just too many unpredictable variables out there. As a developer, you are writing code on your computer, but your code is actually running on the wired in servers that you don't control on browsers and other client computers and their browsers, which you can't control. You can't control the network as much. There is a lot of lack of control when it comes to the web environment as opposed to desktop apps or native apps and other things. It is very hard to have one predictable path and always say that, oh, take the network for granted or take the browser speed for granted or take the user's phone processing power for granted. It's not possible to do that. Therefore, most importantly, you are not your user. If you are testing your own website and saying that the server and the site is fast, you are happy enough with it. That is not a great measure because of the above things that I said. As a consequence of the above things that I've said, there is no single metric that is important than everything else. There is a combination of different metrics that you have to probably look at. It's not important that just the first page load is fastest and that's why your page is fast. It's not that the first page load is slow and other page loads are fast. That is why it is great. These are all different strategies and they lead to different experiences. Of course, you can start optimizing on every metric that is possible and that is also going to be hard. That is why it's important to understand that performance is not a binary thing. It's not yes or no that this is a performing website. This is a non-performing website. It's in a continuum. You might be in different spaces and you are always going to need to improve as far as I have seen in the past 10, 12 years or so. There has never come a point that when I'm not learning new performance techniques, that has come up. Yes, this is going to be a constant work. The last thing that I want to point out is that most of the time we are always speaking of symptoms but never the diagnosis or the root issue. If you say something like one CMS is slower or faster than another CMS, then you are talking at an extremely high level and there's so many layers of complexity underneath that that it's all getting hidden. It's almost like saying or looking at a person and saying, oh, you are coughing but your coughing might be a result of very different diagnosis or different diseases that are out there. Whenever you are making a statement or you are hearing a statement that X technology is fast, it makes your site faster or everything else, take it with a pinch of salt because that is just the surface level reading. The underlying things have to be understood as to why is it running fast and it is quite possible that if your website is running slow, you don't need to do a technology shift completely. What you probably need to do is find out what can you do incrementally to slowly reach closer to a better performing site. Personally, I don't believe that there's one CMS that is slower than the other or faster than the other or one technology that necessarily is faster than the other. I want to explain how performance works to make it really simple for someone who's not coming from a technical background to understand what do we mean by performance. I'm going to take an example of when you're eating out what happens whenever if you go to a restaurant and if you're ordering food, what are the steps that happen? You first want a menu. This is a very low-fidelity way of explaining that structure. In the Excel sheet, I have columns for what does the guest do, what does the waiter do, what does the kitchen do. Every row that is there is a step that is happening and every time things are moving on the right, that's when someone is handing over their work to the next person and then to the next person in a way. If you look at this thing, the first step that happens is someone wants a menu. You request for the menu, the waiter walks to the menu card which is at the menu card station, picks up the card and then walks back, gives the menu to back to the guest. The guest will then decide what food the person wants to eat. The guest would want to place the order. The order is then again carried by the waiter to the kitchen. The kitchen receives the order. The chef would probably start cooking on the grill, probably cook a patty, cook some, like fry some fries at the fryer. There'll be dishwasher. There'll be more things, processes around, you know, that happens in a kitchen. The process of cooking will take a while so there are multiple steps in there. I'm obviously not going out detailing what are the steps there and eventually you might assemble a burger and once you've assembled the burger you send the food back. The order goes from the kitchen back onto the table to the guest. After eating and I'm skipping that part, how much time you might take to eat the food, you will probably request for the bill. The waiter would now again go to the cashier, ask for the bill. The bill gets generated by the cashier who is out there, sends the bill back. The waiter walks back to the guest. The bill is received. The bill is paid. Walk to the cashier again. Get the change back. The change is received and that's when the transaction is over. So you see it almost took like five to say 14 steps in a way for the entire transaction of placing an order and getting your food and having everything done in a way. That's like a simplistic view of it. Now if we take the same thing, analogy in the fast food environment, this is what happens. You look at a menu. You don't have to ask for a menu. If the menu is right up there, you're able to immediately look at it and there's no step involved in you getting to know what to order. You can decide the food and when you place order, the request is received. The order is punched in a machine. A bill is given to the guest who has come in. The guest pays. The money is received. The change is given back. Then the person will simply turn around and you see this counter. This is the most interesting and the best analogy I've been able to come up in one of the performance thing is that you get to completely leave out the complexity that's there in the kitchen. You pick up the burger from here, set the tray, turn back and give the food to the person. I don't know what this thing is even called. Somewhere it's called the burger slider. The kitchen keeps putting in the right burgers in the right slot and the person at the cash counter knows that the burgers are ready and waiting. You get to completely short change and short rather the entire process of cooking, patty, fries, everything else and sending the food the entire thing and the number of steps that you take in an example like this is so much fuel from 40 that we have moved down to about only about 15 or so. Something like that. Now, this is where fast food is able to make the entire turnaround and the process faster. What has happened is if you can take an intensive operation and an operation that will take a lot of time to build and you can all pre-do it and keep it there for you waiting, the entire turnaround time will be much faster. The other thing that has happened is if the entire distance between where the food is prepared or kept and the guest out there can be reduced, you can just simply turn it around immediately much faster. So the number of steps in this direction that is the number of, I would say hops here is also reduced. The number of steps here in this direction is also reduced in a way and that is in a way a core part of how performance works in computers as well or in case of websites as well. I'll also talk a little bit about perceived performance over here. So although the steps are going to be still the same, you can start then imagining what is it that we can do to make the person who's at the guest perceive that the order is coming even faster than this. So for example, you see there's a lag over here, right? Then when the person turns around sets the trays and all. But there is always a case where as soon as the order is punched, there's a second person and you might have seen that at different fast food places. The person looks up the order and starts setting up the tray behind the scenes while the money is being exchanged and immediately you give back the food on the table. So the person will collect the change and immediately see the food is there. It's not that the steps have gone away. The steps are still there. But while the person was engaged in exchanging money or doing some transaction where the person is focusing, something else happened in parallel and the food got served to the end user or to the guest. So this is another point that I want to point out that this is where perceived performance is more even though from a steps point of view, the scenes that have steps have been followed. Just someone else did it behind the scenes without showing you that the person is doing those steps for you. One of the important things to understand in performance is what matters at the end of the day is perceived performance. If you can make sure that the perceived performance is fast for a user, then I guess that's where things are great and that's where you have achieved what you want to achieve. However, it's also important to know that even perceived performance cannot happen until you have this setup. The background setup, the fact that how to make sure that this burger slider is there, the burgers are pre-prepared and you can simply collect it and give it on the other side is important to have that infrastructure in place in order to finally have the perceived performance very high. So you can't do the things without this background infrastructure but then eventually you have to start also start imagining how to improve the perceived performance and outsmart the user in a certain way or do steps without ever showing it to the user how complex or how many steps they were in. So that's an eating out analogy out here. Now I want to just move on to the website of things. Now what happens when you actually make a website request for your site? What are the steps that happen in a similar way like in the Eat Out example I gave? I'm going to list out the steps for you. We have the client. The client is the browser in this case and the client can be located anywhere just imagine a situation where the user is located in the US but the server this is where our code is hosted is located here in India. Say we are serving the US customers as an example. There's a lot of distance in the network distance between US and India probably the maximum that can be because we are halfway around the world. So even if you think that your customer is in Singapore there's still a lot of distance between Singapore and India when you compare to say Bangalore and India. So your best case scenario is that this client and the server is located at the same place but they'll actually never be and you'll always be passing through a network and when you're passing through a network there's going to be the client side ISP the main backbone of the internet and there's going to be ISP on the server side who are connected to the internet as well. However they get connected. These two distances are always going to be there in order to reach each other. There's also an intermediate service called the DNS which is where it this is the service that can translate any URL that you type. So if you're doing say google.com then google.com translates to something called an IP address you might know about it and DNS is the server responsible for resolving that google.com is IP address and therefore now you can make your request directly to the IP address because the actual request has to go to the IP address and not google.com. Google.com is going to actually translate to an array of servers out there possibly because they are operating at such a high scale. In our scale maybe it's just one server that is what I have prepared the example for over here. So what happens when the first time the page is being requested when the user meets the first request for your website. The browser is going to make a DNS request because the browser wants to translate your example.com whatever is your domain name into what is the IP address. The request travels it goes to a DNS server the DNS lookup happens then it comes back the response comes back and then the DNS response is being processed by by the browser and now the browser knows which server do I need to send this new this new request for the page. This is HTTP request is the one or HTTPS whatever it might be that they're there I'm obviously simplifying things there are going to be multiple steps internally within all these things as well but broadly speaking this request is going to then travel through the entire network and then reach your server at a level or at a layer that's called the web server. The web server is usually the first point at which your request is intercepted and it tries to process. This is not your CMS. This is not your own code usually unless you're writing your own web servers. If you've heard of the words like nginx or apache or other IS and other servers those are generally the web servers. Application is what your CMS is or your own code is. This is where your code resides. Now the web server once it collects that request hands it over to your application now say you're running a WordPress site or say you're running a Drupal site whatever it might be it then gets handed over to WordPress or Drupal or your own CMS. Now that is when the code that the developer has written starts getting processed and once you when you start processing it you have to also access a lot of data in between. So data is broadly divided in three parts. One is a database. If you're running WordPress you might have a database out there. It might be on a file system also. There's a lot of temporary data or a temporary application data that is being written and there's going to be a bunch of assets and media that is your images, your videos or any other files that you save that is there on the server as well. The application is responsible for fetching those datas, doing a lot of read write queries on the database and this database query which is something I've highlighted is one of the slowest aspects of your website processing. So the more number of queries you're executing typically a single request can range between anywhere between tens to hundreds of queries being executed. That's the amount of time your CMS or your code takes to actually generate the page, build the response, send it back to the web server which gives it back and pushes it back from the network to back to the client or the browser. This lag is a lot. This distance is a lot. Just take a note of that. So once you have received the response what you've got is the HTML page or the base page that you have and that is still not your entire website. The HTML code that is there is the first thing that has been received. Once you start processing the response the browser is going to notice that there are a lot of blocking assets. Blocking assets essentially are CSS files, JavaScript files, font files, third party files that might be there in your code that might prevent it from drawing or painting your website on the screen. So even before it starts painting the website it needs to know what style sheets are going to be there, what CSS is going to be there, how should the layout be, how should the fonts be, how should it look like. So it will again that particular resource whether it's CSS, JavaScript, fonts, whatever it might be they again have a URL. The DNS again has to be resolved. Same way the blocking requests are sent. Most likely it hits your server. It probably hits your application also. Often it does that if you don't configure it differently. Once the application takes it the asset is received from the assets of the media folder that's there on your system itself and that is sent back and this same request probably happens 10 to 12 times. Completely depends on how you have coded your own software or your own website basically. After it does those 10 to 12 requests then it starts to be able to paint the screen that is to draw out what is going to be there on your site. Now at the point when it's drawing out the site it will realize it will have to start requesting from some non-blocking assets as well. So you might have certain images that have to come in and fit in the screen in between the text and other things. You might load a video. You might load an external embed or things like that. Those external requests are also goes through the same channel again. Some of them will be to your server. Some might be to a third party server and they come in. Sometimes between this process the browser has to either repaint the entire screen because it's just learned something new or reflow which is an even bigger thing which is when the layout changes. So if you have ever seen something where a little bit of the site has loaded but then something else loaded and they send and jump and the site suddenly moves or gives you jerks like that those are the times when generally reflow happens and that is an intensive operation for the browser itself to do. So these non-blocking requests you don't always have paints or repaints or reflow. I'm just giving that as an example. Not every request will have that but typically anywhere between 30 to 70 requests a typical website makes getting all these images, getting more JavaScript, getting more third party scripts and whatever things are going to be there. Once this entire process happens that's when the final website has been loaded. So this is the entire set of process a similar analogy to what I explained for the food aspect on the food aspect of things that happens for loading your site for the first time or the first page that goes in. Now when the same thing happens for the second page a few things don't happen like for example now the browser already knows the DNS is what is the IP address for your URL. So once the second page load basically is a link that you click in your site to load the next page or some other page in the site. Then in that case that click or the tap that you do can directly initiate a HTTP request that does the same process, travels back, repaints the entire thing. The DNS requests are not happening here. Sometimes the blocking assets that are there often becomes much lower because you don't have to request them again. This is just a typical case because you have requested it once the browser knows that those things I have it saved at my end. This saved at my end is called the browser cache. So it will just look up and load from the cache and then start painting this case. So you have certainly saved a few things over here, but then again you have to request for new sets of images for this new page and all if they are actually new domains, a domain request also might happen. But again the assets eventually again come in from your server and they again repaint, reflow, painting the screen. Some things got saved, but many things complete the same cycles. Now if I have to take the same analogy as what I had done before, what is it, where is the scope for us to keep changing things or keep saving things and preventing things from repeating? The idea is that if we are able to save a certain operation and save a certain few steps and quickly give the response back, in that case we are able to make sure that the website is performing much faster because these steps don't happen. And one of the example of doing that is you can introduce something called the CDM. There's a layer over here that on the in the network, which is usually a server that is much more closer to the to the browser or to the client who is actually viewing the website. And that is where you can save a lot of static information, information that does not require business logic, that does not require to be processed on your server. Typically the the heaviest resources that are out there are all these media files that are being requested. So instead of retrieving the asset from here that is there in this media, in the assets in the media side of things, what if we we can one of the steps we can do is make the web server directly request for this. So we can probably eliminate these two steps that that are out there. Let me just hide these two rows. We can probably eliminate these two steps all together. The web server directly receives one step gone. But we can also because we've introduced the the thing we can also copy over the the asset over here itself. If the asset gets copied over here, you get to again short circuit this entire process. That means this can hide and even this can hide. Right. And if the short circuit the entire process this step will not reach all the way here, it will probably just reach to this point and back. Right. You've also shortened this request. This is one example of being able to do that. So when your asset. Hi. Yeah. So yeah, so we took a quick question. So Cindy and is the Cindy and is a geographical construct that shortens your path of network. Right. Yes, these are a network of servers that are geographically distributed and spread. Therefore, it shortens the path of the network. That's one benefit. It also reduces so much load from your server because your server does not have to. So these 30 to 70 different requests that I pointed out here, you the server doesn't have to do this anymore because these things are taken care by the this the CDN itself. So there's someone who has raised a hand. I just got a request. Is that something that we're taking right now? I anyways, I let they just let me know when I have to stop and take questions. Okay. So this is one of the things we have short circuited the entire network. The other things that we can do, and this is a huge benefit. The other thing that we can do similar to that burger slider, we have short circuited this the burger slider can also exist in this process itself. In this process, if you can introduce a case layer itself that the web server, instead of processing it, the always giving it to the application server, if there is a page case already existing, right, then this send response and this can completely move at this step. Right. And the send response as well. So if you see that we can shorten the entire processing of the application short circuit that because there is a page case available, that means whatever was just supposed to be the output of that entire process is already cached and again, the you have, we have saved so many steps over here. So this is just two examples of how we can significantly improve the server requests, the request time of loading and all, but the time of loading is not the only thing I would say at this point of time. And I will just scroll it down over here. I'm not going to change everything around for you at this point of time, but I can take more questions. But there are many different goals that we can have in order to start making performance. And when I'm taking questions, I can use this diagram to explain certain things again. But the goals over here are reducing the number of requests, reducing the payload size, what that means is if you are making 30, 40, 50 requests, and if you can cut down the number of requests that have to be made to your server or to any server from the browser, that can save a lot of time. If you can cut down the size of every response, so an image which is two MB in size, if it can be cut down to say 200 KB, it's a huge saving in the amount of time it will take for you to load the site. The other thing you can do is reducing the processing that is happening at both ends. That is, at the end of the server, there's a cache and that can short-circuit the entire set of processing that your CMS does. And at the browser also, if your resources are already cached, it short-circuits the entire request that has to be made to yours or to any other third-party server in order to be able to generate that page. And similarly, you can optimize the network request as well in a certain way. And what are the things that you can do? So what are the things that run at the client side, which is the browser side, and what are the things that actually happen at the server side? I've just created a table out here with the different strategies that are out there. You can do browser caching. That means whenever one resource has been collected by the browser, the browser remembers that and never has to request again. You can use fewer domains. If you use fewer domains, fewer DNS requests. You can delay certain requests. You can say that, hey, here is the most critical thing that you need to load. The rest of the things that you need to load, don't wait. Don't make it block. Reduce the number of, as I explained, there are blocking assets and the non-blocking assets. Reduce the number of blocking assets as much as possible so that the beginning of the painting of the screen and loading of the site itself can start happen. Move more and more resources and more and more assets in the non-blocking space of things and make it initially optional in a way. The things that people usually do is reduce the render blocking assets that are there, lazy load the images, lazy load the fonts. There can be other things that you reduce down over here. When you try to reduce the payload size, you try to introduce responsible images. Why? Because if there's a smaller screen, it needs a smaller image. If you serve it the smaller image, the size of that image in the number of MBs goes lesser. You can reduce the page weight as much as possible. This entire thing is called page weight to make sure that the number of bytes that are getting transferred across the network is as low as possible. Now, you can reduce the processing and the wait times over here by having more efficient code, less code, less JavaScript, less CSS, everything less that you can do. Those are going to be faster. You can use critical CSS, which is to make sure that you pass on the base layer of the CSS at one go so that it is not waiting for other network requests and other things to happen. The painting of the screen is simply waiting until those resources come in. If you critical CSS essentially is to cut out that part of the style of the CSS and make it inline in your main JavaScript in the first request itself and not wait until a subsequent CSS request or a JS request happens, not JS request happens, for the browser to start painting your screen itself. PJAX, turbo links and all are methods by which you don't make the page, the browser itself, re-render the entire screen. Instead, you only make it render a small portion of the screen so that the processing time is lesser. You can also optimize the network request. This is one of the things that can improve perceived performance, that you start eager loading or prefetching things. That is, the user has not even clicked on the next link, but you can just pull in the next link content as well. But the user has not even gone to the next page or even before your code has reached a point wherein it's requesting for resources, you can start prefetching the DNS and some of the steps that are there out here. On the server side of things to reduce the request, the best strategy is to concatenate files, fewer number of files. Instead of giving 20 JavaScript, give one JavaScript, give one CSS, maybe two, not more than that. So that's one of the big things that can save. The reducing number of requests can really save a lot of things as well. Now, minifying, purging the code, that means, in your code, if you have extra spaces, extra semicolon, everything adds to the bytes. Even though you might zip it and all, it all adds to the byte, if you have code that is not going to run ever, then don't include it, reduce the code. So don't keep adding plugins, use as less code as possible, as an example. Then optimizing the media, reducing the image sizes, reducing the processing time, essentially at the server level means having more efficient back-end code. Having a faster hardware can reduce the processing time at least, doesn't reduce the processing is the same amount of processing, but it reduces the processing time because it's so much faster hardware. Caching is the step that I showed, is the same as the Burger slider analogy, is that you pre-build certain things out and short-circuit the processing as much as possible. And finally, when you have to do the network request at the server end, you make sure that your request responses are compressed. You're using HTTP2, which allows for parallel requests to happen together. And make sure at the CDN level, serve as much assets from the CDN, not the static assets, but as many assets you can serve from the CDN. Those are broadly the landscape of how you can start improving performance. I'll quickly run over some tools over here and some common bottlenecks. The tools that I want to just quickly share are, use PageSpeed Insight Lighthouse, here's the link out there, which is broadly a tool that Google has put out. It also uses it for SEO, the metrics that get out of that. But you should note that PageSpeed Insights and Lighthouse primarily measures the front-end side of things. It rarely measures the back-end side of things because it doesn't have access to the back-end. It is going to process your front-end code and see how many times you're requesting for the network, how much are you using CDN or not, and things like that. So all the things that are outside this space, not this space, but most of the things that are outside this space, but sure, it will also check whether you've run minified code or not. But it will not be able to check whether your server can perform even faster or not. Or some of the other back-end thing. Now, WebPageTest does a few extra of those things in a way. It does check how much time did it exactly take for the first load to happen, the second load to happen, and things like that. So some of the more back-end-oriented things or some of the more server-side things get tested at the WebPageTest level. GTMetrics combines a bunch of these tests together. It combines PageSpeed and all, and YSlow, Yahoo had this YSlow tool to do that. Now, the first three tools, broadly, tests the PageSpeeds. This is mostly about speed. It does not do or hit your server or hammer your server with hundreds or thousands or millions of users or user requests in order to see what's the stability situation or the scalability situation. Those tools are like Loader.io, Apache JVita, Apache Bench, very simple tool, command nine, you can just fire a command and see if I end up hitting the server 1,000 times a second. It's very high, but if you have such a high number of user count or at least say 200 times a second or 100 times a second, is the server able to handle? And if you use the right layers of caching, which is, again, the golden rule for short-circuiting many high-intensive processing that people do, in that is going to save you a lot of things. The downside of caching is that it can be really, really hard to know when to invalidate a cache, so you don't start serving stale pages or stale content. And that is a different, I can take more questions around that as well, but it's one of the most difficult parts. If you save a page or if you save anything in the cache, how do you invalidate it? When do you invalidate it? That can often, because if you invalidate the cache, your entire performance boost is lost until the cache refreshes. Now, common bottlenecks can be large page weights, and I'm just, these are like the bare starting points that can be a lot of things that you can do. If you have a large page weight, start optimizing on the images. That's one of the biggest things you can do, because images typically constitute the maximum amount of bytes that are getting transferred. If you have slow network requests, use CDNs, concatenate, reduce the number of requests as much as possible, optimize the web server configuration, see whether you're using, leveraging on the browser caching and all those things enough or not. Now, if you have slow page rendering or the performance side of things, you can remove all the blocking script as much as possible. Use techniques like PJAX and Instant Click. What they do is behind the scenes, even as soon as you start hovering on a link, it starts prefetching that data in a way. And this can be a great way of improving the perceived performance for the user, because even before the person has stopped, the request has already gone to the server and the data is already coming back. So you will suddenly see this page come up very quickly. So this is one of the surprise elements that can happen. And if you have low server speed or slow servers, one of the big things you can do, you should look into is, are you having a good host? Are you having a good server hardware? Are you on a VPS or a shared environment as an example? Are you deploying server side caching, the caching things that I showed on the server side? Are you optimizing on the number of requests your server can handle at a certain point of time? And one of the key things you can start doing in case you're using Apache, which is something that a large number of people do, I would say that prefer Nginx, because it's much more lighter weight and all, not to say that performance cannot be achieved out of Apache at all. This is just a hack. This is not necessarily the right way to solve it. You can solve the performance problem on Apache as well. But I find Nginx to be easier and fewer number of things to be done in order to have the performance better in Nginx because of the way it processes certain things. I'll not go into that. That's too much detail. Lastly, who should be responsible for all these things that are happening? I think the leadership has to be from the developer, the development, because that person will understand the things. But the design and the content teams, if I broadly define any website to have design team, a content team, a development team, then learning and educating, although the lead, the developer might be taking the lead in that, but it's important for the designer and the content team to understand that very well as well. So just talk to the developer to understand and ask the question, how can it be made faster? The development team can try to create a performance budget and say that we are not going to allow more than say one MB of page weight or one and a half MB of page weight or something like that. Put in restrictions. And that's when the performance budget has to be touched. And the design and the content team have to understand the implications, what they can do, what they cannot do. Things that the design team can do is follow a design system. Don't make too many varieties of design because then the CSS code will increase. Use fewer assets, fewer images if you can. Correct the format of the images that you're using. If you can use JPG over PNG, use that as an example. Do responsible animation in a way because animations can also make things jitter and all. And at the same point of time, it can also improve the perceived performance sometimes in certain ways. The content team should be using the right type of format of images and all that when you're putting in. Make sure you're using the CMS tools exactly how you're advised by the developer because often you should consult a developer before embedding script. So often content team decide, oh, I want to embed a visualization. I want to embed a YouTube video. I want to embed this, et cetera, et cetera. Once you start embedding those things, you are causing those issues that I've just mentioned and described before. The developer should try to automate as many optimizations as they can, especially image optimizations in a way. And the measure and improve is the last thing that everyone can do. You can use the site tools, the measuring tools that I just told in the last page that are there. The development team can also start looking at performance APIs and real user monitoring or real user measurements. These are slightly advanced topics and I won't necessarily get into this unless people ask me questions around this. So that's broadly it. That's from my side. Are there any questions, anything that I can try to answer, Tejas? Yes, certainly. That was fast. Okay, so we have one question from Mohsen. I'm not sure this might have already been covered a little bit, but Mohsen is asking if it's possible to host images and media on CDN, not any third party files, but images and media. I think this might already be part of it. So on the CDN, not just images and media, you can even host your base HTML, the page itself. The main page, let me go back to this diagram. You can technically even host this page output. You see the page case that has been created in this server? You can also host it in the CDN. And that can even reduce the request of the first thing itself over there. Images for sure. Assets for sure. Media for sure. Everything can be hosted on a CDN so that the request doesn't hit your server at all. And if it is on the CDN, you are rest assured that a person in India is actually accessing the page from a server close to their location. A person in US is accessing the page from the server close to their location. Mohsen, does that answer your question? You can also allow Mohsen to speak maybe. Yeah. Okay, sorry. The other question we have from by Virendra Pratap on YouTube, that if the critical CSS needs to go as page-wise, on four-page basis. Yes, critical CSS is a very tricky topic. I didn't even advise it in this one, in the first set of things over here. I have written it. But critical CSS is something that needs to be embedded on every HTML response that is being sent back from the server. So whenever the browser will request, will get that page, that critical CSS is going to exist in that page so that it can immediately start responding to or drawing out at least the first page. That's also perceived performance. The rest of the page below the first fold that is there in the user screen has probably not generated yet. But just because it takes a few milliseconds for the user to comprehend the first screen itself, that is enough of a time the server or the browser has to load the rest of the resources and start painting the page below that. So critical CSS has to be inserted in every page. And for every page, especially if you don't have a singular template across your site, which most sites don't, they have probably a blog page has a slightly similar template, but the blog listing page will have different attack page will have different. I'm just taking an example out there. So you need those many critical CSS built out for you and inserted in those templates. Awesome. Thanks. I had a question as well, but I'll ask it after all. I'll just open it to other people to ask questions. If anyone has any questions, raise your hand or type in the chat window and I'll unmute you. We have one raised hands. Mohsin, you can ask the question directly. Mohsin, you're on mute, I think. Yeah, hello. Hi, Mohsin. We can hear you. Generally, when we do the page optimization for any website, then we see the different number for the mobile and for the desktop. Why this is so like we do the same operation every to the same files, but we are getting different results for the mobile and desktop. So what is the main reason behind it? This is you're talking about page speed insights. Yes. Okay. Page speed insights has a different benchmark for mobile and a different benchmark for desktop. It has created these. So when you go into the page speed inside documentation, it will explain to you what are the metrics and what are the percentage weights that are given for different things or optimizations you do in mobiles and what are the different metrics it considers for desktop. You might be sending in the same code, but your code might be fast enough for a desktop which has a higher processing power, which probably is on a more stable network than than mobile. And therefore you can do less optimizations and get away with it in a desktop environment. But however, in the mobile environment because mobile processes are slower, it has to and also the network might be more unreliable. Therefore, you'll have to do more number of steps in order to be able to reach the same target, stay page load time or a page generation time and things like that. So these are different benchmarks. That's why you see different scores. Does that answer your question? Yes, I like that. I understood like we need more analysis and more in depth. The fixes need to be do for to improve the mobile, right? Yes. So if you can optimize for the mobile, you are almost certain that it's you're already optimized for the desktop provided you are serving a better image for the desktop than for the mobile. If you serve a better, like for example, your desktop will have a bigger screen, mobile will have a smaller screen. So you can send in smaller images for the mobile. But if you start sending the same smaller images for the desktop, user experience wise, it will not be great. But I think performance wise, it will be pretty good. So if you see page speed inside starts complaining about things, sometimes it complains about things beyond performance as well. It complains about things around user experience as well. So just take a note that page speed inside is not purely performance. It also has many metrics around user experience, like how many times it does a page jerk and load things in between. So it's called the cumulative layout shift. So how many times the layout changes and jitters and things like that. Those are less performance, but more I would say user experience better using. So page speed inside is a mix of that. If you optimize for mobile, you automatically optimize for desktop because desktop has more relaxed benchmarks. Okay, this last question, like we have, like if we use the bootstrap, right? Then obviously, like the entire bootstrap CSS will not be used in our website. So sometimes what they give an error into the page speed inside that, like there are some unused CSS, which is not used into your website, some, some extra classes and all will be there. So I cannot reduce the CSS, right? Because you can, you can. So for example, there's something called Perge CSS as well. Take a look at this tool as well. What it does is it goes in and checks in your HTML, which are the classes you've used. And in your CSS, if those classes are, there are classes that have not been used in your HTML, it'll go ahead and remove it from your CSS as well. So if you're using build tools to actually compress, minify code, you can additionally use it or concatenate concatenation, minification, compression and all those things for JavaScript and CSS, you can additionally use tools like this Perge CSS, which will further do more processing and remove out CSS classes that are not getting used. Okay, so like in future, like if I did this operation on Perge CSS for the boot set, which is the library, okay, a Twitter library, and then in future, if I wanted to use some classes from the boot set, then again, I need to add that particular related because I don't know where that class is used or the entire CSS will be there into the boot set. I have to, like, did you get my question? I got your question. So the way this happens is that if you're doing a manual building of the CSS, so usually what we have is you can have a different atomic sass files or less files. I don't know if you use sass less or anything like that. I use less. You use less. You also use less as an example. So when we are using a different less files, you have the way of combining the less together and maybe use gull, grunt or whatever, whichever tools you're using in order to combine them. So that's called automating the developer workflow. That means it will compile the less into a CSS, right? So the Perge CSS has to work inside that process, gull process or grunt process or whatever tool you might be using. Once when it checks out, whenever you save new code, it's going to run it through the CSS file and the final build file that is there, that's where the Perge happens. The Perge does not happen in the code, the less files that you are actually working with. Your less files will have 100 classes. Maybe you're using 40. The build CSS file is going to have only 40 of them because Perge CSS has eliminated them in the final build CSS. Is that clear? And if that is the case, then that is an automated thing. So you add an extra class inside your HTML, then Perge CSS knows and next time it runs that build process, it does not eliminate that CSS. We should let in the next question. So Kunit, I have unmuted you. Please ask. So this is not very specific. Sorry, your voice is breaking. Can you hear me now? Yes. All right. So what I was saying is my question is not technical or specific, but more of a general question, which is that web performance gets discussed so much and there's so much attention and yet we end up with a lot of lower websites. So with your experience of having interacted with so many website owners, organizations, what do you think are the real world challenges? Need not be specifically technical challenges, but in real world, what do you think causes so many slow sites still to exist despite so much of focus on the website? Okay. If I go back to this slide, I hope you can see the screen. This point that I have written is one of the biggest reasons for that. I believe so, that you usually end up testing your site only on your own computer and you see that, oh, I'm able to see the site. I am happy with it. I'm excited about it and you are not going through and following up on whether the performance is good in the real world out there itself. The moment you start getting the feedback, the moment people start giving you the feedback, that is when you realize that, oh, I thought my website is fast because I have a 40 Mbps lease line, whatever connection at home with this, with a large monitor and things like that. That is where the, I think one of the biggest challenges happen that people don't realize how slow their site is in the real world out there. And the conversation that is happening around performance is actually a very privileged conversation, I believe, because I think a very, still a very small set of people are talking about performance as much. Still a large set of businesses first want to contact a designer to make sure that the website is really great looking, great big photographs. The visual experience is given far more significance over the performance that that follows for that website itself. And that is where I think, I think that there's an awareness issue. There's an issue of thinking that you are the user yourself. And sometimes maybe even as a user ourselves, how much are we, does the flag go out in our own head that, hey, I am visiting a slow website. It's not my website, someone else's website. I'm visiting a slow website. You tend to self-blame. Oh, I have a bad connection. Oh, I blame Airtel. Oh, they have such a poor connection and the network speed. The blame unfortunately is far greater towards the network, your device speed, your as a user, your realization is, you don't actually pin it back to the developer of that website to actually make that connection that how much control that developer had in order to make your experience better. So it's a variety of all these factors. I believe that doesn't bring it out in the emphasis. But among the people who are going for it, the fact that it has become such a big SEO metric at this point of time, Google has been pitching it and pushing it. And then there are these lots of other JavaScript libraries and other libraries that have come in, which are pitching it as an important feature that people have started talking, but I don't still feel enough people are talking about it. Interesting. Yeah, that was inside. Thank you. Thanks. Savit, I think we have time for one last question. We have two minutes over our time, but we can. I think we can do another five, seven minutes. I don't think there's a problem with that. We can take a few more questions. Awesome. Awesome. So there's a question from Nikhil Mishra on YouTube. Any special recommendations for JavaScript heavy websites we're using libraries like CDFJS, whether the response is coming in from, in form of JSON? The first is that if you are using a JavaScript heavy site, my first recommendation is focus on the first page load. Because what JavaScript tends to do is always or the JavaScript heavy applications that are there out there, what they always tend to focus on way more is that, oh, look how my subsequent page loads are so fast. Okay. That they almost say that, oh, the first page loads is just a one time thing. The subsequent page loads are so fast. But unfortunately, the first page load is what gets impacted the most. And in order to get around it, the unfortunate reality is you have to reduce the amount of JavaScript. At least the amount of JavaScript, which is blocking. So don't push in a lot of blocking JavaScript. Honor the fact that the end user might be on a slow mobile phone on a bad network, and try to probably pre render the screens and send it to them. And rather than doing a rendering on the client system itself or client side rendering itself. Personally, I'll also, as a matter of full disclosure, I'll also say that I am not someone who uses JavaScript a lot. In fact, I see that non JavaScript sites can be as fast, if not faster than JavaScript, which have a lot of, then sites that have a lot of JavaScript in there. But going back to the original question that is out there, as I said, focus on the first page load, try to make sure that there is less JavaScript as less as possible, especially the blocking JavaScript that you have. And if you can serve the JSON responses and all from CDNs and all, I don't know what kind of application you'll you probably have. There's a good good good chance that you're probably directly querying your server and you cannot actually case the response in a CDN and all those challenges might be there. But if at all there are possibilities of doing those serving these from a CDN, the responses as well, or serving from a closest server, those are some of the things that can help make site faster.