 Yeah, yeah, all right, so we have like I'm Paul Lewis you might have met me Paul Irish And we've talked we've been hearing a little bit about rail We just want to spend a moment to just like focus on it make sure it's all covered Yes, and just give the give the deep dive on it. Yeah, and I want to start off by just Discussing like performance in the way that we think about it like Oftentimes we consider as kind of this linear relationship between like the faster it is The better it is and this is you know generally true and there's a lot of academic research and a lot of like You know metrics and numbers from industry that validate this and say that yes actually conversion goes up revenue goes up All these things are great But we kind of think of it is like this like straight line right and I'm not really sure but like you know Because at certain points there's certain things, you know if you're on some experience and and it's just like terribly slow And you're like come on, you know you quit like I quit you quit It's just you have to right it gets a little bit better and then you're like, okay sure. Yeah, I'll put up with it Pass that even better and like yeah, I'm happy It's beautiful. It's smooth. It's chill But if we like look at it as like these like break it up into these quartiles, I guess Maybe the line is a little bit more like this it might be a little bit more like we start out and In the front actually, it's just like it's literally too slow like From from terrible to like pretty terrible. It's just still not really satisfying the user Up at the top, you know very high performance like changing the page load from I don't know from being a second long to being Like a half second long like both are pretty much great and it might be incredibly hard So the ROI of development there is that's important That middle area, this is like the sweet spot, right? You know, this is like everything is good I put in the right amount of effort users are happy. It's smooth. It's chill And I do feel like a lot of times like we kind of end up started, you know, we start here and We kind of want to figure out where it is that we go But we need to figure out like What what it is and right now, you know, this is the two slow thing. Yeah, which I think I mean Yeah, you want to get from too slow to where what do you call it chill chill? Yeah, it's a very you was a good thing It's a bit. Well, yeah, it is for you. Of course. Yeah. Yeah So but too slow itself like is I don't like to slow. I don't know doesn't feel good. So, um, I think the question Why I wanted to ask this like is 50 milliseconds too slow Just kind of have this question in your mind as we kind of go through it's like well 50 It is it is just what well, I guess I mean, you know what's coming up. So it's true True 50 milliseconds isn't too slow Well, look at it this way, right? If you're doing some page load like you're loading the Google store or something like that 50 milliseconds here is not a big deal, right? Because you know, it's probably gonna take a second or two There's a lot of stuff going on But let's say you are scrolling the store, right? 50 milliseconds here, you're gonna feel that a lot more you're much more likely to introduce jang Exactly well, let's say you're doing something with web GL. Oh, I know this is so pretty. Oh, yes Jame well done. Well done. Jame. It's good. It is one of the nicest things I've seen You know another 50 milliseconds here. You're gonna feel that one too, right? What it really comes down to is that the user context matters What the user is doing is actually the thing that's going to define whether it feels too slow or whether it feels chill Hmm. I like it. Yeah, good. All right. I think that's kind of the way we've been thinking about this like performance Has had a lot of ambiguity and we felt it on the Chrome team We we've optimized, you know for things like benchmarks and Kraken and Jermeo and octane and that's cool at all but like Not really satisfied with that We were thinking about a better way of modeling this and kind of walked back to Google's principles The number one principle is like focus on the user and all else will follow anyway That makes sense seems like a good thing great thing like let's apply this to performance And so like we thought it might actually we could flip the question kind of on its head, right? Right, so instead of being kind of going what's slow or it's 50 millisecond slower or any of that kind of stuff instead of that why don't we say What does the user feel or as I like to put it how can we make performance user focused? And I think if we're talking about users we're talking about human beings and we have to start with human perception I think a lot of people Many of us have seen these numbers before They're about how delays are perceived so up to a hundred milliseconds. It just feels instant 100 to 300 there's a perceptible delay, but it's not too bad up to a second. You're still kind of Task-focused, but it's very perceptible now and then it kind of goes all the way up to 10 seconds where you just get and give up I give up. I'm not gonna bother with this. I'm just gonna go and do something else And I guess there's probably one more number that we should kind of toss in the mix 60 FPS right or kind of the flip side is the 16 milliseconds per frame in order to achieve 60 It's just kind of like the jank thing that's been discussed So I'll add that into kind of the number mix Okay, so on the one hand is like this kind of theory I suppose And then on the other side you've actually got the reality of looking at a site and what goes into it So for example, let's say here I'm going to the Chrome Dev Summit website and I tap on it and I'm in the search So I tap on the site stuff and that's a load and we're loading the site and I maybe scroll a bit That's an animation fair enough. I'm gonna tap on the menu Loads me the data there. I like I do a bit of a fling yeah, and then We go into a section with Joffrey and then and then Owen. Yeah, yeah, you call him on whatever So we start to sort of see these atomic actions as you're going through as you're thinking about the things that you're building You kind of go. Yeah, that feels like these are the discrete discrete interactions that are actually happening So what we then need to do is tie those two things back together. We know how humans perceive Delays and and emotion and so forth and we know that we can break down our experiences into these Kind of book hits I suppose. Yeah, so the four that we have our response animation idle and load and Conveniently by the power vested in us by transitions So good so good feels great. Okay. I was I Really wanted like that Yeah, I couldn't bring myself to do it. I do I do love the flame one Yeah, like the classic, you know flamboyant So good. Anyway, so rail dive into those responses This is kind of the you tap on something and we bring something back on screen From the perception we know that it's something that feels instantaneous hundred milliseconds is gonna make it feel So then maybe that tapping on a button or tapping on a form control something in that kind of area We want that to feel instant to our users Next up animation. Well, we want these to feel smooth and consistent So this is you know animations like scrolling or transitions or gestures or those kind of things Humans are very good at noticing variation in frame rate not necessarily what the frame rate is But because the frame rate on the web is 60 frames a second That's what we aim for and we want consistency there more than anything. Yeah idols next Idol is you know, interesting. It's kind of like the absence of an interaction The user is not doing anything right now, but the thing is is they might be And the key thing here is this is a great time to do work But the user might start interacting at any time So you need to be available and responsive to that so that when they start to interact you are Giving a snappy response right back And so if you break up your work into 50 50 millisecond chunks You can basically guarantee that between you and the browser you're gonna do a good job of responding to that user when they start to engage The last one is load load I think is the one that we're all kind of most familiar with talking about it for years and load Firstly like getting the experience to the user delivering to them in about a second to keep that like seamless flow of thought really nice Is kind of what we're shooting for here. Yes so That's kind of like the numbers But we're developers and we need to kind of like make this both measurable and like quantitative things that we can discuss on our teams And just make it really action-focused So if we take that stuff and bring it blended in we're gonna kind of just walk through the specific items Right. So I said it's like the responses is buttons. It's Form controls. It's anything where you kind of changing state I suppose. Yeah, it's the opportunity to give the user some feedback. You want that to fill instant 100 milliseconds You could call this it's it's input Lindsay to exactly, right? Generally, just Response have you ever had that thing where you tap on something and you're like did that work and you go for it a second time Just as you tap it the second time the first one kicks in and you're like, oh, just See them tap it like a third time You know, I'm gonna wait this time and then you've kind of get it just drives me mad That's what this is talking about very much Animation is the next one as I said scrollings transitions gestures, you know, like pinch zoom all those kind of things You want those to be stick to finger fast? So 16 milliseconds An idle great time to schedule work chunk it into 50 milliseconds. It's right ready to do it and lastly load Deliver in one second but in addition to that and probably the trickier part is Continuing to satisfy these response goals and stay responsive to the user during that load You know during a page load a lot of things happening job script running all over It's just like a circus and cacophony of things happening on a single thread And it's a little tricky to actually continue to satisfy like responding to the user when they start to engage And they want to engage like they do they're just there's a thing Up we go The it's good for us to see kind of goals and and so on but the important thing that We want to reiterate about rail at this point is Essentially that it puts the user right back in the center of the performance story the technology and the technical decisions They will come as as part and parcel of that but putting the user in the center is exactly right because that's exactly Where we think they should be yep. Thank you