 Hi, so I am Mankit, I am one of the co-founders of ClearTax and I am here to talk about the basics of the performance measurement. So before we get into it, I just want to talk about what is actually performance measurement, what do I mean by performance measurement? So take an example of a startup building an app, you are very resource constrained, you will have few developers and you have to deliver features, you have to customer support, you have to build great experience and also make sure that the product is fast because speed matters, it really helps in conversion. So yeah, being aware of the performance profile of the application makes a very big difference and using performance measurement, you should be able to figure out what is the, you know, what is the critical path of attack, in the sense that what is the low hacking through, what is the thing you can tackle first. You can try to try to go about improving your site blindly, but actually knowing what is happening will make a huge difference and you will be able to fix anything that is wrong faster. So yeah, this is sort of the overview of the talk I am actually going to do. I am dividing it into four sections, knowing your users, understanding what it is you are actually measuring, then you can actually spend time looking at your site yourself and figuring out the simple parts and fixing them and finally we come to real user monitoring, which is actually monitoring the performance of your site for end users. So yeah, knowing your users, can everyone read the text, oh thanks. So I can't really talk too much about this, I am thought of keeping it as a homework assignment. By knowing users I mean that you have to understand the use cases you have, are you building a desktop site, are you building a mobile app, are you building something that is both, do a users use 2G, what secrets are they distributed in, how are they actually using your app. One of the first sort of most important recommendations I can give you is don't just go by data, actually understand how the user is approaching the site, how they are using the site, like you can actually do a face to face session, see how they are using it, how do they otherwise you can take a phone call and get feedback, that really makes a huge difference. So let's come to the understanding part and I may cover some of the basics here and I may just run through it a little faster, because I am hoping that everyone is aware of the basics. So ignore the large diagram, it is just for this slide, I will go into it, I will break it down into different sections and we will go into it. So this diagram is basically the different timing measurements that the browser gives you. The browser has a navigation timing API that is standardized on all modern browsers and you can use this API to actually measure page load times from the client and so again I like to divide this into three layers of performance, you can think about network, back end and front end. Dividing it into these layers makes sense to me because there are some things you can think about in isolation and there are some things in your control, some things that are not in your control. So you can focus on the parts that you can actually control now. So let's talk about the networking, these are the measurements that the browser gives you for the networking aspects, very high level, let's just talk about the first page load of your site because that is the worst case performance. The first page load, let's say your user is coming in via Google search, the browser will have to do a DNS lookup, DNS lookup, so the browser gives you measurements for that gomin lookup start and end type, you can measure how much time it actually took to find the IP address from the DNS post name. Then once the browser knows the IP address, it will start doing the TCP connection. The TCP connection again is a sort of three way handshake, it takes few round trips to actually establish the connection to start it and I'm sure that most of you are on SSL. So after the DC connection is established, you actually do a SSL negotiation and key exchange and all of that and finally if everything is ready, just before the HTTP request is about to be sent, the connection end event is fired. So using these measures, you can actually figure out how much time it is taking for the browser to connect to your server and probably this would be like the front end proxy server you are using, the NGINX server. So typical times for this are very varying, it depends on where your server is hosted. DNS is typically passed like should be around 10 millisecond. TCP connection handshake really depends on the latency between your browser and the server. So if it is taking three round trips, you establish a connection, the ping time really makes a difference and again SSL negotiation will have a few round tips. So it really depends on the latency from your browser to the server and the best thing you can do over here is like if you are serving an Indian audience, host your application in India. You will have like a 40, 50 millisecond ping time instead of 250 millisecond for AWS in US and that is a huge, huge benefit. Like you will cut down your load time, your connect time by a large margin. Recently AWS launched a region in Mumbai, Azure is there in India, Digital Ocean is there in India. So even if you are using cloud services, there is almost no excuse to not host in India now. So yeah, coming to that, so there are not too many things you can control in the networking layer, but you can host in India, you can use CDNs. CDNs typically most applications will end up using CDNs for images or if you have a proper build set up, you will put the JavaScript and CSS files bundled and distributed on the CDN. The reason to use the CDN again is they are experts at this, they will have edge locations throughout the country, throughout the world and the CDN server will be closest to the end user. Depending upon the resources, depending upon your site, you may actually put the whole site behind the CDN. So it really depends on what you are building. Let's say I spend tracking application, typically will have the resources and the CSS files in the CDN, but if you are building a video streaming site, you may end up investing a lot in the CDN layer from day one. And again at the networking layer, one of the most critical things you can do is reduce the number of redirects. So as I said that first connection, there will be the TCP connection, the SSL connection and so on. If you redirect the user to a different domain name, it's going to cost a lot, especially on a mobile phone. If there are couple of redirects before the actual page load is started, then the user is going to see a blank screen for three, four seconds before even the request comes to your server. So for redirects, the simplest thing you can actually control is, you can set up a canonical server name in your Google webmaster tools. By that what I mean is typically every site would have almost like four variants with www, without www, with STTPS, without STTPS and you end up redirecting to one version. So in Google webmasters you can actually set, this is my canonical URL and Google search results and so on will actually show the correct path and if you can avoid doing a mobile redirect, you can go to something.com, that is also great. So next we are coming to the backend layer, again I won't go into too much detail here because we are not talking about the backend at this conference, but again the basic thing is that you want to optimize for your response time, you want to make it as fast as possible. Sort of high level positions that I can give you, when you are looking at backend, let's say you are doing a full stack development, don't look at the response times like the mean response time or the average response time, look at the percentage, look at the distribution of response times, look at the 90% time, the worst case 99% time and this will like inform how your design is. So the browser will give you like these three timing measurements you can use, request start when the STTPS request goes to the server, response start when the first byte comes back from the server, so this can be called as the time to first byte really and the response end, this is when the full HTML of the page is sent back to the browser and like depending on your server configuration, if you are using a streaming methodology, you can get the response quite soon. So yeah, let's talk about the front end section. So front end, you have a lot of different measurements given by you, given by the browser to you. So let, I'll just quickly go through them one by one. So basically this DOM interactive is a timestamp given to you when the full HTML is passed and the whole DOM is created. Typically this is almost the same as the DOM content loaded, which is like a document ready event in jQuery. This is when you typically start initializing your JavaScript application and start setting up everything. So there are cases where like even though the DOM is ready, your document ready event may not fire. We'll go into that later. The browser also lets you measure the time taken by the event handler itself in the sense that if you have a document ready event listener, you can measure how much time it took for the event handler itself to execute by taking a subtraction of the event end event start time and finally you have the load. The load event is when the document ready is, DOM content loaded is for the main sort of document without the sub-resources, without images and so on. While the load event is, you have all the, all the resources loaded. So mostly like when you are talking about content development, you are mostly looking at the first event, not the load event. So now like this looks like a very straightforward process, but it's not really a linear process. There is a lot of complication that comes in. Let's actually look at the diagram here. So like the browser doesn't do these things in a sequence. It will, as soon as the response comes in, it doesn't wait for the old response to parse the HTML. It will start parsing in parallel. It will pipeline, the execution is like a pipeline and as in when it reaches a script tag, it will start fetching the script, executing it. So there are a few interesting cases here, like if you don't have any CSS or JavaScript in the page, parsing the DOM is like okay, your document is ready to render, but you will of course have a lot of, you will have some CSS and some JavaScript there, right? So the behavior of the browser is when it executes a script tag is dependent on the location at which the script tag is present. For example, you can mention that the script tag is async, that will not block the browser and it will continue processing. But if you have a script tag and you have a CSS tag before the script tag, typically the browser will not even execute the Java until the CSS is loaded and it constructs the CSS object model because the script itself may be like looking at some element, they may be looking at the width or the color of some element, the browser can't really predict what the script is doing. So it will wait for the CSS to be parsed and then execute the script. So there is a lot of interdependency between these steps. And while this is happening again, you have a layout happening, the layout will be sort of again, it will not wait for everything to end. The browser will start making the layout while these processes are happening and as in when it has a proper structure of the page, by the layout I mean like it figures out which element goes where, the height, width, the margin padding, all of those things. And based on the layout, it will figure out what is the rendering path, rendering tree, which elements are visible and using that it will paint. So the first paint of your browser may actually happen before your document content loaded event is fired in some cases. It may happen afterwards. It really depends on how the actual scripts are structured. You may have cases where you get like a flash of unstyled text without some CSS being handled or you get flash of invisible text where you are waiting on some font but the layout is sort of complete so you get a blank page without the text or so on. So again, all of this is mainly looking at the static page but since you are building application, like on the document loaded event, you will start initializing the application, you will start setting up the event handlers and updating the HTML and everything. So now again JavaScript will execute and the whole sort of cycle continues. So yeah, it's not really a very linear process. There are a lot of interdependence between them. The timing measurements that you get are for the initial load but after that you have to instrument it yourself. So let's quickly go through some of the steps you can do yourself and figure out what is happening with this application. So I'm sure everyone is very, very comfortable with your browser details. I'll not go into that but there are a bunch of tools out there that you can use to leverage to actually look at your site from a different angle. One example is HTTP archive. HTTP archive is sort of like a internet archive is for, you know, hosting previous versions of site. It's like a public domain crawler which will host history of your website. HTTP archive hosts sort of the performance profile of your site. It crawls the top million sites of the world and for every site it will take care of measuring the load times, response times, the performance profile and it will give you the data to study. So you can actually download the whole data from HTTP archive and study what is like the average site in the world looking like. You can look at your own site in this HTTP archive and see how it looks like. And the web page test is again a sort of community project that's sponsored by Google. It's what you can use to actually like open your site from different locations throughout the world, different browsers, different connection profiles and test the performance. And there are a lot of other tools there as well. So these tools really, really help a lot in measuring your performance. One interesting example I wanted to give was using HTTP archive. You can actually look at, let me zoom in a little bit, okay. So using HTTP archive, I am looking at ClearTax right now and for some reason this thumbnail didn't load but it actually shows you the loading progress. You can look at the history of your site in the sense that over here I can select compare what ClearTax is right now to what it was in November and I have this open. It shows you by data over time. It looks like November last year, our site was much faster. It was 3.5 seconds to load. Right now it is 4.5 seconds. We have one second extra but we are doing a lot more things now compared to November. So that's a trade-off we have to make. And you can actually look at the whole waterfall model of your site. You can compare against the previous version and so on. So this is really very powerful. So now I'll just talk about the very sort of low-hanging fruits you can tackle first. The first thing you should be looking at is content sizes because it really doesn't matter how you are splitting your JavaScript and all of these things. If you are loading like few MB worth of banner images on the top of your page for the user. So take care of the very simple things first because that is going to make the most difference. Reduce number of images. Reduce number of fonts you are loading. What don't load a font if it is not required. Make sure you are using gzip and cache headers and everything. These basics are really important and make sure that you have covered the basics first. And again the size of JavaScript and CSS makes a difference especially on a mobile device where the CPU power may not be too much and executing the JavaScript may be slower than what we will see on a desktop. So you will see this term a lot when you are looking online for resources, the critical rendering path. The critical rendering path is basically all the steps required to show something on the screen, the first print. So knowing what is happening to your site, looking at your performance profile, you can use different strategies to actually improve the, reduce the critical rendering path. And you will come into terms like pursuit performance over here, which is basically if your site is going to take 5 seconds to load regardless of what you are doing, might as well show something to the user before 5 seconds, even if it is like the layout of the header footer or something like that. So this is a very interesting problem for single page applications and we had with how sessions on this later in the day and tomorrow to how to optimize for rendering something to the user totally when you are building a single page application, for example, this is React or React. So basically these things, the really core basics of performance really help in like while you are developing the site as well. Because if you are aware of them, if you are aware of the public profile, you can actually make the right decisions while implementing. So it really depends on the team size, what you are working on. Two person startup may not have the resources to focus on all the optimizations possible, while a 20 member team may actually have someone dedicated for performance and so on. But knowing the concepts will help avoiding mistakes before they are made. So finally we come to the real user monitoring section. So this is again like a buzzword. Everyone talks about real user monitoring. It's basically this timing performance measurements that you see from the browser and sending it to a analytics software or to your server for collecting it and analyzing it later. So like this diagram that we see, that we had seen earlier. It's basically a browser API. So you do performance of typing and you'll get all the timestamps. So these are UTC timestamps and you can look at the difference between them to figure out the load time and so on. So every page load will have this data available for you. And this is available on all modern browsers, almost all for our browsers. So you can actually look at the usage pattern. I think like mobile Safari recently has dropped the port for it. But otherwise almost all browsers have it. So the good news is that you really don't need to build a lot of tooling to measure performance right now. Because let's say you're using Google Analytics, which I'm sure most of you are using by default. Google Analytics actually collects these performance measures by default. And it will send to Google Analytics server for... So one thing you need to be aware of is that Google Analytics by default collects these performance measures in a sampling mode. It will only collect the performance measures for one percentage of all sessions on your site. But you can configure it in GA by setting a sample rate. You can say you want to sample 100%. So all sessions will be sampled. And there is also a fixed limit, like the number of sessions it will allow. But I think like 25,000 or 50,000, some number of limit that is allowed per day, depending on your site, depending on whether you're on the free version or the enterprise version and so on. So if you're not very familiar with Google Analytics, Google actually has a demo analytics account that you can add to your account which has a lot of data pre-populated in it. And I will put the link here and share the size later. You can actually add a demo account to your GA profile. And you can study all the sections which are pre-populated and figure out what is happening. So hopefully if internet is working, I'll do a live demo of what is happening, otherwise you can look at some screenshots. So is this visible to everyone? So I'm looking at a demo account on Google Analytics. So this is like sort of the default view you see. If you go to the behavior section and look at site speed, this is where your performance measurements are actually going to be present. So you'll start seeing all these numbers over here, like the average page load time, or you can look at domain pickup, you can look at different measures. Let's go into it a little more detail. So this section will show you the average load time over a time period. And you can compare against a previous time period as well, compared to last year, for example. You can see a difference. So the average is fine to look at. It's actually quite useful. But the more interesting thing is going into this distribution section. So the average may lie because you have some users who may get the site loaded in 1 second, some users who get it loaded in 10 seconds. And you want to know exactly what the performance profile is. So the distribution over here is actually sort of the most critical part. This shows you a grouping of whatever metric you have selected. So for now it is load time. Let's say document content loaded. Because this is when your initialization and everything happens. So the average time is 2.9 seconds for this data. But if you look at the performance buckets over here, most users were in the 1 to 3 second range. But some users around 20, 25% of users had more than 3 seconds. And like 3% of users had more than 10 seconds of load time. So you'll see the sort of distribution you get. This will help you in understanding the exact sort of profile. For example, let's look at server response time. So typically when you look at server response, you'll again see a sort of variance in the response times. The request was for a static asset or not. It was a cache request. Whether it needed some BV lookup and so on. So you'll see a lot of variance. Some requests are very fast. And some requests take more time. So again, you can go into it in very granular detail. You can go into it by like selecting a specific geographic region. Let's say you are building an app which is available in two cities. So you can compare those versus Delhi or something like that. And the other great advantages, Google Analytics has a lot of powerful segmentation capabilities. By segmentation, I mean it can look at a subset of users. Let's say you want to look at people who are on mobile. So this is like a built-in segment. It will create a group over here. So right now we have two segments selected. All users and mobile traffic. So if you look at the distribution, you can see the difference between them. So for example, page load times. The page load times may be very different. So for normal, all users, the average case is around 5 seconds. Mobile users, it is almost 8 seconds. And you can see the distribution how it happened. So the segmenting the users looking at a specific set is very useful. You can create segments like people who came in via search query and looked at your site, people who ended up doing a transaction or converting and buying something on your site. You can create segments based on a lot of different conditions. So there are built-in segments, but you can create custom segments based on any Google Analytics property you have. So that was a very quick demo of what GA does. So you have to be aware that Google Analytics is very powerful, but it is also limited in some ways. One of the main limitations is that it is going to give you aggregate data. It is not going to give you individual data. It is that you can't really study one specific user's performance issues. Let's say someone raises a support ticket saying that it is not working for them. You can't really drill down into that in Google Analytics. It also up to a certain level, it will give you data even if you put the sampling rate at 100%. After that, it is going to start sampling data and it is going to give you limited sort of metrics. So sometimes if you actually have to troubleshoot a problem, it makes sense to actually do a remote desktop session with the user. Or if the user is technically savvy, ask them to share an HR file with you. So some recommendations I would give if you are using Google Analytics is that you should build custom dashboards with these measures. I will quickly give an example here. So you can actually build dashboards for your key metrics like this and you can put it up on a board somewhere. Even the dashboards in this case, it has a lot of the technical timing metrics. You can actually segment the dashboard also. You can say, let me show mobile traffic and desktop traffic separately. Remove all users. So now you have two groupings over here, mobile and desktop. And you can see the load times and everything separated by the segments. This is very useful. You can configure these type of dashboards to be emailed to you daily if you want. You can set up alerts on this. So you can actually go into alerts and set up a custom alert like you can put rules like if load time in some region goes above 5 seconds, send me an email and so on. You can also very interestingly look at historical performance. So let's say you changed, you upgraded the React version and so on. You want to see how it impacted the performance of a site. You can study the average times or the mean times. Before the change, after the change you can compare them and you can see the distribution. So it's very useful. Google Analytics is what I was focusing on because it is available for you. Almost everyone uses it. But there are a bunch of other tools which will do this for you as well. Like New Relic, Pingdom and so on. At scale, let's say you are really focusing on performance and you really want to optimize. You can actually collect this raw data yourself and send it to the server in a beacon. And you can, let's say you have an analytics pipeline in the back end where you have some standard stack like logstash and so on. Set up for collecting metrics. You can put the browser metrics into that as well. So again, what I was talking about so far was navigation timing API. That is for load times. In today's world, load time is just like the beginning of the sites journey. Once the application is loaded, you have a lot of interactions happening. Front end is basically the application for the user. So what you want to also do is you want to measure timings after load. You don't want to just measure the basics. And there are a few options. Like as mentioned earlier, there is this user timing API that is like a W3 standard and available on browsers again. You can use that to measure timings and it will come up in the DevTools timeline. It will show up as, I'll give an example of, let's see how few components. You want to see the render time for that specific component. You can use that. So in GA, GA by default understands the navigation timing API and it takes it, but it doesn't understand the user timing API. It is the W3 standard. If you want to put this information in GA, you have to use a specific API like this, which is sending some timing information for a specific component. So lastly, I wanted to talk about prioritization. It really depends on your use case, your team size, what you're focusing on. But you have to understand the users. You have to understand the problems you are facing and optimize for 80%, 90% cases. You may not be able to go to 100%. So again, performance is an art. Being informed, understanding, sort of the broad picture will let you prioritize and quickly make decisions on what is most critical to fix. And I also want to say that performance is a goal, but it is not really the end goal. Let's say you are building a filing website like Lee Attacks. Getting the users to file actually is the goal. The usability of the site, the product is the end goal. Performance really helps in everything, but it is not the only measure you should look at. So yeah, that's about it. Any questions? Please raise your hands when the speaker is answering your questions so that we can pass the mic around. Usually regarding Google Analytics, how does this apply for a single-page app? So as I said that GA by default will take up all the load timings and initial site rendering information and all of that. But if you want to understand the behavior after the load, you want to use these type of events which you are instrumenting yourself. And you might ideally want to put a wrap-up function which will, you know, put it both in the W3 standard timing API as well as in GA so that you can see it in the DevTools timeline as well as you can send the event to GA. Based on the navigation I can file. So yeah, based on your application. So I have a question about the privacy of the data. So in this particular case, I believe we are publishing the data to Google Analytics servers. So do they offer some kind of a productized mode of it so that I don't want to publish my data to them? So Google Analytics is sort of ubiquitous on the site, on the internet. Almost every website you go to will have Google Analytics tracking code installed. It's really a control on the browser side where you can block GA scripts from executing with ad block or something like that. Or application developers perspective. GA has very strict privacy controls. Like you're not supposed to put any personally identifiable information in GA. You're not supposed to put the user's email address ever. All the information in GA is anonymized and it's aggregate. It never goes into individual user level detail.