Core Web Vitals in the DevTools timeline

Key Takeaways

[Music] [Applause] [Music] hi everybody I'm Paul Lewis and I'm Philip Walton okay so we thought today what we do is we would talk about the core web vitals inside a dev tools now I know about the dev tools side in fact I implemented some of the core web vitals in side of dev tools but Phil you're more of the person that knows about the actual metrics where they came from and that kind of stuff right that's right I know a lot about the metrics I work on the chrome team working with some of the people that were helping to define the metrics and standardize them in browsers but I don't really know much about how they work in dev tools so Paul you're a great person for me to talk to here let's let's dive in and see what we can what we can find out okay so I guess our plan is to have a bit of a conversation to go back and forth we'll be diving in and our dev tools having a bit of a discussion about these metrics and just trying to kind of explore understand and share what's kind of going on there so I guess the first one that I was kind of thinking about when we were discussing this was LCP and FCP so there guess the first thing to do to kind of talk about is what are what are they like where do they come from you know these are both paint metrics so FCP is first content for paint its tan it represents the first point in time that the browser is able to paint any content on the screen and LCP is largest contentful paint and that represents the largest single text node or image element on the page and the idea between these two is that FCP represents like the first time the user sees something and an LCP represents when you know the main content of the page has painted I mean in general whatever the largest thing on the largest image or text node on the screen is generally the thing that the user is going to notice and so that kind of represents once the page is really loaded so I guess for a lot of people then the first thing they're going to think of certainly for the largest content for paint will be something like a hero element or something like that right yeah they can a big image at the top of their page for example absolutely okay right but it's not always that I'm guessing because you could be deep-linking into some content like further down the page and everything else yeah that's up so I okay I tell you what we'll do then let's take it I've got a page here actually I've got this page on web dev we perform it to tap open inside of dev tools and I guess the the goal here is going to be to show FCP and LCP in context and I have web dev open here on a page in the performance section around using image Sirians to optimize images so if you've not seen this content definitely worth a look it's a great art okay and we have yeah we have I'm DCI can deep link in to this section right Graham with the right and so this I guess would become a hero imagery and an interesting point to make here is that the hero image is not necessarily going to be above the fold like in this case you're loading a page halfway down have we scroll down the page and so LCP is always you know it's only going to consider elements that are actually visible to the user on the screen right great points so this is what's going to make this brilliant but interesting so what I'm going to do is I'm actually gonna going to go to fast three G so in the performance tab you can open the capture settings here I'm going to change just online oh it's a fast 3d so we're just going to switch to a slow down on the performance you see this little exclamation mark shows up saying Network throttling throttling is enabled and I'm gonna i'm actually gonna slow down the cpu just a little bit and you doing this so that we can see things you're doing this to simulate maybe a lower powered device or something like that correct yeah yeah I am but right now as well what I wanted to do is if I take a recording with things just slow down a little bit it might be easier to just to see what's going on because I happen to be somewhere in my house has actually a really good internet connection so I don't particularly see Network latency quite as much as you would in know the cases saying right if you're on a mobile device that so I just thought let's just try this and see what happens so I'm going to hit record I'm gonna hit command shift art to do a reload okay and I'm gonna stop and we can discuss what we see okay let me just wrap this up here now the first thing to notice I suppose would be the timings row here to have to remind ourselves what these are Dom content loaded this has been around forever hasn't it yeah but there is first paint first content for paint first meaningful paint which we could talk about it a little bit I suppose largest content for painting you can see this actually highlighted our screenshot here and then the load event now I could use the keys on the keyboard to come into a a little bit closer zoom in a little bit on this particular area of interest and you see here I suppose the first content for paint is presumably happening and then the largest content for paint is happening slightly later that's right now I think we can get a little bit more info about this because first non sinful paint is happening and then the largest content will paint which implies to me that the image is coming in after the initial page content so we're drawing something we're painting something and then we're painting the image after the fact so let's see we do that with screenshots on and we will record again and see what we get okay I'll stop there and hopefully they just lose this a little bit and we might see okay so roundabout fact they wonder if I can just bring this in a little bit further let me just see if I can drag that down throw this a little bit okay that might be as clear as this is gonna get I wonder yeah it is okay I think what we're gonna do we're going to make this a little bit clearer because what's happening is we're actually seeing the page content before I did the Refresh and then slightly after so I can do I can if I take this and I go to about blank this is actually a really interesting way to do this testing if you're ever curious about it record it from about blank so that you start without anything on Paige can that can make it easier to find your screenshot so I'm gonna and a paste in the URL here but not hit enter not go to that yet okay hit record go and now go there okay yeah hopefully that will make it a little easier to see what's going on okay so you see we've gone from here into the screenshots we see this we see the original page content the top of the page and then we're going down to our deep link just below that so my assumption is if we if we bring our zoom in here that around about here in fact we can just do this here yeah good you see we're just right on this line here where we go from nothing to something right nothing to something is exactly the point where we actually start to see this this the first register concept for paint coming in yes the first thing that the user sees but it's not the main thing that they wanted to see when they were when they were loading the page yeah in fact it's saying largest content for paint at this point is actually this piece of text now let's try it one more time from her just a really really dilated I wasn't going to go for slow 3G I'm gonna go to about blank again I'm gonna hit record and I'm gonna see what happens I feel like we're gonna see something reasonable here let's process that profile okay there we go this I think is starting to make more sense to me over here there we go okay Wow there we are first content for paint is here there okay and then much later OOP there comes our image okay which is slightly over to the right here and there so I can select that area and as from the based on the screenshots roughly there and I say that's the first content for paint and then if I select later on in the screenshots there I consider that's the largest concept for pick which is high imager okay that's nice that dip tool shows you exactly what element on the page is the largest contain absolutely I can't resist I know we're going to talk about layout shifts next but why I'll just jump the gun a little bit we actually have a layout shift showing up between first step content for paint and largest content for paint and I think based on this I think the reason is because we're going from no image to image and pushing the content down their terrain so I think we're seeing the page content move so my guess is if we were to go and find this image here in the elements panel we're going to see that it doesn't actually have yeah it doesn't have width and height attribute set yeah and I think that's basically causing this to happen so if you will come we're talking about layout shifts more in a second but the reason this page is shifting is because we have an image here that that loads when it loads loads asynchronously essentially and it when it's loaded it pushes the rest of the page content down if we added width and height attributes to this image we wouldn't see we wouldn't see that layout shift as I said we'll come back to that more anymore yeah that's a good general I guess best practice though just let everybody know always put width and height attributes on your images that way the browser can render the space that it needs it can it can allocate a space that it needs to render them before it actually finished loading loading the image so then you don't get that layout shipped exactly the other thing I think we should talk about felt before we move on is how to optimize for this particular situation so what would you suggest if somebody said I need to get first content for paint and largest content for paint and nearer the start that is taking too long to get to these numbers these numbers are too high do you have do you have a kind of go to list of things you would say to them yeah well definitely one thing that you you don't want to you know ever block I mean ideally you don't ever block painting on more than kind of one network request that initial Network request that you make ticket the page content you want to be able to paint at that point if you have additional requests like requests for fonts or style sheets or other things that are preventing you know the browser from painting that will just delay the time when that paint can happen and so you know I mean sometimes you know it depending upon the design you're working with you don't have a choice but in in an ideal world you would want to be able to paint right away and so looks like in this case on - I've got dev we are able to paint pretty quickly and then and that's why first paint is happening you know at the beginning and then the browser is loading this image and then largest content paint happens as soon as that image gets loaded in exactly yeah I think what we're actually also seeing here is the app CSS which is the main stylesheet and the fonts as well okay my guess is that they are going to be blocking based on that you can see that when I roll over them the network panel here saying highest which is the priority that's been assigned to the CSS and the reason I guess is because the CSS is going to be blocking the render which is what you were saying your own so that's why I think some people would inline that but I guess if we go ahead and take a quick look in our head and if we can find we could search for it but I'm gonna lick well link rel there's the stylesheet yeah you see there's a stylesheet for the fonts and right below it up dot CSS and so this would be a classic case of here's a stylesheet it's gonna block render because the browser Chrome is gonna take a look at that go well I need to wait and see what styles are before I render anything right absolutely so there can be something that we can sometimes take a look at say with blocky JavaScript right yeah we see that one sometimes I guess gets in the way can use something like differnece you sometimes hear this referred to as critical CSS where you identify just the CSS that is needed to layout the page not necessarily style all the components on your entire site and so you can inline just that CSS content in the head of your document and so then you're not blocking on an additional Network request in order to paint something on the page exactly Yeah right so that that was FCP and they'll sleep in as I say you you will find those on the timing's track here in dev tools okay some next up layout shifts now we talked about this very briefly just now yeah but with these two down here but where does he come from what what's the history of the layout shift and cumulative layout shifting I think I've also heard it called yes so the metric name cumulative layout shift or CLS for short is a metric that tries to capture the experience of visual stability on a page you probably everyone's probably had this you know experience where you go to a website and you go to tap on you know a button or something and right before you tap on it it shifts out from underneath you it's a very frustrating experience even if you're not interacting with the page just reading it if you know some images late loading image just pop in some ads pop in the content changes like a number of things gonna happen and you lose your place as you're reading and it's it's just not the greatest experience as a user from the user users point of view so cumulative layout shift is a metric that attempts to quantify that experience and so there's a couple pieces there but a layout shift is anytime an element on the page between one frame and the next frame its start position changes and so this will happen like in this case that we just saw an image loads in and it pushes the text below it down and so the image that the layout shift was not on the image the layout shift was on the text below the image that on the previous frame it had you know an x and y position of something and then on the next frame it was pushed lower and so its position change so it's a bit you know tough to explain but the CLS is a measure of both how much of the page content moved and also how far it moved and so if the entire page content shifts from being fully visible on the page to not visible at all that would be a CLS of one if that happened 20 times throughout the page life cycle that would be a CLS of 20 you know and then if it moves kind of half of the screen distance and the the image itself is only filling up half the screen that would be roughly you know 0.25 cos you can go read more about how to calculate CLS and whether the dev is a little bit too complicated to explain now but that gives you a sense it's a measure of kind of how much visible instability there is on the page okay so as we talked about before then we have this one layout shift here and so on price this is probably the better one of the two to actually demonstrate this and when you click on this and it's in this experience track if you don't get this experience track in dev tools it means that we didn't detect any layout shifts in that particular recording if you do find that it's there then you'll see that it's populated with these kind of records now you can click on this and it will take you off to the detailed information about CLS but what we try and do is we try and give you a sense of the score and the cumulative score of buzzwords about what's going on but we also try and highlight for you see you go going from an image here that's 11 by 11 and we show it as this very small overlay on the on the left hand side there to a much bigger 801 by 4 1 4 so one of the the items that I actually have to do in this area you can see actually have a few going on here which are profit probably other images that are being shifted you know as we as we make our way through and let me let me just one of the things I wanted to step back for a second and just talk about why somebody would do this I mean typically you'll you know you'll run lighthouse on a page or you'll go to search consoles new corbels report or the chrome user experience report and you'll see that you know you have layout shifting happening on your page and you might be wondering to yourself okay but I don't see it when I visit my page so where is this layout shifting happening and so then dev tools is a great place to debug that into load you know figure out which page on your site has layout shifting and then load it up in dev tools under the throttling conditions that you know Paul showed earlier and then you know look and see what dev tools was telling you is shifting because that's how you can figure out what's causing the layout shift and then you know you know what you need to do to fix it yeah there's more I have to do here to be clear I think one of the things that is missing from this which is actually available in the data I just need to plummet through is which elements are we talking about but I can show you that we've got these areas but we it does feel like we're missing a bit of information about exactly which elements it is like we do with the LCP we highlight the image that we're actually you know referring to here we should be able to do the same here so by the time this goes out and you're watching this give it a try in Chrome Canary because I might have been able to land the feature by there yeah I'm not making any promises but that would be good with it and just um yeah just as a kind of a quick point there there's often two pieces to a layout chef there's the there's the element that shifted and then there's the element that caused it to shift and so sometimes you know figuring out one or the other can be helpful in fixing because it looks like here that it's showing the image that came in but adding images so adding elements of the Dom doesn't in itself cause layout shift but if adding an element of the Dom moves the elements below it then that would cause a layout shift right because the the default size of this image looks to be 11 by 11 pixels to begin with and then when it when it gets populated with the actual pixel data it pushes down the rest of the page content which I guess justifies be the layout shift there yeah yeah okay so that's that's that you know if you've got like we said earlier if you put width and height on these things that will help but you can also have I mean let me show you this other one even on the Google home page this privacy reminder down here I take a recording here and I just refresh this page we're gonna see a layout shift here and similarly we've got this here which is going from down here and I presume there's some JavaScript or something like that that's looking to see whether the privacy reminder has been seen and if not it pushes that content on them and so again this is probably JavaScript based and you're gonna know in your own apps we know what's going on what is it third-party content is it your own JavaScript is throwing styles right and it's a case of digging into the specifics of your application to try and figure out exactly you know what's triggering now like what could be happening there in order to figure it out so that's just you know a couple of examples of the layout shifting that you can see yeah and just you know right what one thing to keep in mind is that in an ideal world you would have no layout shifts on your page but sometimes it's unavoidable and so the you know the threshold that we recommend you know folks stay below is is 0.1 and so it looks here that you know this layout shift is is quite a bit below that and so even though you know you still want to be at at at zero if you can as long as you're below 0.14 you know 75% of your users you're usually in good shape so you say 0.1 I guess that's like for page load because that's where a lot of these all of these metrics are aimed at page load right now right yeah so that's actually a really good point I'm glad to have it up CLS measures layout ships that happen during the entire lifecycle of the page from when you load the page until when you unload the page even if you leave the page open for you know days or weeks it does measure that entire time whereas here in dev tools you ran a trace and you got you saw the layout shift that happened during that trace and so in this particular case CLS was only measuring shifts for a small period of time it's important that developers keep that in mind because you know the layout the the actual metric definition is for the entire lifespan of the page so if you run a lighthouse trace or a webpagetest race or even in dev tools and you see a certain value and it's below 0.1 the threshold it just mentioned just keep in mind that you have to actually be measuring it the entire time you know that that's that's the the the metric the measure that counts is the entire life cycle of a page also I think in this area we should talk about perhaps the the metrics themselves as a bit of an evolving art I mean we have for example first meaningful paint up here but this isn't one of the metrics that we would mention say something like core where vitals and as so no metric as far as I'm aware for something like animation performance so that's true I guess my question to you what's going on there why have we got a metric here that we wouldn't refer to and why do we not yet have a metric for something that we might be interested in tracking what's the kind of history and story there yeah that's a good question so F and P are first meaningful paint if you remember from a previous you know trace that that you did Paul FOP was right next to FP FCP and then LCP was Lena later in the page load so what actually ended up happening was that oh yeah and it looks like that's that's the case here so yeah after a bunch of testing I mean F and P is essentially it's a different metric it has a different meaning than LCP and after a bunch of research we found out that FMP actually wasn't as accurate at predicting when the main you know what most people would consider to be the most important content of the page you know the most meaningful part of the page the metric itself has the word meaningful in the name but it turns out that LCP is actually a better predictor and so as we come up with metrics that are better at capturing the user experience will you know kind of deprecated older metrics and replace them with with newer metrics but you know we do recognize that that's happened a bunch over the years and I'm sure developers are getting tired of hearing new metrics announced all the time and so one of the things that we did with core web vitals with the web files initiative and specifically with core web idols is we're committing to you know only introducing metrics at most once a year for the the core set of web vitals and so developers are following along they can bring back you know give us a little bit of stability if they're building a business on these metrics or you know predictability if they just kind of don't want to have to you know always be following along with with the latest and so you know recently we announced LCP was one of the core Web vitals and an FMP was not one of the core one vitals and like over time that will probably be deprecated so you also bet also asked about animation performance this is definitely a metric that we're looking at for the future maybe you know in 2021 or 2022 so we know that the set of core web idols doesn't capture the entire you know the entire story of user experience and we're hoping that over time we can improve it and animation performance is definitely a metric that were adara of performance that we're exploring I think the last one that we talked about talking about if I gather right yep I think I did um did was first input first input delay which is not directly shown in dev tools so what is it's not sometimes called fi D right what is that and and why yes so first input delay or fit or F ID for short represents the time from when the user you know interacts with the page so taps on the screen or you know clicks a key a keyboard key to the point when the browser is able to respond to that input event so this can you might think that it's always going to be instantaneous like you you know you click on the screen and then something will happen but as users we kind of know that that's not the case oftentimes you know we've all had the experience of clicking on something or tapping on something and not having an instant response and so this can happen if you know there's a bunch of JavaScript running on the page maybe you have a large JavaScript file that the browser is currently parsing and executing and then so if at that exact time a user taps on the screen then the browser has to wait a little bit of time before it can respond to that input event and so f ID quantifies like that duration of time and you mentioned they it's not exposed directly in dev tools and the reason is because I'm assuming you know here you're the one who helped implement this but first input delay requires an input it requires a user and so you know in many lab scenarios there is no user and so you can't always measure first input delay that way but we have another metric called total blocking time that quantifies just that we do have yeah that's great and that quantifies how often the main thread how much of the main like how much time the main thread is blocked and main threat as I just mentioned contributes to you know the likelihood that a user will interact with the page but the browser won't be able to respond right away so you said that total blocking time is in dev tools can you show me where that is yes oh I see you there at the screen I have I have long tests over here and I yeah it is down there and it currently says it's unavailable and I'll talk about that more a little bit I've been working on that feature in fact today so I can tell you a little bit more about what's going on there too so what others I've come to web dev and I've cleared it and I'm just going to record and I'm gonna hit refresh and I don't expect here that I'm going to see any particular blocking time because I've got a first machine I'm on a good connection and yeah you can see right down to the bottom here we have total blocking time and it's currently set to zero millisecond so what that roughly translates to over here is when we zoom in on these top-level tasks which are on the main thread we have no task that goes over 50 milliseconds so 50 milliseconds is our threshold for hey this task is long and it's it's gonna contribute to the the blocking time right because what we want to do is we want to keep a track on on tasks that that go over 50 milliseconds because they're the ones that are most likely were the user to interact they're the ones that are most likely to prevent the browser from being able to respond in in an adequate amount of time right so we currently have no tasks block to blocking time is defined as any time greater than 50 milliseconds in a task so if a task is right forty nine milliseconds there's zero blocking time and if a task is 51 milliseconds there's one millisecond of blocking time and just out of curiosity some people asked why you know why 15 milliseconds what's the thinking behind that yeah so the answer is that the idea you might have heard of rail the rail performance model and you've heard often times people say you should always respond within 100 milliseconds of user input and so the question is why is 50 milliseconds to the blocking time and the idea there is that if you ever have if you keep all of your tasks below 50 milliseconds then there's never situation where two I can't both run within the 100 millisecond threshold and so that's kind of if people are wondering why that 50 millisecond time exists and why we chose that for the the magic number with total blocking time exactly and of course if you were doing an animation then your task time really should be under like 10 that's regular seconds so so we'd sort of it you got to be context aware the 50 milliseconds number is a it's a great number to have in mind especially for load performance but it does change depending on the context and whether you'll say animating or not now what as I said we have no tasks here that are running long and now I mean if I got a trace like this from somebody I would be very happy perfect I would say listen oh yeah I wouldn't complain at this at all but what I can do is I can least simulate a slower device like I did before over my capture settings I'm going to go to like a six time slowdown and I'm expecting that this 25 milliseconds here is going to run long so this is some JavaScript that's being evaluated so I'm going six times slow down I'm gonna hit record and I'm gonna refresh again okay I want to do two things I'm gonna stop the recording a little bit earlier than I did last time but the first thing to notice here is our tests are now longer because of the slowdown and if i zoom in on this task it's 176 mm 0.5 5 milliseconds and you can city it's qualified for being a long task goodbye once a hundred and twenty six point five five milliseconds okay so what we do is after the 50 millisecond point on this task we do this candy striping here and we also pop a red triangle up into the top right hand corner so that when you're looking at a glance like zoomed out you get a sense of just how many of your tasks are running a bit long I think almost universally here the ones that are running long are JavaScript based yeah so if you if you again you know are looking at the chrome user experience report or search consoles or web files report and you see that you have a first input delay that's higher than you would have expected for a certain page I think this is a great example of how you would go about debugging that so like you might you know be on your fast MacBook Pro laptop or something and not see any long tasks but if you go into dev tools and you throttle the CPU and then you start seeing a bunch of long tests like shown here and that would help explain why because if a user tried to interact with the page during one of these long tests the browser would not be able to respond it would have to wait until the task completed before it could run those event handlers yes supporting and Singh unavailable there in the bottom in dev tools what does what does that mean yeah so sometimes we do say unavailable the reason is we wait for blink to tell us when it's happy for us to declare the page interactive and at that point it tells us how much blocking time it measured and so sometimes if the trace isn't long enough we don't actually get that information so what I've been working on actually recently is adding in an estimate which is essentially counting up the amount of candy striping that we're getting right in those top-level records so that we can at least give you an estimate even if blink hasn't given us the kind of official answer so hopefully you should see that in Chrome Canary them soon yeah that makes sense because yeah total blocking time is technically the definition is the amount of blocking time between first content for paint and time to interactive and so it makes sense that dev tools would wait until the browser is interactive but yeah that does seem like a good feature to just give like in an unofficial total when it's not interactive yeah exactly so now we've talked about FCP LCP layout shifting and long tasks and if ID or fit uh yeah if I was a developer who wanted to know more about these things as well as playing within dev tools where would I go and get more information that's a great question you can go to web dev slash vitals and that will have you know all the information about the definitions of the metrics links to guides and how to optimize for them you know links to more information about all the tools that support them and everything like that so definitely the best place is to go to web dev slash vitals [Music] [Applause] [Music]