Critical rendering path - Crash course on web performance (Fluent 2013)

okay so we've talked about the network hopefully that gives you some some background for things to look out for things you could look forward to in the future like hp-200 and other things now let's talk about this concept of a critical rendering path so the idea behind the critical rendering path is there a certain sequence of events that needs to happen in the browser before we can paint something to the screen right put some pixels on the page or on the on the screen and effectively this is the sequence that happens and we're going to go through it and try to understand what are the bottlenecks along the way so first of all what's so critical about the critical rendering path right let's start with a very simple example this is a five line HTML file and a CSS stylesheet that I want to render on a page right so all I have here is a title called performance I am embedding a reference to a stylesheet and external stylesheet and I'm just printing hello world and my stylesheet just contains these two rules so if you actually if you pay attention here my span is actually set to display:none right so in theory when we when the browser actually renders this it should just say hello all right nice and simple this should be rendering in like nanoseconds right everything's nice and optimized here well not so fast so first of all let's start from beginning right we look recall the earlier slide when we're transferring a tiny little 20 kilobyte file right so we're sending this data in chunks so just for the sake of an example let's say that we sent we get the first part of the HTML data right so we send the request we get the first packet and it just contains the stuff here at the top which is doctype meta and title performance so it comes in off the network we get partial HTML of this entire file and we can start constructing the Dom or the the document object model of this page and this part is important right so at this point the screen is blank because we haven't received the full HTML and the important part about the parsing in the construction of the DOM is actually done incrementally which is to say we start with you know bytes on the wire the bytes come in we interpret them as characters and then the the browser starts creating tokens out of the string right so it looks at the string and says okay there's a P tag there's a hello string a start tag for span and all the rest it creates nodes out of it and then it connects these nodes into this tree here right and basically what the html5 specification provides is a specific algorithm for how you go from the top which is you know a text string to a tree that looks like this right so the html5 specification actually gives us a very concrete sequence of steps to say this how the tree should look like at the end this is important because prior to html5 there was no size specification which is why there were so many differences between different browsers like we would take the same HTML and we would give you a different tree at the end just like what happened there right so this is one of the great things about html5 or finally have a spec for this thing great so we're constructing this stuff now let's say we got the second packet right so now we have a reference we discovered the reference to the link to the link tag or the stylesheet and immediately the browser is going to send that HP request it says well okay does this user is asking me for the stylesheet let me dispatch that request on a network in the meantime I can proceed and continue to parse the HTML and construct the Dom right so at this point we've actually finished right this is the end of the HTML file we have the HTML we've parsed the Dom we have this object model but nothing is on the screen yet because we don't have the CSS yet right what would happen if we rendered the Dom without the CSS well you would get an ugly unstyled page right which is not a nice experience so this is known as a flash of unstyled content right so basically the browser is just at this point we just block and we say look until we have all of the style information we can't put anything on the screen so in the meantime we're waiting for the network we're waiting for this year for the request for the stylesheet next you know our two line stylesheet actually arrives in two packets and I'm kind of using this as a silly example but you can imagine a larger style sheet which has many different styles and we got the first line here which is the P tag notice that unlike the construction of the Dom we can't actually ours this the CSS incrementally because of how the CSS is specified right we have these cascading rules we need to have the entire file before we can evaluate it we can't incrementally build it up right so if this if this takes us 200 milliseconds to fetch we have to wait for 200 milliseconds for the entire CSS file to arrive which is also you know this kind of an important takeaway right here is if you have one giant stylesheet even if you split it into multiple stylesheet style sheets that may be beneficial because we can construct those or evaluate those incrementally right so concatenate everything into a style that CSS may not be a good rule especially in mobile so great finally we got our last line we can construct the CSS object model right so now we have two trees we have the Dom object model and we have the CSS object model except that we still can't paint anything right so the screen is still blank next what happens is we actually take these two trees the CSS object model and the Dom object model and we build a new hybrid tree out of it right so for example here we have our body tag right we have the P the paragraph tag with hello and then there's our span and our span tag right which is the CSS rule that says this plane on gets applied to this guy right here and what we get at the end is a thing called the render tree and notice that there's something missing from the render tree notably the span tag is missing right so what we've done here is we saying like look if it's not going to be displayed on the screen there's no point for me to like spend the CPU cycles to render this thing only then to hide it right so elements that are display:none are just not part of the render tree right so at this point we've we're taking these two trees and we created the render tree notice that the screen is still blank right this is all work that's happening within the browser and in fact there's not just one render tree this is like not a million but whole bunch of render trees out there and some so why do we need this well certain elements may have special implementation details for example a video tag right a video tag kind of has its own layer and it's in its own priority where it may be hardware accelerated or GPU backed so we have kind of these different trees that are being balanced and they're all need to be synchronized between each other so this is just to illustrate that there is you know there's a relationship between all of these so the idea of the critical rendering path is exactly this right what we have to go on gone through here is we got bits off the wire we've constructed the Dom we've asked for the CSS we've constructed the CSS object model we've built the render tree in theory now we have all the information that we need to start putting something on the screen painting pixels except there's also the layout phase and paint so what is layout and paint but before we even get there I guess a couple of takeaways so hTML is parsed incrementally what does this tell us well it actually means that if you can you should be delivering the HTML incrementally to the browser right so there's here's two different strategies that your application server could use you could generate the entire response let's say you know wait for 100 milliseconds to generate the entire index.html file and then ship it all at once at the end that's one strategy and the other strategy is to say well okay great I've got everything up to like half of the page now so I'm going to flush that to the user and I'm going to feed you the next part of the page after that the second strategy is actually much better because we're parsing the HTML incrementally which means that we can discover the the CSS stylesheet much quicker so a fun example is our Google search pages so what happens so we want to make the search pages really fast right so we have this nifty little trick where you send us a packet with a search query right and before we even understand what the search query is we immediately send you the header response of the page which is like you know all of the search pages have the same header so we don't even know what you're asking for but just like here's a header start fetch start parsing HTML start fetching the CSS or any other resources and then once we sent that data we actually look at the query in Lex ok so what are you asking for search for fluent okay let us query the search index build the actual result page and then deliver all the rest right so it can progressively fill this in so you know kind of this is a low-level example this but this is something that you can leverage the other important takeaway here is rendering is blocked on CSS so if you're delivering a lot of CSS or splitting it between different files you can you can use different strategies but you have to we have to have all the CSS right this is before we put anything on the screen so CSS is truly critical if you want to have a fast loading page you know have visual output so you want to get the CSS down to the user as quickly as possible sometimes that may mean inlining some of the styles into your into your page sometimes it may mean like hey I have a giant stylesheet and I only need 50 Styles out of 500 on the specific page can I deliver just those 50 and then load the others later after the fact because otherwise you're just blocking the entire rendering waiting for those other 450 on you styles and we'll see an example of that in a second but you know this is kind of a cute example five line HTML file but didn't we just forget something which is critical to most of the web apps there's this guy called JavaScript our friend and foe so our friend because javascript is truly what enables the web to be what it is today right it's dynamic it responds to your input it does everything that we need and allows us to script all these applications but actually makes the story much much more complicated for example JavaScript can query the Dom and you can also query the CSS object model right you can ask for like what's the style of this element or let me grab this element let me change the style of it you know what I'm going to add a new Dom element with a new style on it all right this is how we build these apps but it actually makes the performance story much more complicated so here's an example right with JavaScript we can be clever and we can say look I've got this string but I don't care I'm going to execute a JavaScript I'm going to execute the snippet which is I'm going to write into the actual HTML markup right document that right I'm going to pass it a string or what it can be an HTML element an arbitrary piece of something and just write this into the Dom right so why is this a problem well recall that we're parsing the HTML incrementally and then let's say there's a script tag right right in the middle that says I don't know awesome script GS when we execute that awesome script you can actually inside of that script say well I'm going to write a bunch of new HTML right below my current script tag so whenever we discover this tag the script tag we say look we don't know what you're going to do next because you could be changing everything that comes after the fact so we're going to stop the world right now I'm going to wait until we fetch the JavaScript code executed and only then can we proceed to parse the HTML and the rest so it literally blocks both the Dom construction and everything else so we have to fetch the JavaScript and we have to execute it before we can proceed right so putting a JavaScript tag at the top of your file will just basically block you on the network until we fetch that file which is why you know if you've ever come across advice of put your CSS at the top and JavaScript at the bottom well now you know why because putting your CSS at the top means that we discover it early and if we discover it early we can fetch it quicker and that unblocks rendering putting your JavaScript at the bottom means that you know you will still block but hopefully by that point we've already constructed most of the page so you're not blocking much right so it's still kind of a not a great outcome we still have to block the page but that's the reason that rule exists also you know performance talk is complete without talking about asynchronous scripts here's an example so this is just an example with the +1 widget right oftentimes and this is not just for social widgets for any JavaScript Google Analytics all the rest you can have two variants of this you can say look I'm going to include the script tag and it's going to be the +1 and it will add the functionality that I need in my page or I'm going to use this kind of crazy-looking asynchronous function thing at the bottom it looks scary right like I'm not sure if that's even going to work should I use that or should I use a simple one I understand the top one the problem with the top one is it will block the rendering of the page so whenever you put it we have to stop the parser fetch that file execute it and only then can we proceed with the asynchronous version which is the kind of this pattern here that can be applied to any JavaScript code this will fetch the script asynchronously right so we don't have to block the parsing and construction of the page another interesting feature that we have and it's actually well supported across all the different browsers is this async keyword so the idea here is you know here here's the case that we've just described right we're parsing document everything's good and then we encounter this tag here which is file AGS at this point we need to go out and fetch the file right so this is the blue line here which is we add some extra latency Network latency to fetch the file we parse the JavaScript and then we execute the JavaScript and only then can we proceed to build the actual page continue building the actual page if you add the async keyword the async keyword is basically a promise like it's it's a handshake that you give us and say look I'm not gonna I promise I'm not going to dock right and that keyword allows us to then say okay fine we won't block the construction of the Dom we will continue to we'll start the download we will start downloading the JavaScript and we'll just execute it whenever it's done right because you promised us that you're not going to just like willy-nilly modify all the HTML markup on the page right so if you can you should use this tag on your script and that will certainly make performance much better because we don't have to block in the network here so we've covered this already but here's an example right a very simple example I grabbed a reference to some element on a page I can query its style which is basically going to the CSS object model and I'm extracting the width right and I can also update the width right so I can do this from JavaScript I'm basically I'm modifying the CSS and the object Dom object model variables and here I'm just writing a simple string into the document directly so first of all you don't want to be doing document to start but the important takeaway here is javascript can block both the Dom construction and CSS right so think of it this way recall that we couldn't paint anything until we had the CSS now what if your JavaScript also asked for a CSS property right so JavaScript can block on CSS and now you have this kind of funny relationship graph where you say okay I started constructing the document I'm fetching the CSS I'm going to try and execute some JavaScript at this point except I can't because you may be querying for CSS alright so once again you want to get the CSS down to the user as soon as possible you want to avoid having synchronous JavaScript files as well so putting it all together right streamed HTML this allows us to incremental e construct the page you want to get the CSS down to the users as soon as possible and avoid dock write or use async scripts so that'll help us with the initial render speed up the initial render the page or at least it it removes some of the speed bumps along the way right that are inherent on a lot of different pages so let's look at an actual example actually before we get to the example let's say we wanted to deliver a great experience over loop we want to break the Mobile break the one-second mobile barrier right we want to deliver pages within one second as we saw previously the just the latency overhead of a 3G or 4G network is about 800 milliseconds right and higher on a 3G network for 4G we were down into kind of 400 500 millisecond territory so we don't have a lot of time what does that tell us well the server processing time must be really fast like ideally below 100 milliseconds right if you're taking hundreds of milliseconds or seconds that's definitely an area that you should be optimizing for specifically for mobile and if you want to hit this goal then we fetched all the resources you know your server response time is fast we also need to make sure that we allocate some time for the brow to do all this work right we just described a lot of us like constructing the Dom cssm render tree and all the rest there's a lot of overhead associated with that to paint that so you need to allocate some time on top of it within our one-second budget for this extra rendering time so you know some very simple implications out of this specifically for mobile like if you want to break the 1 second barrier we have to inline request we have to inline resources right and you know just earlier I was talking about HP 2 and houses an anti-pattern yeah and you know I think there's some a lot of interesting room for head scratching for how do we solve this problem right maybe we can use server push to deliver instead of inlining but basically what this tells us is if you want to deliver the page within one second we can't afford to make extra HP requests because just the latency overhead of that first request is basically a second so we need to deliver as much data as much useful data as we can within that first second and that's how we unblock the rendering so if we want to have fast mumble sites that's what we need to do and then I'm not saying that you need to render everything within one second I'm just saying you need to render something useful to the user within one second right maybe it's the head of the page maybe it's the basic text and then after that you can continue and progressively load the rest right deferral the other JavaScript you know you don't need your social widgets and other things to fire immediately within the first 100 milliseconds your analytics beacons and other things all those things can fire afterwards so here's an example a slightly more complicated but nonetheless very simple one right we have simple HTML file with a stylesheet reference and a script reference and I can tell you right now that this page on a 3G phone as simple as this pages on a 3G network this will not likely render in one second within one second right the only and the reason for that is you know we need to make an extra HP request so there's a round-trip to get the HTML file hopefully we're streaming this HTML back but then we need to make the sales rate request and we need to fetch the JavaScript code and the JavaScript code will block the construction of the Dom later right so all of these things are working against us how do we work around it well we have to start in line things right you say okay I am going to inline my critical CSS Styles and what's critical CSS Styles well maybe once again it's like the header of your page or something meaningful like even the loading bar right that's going to come directly in the page and yes there's a cost trade-off here right what I'm saying is you're inflating the size of the page by inlining this potentially across all of your different pages but maybe that's not a problem for your site right you want to isolate the critical CSS and have that as part of the initial page same thing happens for scripts ideally actually you don't even have scripts at the top right now it's true that a lot of applications require JavaScript today or pages I should say require JavaScript but it was also true that a lot of the JavaScript is enhancing the experience right so you're loading jQuery to add on click handlers you're adding social widgets you're adding interactivity but that doesn't block us from first getting the content rendered right and then loading and adding in those things incrementally afterwards so most of the time you can safely at least my experience you can safely defer most of your code until the first render happens and then add that functionality this may not be true for your single page app experience because your single page app is the one rendering the entire application and in that case you know I I anticipated this question like how do we make this work for one page app the question the answer is like tough lock right because chances are you're going to be fetching a JavaScript file with a lot of templates and CSS and other things and in short you probably won't be able to hit this goal although you know there's there's maybe there's some tricks that you can use with similar techniques like inlining and all the rest and then just you know at the bottom here I'm showing you that you know we can just create a simple function to say load this after the first paint right so get it out of the critical path you don't need all the JavaScript immediately so how do you even identify something like credit like what the heck is critical CSS one nice tool that you can use is if you open up your chrome dev tools you can actually go into the audits panel and within audits you can actually run a performance audit and it will look at you know the number of different things on your page but one of the rules it looks at is actually the CSS that is being used on the page so here you can see that when I ran this example there was about 55 kilobytes of CSS on this page oh sorry yes 55 kilobytes of the CSS on this page but 60 percent of it was not being used right so this is shared styles across many different pages and perhaps we can somehow split the critical and non-critical CSS right so some of these files probably didn't need to be loaded initially right they could be loaded after the fact and that would accelerate the rendering performance another example and I'm not sure if Wi-Fi is acting any better now if not we have some screenshots yay okay so another interesting tool that we have is our pay speed insights tool of course you can look at your waterfall within your chrome dev tools or Firefox tools and all the rest this is just kind of the same same view but on the web right and yes it's it's tiny but we're looking at Guardian Co UK and this is the like this all the files that we need to load this page right so it's it's big like there's over 100 different files there's CSS there's JavaScript and all the rest but not all of these files are required for us to first render the page right so this is why we have this highlight critical path button and look what happens when I click on it right that entire page the entire waterfall collapses down it's basically this sequence here and what the sequence tells us is yes you have 80 plus files on your page images and other things but these are the files that are critical for us to actually get something visible right like here's the sequence of JavaScript CSS files and other things that we need so this is a great way to kind of look at your own site or any site for that matter and figure out what does that sequence like what's currently blocking my performance so let me go back and actually show you some examples here so when I grab this snapshot earlier first of all when I went to garden yet issued a redirect right which on mobile of course is extremely expensive right we just said that we just won a spear Quest is going to take us about a second now if you redirect me from you know ww Guardian co uk to MDOT Guardian co uk that's a new host name which means the new xia nslookup it means a new TCP connection it means basically they're starting all over right right from the beginning and in this case it's 300 milliseconds and that's on a very fast network so redirects on mobile ideally the number is zero right you should avoid them whenever you can and then after that we can start looking at you know how is this page being constructed so you can see that a guardian is actually doing a good job like their shipping and so the green bars here are the CSS files so they are in fact putting the CSS at the top which is good exactly what you want but then later they start loading JavaScript files right and so here the looking are they're loading the jQuery min plus some other plugins so far so good except then they encounter the they have I guess their own show ads script and the show ad script issues a document right to write the Google ad code right and if you recall our earlier discussion that's definitely an anti-pattern right because this will block all of the rendering and not only that but because this code gets written as part of the script we can't discover it early right so the document parser is smart in a sense that it can actually look ahead a little bit and say like hey are you going to be asking for this image file right I'll look ahead and just start our request with document that right we can't do that right we have to wait until you're right into the document and only then can we dispatch the request so there's this is why there's this really high amount of latency here and then later there's just actually some really long running JavaScript on this page I didn't really dig into as to why but a good opportunity to profile your JavaScript right here no let's keep that so what that showed you there is the idea of a critical path right and certain things that you can do to optimize the rendering part of it CSS DOM and JavaScript once we've loaded the page right so we've gotten to the first paint finally hopefully within one second once that's happened we enter a new basically phase in the lifecycle of the page which is the in app performance right now we need to sit and just render the pixels and react to user input and hopefully we're doing this at 60 frames per second so same pipeline except now we're running in the loop right your javascript is likely what's triggering events or maybe it's the user triggering events right a scroll event or clicking a button or clicking in a form or doing one of these things and each one of these events is going to trigger a couple of different things within the browser you can trigger a style recalculation it can trigger a layout or a paint update and we'll talk about each each and every one of these so as I said performance in this phase is 60 frames per second and you know this may sound a little funny it's like look I'm not building a game here I'm just building a webpage right like what gives 60 frames per second well it turns out turns out that it actually matters so just recently Facebook shared some interesting an interesting story where they intentionally slowed down their timeline from 60 frames per second so when you scroll your timeline right they slowed it down from 60 frames to 30% sorry 30 frames per second and they found out the engagement of users with the timeline dropped meaning they viewed the fewer stories they scrolled didn't scroll as far etcetera so kind of that extra jank if you will or the skipped frames literally translated to fewer fewer engagement less engagement from the user and if you do the math like what 60 frames per second right we have one second thousand milliseconds divided by 60 frames per second that means we have a budget per frame of 16 milliseconds which frankly is not a lot of time right so 616 milliseconds so what's a frame we need to render 60 frames per second right so that's this line at the top here and each frame has 60 milliseconds and there's a lot of things that we may need to do within each one of these frames first of all your application code needs to run so let's say I click on a button right and there's a handler associated with that button so you need to process that input and do whatever that you need to do but then after that you know based on whatever your code did I may need to as a browser I may need to trigger a style recalculation right so let's say I click on the button and you're trying to open a new window right that made a reflow the Dom that may create a lot of JavaScript garbage and I may need to update the actual pixels on the screen so it doesn't mean that you know I have steps here they don't necessarily happen in this order and you know GC doesn't always happen that you know in the middle and layout and paint and in fact you know that's the ideal case where your code runs and then we do a little bit of cleanup at the end and we paint the pixels that is the best case scenario we'll see why this is often not the case and why it's a performance problem so what happens if we can't finish the frame in 60 milliseconds let's say I have a long-running function right the user clicks on a button and I I don't know I'm trying to compute PI I don't know right so some expensive function and if we can't finish it in 16 milliseconds we we cross over that budget basically we just skip a frame right so let's say it took 17 milliseconds great we the browser does some cleanup after that but then we wait until the next paint which is 16 milliseconds after that right so we're basically we have these intervals fixed intervals within a browser we say we're going to paint updates to the screen at these fixed intervals or that's the vsync interval if you want if you want and if you just happen to cross one of these thresholds we'll just wait for the next one so if your code consistently takes 20 milliseconds to run we will paint at 30 frames per second if your code takes more than 32 seconds to run right you can do the math right so it's not like we don't we don't really have like you finish your code and we paint we have these specific V sinks that you have to hit in order to deliver consistent experience and a dropped frame and it is what we lovingly call as jank in the browser so the takeaway here is whatever code you need to run in order to deliver 60 frames-per-second it needs to run within 16 milliseconds in fact it needs to run much quicker than 16 milliseconds because the browser also needs to do a lot of extra work right like you've you've done your stuff now we need to do our stuff which is we may need to update the Styles the Dom the painting everything else and this cost is of course variable right like 60 millisecond sounds like an absolute term it's not because 60 milliseconds of CPU time on a mobile device is completely different than 60 milliseconds of CPU time on a beefy desktop right so as a rule of thumb you probably want to aim like you're developing it on your laptop you probably want to aim to complete all of your work within 10 milliseconds right that gives us kind of enough of a buffer and hopefully even less much less right but 10 milliseconds kind of like that barrier where if you're not hitting that then you're definitely dropping frames on mobile and the important thing here is if your code takes let's say 100 milliseconds to run we can't interrupt it we can't interrupt it and say like ok let's let's paint an intermediate frame whatever that means if you run 400 milliseconds 200 milliseconds it just blocks right so if you ever had the experience of for example you come to a site you start scrolling and it's kind of like it's it's janky for like I'm not sure if that's the right word here but like it just skips right that's what happens you're probably firing some JavaScript code which runs in the background we can't update the screen we can't scroll the screen because the JavaScript code is taking so much time so we're dropping frames and that's why you get that slow experience all right so also frequently you know before I was aware of this I would come to a site which was put a lot of JavaScript handlers usually like an on scroll handler right because they would attach it to say like I'm going to drag this element as you scroll down the page and it would be very expensive and then you're scrolling and it's like it's very slow you're like oh my god my computer slow and I need to close Photoshop and I need a new laptop right and then you profile your code you're like actually no no that's that's not the problem a laptop won't help it's just the site is really slow or the JavaScript is taking so much time so here's an example this was actually a screenshot that I took a few months back on a very popular web destination right so lots and lots of users and what you can see here is this is directly from chrome if you go into timeline and you start recording we will actually show you how much so each one of these bars is effectively a frame right and how much time the frame took to render the yellow bars show you the JavaScript execution so we can see here is an event a scroll event has fired and there is a long-running JavaScript function after that in fact in this case this function took 46 milliseconds so because it took 46 milliseconds we dropped three frames right there right so we're not delivering 60 frames per second in this case for sure and even worse this funked or this implementation I'm scrolling the page it's firing the event scroll on every single every single time and this javascript function runs every single time event fires so in fact within this frame we did the same work twice which is useless if you think about it right what you want to do is you want to register the fact that an event has happened within that one frame handle at once and then defer any work until after right so it's a very common problem for a lot of sites on the web today and something that we need to fix so a simple way to fix it is if you guys are not familiar you can use the request animation frame callback which basically says call me every time a new frame starts right and the browser just calls your function so what you want to do is you want to register the scroll events put them in a queue and then when the requests are the RAF callback fires you say okay I have some outstanding things that I need to handle let me handle them and then I'll defer all the work until the next frame similarly you know if you do have a long-running function maybe you can split it right maybe you can actually say well I'm going to do this part of the work now but then I'm going to yield control such that I can update the browser the browser can update the screen and then I can continue running it right so it definitely requires a bit more work on your part but it's definitely worth looking at because rendering performance definitely matters and you know at this point of course it helps to talk about profiling your JavaScript code chrome provides a couple of good tools for this in fact we actually provide not one but two different profilers we have a structural a sampling profiler and what the heck does it even mean John and myself actually did a full one-hour episode on the difference between structural and sampling profilers and why would you would need either one I'll give you a very brief version but if you want you know if you think JavaScript performance is your bottle I could definitely encourage you to check out the full video so the difference is if you open your dev tools and you go into your profiler right and you run the JavaScript CPU profiler basically the way it works is your code runs we pause every let's say hundred milliseconds and we just look at what functions are executing right and then record that we can see we let your code run and then we pause examine the stack and basically it's a sampling profiler which may or may not be the right tool to find the problem in your code right sometimes it may capture the exact problem like if you have a really expensive function and you're always blocked in it great sampling profiler will identify it very quickly and that's probably the tool you want to start with but the structural profiling actually allows you to go deeper like instead of saying like we're going to sample we're actually saying like here here are the points that we want to checkpoint right any one we measure the time taking between between these two points and how many times we've executed so for to use that you need to use the chrome tracing functionality and the way this would work is laying your JavaScript code you could actually annotate the specific work that you're doing so for example a console dot time a and then time ents you're basically marking specific intervals in your code to say I'm going to execute some work here and I want you to track this work right and then once you visualize it you can actually you kind of get this graph where you say well I was processing a data item one data item two and then data item for some reason took up a bit longer than all the other stuff and because this is using Chrome tracing and this is a pretty low-level look at what's happening in a browser you also get an insight into things like what was the v8 function that was being executed or when did the GC happen or what was the rendering thread doing at this time as well so you know there's a lot of information hidden there and it can be a little bit daunting to start with the first time you open Chrome tracing so if you're not familiar with it I recommend they check out the video because we talked about some specific tips for how to navigate chrome tracing it's it's not exactly the most user-friendly UIL I'll give you that but we're working on it of course garbage also happens right so we're running JavaScript code we're creating downloads we're creating other things we're allocating objects sometimes we basically need to pause and just collect the garbage and you know garbage is okay that's that's fine but sometimes it is a model like if you're running for example if you're building an applique you know even a pause for of 20 milliseconds mean for collecting garbage means that you've dropped the frame right of animation and that will result in not the best experience for the user so chrome also provides good tools to track this down so if you go into the timeline same thing you record a trace you start interacting with your application right you hit record start scrolling your page playing a game what have you what we'll show you is the growth of the allocated memory and also how many event listeners or downloads you have allocated in your page and then of course you can you know tie that back to like I was doing this specific action the number of dumb notes has increased and it did not go down after that so you can look at this graph here and say okay well you know clearly I'm linking memory we also provide some useful tools for to identify differences between different stages of your applications so for example you want to start playing a game you know you've done certain actions how do you know what the difference is so let's actually take a look here so this is just an example in our documentation code and what it's doing is it's a very simple example kind of cute example of it just going to create a whole bunch of objects right so let me open dev tools I'm going to go into timeline or profiles rather hello let's try that again so profiles I'm going to take the heap snapshot so I haven't noticed that I haven't done anything on a page right it's kind of like my baseline I just loaded a page right so I'm going to take a snapshot of everything that's in memory right now then it's taking a little while it's a big heap and at this point I'm going to click this action button and I guess I have a few things enabled here that I'll just disable for now so I'm going to click the action button right so it's just an example like nothing really happens but what's happening in the background is that I'm running this JavaScript code which just generates a whole bunch of objects and then it leads a whole bunch of objects right so now I've done something on my application I'm going to go back and I'm going to take another snapshot and once again it's going to run through and gather all the data you

Channel: Ilya Grigorik

Views: 33,158

Rating: 4.9512939 out of 5

Keywords: web performance, rendering, performance, chrome, javascript

Id: PkOBnYxqj3k

Length: 41min 10sec (2470 seconds)

Published: Fri Jul 12 2013