 Thanks for the intro So the I know the topic doesn't match what he told that's nobody's fault but mine but It is pretty much the same thing. I'm going to be talking about performance Welcome everyone after lunch. I guess you're all full. I hope it doesn't bore you much So today I'm going to be speaking basically about My work at Atlassian from the past one year We have been trying to set up all our teams to be very sensitive to performance front-end performance And my team was one of the first to adopt this and so that's what my talk is going to be about how to get speed as a feature in our front-end teams and Basically, what cadence do you have to follow as a front-end developer? So the goal of this talk is basically what does it take to build a culture of Performance sensitivity in your front-end team So you all know how important performance is and there's been multiple researchers. There's been multiple talks on this I think like 2018 2019 according to Google their whole Focus is on performance. But for me, it was not the same at least my career graph I did not care about performance for the first half of my career and Early joining Flipkart. I was like Abhinav Rasoji told me like no junk There should be no junk in the website and that's the extent of my knowledge until then But in the past one year at least I have tell deep into what it takes like To to debug when performance issues come. What do you do? How do you monitor and what do you monitor for? So this talk will basically I'll talk about What all I learned during that time and what we've implemented first we So all of you do you all work on JavaScript? What do you do work on front-end? What is the? What is the ratio most front-end JS? so In JS at least according to this research, we all know performance is important. So according to this research So this is by Tammy Edwards as part of her company her research company. They What they did was they slowed down Tesco's website by 500 milliseconds and The interesting thing to watch out here was that People thought that not only not only was it slow but people thought other things about the website Which were related to features that they were developing they thought the features were child-like They were complicated or hard to navigate This is an important thing to keep in mind about why performance is important and in Jira we get similar feedback I work on Jira like Where users mistake slowness for a badly built website badly featured website So You your performance problem on your website might be bigger than what your notes users are just not complaining. It's slow They're just complaining that I can't I can't go anywhere. I can't figure out this website because it's so slow So to give you context. Yeah, I work I work on Atlassian's product called Jira. I work on the cloud team and Basically when I joined like I think six months before I joined we started a new repository Where we started developing Jira with the reactor this has grown considerably in the one year And it's grown up to like hundred and fifty plus developers contributing to this repo There's more than hundred commits every day and the teams are so dynamic like we I have moved teams already thrice in my in my one one year one year two months and So you might have to move within teams a lot and we work both with like legacy pages The older pages that are served using JSP and we try to incorporate them into the SPA that we're trying to build with reactor So this is kind of the scale that I'm working with So maybe my talk might not apply to all of you, but the principles should remain the same whether it's bigger scale or smaller scale So one thing that I learned to working working on this product is that front end performance is hard it is so hard to To convert something slow to to work faster and worse than that something I learned Is that front end performance is fragile? So it takes a whole army to build a fast website But it just takes one person's mistake to slow it down for a day It is yeah And if you don't have checks and balances in place these things can slip unnoticed and gather into a big mountain Which you cannot debug later Like if even some ill-placed loop or Not somebody not debouncing properly all of this can affect a whole website very badly So how do you go about how do you go about setting in this checks and balances that can help you? Help your performance be more predictable as you make changes to your code base at such a rapid rapid Pace right like hundred plus comments every day morning. I go to office and now I'm on leave I might maybe my team has changed there even So, how do you how do you make sure what are the steps that you can take or at least? What are the steps that we have taken to kind of build a performance culture within this large of a team? So step one step one would be to know your tools So knowing your tools what what tools would you use to check performance mostly the ones provided by Google? I guess so one of the most more popular ones is Lighthouse so light house is a tool that is integrated into your browser now What it lets you do is it? you it you can run your website with light house and it'll give you a certain set of recommendations and Insights into what might be wrong with it not even not only relating to performance But also related to accessibility and many other things But at least for our use case we found it to be very mild and we could not it was not very actionable for us So our premier tool at least is the chrome profiler So the chrome profiler is like the only only one of its kind comprehensive tool that will give us some insights Into what code we are running when when a page runs So here basically I wanted to give a small demo of so how many of you are familiar with the profiler and have used it Quite a lot of people, but I still think maybe this might be useful And maybe it can be used as a point of discussion later on in my talk So I'll move to the demo now Profiler is basically One of the tasks in that chrome provides as part of its developer tools So you have your it shows your estimates the source code It shows console and so on there is a performance tab So the performance tab what this allows you to do is two kinds of recording and I use both of them So one of them I use when I want to make interactions with my website and see what kind of a JS stack JS claim charts I get within that or this one I use to reload the page and see page load performance So let's reload the This is me Website So as you saw it basically knows when the page load has finished and stops profiling immediately So if you want to have a look at what this says right now Here at first in this tab You it gives what exactly all the JavaScript that it ran You can basically drag around and select whichever is interesting to you Like I suppose this might be the most interesting part for us But even more helpful I feel at least is the screenshot that it provides on every frame here So you see that there was no activity until here and then there was a load and you get the Then it comes back here right so this page basically took from here Here to load something and this I feel is very Yeah, it's like the highlight of the chrome profiler for me I'm always looking at places where all my all the stuff that I am interested in loads and I select that much part of it So once you make the selection all of the part of below it kind of molds into that Selected part of it and you get more interesting data One of the we I have used basically this network tab the flame charge and Call three here Like all the performance debugging that has been useful to me and I have been able to get some outcome out of it Is by using these three tabs at least so The network tab is quite interesting in the sense It shows you at the exact for the exact point of time that your Scripts would have loaded like for Google at this point You can see that the logo started loading here and then you can investigate what happened before this is too slow once But I think still the most highlight highlighted feature of chrome profiler is its flame chart. This is helping me numerous times I might be able to show you an example So what the chrome profiler shows is what what javascript it exactly right? So this can correspond to the javascript that you have on your For in your code base and if you're running unminified stuff It's very easy to correspond what's happening where and the longer this flame chart is Thus lower your call call is right There is something here that is holding up So the flame chart the way it works is for every call that this This is a javascript call and for every function that is called You have a step in the flame chart and a deep flame chart means that the country was very long So when I see a deep flame chart I basically try to go to the country and I try to find the most So the quality here shows you how much time it took and what percentage of the original call it was and I Many a time I have found that I've been able to find expensive calls using this and Been able to debug my performance problem other than this one other thing that I find useful is these markers that the Profiler provides so these are by default here like it says it's the frame started loading and the Don't content loaded at this point Even though Chrome does provide this it's not usually very useful for my website at least So we try to put as many customized markers as possible we use this We use this API. It's not really standard, but we use this API to record in our Time stamp record the timestamp of each marker performance marker that I use and this shows up This shows up in this graph as As a marker and that's kind of useful for me as to like so I can correspond a UI event to what code exactly ran over there Like something that's happening on my screen to what code actually that which is what I find is very challenging with the Chrome Profiler as this but it's still the best option we have and I use it extensively to debug so moving on now that we have established that it has a Don't contain loaded and marker such as this we can see how we do measuring and stuff like that how we can do measuring So Yeah, this is one of the places where where I was able to find a performance issue We could split it up and added some Whatever I wanted to load over there By lowering this because the fact that you automatically lower priority And so I had a bunch of stuff happening before my most important Was Looking at this graph this was in the network pack And this was another place where React was continuously re-rendering something that we were doing something wrong This So that's step one know your tools know how to operate them not only you everybody in your team whoever touches the code in your website Should know how to use Chrome Profiler if you are serious about So measure your website step 2 What do you measure when you have Website works like this. So there is some loading state when there is Loaded and then there is some visual content appears, right? There's HTML and CSS that's painted If you are doing server-side rendering with your thing you can actually eliminate the whole loading state and only show And then you will know the difference between having the first meaningful paint and Some time to interact So this I would consider as the first meaningful paint. Maybe it's different for you Maybe you don't need the tree there, or maybe you don't need the sun. Maybe you just need the mountain Next step you will download and parse the JS and then your site becomes interactive and that for us is the time to interactive So these are the two most important metrics that we gather for all of our pages at least for page load metrics We also try to find Timestamps of how much each interaction took how much an Ajax called how much time an Ajax called took and so on But this is pretty much standard for us So other things that we like to measure we measure bundle size. We measure dom size. We measure how much time an API takes We measure SPA transition timings and so on You would have to so I still believe that custom metrics is still the way to go when you want to measure the performance of your website Because you are still the owner of how your website works and how and what metrics are important to you in your page So we use these API to record performance metrics so window.performance.now basically Gives the timestamp over there of what happened at that point of time and you can assign a mark to it using the second API You can collect all the marks that you that you created and what we do is basically send this to a backend service And then use that and query that to do our monitoring So This is all fine page by page you have your time to interactive metrics You have your meaningful paint metrics and all of these but how do you make sense of it at an at a team or org level? So we calculate something called a speed index for us We call it by something else, but it's equivalent to a speed index So in the speed index basically what factors inside it is that for every page We calculate a page index so which is basically So time to interactive is in terms of seconds or milliseconds So we try to convert that and convert that into a whole number that people can understand and using that page index We try to prioritize the pages that are most important to us in the application And we give it different weights and then we come come at a speed index that is relevant to us This is work pretty much well for us and when we set goals and stuff we set it based on the speed index Step 3 monitoring and alerting so this is like really really important if you are going to If you if you want to know what's happening in your users website So what do you measure? What do you monitor? You can monitor absolute numbers time to interactive like just see every day What's the time to interactive? You can measure trends across time like what was what was it yesterday? What was it on this when this bill got released and so on we do that So that we get to know which build actually caused a regression You can have stacked charts of Divided so if you have one time to interactive you can say how much network time it took and how much actual How much what was the first you can basically? divided into different stacks and Maybe that's useful to you Basically, whatever you want to monitor You are the owner of your website after all and I have found that different things are important in different pages for us For example, we have this We have this distribution of our ready for user as we call it across different person tile and People were experiencing Some slow slowness over there and we were able to actually correct that and push that down to make that graph more uniform And that helped us We had this so we created the stack chart across person tiles So each thing is like so the first one is the pace loading then how much time the skeleton took and how much time the view rendered with and so on so one of our one of our Optimizations reduced a lot of time in the in the 90th percentile here So I keep telling percentile percentile, right? So what is percentile percentile is basically if you calculate for your real users if you are calculating the time to interactive if you order them in increasing order and you pick the 90th percent User at that point whichever user whatever time to interactive that user had Then that's how you would look at percentile data. So you can you can have good Basically all your fastest pages will be in the lowest percentile and the slowest pages will be in the highest percentile So for us, this is really helpful as we want to help our slowest users and that generally results in a help of all of our Users averages are not very meaningful for us because it doesn't really translate to what the user is seeing Another point of contention while monitoring is to do synthetic or real user monitoring or rum as they call it So synthetic for us. So a story here is we rewrote a component Completely which kind of changed our page architecture and the whole time we did synthetic testing like we had the staging in instance and we thought it had the user specific data and we did Throughout the development cycle we did testing with that and but when we released to the real users we observe different regressions So for us with our variety of data and our variety of different configurations that is possible for a synthetic does not Only synthetic does not really work out but synthetic is what we have in control So we use real user monitoring heavily We have our we use the tool called Splunk Which basically allows us to do SQL queries on all our data and make the beautiful charts that I showed you earlier Yeah, so that's Other than this for alerting alerting has been really hard for us Like to establish a baseline at different percentiles and see whether it improved increased or not to get an alert We do have alerting in place But usually we are all very fatigued to look at it because it alerts at wrong times and things like that And that's something we are working to Get get it right within our team at least So that's monitoring and alerting Step four is how you will integrate all of this into your SDLC software development life cycle How do you make sure that your SDLC is set up to? To work with well good performance, right? But there are some prerequisites for this at least for me without these prerequisites our software development life cycle Wouldn't be set up a performance at all. So we have these robust practices in place Basically, whenever you find a performance issue, you need to change large parts of your code base It's not like fixing a bug for us at least and it's been the case wherever I work performance Usually requires a rethink in architecture and that means your code has to be changeable Like it it should be easy to refactor your code and that is possible if you have a good integration test bed Unit tests will go to the dogs whenever you try to refactor everything and integration test is your best bet Cypress is our tool and that's what we use extensively. We do continuous deployment To staging and staging dog fooding and production So as long as master is green because our test bed are good. We trust it and just push it to production So, but I think the winner in our process at least is feature flagged rollouts We use a service called launch darkly launch darkly and that allows us to roll out each and every feature percentage wise to our users Which is a huge win like we just have to turn off the feature flag to if we see any regressions beat performance or beat just bugs So with all this in place in our SDLC, how do we incorporate performance all the time? So I think heavily you will have to look at the performance while you're planning you so we are trying to drag Jira into becoming an SPA and And that means a lot of performance testing usually all of our pages are loaded refreshed newly every time and that's been And that's been Micro-optimized to try and make it better and push pulling that into an SPA requires extra thinking for us in the performance direction We do server side rendering that means writing universal code things has to work in the browser and the And the server So this means we are switching up state management libraries We are switching up how much of the tree we are walking to what all calls we are making and basically we are trying to find the The critical path of what needs to be shown to the user and that is That is excluding from feature development, right? These are things that we are doing only so that performance is better We do goal-setting for performance So even if it's not like even for every feature if you're not like I'll improve the performance We at least have a goal saying that you will not regress the performance And we discuss per budgets for the designer. This is the hardest part. So the designer wants a feature right and you you have to come up with the With the decision of whether it is really critical whether this feature needs to be at the beginning for the user and how much It will impact performance. You need to make these at least have these thoughts in in the planning phase During the development phase during development We have a cadence of performing QA demo at the end of every PR and QA demos criteria of done Will have profiling in it. So in the criteria of done, we will open the Chrome profiler I will sit with another developer. We will open the Chrome profiler and we look for anomalies We'll make the various interactions will record profile and see if something something we can catch and that has helped us like things like the Rerentering continuous re-renting that I showed you those things have been caught in QA demos themselves We do like I said, we do use synthetic monitoring So throughout the thing we are releasing to staging and running tests on that and seeing all our Time-to-interactive at least we aim that it should not increase We add new measurements new features new measurements and and we keep updating our speed index as per whatever new features we have Three release so this is a stage we go through Because we have launched our clay. So what we do basically is we release we release our feature to 1% of our users and Which is quite huge and we try to do real user monitoring with them and we try to find any Anomalies during that time and this this is basically where we spend a large amount of time like we find something here and go back into development and That's why I I say that real user monitoring is the winner here So once we are sure that we are not perform We are not having any regressions and things like that we move to the release stage and during the release stage basically there's a company-wide Everyday meeting that happens where whatever is being released gets discussed in that meeting and we have to show more rum monitoring in that So you have to show what monitors are in place What are the handlers in our in place and so on before releasing the feature? And we have alerts for all possible for possible edge cases because even though we did synthetic and real user monitoring There are still people in the 99th percentile who will be like I'm on this page for a hundred seconds or so on And most importantly we gather user feedback We have found that our speed index when it fluctuates our user feedback fluctuates Similarly, so that has been the motivator for all our performance work till now And this is really important for any new features we ask the user and sometimes it's a fatigue response But still we have gathered a lot of stuff that is useful for us We read all user feedback and then we iterate iterate and iterate we at the end of the thing We have a retro we see what went right what went wrong if something went wrong We add new steps to our process or we even remove steps sometimes But most importantly I feel we celebrate all the wins that we make with our performance There is always we always pop that champagne way There is a an update that goes through company via team wide or quite that Celebrates all the wins that we make with our performance. I think that's an important step in the cycle That people feel that because performance Work when you do performance work, there is a large amount of work for very less Return of investment But that is still the way to go in the end You you cannot have bigger changes without all the toilet behind the performance profiling So to recap How do you introduce performance culture into your team? You know your tools you measure everything But you monitor a few things you set up monitoring you have alerts around these things You have goals that these monitoring Reaches you integrate with your software development life cycle without this you do not have a performance culture And generally you celebrate when you are able to improve your page, right? Yeah, that's my top basically any 30 minutes correctly So that's my talk basically and I hope it helps you Do do work on performance and make faster websites. I'm sorry I couldn't give you much info on mobile because it's mostly we mostly work for the browser But yeah, that's about it. Thank you so much for listening