Today we have three guests on the show, Annie Sullivan, Yoav Weiss, and Michal Mocny, all of who are engineers who work for Google on the Chrome Web platform.  Looking forward to Google’s new developments for measuring web performance, we dive deep into upcoming performance metrics Largest Contentful Paint (LCP) and Interaction to Next Paint (INP), a full page lifecycle metric.  We discuss what user page interactions we can measure successfully and which we cannot.  We discuss the challenges of single-page applications when looking at core web vitals.

Hey everybody and welcome back to another episode of JavaScript Jabber. This week on our panel we have Dan Shapir.

 

Hi from sunny and hot Tel Aviv.

 

AJ O'Neil.

 

Yo, yo, yo, coming at you live from Waffle-Topia.

 

We also have Steve Edwards.

 

Howdy from a sunny and then rainy and then sunny and then rainy Portland.

 

I'm Charles Max Wood from Top End Devs, and this week we have a few guests. We have Annie Sullivan back. Annie, do you wanna say hi?

 

High from Michigan.

 

We also have your vice.

 

Hi from Southern France.

 

We also have Michael Machney.

 

Good to meet you folks. It's a foggy one up in the North Bruce Peninsula.

 

So yeah, so you all, do you all work for Google?

 

Yeah,

 

We

 

we're

 

Let's

 

do.

 

all

 

just start

 

engineers

 

there.

 

on Chrome Web Platform.

 

Okay, good deal. And this is kind of a follow on to the episode we had you on before, Annie. Do you wanna kinda, I'm not sure exactly where we left off or where we wanna start here. So I'll kinda let you take the reins and lead us out and then we'll see where we end up.

 

Yeah, so last time we talked a lot about Core Web Vitals and the goals behind

 

Mm-hmm.

 

them and where they came from. And I also thought it would be really fun to talk about where they're going. And so I invited Joav, who's leading our efforts to integrate single page applications into Core Web Vitals and Michael, who's working on our new responsiveness metric, Interaction to Next Paint, to come on and talk about those things.

 

Very cool. I feel technically inadequate with you guys on here.

 

I agree. This is one where I'm going to just be sitting back and listening the whole

 

Yeah,

 

time.

 

but this is totally my

 

Right?

 

jam. This is like, this is what

 

So, yeah,

 

I live

 

so

 

for.

 

I guess we talked a little bit about Core Web Vitals and where things came from and where they're at now. One thing I'm curious about is as you start looking at, okay, well, where are we gonna take this? Like, how do you make that decision? Right? Because it seems like there are a million metrics you could use, right? There are a million ways you could make that decision. And so, how do you make that decision?

 

Yeah, there's a couple of things that went into it. I'll talk about responsiveness first. So when we look at the original Core Web Vitals, they were really intended to be those three metrics and it's supposed to be like a three legged stool. We have this page load metric, largest contentful page. And people were concerned, like what if they try to cheat by like throwing up pieces of content really fast and cumulative layout shifts, which stop, you know, it like measures content shifting around, can really backstop that. just throw some stuff on the page willy nilly and have it kind of shift all around because you have cumulative layout shift. Similarly, there's a big concern. What if you throw the content up really quick, but then you have a ton of JavaScript and it just freezes the page? And first input delay is meant to address that. But the consistent feedback that we're getting from web performance experts and also concerns from people who work on the web platform is that first input delay is not a strong enough backstop, that there's just tons of JavaScript. down the user experience. And we need to do something more about it to really be measuring the user experience. And so Michael's been working on this new metric interaction to next paint. That has kind of two differences between first input delay, which is our old metric. The first one is that it measures the whole time until the next paint from the user input until the paint. First input delay just measures the time to process the event. So that's just the kind of main thread busyness. Second, it measures all of the interactions on the page. So that we think is really capturing. And when we look at the numbers, we compared, for example, first input delay versus interaction in next paint. We looked at the HTTP archive. And we took three million sites that had these metrics and that they also had lab data from Lighthouse. And we found the interaction in next paint things like total blocking time that show that there's a lot of JavaScript running and blocking interactions. So we think the interaction in the next paint is a much better leg for that three-legged stool that measures the slowdowns that people get from JavaScript.

 

So could you rephrase that, the meaning of that one more time for me? Because I think I understand it, but the words don't, on their own, quite don't make sense of the name of it. In the interaction to next paint.

 

Yeah, Michael, if you want to jump in, you

 

Sure.

 

can. Michael, propose a name.

 

So

 

It's his fault.

 

yeah, throw me under the bus. So I think it's easy to make these things sound more complicated. So I want to start by just focusing on the goal. And then we can go back to some more details. So when you interact with the page, you should see the feedback. You should see the result of that interaction quickly.

 

Yep.

 

So it's from the interaction, from the time screen from the time you type on the keyboard until the next frame is actually shown on screen, until the pixels appear on the screen. And those pixels have to have the feedback of that event. We're constantly animating things and so it's the first frame that actually had that interaction content in it.

 

I apologize for barging in, but how do you know? I mean, pixels get drawn all over the place, and especially with JavaScript, you know, can do whatever

 

Yes.

 

it feels like

 

Yes.

 

in response to an interaction. How do you know that a particular set of pixels are a response to that interaction and not, I don't know, some video playing or some animated gif

 

Yes.

 

or something?

 

Great question, Dan. So we're building on work that has been in the works for years and years. And this is work that we needed for metrics like LCP and a whole bunch of other responsiveness metrics that measure presentation times, paint times. So in Chrome, we instrument side effects, whether they come from main thread or compositor thread. And as you make changes, we sort of pass data structures along port sort of feedback when the pixels arrive with those changes. So in this case, we have an event is handled by the browser process. It gets sent to the renderer process. It gets queued up on the main thread. The events are actually dispatched, actually run by JavaScript handlers that the developer registers. At some point when those are finished executing, finished processing, we will eventually schedule a new main thread rendering task. which is the first opportunity on Chromium browsers to take all of the effects that happened on the main thread, commit them over to the compositor thread. And then eventually the compositor still has more work to do, eventually has to submit that to the GPU process, and eventually those pixels have to get to the screen. And then finally, when all of that work happens, we sort of pipe along presentation feedback. So there are just simple data structures along this whole rendering pipeline, which took a lot of time to get right, kind of improving it and making it better. But in this case, I think your question might be, how did you know that the pixels in that update were directly feedback for that response? And in this case, we don't. In this case, this is the first opportunity that it could have provided feedback. And that is what INP is measuring. So we don't get confused by video playing alongside It will be the frame that had the result of the event handlers running, as well as all of the default browser styling work. If you click on a link and it changes from blue to purple, or if you type in a text box and you get the character appearing inside the text box, this is sort of default browser styling. Those effects will be included in that first visual feedback. But we can't guarantee

 

you

 

that all of the JavaScript that was a reply to that interaction.

 

So, I would actually ask or use

 

you

 

an example of

 
Dan_Shappir:

an issue that I would encounter with the FID metric and I wonder if you could describe what would happen with the INP or INP in this context. So, one thing that I actually saw with some JavaScript heavy pages was that they took download the JavaScript before hydration, that hydration actually not only ran long, but also kind of ran late.

 

Yes.

 

And what would happen is that people would actually interact with the page before the hydration even started, not while the hydration was running, but before the hydration actually started. So thanks to SSR, you actually had content on the page. For those of you who are listening in, SSR means server-side rendering, which JavaScript usually running on the backend, React or whatever, or some static site generator provided the initial HTML so the page was visible with content from the get-go fairly quickly, but it's not interactive until a whole bunch of JavaScript, let's say React or Vue, whatever, actually is downloaded and executed on the client side, and that could take some time. the user interacted with that visible content before the JavaScript even finished downloading. That means before it actually even started running, which means that the CPU was actually totally free. It would actually react, the FID would come out as being excellent because you click the button that let's say or a link that was not wired to anything and it responded instantly by doing nothing.

 

Yep.

 

So there would be no visual change, no nothing. page itself, like, I don't know, sometimes you might click an area in the browser window just to make sure that the focus is on that window and not some other application running on your desktop, and that would count as an excellent FID even though nothing actually happened. So, my question is, in those scenarios where you click something and nothing actually happens What would imp indicate? By the way, should I say imp or imp?

 

INP, INP,

 

Imp, okay.

 

let's not go within. So great question. I think that first we can focus on the metric definition, and then I want to add to that scenario a little bit. So the metric INP, in the case that you interact so quickly that there has not been, the JavaScript hasn't downloaded, handlers haven't been registered, nothing happens, the component doesn't feel interactive, and P in that case. I'm still assuming the scenario you set up here where rendering is yielding, there's nothing happening on page. We do not judge the quality of the interaction. There's no way we try to assess whether this was a useful feedback or whether this element was interactive. That would be too difficult to assess, if that makes sense. The UX experience of whether this was working

 

Well,

 

or not working.

 

So just to

 

couldn't

 

verify

 

you?

 

that I understand, sorry, I just want to verify that I understand what you're saying. Let's say, for example, I'll give a concrete example. You

 

sure.

 

have a mobile application with a hamburger, and it's actually an example of something that used to exist within Wix, where I used to work, where

 

Mm-hmm.

 

the hamburger menu that was used by the mobile application, by mobile view of many websites was originally dependent on hydration.

 

Mm-hmm.

 

And the hydration used to take a bunch of time. And as a result, if a visitor clicked the hamburger menu fairly quickly, nothing happened because the hydration

 

Sure.

 

code hasn't even finished downloading yet. And so that's the worst possible user experience. You clicked the hamburger menu, no response whatsoever. Not a delayed response, no response, nothing.

 

Sure.

 

But the FID was excellent.

 

Yes.

 

Because the thread was free, it was still waiting for the resources to download, and hence responded really quickly. If I understand correctly, what you're saying is that that particular INP measurement would still be good even though nothing was rendered because

 

Yes.

 

if something would have been scheduled to render, it would have rendered really quickly.

 

Yeah.

 

the next animation frame would have happened really, really quickly.

 

Precisely. So the second part to my answer is that that one interaction would have been measured as performant. We're not judging the value to the user of that interaction. This is just whether or not we know for sure performance was affected. There was rendering could not have proceeded within 200 milliseconds is the threshold that we're using for good for MV. would have scored well in that one case. But we continue to measure every single interaction with this page. And so at some point in the future, if there was another interaction that took longer because it did more, it would overwrite sort of those things. So in a long-lived session where the user does eventually wait for these things to load, INP is not affected in the same way that FID is. So that's, you

 

So

 

know.

 

basically,

 

But.

 

you're saying that because FID is like this one shot, this page would get a pretty good FID or this session would get a good

 

Yes.

 

FID because that first interaction, but with INP, maybe

 

Yeah.

 

that first measurement would have been great, but eventually all that JavaScript would arrive, which would likely result in a lengthy hydration. And then when the user tries to interact with the page then, probably rich clicking because and nothing happens with that menu,

 

trying to get it to work right.

 

then you would measure and report the higher

 

Yep.

 

INP value. That makes total sense.

 

There's more to this answer as well. So the scenario you describe, I think, is more likely to happen with INP, because frameworks nowadays have been optimizing for FID for so long that all of the heavy hydration, you presented a scenario where it's before hydration even begins. But we're busy loading. We're blocking rendering, perhaps. We're getting in the way of the ability to even schedule a rendering task. But it comes out that the input delay not affected. Website authors have optimized for that metric to make sure that the event handler does get dispatched quickly. So FID would score well, but even in this case, if you're heavily loading early on, INP might still have not done. Even though the interaction isn't doing what you expect it to do, it might still also not be performing well. So this is worth testing and trying it out. But perhaps the quote unquote, crux of your question, Dan, is Is it worth measuring an interaction that is broken? And I think it's difficult to judge. If you have a buy button on a website and you click that buy button and it performs well, it gives you feedback, the JavaScript has loaded, you get something, but the item doesn't get purchased and it doesn't arrive, the user would consider the site broken. But that is incredibly, it is an impossible problem for a performance metric to judge, it's not our role in this case. it is a trend in

 

Thanks for watching!

 

the framework space to be more accessible, to have more progressive enhancement. So on a framework like Remix, all your links, all your buttons will use forms. And before hydration takes over to turn a server rendered site into a client site, site with interactivity and JavaScript, it will continue to work. That button will still provide an accessible action that might just do a server post or some useful fallback. it is difficult to judge, you know, the JavaScript handlers haven't been registered. Does this interaction do what is reasonable or not? There's no clear answer. And so we measure the performance only.

 

So, in this context, I have to mention Noam Mozenthal, who recently

 

Mm-hmm.

 

joined you guys at Google. He actually gave a talk at the recent React Next conference in Israel, and he talked about how to overcome the problem of hydration and responding quickly to user input, basically could be properly interactively handled before hydration actually even happens, like you mentioned, by basically either letting the browser do it or using much lighter weight JavaScript and CSS handlers that you kind of custom create to execute before the hydration even starts. And finally, this is actually based on a real world case, also worked at Wix, where going back to that specific example that I gave with the hamburger menu, he, I think it was him, but it might have been somebody else, but basically what they ended up doing was handling that particular UI element using a web component that was, that its JavaScript was totally independent of the hydration and the larger framework so it could download and execute much, much earlier and be able to actually display the menu when the user clicked it. So that's an example of that. I totally agree that the Remix, the approach that Remix uses, and I don't think they're the only ones, of falling back to the built-in functionality, be it buttons or forms or links, to let them handle Even if it means that instead of working as an SPA, you work as an MPA for that initial interaction, I think that's definitely the way to go.

 

What a segue, Dan.

 

Hahaha

 

Mm-hmm.

 

So that would be an excellent segue to talk about MPA and SPA. But we are only scratching the surface of INP. And I wonder if we should just exhaust that one first.

 

Yeah, for sure.

 

So.

 

So you mentioned that you measure throughout the entire session, not just the first interaction. Then

 

Yes.

 

what is it that you report? As I recall, when you were experimenting with it, you were looking at possibility of reporting the average or the median or the largest. What did you end up choosing?

 

Yes, so first on the topic, this is a full page lifecycle metric. That's just kind of the phrasing we tend to use or like a full runtime metric, I think we use different terms, but much like CLS, where it is not just measured during load, it is measured from load until page unload. So every single interaction with the page matters to users. a bunch of different ways to do those measurements. We evaluated whether, you know, is there a budget? Like, do users not notice responsiveness under a certain amount? And so it only matters kind of like long tasks above a certain threshold. We evaluated, should we take the sum of all of the time they're spending waiting above their budget? Should we look at average? And everything has flaws. But so we found that one of the simplest definitions, which I'll give in a sec, was very, worked well. But it also had other properties, properties that are useful for end developers. It was the simpler you can get in your definition, and it actually passes the tests like it does well as a metric. It represents the user experience effectively. It just has, it's hard enough to define these things on their own. And so what we ended up settling with is it's a single interaction. So one interaction, however long you had to wait for that interaction, that's your score. from when you interacted until pixels appeared on screen. And I use the word duration the way the event timing API uses the word duration. And what we look at is the worst interaction with the page with a little bit of a caveat there, and I'll describe that. But users, the one worst scenario that they spent with a single page load session is how they kind of tend to remember the site. And so that's what we're focusing on. Now, in practice, what we ended up settling with is the 98th percentile interaction. So we pick the worst one, unless you've interacted with the site more than 50 times, which is super rare. Very few sites interact more than 50 times. But if you're there, if you're, you know, the Gmail's of the world or the YouTube's of the world, and you interact hundreds of times, you leave that tab open, long lived, You will eventually have all of the stars align against you. Garbage collection is happening, the user had the tab backgrounded, power saving mode enabled, and etc. And so this interaction could be a blip in the system. If a user is truly spending that much time on your site and interacting that much, maybe they really love the site and the performance is doing fairly well. And so we judge a little bit down from the single worst outlier, if that makes sense. But that detail is only important if you're really diving into the weeds. it's easy enough to just think of the single worst interaction for like 99% of use cases.

 

That's actually really interesting because what I found is that core vitals, while they're an awesome set of metrics for let's call it e-commerce websites and obviously landing pages and blogs and whatnot, they're not necessarily such great metrics for dashboards. Because with dashboards, it's usually not so much about the initial load time. more about how your experience over time, how it re… Sometimes I joke that people open a dashboard and they go get a cup of coffee. They're fine with it taking

 

Hm,

 

a while

 

hm.

 

to load, but once it's loaded, they want it to be responsive. And I think that IMP is actually potentially a great metric in this context based on your description because… And it's a metric that I'll certainly try to look at in the context because at Next where I work, we actually have a bunch of these dashboard-style web applications. And it seems that the INP could be a great metric in this context, especially if it works well in a single-page application type scenario, which I guess we'll get to soon. Definitely, that's great. I do, on the other hand, have to mention that while we were talking, I was looking at the dashboard that Rick Viscome, who also has been on this show, has created, which I highly recommend for everybody to look at. And I was comparing the various different frameworks. And by the way, I even recently wrote an article for Smashing magazine looking at the core vital scores of the various JavaScript frameworks. And all the JavaScript frameworks score phenomenally well for FID, but are fairly abysmal for I For FID, they're all in the approximately 95% range, so it's like everybody's acing it. For INP, they're all in around 50%, all of them. Even the quote-unquote fast ones, like, I don't know, like a Svelte or Preact or these. So that means that, I don't know, when you plan to do the switchover, I don't know if it's decided already that you will be doing the switchover, I'm expecting to see the old green co-invite ratio drop like a rock when that happens, especially for all the websites that are using JavaScript frameworks.

 

Don't hurt Vio, it'll hurt Steve's feelings.

 

Hahaha

 

Darn

 

Yeah,

 

right.

 

we do expect the pass rates on Core of Vitals to go down. I think what's really interesting though, is you look at any individual framework and you look at the distribution of IMP scores for sites, and you see like kind of this bump at good, and then like this super duper long tail. So I don't think, and as you said, it's kind of like some frameworks have like more distribution of like good, and then like shorter long tail, with a longer long tail, but overall it doesn't really seem to be necessarily the framework itself that causes the performance problems, but just the fact that people can very easily load a lot of third parties, load a lot of libraries, make their JavaScript bundle larger, start running more and more stuff. So I think that it's not necessarily a problem with individual frameworks, but more so like a problem of just including too many things and trying to do too much.

 

I wouldn't necessarily give the frameworks a pass. If I also look at the all metric, which is an aggregate of all websites, it's noticeably better than any framework. And I assume that third party exists on websites that don't use frameworks like WordPress sites, for example. And you know, it looks like frameworks have a problem.

 

So.

 

but that's the feeling I have.

 

So I think there's one pattern in particular that's worth calling out. And then until this pattern is addressed, we should hold judgment, I would say. So the reason SPAs are so popular is because I think we all know this, the interactions tend to be faster if you do them right. If you, a good SPA is valuable and that's why it's a pattern that is adopted. Okay? There's some smickering in the room, I think. If you compare doing a hard navigation, an MPA reload, to another page URL, another route, we would assess that with FCP, LCP, which is in the 1 and 1 half, 2 and 1 half second range. That is the amount of time we expect users want to target to feel fast and smooth. With INP, we are targeting 200 milliseconds for that interaction until the next paint. being on the same document and doing the navigation client side, you are being assessed with a 200 millisecond duration instead of a 2 and 1 2nd duration, if that makes sense. So a user might be using an SPA. They might click. It might take half a second to see visual feedback. And they would say, wow, that was a fast load as compared to 2 and 1 2 seconds LCP.

 

Yeah...

 

So this pattern, the direction that many frameworks are going towards is to have, and this has been in their documentation for a long time. They've been doing tech talks and conference talks about this for a long time, but it's becoming a first-class citizen big time. Our transitions, where you unblock the very first part of feedback. You don't do a giant component re-render, in one step and then wait for browser to render all that layout style, like decode all images and then do one giant rendering update, which could take a long time before you see anything change. But it all pops in nicely. But instead the

 

Hmph.

 

direction is an initial critical set of feedback first and then progressively add the rest. And there's tons of different ways to do this in different frameworks, but it is a direction that we're heading. And so what you see is you first routing as being in the next upcoming version. And so every single route change you'll have a progressive visual update. And so INP will just explode, I think, an improvement performance on those types of sites. That's my

 

Now, correct

 

feeling.

 

me if I'm wrong, but I was listening to another well-known tech podcast this past week and they were talking about transitions being added into the browser. Is that

 

Mm-hmm, mm-hmm.

 

correct?

 

This is unrelated, but that is an incredibly exciting feature as well. The Web Transitions API and Jake Archibald's

 

Shared element

 

thing, yeah.

 

transitions,

 

Shared element

 

if

 

transition,

 

I remember

 

thank

 

correctly.

 

you.

 

Yeah.

 

Wait,

 

So.

 

what does that mean?

 

Essentially, so my take is slightly different than Michael's.

 

Hehe.

 

I think that SPAs are popular like for two reasons. One is like developer oriented reasons that I won't go into. But the other one is that as a platform, we've been providing like the SBA experience. when done well is better than MPAs in terms of enabling transitions between one page and another instead of going from blank screen and then re-rendering the next page or the better scenario of not going blank screen but still not smoothly transitioning between one page and another. And that as well as across different pages provide, like basically there are. user experience facilities, user experience advantages in using an SPA when done right over MPAs, over old school multi-page applications. And shared element transitions is one feature in a larger set of features that is aiming to close that gap and enabling the same experience in a multi-page app. you would be able to have multiple pages, multiple HTML pages that are independent, but have a smooth user experience when the user is clicking from one to the other. And a lot of the advantages of SPAs in terms of performance are done by the browser by the fact that you're loading significantly less JavaScript can, for example,

 

Thanks for watching!

 

use code caches and other ways of just,

 

you

 

you know, making sure that that transition from one page to the other is fast.

 

I have to say, only half jokingly, that I identify modern web applications by the fact that they have multiple spinners on the screen at the same time.

 

Thanks for watching!

 

Ha ha ha

 

So yes, you click and it responds quickly by showing you a whole bunch of spinners and then

 

That's

 

gradually,

 

a parallel upgrade.

 

yeah, and then gradually every spinner disappears to be replaced with a bit of content.

 

and not

 

But

 

found.

 

yeah,

 

a bit of

 

or

 

placeholder,

 

not fun.

 

which is later replaced by content.

 

Yeah. But yeah, I'm totally with you, Av, on that. First of all, it's worthwhile noting that already the experience of transitioning between pages in a multi-page application is way better than people recall it being like, I don't know, 10 years ago when you had that flash of white, because now the previous screen is retained much longer, and you can create some sort of instant reaction in the page remains visible for a while until it's replaced with the next page. But what gets really interesting with the transitions is that you can create, like you can use CSS rules to animate from the previous page to the next page. And I know for a fact that a lot of websites chose SPAs originally, again, putting aside developer reasons, But if I'm looking from the actual user experience perspective, just for the transitions, just to be able to do a more sophisticated transitions like you, you know, people might expect in more modern type applications, especially on mobile. And now you'll be able to do that with CSS between distinct and discrete pages in a multi-page application. And yeah, that will be really, really interesting. packs your measurements of core vitals.

 

Absolutely. Well, I will say I'm happy that Joav and I can have reasonable disagreements and argue over a beer as to which approach is best. I am in team JavaScript. I have been developing client-side rendered sites. And I'm super excited about

 

He just

 

transitional

 

froze.

 

We lost you.

 

apps.

 

Yeah, I think we know who the podcast software agrees with in this case.

 

Right?

 

Yeah.

 

Let's

 

I

 

see,

 

can pause

 

is

 

him

 

it

 

too.

 

better?

 

Yeah.

 

Is it better, is it better?

 

No,

 

Yeah,

 

you're

 

Yeah.

 

back.

 

you're back.

 

You're back.

 

Great, there goes all the enthusiasm.

 

Ha

 

Ha ha!

 

ha ha!

 

So you kick him back having a beer and then.

 

Okay, let me take that again. I was gonna say that. I'm still seeing AJ's internet is weak. I don't know. Am I out again?

 

Não?

 

You're weak. Nope,

 

My

 

you're good.

 

internet is strong!

 

AJ, you've got guns!

 

He does? Where?

 

HWAH! HWAH!

 

This is America.

 

MWAH! MWAH! HWAH!

 

Anyway.

 

I was-

 

Thanks for watching!

 

I

 

Okay

 

would

 

I was-

 

throw

 

I

 

now

 

don't

 

in

 

it

 

a

 

just

 

know.

 

rim

 

got

 

shot

 

weird.

 

there Chuck, but I don't have that right now.

 

riverside

 

Oh right,

 

UIs

 

cause you're not

 

all

 

the...

 

over the place.

 

Yeah, well, we can hear you at least, so keep on going.

 

OK, yeah, so what I was going to say is I'm quite happy that Joav and I can have different perspectives on this problem. I would consider myself team JavaScript. I would consider myself I've done a lot of CSR rendered sites, and I'm incredibly enthusiastic and interested in the direction of transitional apps or one app. Or there's a bunch of very exciting stuff happening in the JavaScript space with edge functionality as well. The cool thing about Core Web Vitals and our program in general is that we are entirely agnostic with how a site is built. We focus on what the user sees, what the user experiences, and it doesn't matter how you get there. We also focus on budgets. It's not a race necessarily to the bottom of who can get 10 milliseconds better on this or that. If it is good enough, you might choose to start optimizing other metrics like the cost for your server costs or whatever it is. As long as the user experience is sound, and Core Web Vitals is just one way to help you draw attention and focus to get there, we are very happy. And we're glad to see improvements across the board and with so much focus here. So yeah. It's

 

Yeah.

 

fun to speculate. It's fun to argue. But at the end of the day, there's room for every approach as long as it meets,

 

you

 

as long as it does what's reasonable for the user.

 

I said that to Annie last time, you know, when she was our guest in that previous episode talking about the history of Core Vitals, that one of the things that I love and appreciate about Core Vitals is how user-focused they are. I mean, obviously, no metrics can be perfect, and especially when you're only using three and you're trying to keep them as simple and understandable as possible. But it's really great because in the past, we've had metrics that were less focused on actual user experience.

 

Mm-hmm.

 

So in that regard, Core vitals are great, but it's also still worth saying that if you're optimizing Core vitals without actually improving your user experience or potentially even degrading your user experience, and I've seen cases of that, then you're certainly doing more harm than good. You know, especially given the fact that Core vitals are kinda tied to SEO, I've seen, you know, situations try to quote unquote cheat the metrics or cheat their customers that they're improving their metrics if it's like, you know, consultants or whatnot. And if and it will get you nowhere because even if you're somehow able to pull a fast one on the Google search and maybe get slightly more traffic, then you lose that, then you lose that to bounce rate and much more if your user experience gets worse. always at the end of the day about the quality of the user experience.

 

Yeah, and there have been like the bit that I like most or worst, depending on your point of view. Colin Bendell from Shopify had this tweet where there are plugins paid for, plugins that people install that cheat. And basically when when you're being tested in Lighthouse, they document that right the entire page into nothing. So you basically get a blank page in Lighthouse, which gets a good Lighthouse score, which cheats no one.

 

Thanks for watching!

 

This doesn't help you in any way other than cheating yourself. And people pay for those kind of plugins.

 

You don't even need that. Just make your server that much slower and you'll time out the Lighthouse score and you'll get a perfect result. So basically when you're running Lighthouse, especially after purchasing a performance plugin, look at the screenshots. If what you see is blank, then get your money back. That's

 

Yep.

 

all I can say. But definitely, definitely. So talking back about INP, is that a done deal? experimental now. You're already collecting information into crux. As I mentioned, you can already see the data in the report. So is it just a question of time until you replace FID with INP? Or are you still tweaking things? Or is it still in discussions? Where is it?

 

So it is not a core WebVital. We understand the limitations of FID, and this is the metric we have the most hope in replacing FID. We are still working through various kinks and feedback, and so there is nothing done deal about it. I think there are several smaller open questions about how we want to define exactly which interaction we exactly which parts of each interaction count or don't count, some small details might still change in order to be the best version of this metric. So I think we are on the path towards optimizing the best version of this metric. I think the bigger picture of we want to measure the initial feedback by focusing on the time from interaction until that next paint, I think we've stood enough of a test of time and gotten enough positive feedback And there's enough room for improvement. Like it has so many positives, especially as an improvement to FID, that I would be surprised if there was a last minute giant change in that department. Now in terms of the timeline of these things, I think there is at least a six month lead time before we make any change and when it's announced. And we haven't even made that announcement. So there is at least six months from now and probably more. I don't know, Annie, if you have more details on that part.

 

Yeah, so we haven't made a decision over whether to include it as a search ranking signal But again like for any like new metric or metric deprecation or change in threshold There will be some sort of announcement and then a six month timeline before that became active in search

 

I will say this and going back to the whole UX points that we made. And the jokes that I previously made about spinners. You can improve INP without improving UX or even potentially degrading it. If all you're doing is just drawing some pixels somewhere quickly and then taking your time to actually fulfill the request. before, because you put in that mechanism to create some sort of quick feedback, you're not necessarily doing good. Let's put it this way. And I think also, again, I mentioned Alex Russell before, I know that he raised a potential issue about the fact that if you're like typing and you just have a 200 million millisecond delay all the time, or 199 milliseconds. So you're still better than

 

Yeah.

 

200 milliseconds. It's still a pretty poor user experience. Now, my reaction to him is, given the results that I'm seeing with pages already, giving the initial data that you're collecting, I wish that would be our problem. But yeah, I don't think that even getting a good INP is a guarantee of good UX. I do think that it's already a significant improvement over FID, which has become effectively a meaningless metric because everybody gets such a great score.

 

Yeah, I

 

Yeah,

 

think

 

I think.

 

we always need to continually improve the metrics, right? Like it's not like, okay, then we're gonna introduce IMP and then we'll be done once and for all, right? I think it's a clear next step where like, obviously there's like another step after that in measuring like asynchronous interactions and understanding those which is more complicated and harder to understand. But I think IMP is a step in the right direction. One of the things that we've been seeing a lot, reports where we can get anonymized traces from users. It looks like kind of a DevTools timeline. And one thing that we're seeing a lot is that somebody will interact, and then it's so slow. Nothing happens, and they interact again. And so for your first point about, OK, you have this quick update, but then the task isn't done because it's asynchronous, I think it will usually. If the user is not seeing that the task is happening, they'll click again. that IMP will still reflect that, at least for most cases.

 

I do want to push us to the discussion about single page applications because we're starting to run long in this episode.

 

Yes, we are.

 

So maybe we'll talk about that. So quickly, why are single page applications a problem, especially in the context of Core Web Vitals as they currently stand?

 

So I can probably take that. Historically, so let's start with the first version of CLS, of Communitive Layout Shift. Historically, it has been the shift that is accumulated throughout the entire lifetime of the page. That was the first version of CLS before it was improved to be a more balanced metric. And that resulted in long-lived pages significantly worse scores, even though, like, if you have, let's say, one small layout shift per minute, if you have a long-lived page, that would accumulate into a very high score, whereas if you have a lot of short-lived pages, that would not accumulate. So that created the first initial tension between, you know, SPAs that are typically of shorter-lived ones. Then as part of the full page lifecycle metrics effort, CLS was improved. And INP is also modeled based on a similar model where we don't just accumulate scores over time, but we pick the worst experience throughout the lifetime of the page. Still, you have, like for SBAs, the way The worst score throughout a very long lifetime will potentially be worse than the worst score of a very short lifetime that MPAs typically have. So there's still some tension there. And there's also...

 

Also, if I may interrupt, MPAs, because they push computation to the server side, they could potentially get really great scores for scenarios where, for INP scores for scenarios where single page applications would be severely penalized. Like if you click something to transition between, effectively transition between a page in a multi-page application, because nothing literally blocks the transition. The INP score would be great even though from the UX perspective nothing happens for a long time, just the spinner in the browser's toolbox starts rotating. Whereas with a single page application, if you show nothing until and you run a whole bunch of JavaScript in order to handle that because you do the processing client side, you would potentially get a really bad score even though the UX would appear to be essentially identical.

 

So first of all, at least from my perspective, the browser signaling is an important signal to the user and is a signal that almost all users recognize as something that's happening where thinking about it will give you a reply shortly. So I don't think we should discount the browser signal of the pages being loaded.

 

Point taken.

 

Yeah, but at the same time, yes, if we're talking about, like Michael said earlier, for MPAs we have FCP targets for a second and a half where responsiveness is 200 milliseconds. And for that, in order for us to be able to expose the same levels of data for SPAs as is how long, you know, start recounting LCP after SBA navigations and provide the same kind of thresholds and provide the same accountability to soft navigation routes versus just, you know, assigning everything and attributing everything to the original landing

 

Thanks for watching!

 

page URL. In order for us to do that, we need to be able to recognize soft navigations.

 

Can you define soft navigations for listeners?

 

So essentially, navigations that are being done by single page apps where the URL is modified and the content is modified as a response to a user click.

 

So essentially, it's a navigation that's handled by a client-side router that's built into the ones that are built into most frameworks rather than by the browser itself dealing with the server.

 

Exactly. And because it's being done by JavaScript and not by the browser, historically, it is not something that the browser know things about and therefore cannot attribute metrics to. And essentially, I'm working on changing that.

 

So what, you're going to basically look at the interaction, then notice that the URL has changed, and then look at the next paint after that, something like that.

 

something along those lines. So basically in order to do that, I had to build some missing infrastructure in order to be able to tie the user click to, you know, URL changes and DOM changes that happen after that. Cause in many of the frameworks that work is done asynchronously. And even if like, funnels where the new navigation API, that work happens in different tasks, in different microtasks or tasks. We need to be able to tie all that back to that user interaction in order to have reasonable heuristics that don't just assume that any DOM modification is related. I did some work to create that infrastructure for task attribution and being able to say this task is a descendant of this other task. And now I'm building a soft navigation heuristics on top of that, that essentially do that. So essentially, see that the user click has happened and then see that DOM modifications and a URL change happened as a result of that. And then say, okay, a soft navigation has happened. and now we can start

 

you

 

doing things as a result of that.

 

So to put it into practical terms, currently, like you said, when there's a soft navigation, it's wholly ignored in the context of core vitals and other web performance metrics. So FCP is not calculated again, LCP is not calculated again, CLS is not reset, it keeps on going. So what is your end goal to actually deal with soft navigations like they were hard

 

Yes.

 

if I cause a single page application to use the local, as I said, the local JavaScript router to change the URL, that would calculate a new FCP and a new LCP and reset the CLS. That's the end goal.

 

That is the end goal. It is a hard and long stretch, but it's, yeah, that is the end goal. We want to be able to report those, like basically as Michael said, we want to be tech agnostic and client side navigations versus server side navigations should be the same as long as the user experience is good on both. And we want to be able to measure Um, you know, those user experiences similarly in both tech stacks.

 

It'll be really interesting to see the data once you start gathering it, because historically a lot of the framework advocates have been complaining that core vitals are shortchanging single-page applications. That single-page applications generally pay a higher price up front for better experience down the line. And they will need to show that that's actually true, core vitals for those soft navigations given the higher cost of that initial view.

 

That's the goal, yeah. And once we'll be able to know, like once we know how long soft navigations take, then we can start to come, like maybe they are better. Maybe they are a better way of building websites, or maybe they're slower and we need to address that, or maybe some of them are great and some of them are bad, and we can split that bimodal distribution and figure out which ones are bad characteristics and how can we fix them. So essentially until we have that kind of measurement, at least from my perspective, we are shooting in the dark and we should try to stop doing that.

 

So basically, your goal, I guess, for this stage is to come up with some sort of LCP star metric in addition to the current LCP metric that will also measure that. And then you'll be able to graph one versus the other based on real user sessions that are data that's collected into crux, something like that.

 

That's a slightly more advanced goal. Initially, I just want to test that my heuristic is roughly accurate. And this is something that I started collecting data internally, but at the same time, I'm still playing with the heuristic in order to fix obvious bugs that I already found. And then the next step after that is to run an origin trial with run folks who collect performance metrics and have awareness into their SBA soft navigations, and basically run an origin trial and try to get folks that are trialing to tell me where I'm wrong, or to figure out where they're wrong, or like basically compare my heuristic to what and try to find, for example, pages that are using frameworks but have zero soft navigations according to my heuristics. So that would mean that my heuristic is wrong and I need to fix it in those specific scenarios. So that's the first step. And then the step after that is some sort of a, yeah. an experimental internal metric as well as maybe an experimental LCP value to expose to run providers. And then we can see what it would mean for us to shift from one to the other.

 

This is really cool. I really love

 

Mm-hmm.

 

the process that you're describing and all the hard work that goes into these metrics. So this is not just like a mandate from heaven or something like that. These

 

See you next time.

 

are all

 

Bye.

 

the results of blood, sweat and tears trying to get all these metrics to actually correlate with real world user experiences. This is awesome.

 

I thought coming from these people was the same as heaven. Did I miss that?

 

Hahaha

 

Hahaha

 

So when do you think, you know, is there any sort of expectation about when you'll start doing all that work? All that gathering of information?

 

Yeah, it's funny that you used the word expectation.

 

No pressure, no pressure.

 

No, no, it's all good. Basically, I'm hoping to go to origin trial for the basic, like a very early origin trial with a made up API shape just to test the heuristic very soon. Then yeah, other than that, we'll see how that goes. It all depends on whether the heuristic matches what is out there

 

you

 

in the field or not. I'm, yeah.

 

Is there any association between what you're doing in the new history APIs or is this like independent of the of the API's use?

 

It is independent for now. So I'm hoping that I can come up with a heuristic that will work for existing content out there today. It is possible that this will not work out. The History API has some advantages of being able to mark the end of the session from the developer's perspective. So it is possible that we'll need some sort of a developer opt-in into a well-lit path that will make it easier to measure. If that would be the case, that opt-in is very likely to be the navigation API. So I'm still hoping that it won't be a requirement, but it is possible that at some point,

 

I

 

life

 

don't necessarily

 

will hit me.

 

think that such a requirement would be so bad because I'm assuming that most frameworks will adopt the new navigation APIs fairly rapidly. So even if users don't actually deal with it, they'll get it for free as part of frameworks. I'm guessing I'm hoping. I guess I'm hoping.

 

Those that upgrade, maybe. But yeah, it's always better to cover more content than less content. I will, like... Yeah.

 

N-

 

I'll see if there's a... Like, if it's a necessity, then this is the route

 

Yeah,

 

with...

 

let's put it

 

Or

 

this

 

like...

 

way. Websites that don't update, they probably care less about core vitals anyway. Yeah. I mean, if they're not investing in updating their frameworks, then probably not investing that much in their websites anyway.

 

Yeah, there is definitely that element of things, right? I mean, even Core Web Vitals being part of SEO, you know, or influencing SEO, it only the people who care about those particular metrics, right? Where they're, you know, they're ranking in Google makes or breaks their business or at least care about that kind of a thing. And then it's folks on our end who are looking at it and saying, Hey, I want this to be performant. I want it to be a good user experience. I want, you know, these kinds of things, you know, and if you're not on either of those things on the user experience or on the SEO. Yeah, I don't see that that's going to be something you worry about. Similarly, yeah, if you're not upgrading your frameworks, then you're going to miss out on some of these optimizations. But I'm glad that this is being put out there. I'm glad people are talking about how we measure the end of the day. does allow us to provide a better experience for people on the web.

 

And I do think from our perspective, at least the broader of an understanding we can get over as many pages as

 

Right.

 

possible,

 

Mm-hmm.

 

we can learn a lot more about, even basic things are really unknown right now. How many SPA transitions are there for every MPA transition?

 

Right?

 

Are frameworks getting better and worse? Maybe we find out that there's some framework out there where the next version has significantly slower SPA transitions

 

you

 

than the old version. And so a broader measurement would be able of things.

 

It's my guess, but I'm thinking that we will actually potentially be surprised by how few soft navigations actually happen in real life. I think that a lot of websites are being built these days using frameworks as SPAs, even though they are generally very shallow and there are really relatively few navigations within them. So I wouldn't be surprised at all if the numbers are actually fairly low.

 

It'd definitely be interesting to know it for sure.

 

Yeah, future

 

So.

 

statistic for the next for an up for future web almanac, I guess.

 

Yep.

 

Yeah, this is one of the things that actually surprised me the most, working on Core Web Vitals and getting web developer feedback from day to day. I realized I was a little bit biased on single-page apps, where I only... Like the ones that you can feel it, right? Like you're browsing and you're like, oh, this is a single-page app. That was my idea of what a single-page app is. But when we got feedback from broader raise-the-partners, I realized I was using single-page apps every day and just assuming they were multi-page applications. So I'm really interested to know, I'm really excited about you all's work and getting the some numbers out there because I I feel like I can't predict what it's gonna say

 

Yeah, for example, again, going back to my sort of my previous employer, in the case of Wix that's built using React, actually all Wix websites are single page applications. And by the way, one of the main motivations was the whole transitions thing to enable a person who's using the Wix website builder to specify like cool transitions between the different pages. It'll be interesting to see what if and what they do with the transitions API once the if and when these land and gain cross-browser support. But yeah, that's a perfect example of using an SPA for a particular reason, even though navigation might be fairly shallow in most cases.

 

Yeah, and you mentioned WebAlmanac as the way to expose soft navigation. So I think crux would be a more interesting avenue to expose that, because it basically depends on the user behavior. You could have pages with many links that are theoretically deep, but in practice, no one ever click or two. So yeah, definitely I will. Yeah, it would be definitely interesting to also see how we can expose that info in crux.

 

Yeah, I'm all for crux. I love crux.

 

Cool, we seem to be winding down a little bit. Is there anything else that we need to

 

you

 

make sure people know about before we do our picks?

 

Can I add one more topic

 

Yeah.

 

on INP? This could be an open-ended

 

Mm-hmm.

 

one to leave as a challenge to the audience, but INP, I mentioned it several times, that measures from the moment you interact, like the hardware timestamp of the event, until pixels appear on screen. And there's so much focus on JavaScript and main thread and handling processing. But that is just one of many things that can get in the way of that time. We talk about input delay sometimes and what gets in the way other work on main thread focusing on long tasks. We talk about event handlers themselves. But you can have tasks that are queued up and run before the next rendering task. You can have a request animation frame that takes a long time. You can throw a lot of DOM updates that take a lot of style and layout, all of that on main thread. You can also throw work at the browser CSS or et cetera, that just takes a long time to render and makes the GPU bog down to rasterize and to get pixels out. All of that affects the time it takes to get feedback out. And I think there will be a long process of tooling updates, documentation, education, and like mutual, like even the best of us as experts are constantly stumped and learning in this department. And so as browsers become more sophisticated, to improve performance, more of the rendering pipeline becomes a bit of a black box that is hard to understand. And we're going to have to figure those things out collectively as a community. And I think a lot of the questions with INP right now, there's some low-hanging fruit, you know, why is my JavaScript getting the way? How do you define this? How to think? But then once you get past those low-hanging problems, you get into bigger problems where even the experts can be stumped of why did this take so long? Why was this so delayed? Why did delivered. And so we'll get there and I think that's an open challenge. It'll be an interesting couple years or however long it takes and then we'll drive improvements to these numbers. But I just want it to not leave today without at least mentioning that part of the problem which will be interesting.

 

Yeah, for example, just a concrete example of these sort of things, I'm currently investigating why certain interactions are taking a really long time in our application, especially on Android devices. And it's wholly unclear, based on the field data, whether the problem is network-related or CPU-related or both. And using RAM data to determine that is very challenging. Now, obviously, I can try to simulate these type of environments and see what happens in lab tests, but I can never know for sure that I'm actually simulating the scenario that most of the people experience, especially as I move to the higher percentiles.

 

Yes.

 

So yes, it can be really challenging. Yeah, the browser is an amazingly complicated beast, for sure.

 

Yeah, go,

 

Yeah.

 

go, go ahead, y'all.

 

Michael, no, I want you to talk about user flows.

 

So it is true that for all full page lifecycle metrics, taking your field results, which are coming from all users in all geographies, on all devices, in all sorts of conditions, and they might have followed any particular user flow in their long-lived session, can be difficult to replicate. And CLS does tend to lean more heavily towards loading type issues. Clear cut how to replicate, but even then we have issues sometimes replicating field CLS in the lab. But INP is an even bigger problem. And so there's a whole slew of new issues we're going to have to solve, which is we have these reports, how do I replicate locally in the lab? And one way to do that, perhaps, is to just, you know, with crux, all you get is your scores and you get your distribution of scores. You don't get insights. own event timings or layout instability using the performance timeline, you can report attribution and so you could get more insights and so you could report a whole session, the user clicked here then they waited a while then they clicked here then this network request came in and then right around this time on this type of interaction against this node coincided with this long task and therefore there was a long interaction like you could do things like that and project there in terms of helping transition from field data to lab reproduction. But what I was referring to is, even if you have a lab repro, even if you can see that this interaction is taking me a while under these particular conditions that you carefully set up, why? Where did the time go?

 

Mm-hmm.

 

Even that is a problem. And so all of those things are going to be very interesting and exciting. And we will be on Chrome team trying to evolve tooling to make that as easy as possible, also through documentation and et cetera. But that's why those numbers that you see now in field data, I'm still excited that we will drive those. We will improve collectively by focusing on this problem. We will improve it. And that excites me.

 

I love the Chrome DevTools. I live in the

 

Yep.

 

Chrome DevTools.

 

So handy.

 

Yeah, and yeah, it's like on this week's web performance working group call, Michael will be expanding more on that concept. So yeah, tune in if you're

 

I'm going to go ahead and turn it off.

 

so inclined,

 

I'm going to go ahead and turn it off.

 

then we can probably link the, like send the link to the presentation later.

 

Cool, picks. All right, well I'm gonna push this to...

 

Thanks for watching! Thanks for watching!

 

to I

 

Steve,

 

have picked.

 

do you have some pics

 

Do

 

for

 

bears

 

us?

 

walk in the forest? No, I was kidding. So actually all I have this week is, and you'll have to

 

you

 

excuse the heavy machinery outside my window here. Their timing is impeccable.

 

you

 

The usual dad jokes of the week. And sorry, I don't have the rim shot access chuck, so you might have to step in for me.

 

I think I've got

 

All

 

it.

 

right, so.

 

Did that go off? It didn't play.

 

No, you had to be in live mode, so that might be the problem down at the bottom. Anyway,

 

I am in live mode anyway.

 

yeah, I wasn't working earlier today, so we'll see. Anyway, did you hear about the missionary who went around sharing laxatives to people?

 

you

 

He started a religious movement. Thank you.

 

It's not working, I'm sorry.

 

Thanks for watching!

 

And that one is good enough anyway. So I knew somebody who was a longtime smoker friend of mine and he recently gave it up, Cold Turkey. He's doing better, but he's still coughing up feathers.

 

you

 

I actually smiled at that one.

 

And then finally, I was looking to buy some furniture and I went to a furniture

 

you

 

store and the furniture salesman told me, this sofa will seat five people without any problems. I said, where the heck am I gonna find five people without any problems? So

 

Yeah.

 

those are my picks for the week.

 

Chuck, can I go next? Because

 

Yeah.

 

my browser tells me our security team has decided that my browser will restart itself in approximately five minutes. So

 

Do it.

 

yeah, I'll be bumped off. OK, so my first pick is actually one of your Google colleagues, which is Felix Arnets, I think his name is, You know, our topic for today was performance, and he's part of the WordPress Performance Core team. I'm really happy that WordPress, you might say, finally, is putting significant effort into improving performance. Being such a significant part of the web means that any improvements that they can make have wide-ranging impact on so many websites and so many users, and I'm really happy about that, and I've spoken with him a bit, that they're going to be putting in. They've already started doing stuff, mostly collecting data, I think, for now. But they already have ideas of things that they want to do. And it's definitely a challenging problem because that ecosystem is so open and so diverse. It'll be interesting to see what they are able to achieve. So that would be my first pick. My second pick is watermelons, or actually in general. This is watermelon season in Israel and they are amazing. They are just so delicious. They are seedless. They are sweet. I can't get enough of them. You know, if you're really into fruit, then Israel is the place to be. It's a bit expensive, but it's just so delicious. So that would be my second pick. And my third pick is that same pick I pick each and every ongoing war in Ukraine. It's not winding down. It just keeps getting worse and worse and worse with all the atrocities that we're seeing. So I'll keep picking that. And I don't know. Hopefully, it will eventually I'll be able to stop picking it, but it doesn't seem like it's going to be anytime soon. So those would be my picks for today.

 

Yep, absolutely. And I think we all just keep an eye out for ways that we can help. AJ, what are your picks?

 

So I actually don't have a big list this week or anything in detail. I don't think, there was something that we talked about at the beginning of the show that I know I've got to talk about on creedsofcraftsmanship.com, but now I can't remember what it was. But I was gonna pick this thing and now I don't

 

D-L's keyword,

 

remember.

 

maybe?

 

Were we talking about that on the show? I don't think we were talking

 

I

 

about

 

think

 

that.

 

it might be a start topic for a future episode.

 

But yeah, sure. We could, we could pick a Matt Ryers things I never use. Um, so go is already a very simple language. It is, it is extremely small. It is smaller than, than JavaScript when JavaScript was small. And, uh, Matt Ryer has a talk in which he talks about things that he thinks are excessive and superfluous. And one of them is the else keyword. using else it's a signal it's kind of a code smell there's there's very few situations where you else really makes sense.

 

Just to give context,

 

Yeah,

 

So sure.

 

the alternative,

 

you pick America.

 

like I said,

 

Okay.

 

we'll probably talk about it in a future episode, but

 

Uh...

 

small functions with early returns is one possible alternative to else statements.

 

Yep. I did, but I don't remember. I think

 

Alright.

 

I had two things, but anyway. Happy Fourth of July,

 

Oh, you

 

everybody.

 

sounded like you had something

 

Oh, let's

 

else.

 

a little wait for that. Yeah,

 

America.

 

I do pick America.

 

As a Canadian,

 

Alright.

 

I'm gonna let

 

Haha!

 

this one fly, but okay.

 

As a Canadian, you're going to be supportive and cheerful.

 

I saw this tweet like happy treason day you ungrateful colonials.

 

Yeah, I had a picture of King George III. Yeah,

 

Yes.

 

pretty funny.

 

Something like that.

 

Yeah, I saw a few others that were a little bit more politically charged that I won't share. I'm gonna throw out a few picks here. I always pick a board game and this weekend we were down at my mother-in-law's house and she had this game that she was playing with all the kids and then she played it with us with all the adults and it was it was a lot of fun. It's a party game so I have to say I'm not typically a big fan of the party games in the sense that they seem to be kind of light. I don't know. I like the games that really make me try. Point zero five. Now on Board Game Geek, it has a weight of one, which means it's a real. And this one, it's kind of one of those mental word games, which has made it fun. It's called Just One. Really simple game. And effectively what you do is you have cards that it, you know, You get a stack of 13 cards, you take turns putting one up in front of you, and each card has five words on it, so then you say one, two, three, four, five, right? And then everybody tries to give you a clue, a one-word clue, to get you to guess the word. And it's a cooperative game, and so if you fail to guess it, then I guess the game gets the point. you get the point. And so, you know, if you get seven of them, you technically won. But if you pick the same one word clue as somebody else, then both of you have to take your clue out. And you can play with up to seven people. So anyway, it gets kind of tricky because you don't wanna go with just the obvious answer because if you do and somebody else does, then your guess is out. And anyway, it was a lot of fun. enjoyed it, enjoyed playing a party game, go figure. But yeah,

 

you

 

so

 

Thanks for watching!

 

I'm gonna pick that and then I'm just gonna encourage folks to go check out topendevs.com slash conferences. We've got a bunch of conferences coming up over the, toward the end of the year and I would love to, you know, help In JavaScript, so yeah, the JavaScript conference, I think is in September. And then we're gonna have conferences for all of the different frameworks. So React, Vue, and Angular, because we have shows for those, and know a lot of people that can come and share awesome stuff. So anyway, those are my picks. Annie, do you have some picks for us?

 

Yeah, so from the technical end, I wanted to call this presentation from 2018. It's by this guy, Halvar Flake, who at the time was at Google Project Zero. It's called Security, Moore's Law, and the Anomaly of Cheap Complexity. And he's talking about it from the perspective of security, the fact that machines are getting so capable that it's actually easier from a developer perspective to do something that's

 

awesome.

 

more complicated for the machine. And

 

Alright,

 

I really love

 

Joav,

 

the presentation

 

what are your picks?

 

it's really applicable to performance and it made me think a lot and especially you know in this world of frameworks and everybody including more things I think it really helped me empathize better with web developers as well so I thought it was a really cool presentation That's it for me.

 

Sure. So my first pick is just no meetings week, which

 

Yeah

 

relates to 4th of July and Canada Day. I work mainly with Canadians and Americans, and I actually had time to code in these last few days. Between Friday with the Canadians out and yesterday with the Americans out, I managed to land a few

 

Thanks for watching!

 

meaningful patches. Happy about that. So I highly recommend

 

I recently

 

it.

 

tweeted,

 

Maybe you're...

 

Joav,

 

Ah.

 

I recently tweeted a tweet that got some interesting reactions, which basically said if

 

Yeah.

 

you're a dev and you're in meetings all the time, then you're not a dev.

 

Ha ha ha

 

I saw that it imprinted my feelings. Yeah, so my problem is a mix of like, it's typically not meetings, it's mostly like emails and reviews and making sure that, so yeah, but writing your own, like yeah, writing code for your own and getting stuff done that you wanna get done is fun. And my second pick, I guess, is the return of real life conferences, which is exciting. So

 

Mm-hmm.

 

we have TPAC, which is the W3C annual conference that hasn't happened in real life for the last three years. And it's very much needed. And it's coming back this September. So I'm super excited about that.

 

you

 

And then there's another conference coming up this fall, I think end of October in Amsterdam called performance.now, which is always,

 

you

 

yeah, the best conference of the year, every year when it, you know, when we used to go outside of our own homes. So I'm looking forward to

 

Awesome

 

getting back there. Then those are my

 

Alright,

 

picks.

 

Michael, what are your picks?

 

I love Joav's picks, so I'll just start with that. But I have a lot of hobbies outside of tech, and so I figured I could share those. So we're on a podcast. I like listening to podcasts. And so one of my hobbies is sailing. And probably my favorite sailing podcast at the moment is by Matt Rutherford. He's got a podcast called Single-Handed Sailing. Matt Rutherford is a bit of an extreme person. and just started doing transatlantic crossings on his own, single-handed in a tiny sailboat, and then did the world's first ever nonstop round the Americas, where he spent 300 days on a sailboat and got flipped upside down and ate space food. And anyway, what an interesting person. And yeah, when I pick up hobbies, I like to do them pretty extreme. But this is off the deep end. And I'm trying to hold off from dropping everything and just moving on to about myself, we'll see how that goes. The other hobby I have is woodworking and I figured I'd share a fellow Canadian YouTuber and podcaster, Samurai Carpenter, which I find very entertaining. And maybe that's enough for now,

 

I'll have

 

but

 

to check that out.

 

those

 

Yeah.

 

are my picks.

 

I really get into the woodworking stuff as well. And my daughter wants me to help her fix her desk, which I think is gonna involve rebuilding it. So. But yeah,

 

usually the easiest.

 

I fix all kinds of stuff around here and I really enjoy making stuff and it's

 

Yeah.

 

different, right? It's different making stuff in your garage with your tools than it is making stuff on your computer. And

 

Absolutely.

 

I don't know, just working with my hands, it's funny because yeah, I'll get frustrated when stuff doesn't quite go the way I want it to, but it's just so relaxing to kind

 

Yeah.

 

of exercise the other muscle, so.

 

Yeah, my wife wanted us to buy a desk for my son from IKEA. And I said, why spend 300 bucks when I could build one in two weeks and $600 later?

 

Yeah, right. All right, we'll go ahead and wrap up here. Thanks you all for coming. This was awesome.

 

Yeah, thank

 

Alright.

 

you.

 

Thanks for having us.

 

All right,

 

Yeah,

 

till

 

thanks

 

next

 

a lot

 

time,

 

for having

 

folks,

 

us.

 

Max out.

 

Wait, I have a question. Oh, sorry.