Unpacking Core Web Vitals - JSJ 620

Well, hello, hello everybody, and welcome back to another exciting episode of JavaScript Jebber and this day, well, I'm supposed to introduce our panel first, and then our guest Steve has corrected me, so you got me aj I'm your hostess with the mostess or whatever. And then we got Dan Hey, and we also have Harry Roberts, also known as the infamous CSS Wizardry nothing to do with well, hello everyone. Yeah, I don't write any CSS anymore. Also, I picked that domain when I was seventeen years old,

So that's a portion retail for everyone watching. Don't let your children pick their own domain names. Yeah, but parents need to really be on the ball on that one, especially with the credit cards being like twelve year olds have credit cards. Now, I don't know how that happened, but that's the thing I haven't seen that that's terrifying. It has it built into the iPhone. It's like the credit card that you can create a subcredit anyway.

But today's topic is what are we what do we doing? Not child that child? I think today I'm talking about web performance. Yeah, not the bottles. Well, we can have a drink afterwards if we want. Yeah, No, I'm I'm jealous. You know, it looks like a really nice collection anyway, So let's go ahead and jump right in and Harry, why don't you tell us why you're famous and your most three recent controversial tweets? Well, I would. I don't think I'm famous. I certainly wouldn't.

I mean, I think if you do. If you work in the web performance space, you might have my I've come across my website before. But Mike most controversial tweets, I don't know. I don't really tweet controversial things anymore. Probably the most controversial ever was when Imagure i mg u R

dot com switched to a single page, fully client rendered app. Don't if you've noticed, if you look at an X profile now a Twitter profile when you're logged out, it doesn't show X's, it doesn't show tweets chronologically. It shows them in the most liked first find out. Seeing my own profile logged out, and it reminded me of a tweet from quite a while ago. I really went on an Imagure immature because they switched a fully client or

rendered status so that in group. Honestly, you're probably right. I've never heard it set out loud I've never tried set out loud untill just now, but they switched one simple image tag out for about two point seven meg of javascripts, and I got flamed for that one. People like you don't understand the business case of imager. They need to serve ads. They can serve ads, but need to serve the image first, and the white people willtop turning up. So I got flamed for that one. I got flamed for

saying people shouldn't use emojis in professional contexts or gifts in presentations. People. Really one guy wanted to fight me for that one, but I'm not a very controversial person. It doesn't really suit my style and certainly doesn't suit business about famous though, I have to say that I said it before we started recording, and I promised to say it again that in the particular space of web performance, you, Harry, are one of my tech heroes. And

I've been following your content for a long time. You know, your talks, you your posts, and I've learned a lot. So yeah, thank you. That really means a lot, especially because, as we were saying, just before we started streaming, you and I met like years ago. I reckon, we must have met six eight years ago and we have stayed in such ever since, but never again in person, which is a real

shame. But that really means a lot, because likewise I keep eyeing what you're getting up to, and yeah, that means a lot, thank you. Yeah, so I wanted to have you on the show because there are a lot of interesting things going on in the web performance space, and in particular we are a few months away literally actually a one month away I think now from Google switching up Cowork vitals. I mean they've kind of kind of

done it before when they changed the meaning of CLS commulative layout Shift. They have modified LCP over time a little bit in certain ways, but this is by far the biggest change that they're making. So maybe we can start with that. Yeah, I mean swapping first in put the layout and replacing it with IMP I think is it's drastic. It's a huge change, and I think a lot of businesses are going to struggle, speaking purely on it.

Gotally, I have clients who've got twenty two million good URLs in search console and in what is it, the twelfth of March, so it looks like one month and two weeks or whatever. It is these companies are going to have twenty three million bad URLs in search console. The difference is stark, and one thing I do kind of worry about, and it's not Google fault at all, but people have known this update was coming for a long long time and people are kind of I've not had a single client who's trying to

get ahead of the curve here. I worked with the client only last week who were kind of only just starting to really worry about this, because I don't think I don't think a lot of companies were just how big the shift

is going to be. I think it needed to happen. I think IMP is a much more suitable replacement for first Delay, but I do think it may have helped a bit in a stop gap period because the difference between the two as well, you know, is just enormous, and trying to go from FID to IMP in one hot this is going to be a real struggle

for a lot of companies. So maybe it's worthwhile to set the stage a little bit on that, to maybe talk a little bit about what co work vitals are, what I f ID was or is but you know soon will be deceased, and what IMP is that replaces it to give a little bit

of context happily. Yeah, so without slides or visual aids, I guess the best way to talk about core revitals would be Site speed has been a thing for well over a decade now, a long long time, but historically we had to lean on archaic and kind of esoteric events like the browser's load event. We talk about load times, but a load time is invisible to a visitor that they don't know what the load event is. You can have a really feeling page with a terrible load time, and the load time would

be completely irrelevant to what the customer experienced. So Google, to their credit very thoroughly researched, have tried to get some one size fits all metrics, metrics that can apply to every site in the world, and try to quantify the user experience of how fast that site felt. The nearest equivalent to a load time would be the largest contentual paint, which is simply one was the

biggest bit of content presented on screen. We've got culative layershift, which you already mentioned, which is did the page move around as it was loading or as you were interacting with it. That's not a performance metric at all. Isn't measure steed one bit, but it does measure the user experience and sort of measures with this page frustrating to load. And finally, yeah, we

had first input delay. And the whole point of first input delay is, in fact, I've got a really good analogy for first input delay and I inp and purely coincidentally, I'm sat in the right place for it. First input delay is when someone clicks a button for the first time on that page, how long did it take before the web application could start responding. And it only measures the first click, and it only measures how long before the

application could start repon responding. So this misses out to I must have some kind of emojis. I don't know what that was. So anyway, that miss two crucial things. The first thing that misses is it only measures the first click on a page. Now, if the first click happens to be really slow, but the next two hundred clicks are really fast, you only

measure on the really bad one. Conversely, if the first click is really fast and all the next ones are slow, it looks like your page is really click The problem with that is it's really easy to gain you could wait for a use as a click before booting all your JavaScript. You could say, well, wait for the first click and that's just gonna be a click

on anything and it'll respond really quickly. Then load all your JavaScript. You know that every subsequent click will be slow, but you know it won't get measured. That's the first problems first into the day, to just what quick is doing. Although yeah, let's let's let's put that. You know, quick is an interesting topic, but let's push it off a little bit. I did want to say that in most cases you really didn't need to even gain uh f i D that much because you just got to do the FID

score almost regardless of what. Oh yeah, by definition, I said that like we kind of that measurement kind of won in the sense that, you know, if anybody was a laggard and I worked at Twicks, and initially when we started we were even bad at FID, and then we fixed it and now Wicks has good f I D and it's that's that's that there's nothing

more to do in that context. So if you look at most web pages, they just have really good FID and it it's like that if if you know, like have an examined in school and everybody gets an A or an A plus, then you know that test is kind of meaning is meaningless. It doesn't really provide any information. So we needed to replace if I do

with something else. Yeah, exactly. So that was the kind of core problem was that it was like ninety websites past FID despite we all know that JavaScript is a huge runtime bottleneck, so how could ninety plus websites be passing that metric. The second problem with FID is that it didn't measure how long it actually took to do the work. The way I explain this to non technical stakeholders, very non technical stakeholders, is imagine you went to a bar

and you wanted to order a drink. Now, if you get to the bar and the bar is really busy, there are hundreds of people and only one bartender, it's going to take you a long time before you can place

your order for your drink. And that's first. In book delay, it measures your first order for your first drink, and it only measures how long it took you to order the drink, So it doesn't matter how quick the bartender is or how long it took them to get the drink to you that doesn't get it doesn't get counted, whereas interact from to the next paint. The analogy would be you might go to a really really busy bar and you might order a drink, and it might take you a long time to order

that drink because there are so many other customers there. But if you just order a glass of water or a bottle of beer, then the bartender can produce that drink very very quickly. If you order a really complicated cocktail, then the processing time of the drink will be increased. If you just stay at the bar and they slide it over the bar too and you take the drink, that's your presentation delay, and they can get the drink to you

very quickly. However, if you say, oh, I'm going to go and set over in the corner and the bartenders to bring the drink over to you, that's your presentation delay. So what ironp does. It doesn't just measure how long it takes to order your drink. It measures howing it to make your drink and how it took for the bartender to put the drink in your hand. And it does that for every drink you order, not just the first drink, so I think I feel like first time. But the

lay was really easy to gain for those two reasons. It was only the first click, and it only measured the delay to start the work. I NP is much harder the past because it measures well between ninety eight and one hundreds percentile, so more or less your very worst clicks, and it's not even clicked. It's interactions, so keypressers and stuff like that, and then how I'm accepted to process that, and how except to display that to you. It measures a lot lot lot more work. And that's why most sites

are going to go from green to red overnight. It's a few more thoughts both about FID and I and P. So from the get go, I had prompt issues, let's say, with FID, and I was very upfront with the people, with the great excellent people at Google about it, you know, Anny Sullivan, Michael your Wise while he was there, and others.

Patrick And the problem is that in many cases, if your website was especially slow in loading, you actually got better FID because if your JavaScript took a long time to download, so long in fact, that the user interacted with the page before the JavaScript actually even loaded, then when and on the other hand, the page had let's say SSR or SSG, so the content

was actually already visible. Then you would click a button that would literally do nothing because the JavaScript wasn't even wired up yet, and from the fid's perspective, it would be you know, instantly responsive. You know, the response

would be effectively nothing, but your FID would be excellent. And that was one of the issues that we had that again at Wicks that initially, when we started to improve the download speed of the delivery of the JavaScript, they actually had, you know, hit this kind of valley where it seemed to be getting initially worse before it started getting better, simply because you know, we were the pages were getting interactive sooner and that problem I just described was

less likely to happen. But yeah, you know, yeah, go for it. Sorry. I've run into the exact same thing on client sites. Clients very aggressively deferring their JavaScript would end up passing fit purely because even clicking a native browser input like a button, you don't have to wait for the

JavaScript devan handles to be attached. Browsers have their own event handles attached the buttons already, so exactly as you say, if someone interacts with an interactive element before the JavaScript is booted, it will still capture a valid input. Even that input doesn't do anything because it's the other thing first input delay and iron p well, sorry, just imp Even if there isn't a UI up day afterwards, even if there isn't a next paint, you still capture a

score for every click. So what that means is, in the case of FIT, the button doesn't have to do anything. It doesn't have to do anything at all. It only captures the fact that you clicked a button, and if it needed to do something, we could have done it immediately. So exactly as you say, a big risk was people really really aggressively deferring and lightloading their javascripts could sort of skirt around the system purely because the chance

of someone clicking before the JavaScript had run was actually quite high. Now, you talked about the fact that you're seeing customers and it maybe it's worthwhile to mention that you work as a freelance consultant and you work with customers looking organizations looking to improve their performance of the websites, so you're obviously exposed to a

lot of poor performing websites and a lot. Yeah, you mentioned that you're seeing scenarios where they currently have really good FID and even LCP and CLS and consequently are really passing coed vitals on most of their pages in for example, in the Google Search console, but that once they switch over to I and P that the situation will be much worse. Now, it's interesting because I

brought up this concern with the people from Google a while back. I don't remember if it was with any or with Rick or with Michael one of them, and their response was that according to their tests, most what they saw was that most organizations that have a poor I and P or will have poor

I and P also already have poor LCP. So their argument was that the overall ratio of passing websites won't change that much because the score for like you said, this score for that interactivity, the interactivity score will drop, but it will have less a lesser impact on the overall commodative score of all speed core work vitals. Would you agree with that or not based on your person Yes, I haven't seen things that necessarily corroborate that, And do you know

what I don't have? I really don't have the access to the data that they do. So I look at a small enough number of data sets that non no two look alike, and every single site seems to have unrelated issues. So you know, really I see sites that. Yeah, so I've got a client at the moment who doing really well in LCP, really bad in CLS, and I n P their LCP is great, It's been great forever. I don't typically tend to see patterns, but I'm looking at a

really small scale. So I'm not talking HD archive. I'm not talking you know, Google's crook data. Based at large and on my own clients, I can't really there's not contently decipher or see any patterns that suggest that. I have to say. That kind of surprises me to an extent because I would expect for you to be seeing the same issues over and over and over again. Yeah, I mean, really, it's really surprising. Some issues

are really common. But we've had I think the performance industry and people who care about performance even a little bit. Why is the fact that some things are always just gonna will always cause you problems? Client side rendering is a terrible idea. So if you want to be fast, certain things are just starting to get filtered out, and those same mistakes that I would see five years ago are far less common now. What I'm seeing on a per project

basis is every client has pretty significantly different problems to the last. So, you know, that kind of moves us over to the next part of the

conversation. I guess because when we were talking about, you know, what we should discuss on this podcast, I thought that an excellent topic would be to talk about, you know, what you are encountering in various customer site obviously without naming names unless you really unless you really want to, yeah, but probably you know, yeah, basically, yeah, basically things like on the practical side, you know, things that you tend to see in you

know, mistakes that people tend to make, but also amusing stories if you can share them. Yeah. Well, like I said before, it used to be five years ago everyone had gone full client side reacts and that's always gonna start. And then everyone now knows that service side render and then rehydration is faster, not perfect, but certainly faster. So of the age old problem seems to be filtered out. I was I think, well, I think I don't know, how about it was a tweet of mind that was

responsible for a lighthouse check for are you lazy loading your LCPM? And because that was so commonplace even before WordPress plugins enabled that by accident, all these really common problems. I think even just non performance engineers are now so aware of web performance that basic mistakes, certainly on the projects I'm seeing, don't

really get made so much anymore. Where if I can interject, for one thing you mentioned, you mentioned client side rendered React you know, basically websites or projects that initially started with the create React app, yes, I have essentially by definition will have poor core performance as is measured by core advitors.

And that's not rising because obviously, you know, if you need to download a ton ofavascript, then you know, run that JavaScript, makes several AJAX requests, run more JavaScript and only then actually start showing stuff, then obviously that's going to be much lower than a website that just download stuff from the get go. But the interesting thing is that I'm when when speaking with various let's call them larger companies, companies that build let's call them quote unquote web

applications, a lot of them still work this way. Uh, if if the app, if the web app is not seoed. Uh. If if it's you know, if it's something that's behind a login screen or whatever, then from their perspective, you know it's it's it's so it's okay to work this way. So I'm kind of agreeing the market's splitting on this regard, Like some sites care about load performance and a lot of sites really don't. Yeah, and I do agree with that sentiment. So, for example,

my accountancy software is all web based and it's slow. But if I look into my accountancy software, I have to do it, and I know it's going to take me at least thirty minutes anyway, But I don't mind it being slow as long as once it's there, it's usable. And the sensitivity there is a lot less than if I just want to find out if I just want to quickly buy some groceries on the way home or something really quick, I try to buy something quickly and leave. Again, there's a lot

more friction and a lot more sensitivity. If the task itself should be a two minute tests, you don't want to spend ten percent at that time just waiting, Whereas if the tasks are thirty minute tests, you don't mind the different cost. I don't have any research to prove this, but I do sympathize with the use case of we're a web app. I'd be happy to wait for photoshop in the browser. I wouldn't be happy to wait the same

amount of time to work out what time my next train is. There is no way of quantifying that sensitivity, but I do believe it exists, and I do think that there is there's no definition between what's a web app and what's a website. One thing I do think is if you're a company who can name five different pages on your website, Oh, we've got the homepage, a product details page, a product listing page, a search page. If you've just listened four different pages, you're not a single page app.

So don't build a single page app building the page. If you can name pages, you aren't a single page app. Trello is a single page at Google. Sheet is a single page app. Your e com site is not a single page app because you've got your homepage, your category page, your product listing page, your product details page, you've got your faqu's page.

They're all different pages. So a mass Twitter is I mean Twitter and Facebook, Right, would you say that the feed is one app, and then because it seems like the the in between is don't try to build a single

page app where you literally everything that you do in a single application. I agree, that's I mean, that's beyond silly, except that you know that's what's been done the last ten years and and there's no sense and if you have a lot of interactive stuff doing server reloads for every single interaction, but like there is some sort of delineation, like your feed is a single paye ab, your account settings is a single paye ab, but your feed and

your account settings are not the same ap it. I mean, so so if I can, if I can touch on that. So we've had Alex Russell on on the podcast actually twice, and I think we had them almost a year ago the last time. And the distinction that he kind of makes is based on the amount of interactions, like is it is it something that you like click? Like are you clicking a few times to maybe a few dozen times or are you going to be clicking hundreds of times? And now

I don't remember exactly where Alex draws the line. I know that he's done a bunch of research on this topic. You you know, you can chase check his website, which is slightly late I think is No, that's actually that is handled. I always forget frequently not yeah, I and frequently noted, so you can check his Yeah, he's he's funny like that. So anyway, so he's done research on this topic. Uh, and and that's the delineation that he makes. And I kind of concur with that. So

I don't know where the cluster point is and I wouldn't. I don't use I agree with him, but the way I've always would, I'm not. I kind of I've never heard him say that, but I agree with him. The way I've always described it to my clients is how big is the feedback route. If you've got Photoshop in the browser, you don't want to wait a full round trip before you notice the pixels turning green. If you've got Google sheets, you don't want to notice a full round trip of latency

before sell A and cell B gets summed together. So if your feedback loop where you expect feedback is instant, then that is what I would consider more app like if read and write are almost one to one, whereas if you look at an e commerce site or buying. Yeah, just look at an e commerce site or a news website. You don't have feedback loops. You spend most time consuming, especially on a news website, your scroll, you

read, your scroll, you read. That. Didn't want to be a single page app if you are flicking through an article every half a second, which you wouldn't ever be doing. But it's not until you're doing really frequent and you need that feedback loop to be super tight, that you need to build things in the browser. So I think for the most common news cases, eCOM publishing, certainly publishing a single page app is not the right process.

Now your checkout flow, that might be a single page app, because it might be a case of like as you say, it's behind a log in, it's not indexed anyway. By the time someone's got into the checkout process, they asked statistically less sensitive. Studies have shown that once people have committed to buying something, they are more like to stick with it, so they're less sensitive to site speed. There your check out, So that could

be an SPA. That's absolutely find because by and large every pages the same, just different form details, your address, you're billding details, discout code, et cetera. That's where your feedback loop is. Okay, I've got my credit card in my hand and I'm going to do that. So I think Alex says interactions. I think I'm saying the exact same thing, which is nice because Alex is very smart. But I always describe to the clients as where do you want that feedback loop? Trello, you want to drag

a card from one column to another and see it land there instantaneously. If you're clicking a related product that's another page, and that feels like the feedback weroop doesn't need to get anyways near as instant as dragging a card from one column to another. So going back to the topic of the issues that you encounter as as a consultant coming in on ICE mostly to assist with projects where performance is an issue. What are common problems that you encounter and what are

amusing problems that you encounter? Really common problems are things like festicization of things like microservices, micro front ends, composable commerce, and single page apps. They're really common. So nearly every site I look at your single page app, you're struggling with performance, maybe not because of your own fault but because you weren't aware that co ed vitals doesn't play very nicely with single page apps

at present at least. So I've got loads of clients at the moment who their sites are pretty fast from a cold start, but the fact they an SKA means a lot that data gets lost, so they appear a lot slower than they are. One thing I keep coming across is and two projects in a row now is composable commerce. And it's like, right, we've got to make API calls to X different third parties. That's all latency. That

all just goes into time first bite. Paralyze as much of it as you can, but it's still kind of for the most part, only as fast as the slowest response. Then you move to like your server, your client rendered so rehydrates, and you move into the client rendered version, the rehydrated version. All those API calls now happen on the client side. And I've

seen this in two projects in a row. Everyone loves to have API dot company dot com on a different domain, which means immediately across origin request, which means immediately you've got pre flight requests. There are two projects in a row. Never really noticed it before. But full round trips of latency in band on every request to the API end point because they weren't cashing their pre flight requests. These are rare things I see that do They don't amuse me,

but I feel like you designed this problem for yourselves. If you've just had Company dot com slash API, get rid of all those problems. But because everyone loves to have a PI dot Company dot com, you now enforced pre flight requests. Hold on. I want to push back on that.

So can you think of a reason why people are doing that? Because I know of some reasons why it's beneficial, But like, are you just dismissing a wholesale or do you think that people don't actually have the problems they what do you understand what the impetus for the API was other than cuteness, Because I don't think it's just cuteness, although I'm sure that plays a part. I don't think it's just cuteness. And I don't have like a list answers

to why. But architectural simplic simplification, Like a lot of companies just hang things off domain so they can share them internally a lot easier. They can deploy as their own sort of architecture on its own kind of its own standalone product. But yeah, I just feel like a lot of problems like that would be the performance problems it brings. I'd like if we could just stick this on Slash API slash and using resources like preconnect or something like that doesn't

mostly solve that problem. I mean, you're going to be waiting for the JavaScript to download in most cases anyway before making those API calls, so you could at least use that JavaScript download time to pre connect to that API endpoint. So pre connect wouldn't work because pre connect will open a CAUSE. You can open a CAUSE enabled connection, but you don't explain why you need it.

So what a pre flight does is it says, oh, you've got a request headed that we don't We don't like that, you can't you can't hit us with that request. Did you actually get cores on subdomains? I forget you do, yes, cross origin and a subdomain is a new origin.

So I've got a client at the moment, and if they just move from company dot com slash dot, if I move from api dot to slash API, they would remove all the CAUSE issues because cross origin a subdomain and a different subdomain, a different port would put you in that cross origin category. Oh so it's also a different port. No, it's either either. It's either. Okay, yeah, that you come in issues with local hosts on that all the time, which is one of the reasons that tell people

to like use domain or whatever. But so for that, I think that in the modern era, I think that the reasons that we did API dot

whatever don't hold as much water as they used to. One of the reasons had to do with cookie policies and all browsers that are out there today other than your Xbox and your Wii have browsers and those you don't really you're not as worried about, like clickjacking and cross origin forgery of a bank website on those you know, legacy systems that people still use all the time but are

never going to get updated. But all of the browsers that you have on phones and on desktops where you're likely to do work work, the cookie settings are now such that you can you can set a few flags like HTTPS only, server side only, strict origin policy, you know, a few things like that, and you can get all the benefits that you would have gotten by having your APIs go through a separate domain where you you didn't necessarily want

to mix up the chance that your authentication middleware would be allowing cross site requests via via API and accidentally get authenticated with a cookie when they shouldn't have been a j You're absolutely right. I'm not really thought about it like you've made me realized. The whole point of using API dot is you're opting in to cause enabled requests. You're opting into cause you want cause to stop things leaking. But now we've got other ways around that. I guess we don't need.

So I guess the whole punk people did use a got was like, no, no causes a benefit for us, it's a feature. We want to strict credentials. We want to make sure we don't need anything. So that's why if we put it on API dot we get all that for free. Yeah, it's a performance hit, but so you're absolutely right. I guess the simplest answer is causes a feature, not a bug. Yeah so,

but but I agree. I believe that you can get all of the same security features today and and be reasonably assured that if somebody hasn't updated their browser for the last year or two, which is most people that that they still have that in their browser, Like it's been part of browsers long enough

that I think, I'm pretty sure that it's safe to do. But I mean, my advice would be, if you're going to tell somebody switch over from API to slash API slash, that's great as long as the security concerns follow. Oh yeah, absolute in a replace. Yeah, you just said something that really amused me. AJ about the note updating your browser, because whenever I go on my wife's computer for some reason and I open up the browser and I see that red button saying you must update now, I'm like,

how did you not update? My My wife probably updates her browser about as frequently as she updates her operating system, which is, when I sit down at it, I can tell that there's nothing that she's immediately using for something that can't be restarted from and I restart the computer. So about twice a year when she asked me to do something on her computer, her browser gets updated. And that's because she has a techy husband. Yeah, yeah, I really don't think. I don't think I'm I think it right.

I think it's really easy for people like us, who are very tech fluent and who surrounded by every day it's second nature to us. But people aren't in tech. Why don't need to update it? It works? It works,

so title call back in iOS seventeen, I don't care. So basically, you're saying that the fact that Windows ninety five, I think, like couldn't run for more than thirty nine days straight without the restart was the feature rather than a bug that I mean, you know, we give Microsoft a lot of crap for the you know, your computer is restarting and in you know, sixty seconds, But they're not. I mean, they are servicing people who are non professionals and who are you know, they're servicing the lay

people, you know, like the average person you know. So so the average Mac user is someone who is it like, they're in a different tier of work or a different tier of economics than the average Windows user, although you'll be surprised, like I know, like I don't want to, you know, say anything bad about you know, designers, but I have seen

some that like we're kind of unaware about tech. But tell me, like Harry, don't you like you know, come into a project feeling all good about telling them how they should optimize this or optimize that, and then run into like a twelve megabyte gift that they're downloading, you know, in their homepage or something like that. Yeah, luckily that's less frequent, and that's

almost always a CMSA too, like a CMSUS uploaded that. So yeah, I like when I find really impactful, interesting or exciting things to tell people. But part of my standard process is, let's look for anything silly. Let's I take waterfall shots and I organize them by largest and smallest resource. And I once found a one point two megabyte fab icon, and that's because of the designer who was asked to export the fabicon took the entire spritesheet.

It was back when people you sketch, and it was the entire icon sept for the entire website, and they couldn't be bothered exporting the fabicon, so they just set the bounding box to cover the falyc on the neededs and that the the fabic on the ico ended up being this enormous bank of data every icon for the site, and it's had a bounding rectangle around there. When they needed they exported that, it contangled the data for all the others.

Is that right, you've got one point two megabyte faicon after Jesus it was unwieldy, Well there's your problem, Like just that's really low hanging through. Yeah. By the way, one thing that I've also encountered in many cases, like you know, when websites, especially created by designers, is that they construct the images so like you have something which is an image which should have been let's say, well i'll call it a JPEG, but you know,

a lossy compressed image. But they've actually because they use some sort of of the software for actually doing it, and they worked in layers. They actually create multiple layers, and then they and and they need their transparency because they're now layering them one on top of the other. So they're all PNGs. So what could have been one jpeg ends up being comprised of like five

PNGs. Yeah. I mean I've seen back when I used to do a lot of very front end work, kind of slicing other people's photoshop files. My biggest gripe when people make flat looking at UIs when I say flatly, I don't mean the design style. I mean something looks like it could be a flattened signal image, just a raster image exported as a JPEG, not even with any transparency by the way. They made the images by layering things

up in Photoshop with loads different blends modes. But I'll have to like isolate it, flatten it myself, make it transparent, put a background on it,

and then it was all just nightmarish. So like that. Designers then, and I say designers front and developer as people our colleagues might use sort of blend modes in the browser to kind of achieve the effect, but then that just has runtime overhead that can get really sluggish on very heavy pages when you've got images and elements interacting with each other and the kind of intersection of

their blend modes. So yeah, that's not the stuff I'd tend to run into very often because I don't get to work on very I love my clients so much, I love you all very much, but I don't get to work on very creative projects. Normally it's just a case of here's our asset library of every product wesell and that's it. I guess if you look at WIS, you'll see things that are much more creative. Well, one of

the more creative pages that I saw at Wix. It was actually an internal, an internal website built so WIGS does a whole bun a lot of dog footing. All the wigs stuff is actually built on wis or as much as possible, and certainly all the marketing pages that Wix users are built on WIGS. And I was asked to look at one of those marketing pages back in the day and they you know, talked about waterfalls. In this case,

it was literally an image of a waterfall. So they created a beautiful page that had this waterfall running down the entire page, and it was built as one image that was ten screens long. So so I basically told them, let's split this image up and lazy load the rest. Something along these lines, so don't have a really creative thing. I saw somebody gaining LCP that

that wasn't intended to game. That that really destroyed LCP because of the huge image that, Oh, I know, you reminded me of a funny story about you broke an image into smaller pieces. So I had a client and if everyone's watching just looks at like my little rectangle I'm in here, that's your LC. Let's say that's your LCP image on your on your homepage. This client was struggling to get it fast enough because the image it was quite

detailed. They were struggling to optimize it enough that it looked nice but was still fast even if they're preloading whatever. It's all they did because they sliced it into four images and then put them right next to each other, and the image loaded like in a random order, but it was about four times faster because the image each file was about a quarter of the size. So whichever one of those four images arrived first was the LCP, then the subsequent

three were ignored. It was a horrible loading experience. You'd see this image go h and it would a bit random, so sometimes the second image will be first, or the third will be first. Yeah, it is worth It is worth noting, by the way that in the discussions of the W three see Web Performance Working Group, one of the items that keeps coming up is how to deal with images that get progressively rendered, like when should you measure when? When is the NCP? When should the NCP be measured for

progressively enhanced images? Uh? And you know it's it's one of those cases. It's kind of hard to say, well, that's a pretty big topic. AJ was going to say something before we move on. Yeah, do you know why that happens? That's splitting it up into four made it load faster. Prioritize one of them a babula, So prioritize it seems it can give high protis one of them. The compression algorithm is based on pixel with, so if you depending on how you vary the pixel with when it analyzes

the image, it compresses differently. So sometimes just randomly resizing an image, you'll get better compression because you happen to hit one of the default boundaries that will try. There is a tool that you can use. Have you heard of image optum? Yeah? Yeah, yeah, So image optum will basically brute force every possible dictionary size in the compression algorithm and find which dictionary size

happens to be the best one. And on an im too mac max it will take a couple of minutes for a relatively small image file, so it it really does brute force every combination that it can, but it will reduce the file size is much much smaller than probably any other program. That's the other I did not know that I thought you were talking about I thought you was talking from a browser's perspective, how I think size that is on the algorithm for me, by the way, in that context, i'd highly recommend

watching that talk from the Performance Now conference. Who was it that gave it? I need to find it about about how HDP two downloads multiple resources in parallel, the prioritization. That talk about prioritization. You know which talk I'm talking about? Was it from three? Yes, it was Robin Marx. He was talking about, Yes, exact loading up the cutting edge. It was incredible, it was It was the exact kind of content I lived for.

It was really really good Robin Mark's resource loading at the cutting edge. Yeah, it's an incredible talk because he talks exactly about that kind of a scenario where you're using the HDP too to download to you know, to download these four images effectively in parallel, and it depending on the browser and on the CDN on the server, it might download faster or it might download slower,

and you know, it really kind of depends. Thest is, if you download all four images in parallel, you just slow all four of them down. But if your braws AER and server talking the same kind of paroraitization language. It'll do image one, two, three, and then four in order. And that's how you can gain lcp is because you can be fairly certain that instead of all four images are arriving at the same time, you get one then two than to read them for and it's we must say that

please don't gain the metrics because you're doing more harm. You're doing more harm than good. At the end of the day, the metrics. You know, Google might care a bit, a little bit about the metrics, but the ones who really care a lot are your visitors. And they don't care about because the score. They care because of their experience, and if their experience is shitty, then they will leave and then you'll write it right now.

I had this discussion today and it made me realize something really interesting about LCP as and Max. I've been saying this for quite a long time, and I know my friend Andy Davis has been saying this for a long long time. Largest isn't always the most important bit of content. If you go to the left hands a website, or you go to the British Airways website, the biggest bit of content is a picture of an airplane. Most important bit of content is the form inside of it, so we need starios like

that. I tell clients you need custom metrics as well. Use the element timing API. We don't care how soon a user could see that picture of an airplane. We care how quickly they could see the form for booking a flight. So I've got a client at the moment they have a really they're LCP sitewide is I think it was two point six seconds. As far as

colle vitals is concerned, we only need to find one hundred milliseconds. But they read a study somewhere that said somebody else improved LCP by one second and made ten percent more money, So they want to get their LCP down to one point six seconds. It's going to be really difficult for this website because they hit a lot of third party domains to build the page. A lot of the plages are still client rendered, so it's going to be really difficult

for them to hit one point six seconds. So I said to them, kind of as a joke, was I know what we could do. Why don't we redesign. It's an e commerce website. We redesign all the product pages. So the heading is the biggest bit of content and the image is really small, then you'll have a really good LCP because text is fast and images are slow. No, no, we can't do that because weally people see the image. I was like, so, do you care about the

metric or do you care about the customer experience? What we need to measure is how should And then I said to them, you don't care about the largest bit of content. Your image just happens to be the largest. What we need to measure is how soon someone could see the image. If you just want to get a one point six LCP, just just to say you've got a one point six LGP, we'll just make sure your LCP is an eight to one and not an image nice And we can't do that. We

can't do that. So funnily enough, I was working on a page where the hero image was only really slightly larger then the title text. So I said, you know, if if we make the text just a little bit bigger, my name is just smaller. Yeah. Well, it's interesting because the LCP. I've read the LCP spec inside out, So I wrote an article about how to because it comes back. Actually, this brings us nicely down back to progressive images. But the LGP algorithm also uses intersectional observer to

see how much of the element is in view. So I've got certain clients where if the if the mobile phone screen is short enough, the hero image is majority off screen, there is the h one. But someone on a higher resolution or slightly longer like if someone on an iPhone Mex, then the image well not on an iPhone obviously, if we don't cat dry estate. If someone's on a big phone, the image is far enough in viewport that it becomes LCP. So the exact same page on different mobile devices is really

difficult. So that's why when you look at pay Speed Insights or Crooks and it just says desktop and mobile, it's really important to remember that inside of desktop and mobile there are also a lot of varieties. What I'll find is I don't like Lighthouse as a tool for me professionally, it's too simple, it's too basic, But clients love it. Web page tests their mobile devo vice screen sizes are smaller than Lighthouse. Yes, I'll run a Lighthouse test.

Yeah, I'll have like to run a Lighthouse test and it'll come up with a different LTP to the webpage test that I'm running, so there's loads of disparity there. But yeah, I read the spec inside out, and the first thing it does, or one of the first things it does, is it calculates how much is even on screen, because if the image is bigger than the h one, but the image is majority of screen, like

you say, then we just don't count what we can't see. And that brings on to the progressive images thing, which I think it's been a frustration for years. There is no there is no even though customer experience is better, there is no benefit to performance scoring using a progressive japeg, which I just think is unfair, or any progressive format. Yeah, I agree.

Why would you want to use a progressive j peg because you get content, You get meaningful potentially meaningful content on the screen faster, do you really? Because I remember progressing JPEGs and they just kind of sucked, So you'd have to you probably want to do You're probably want to build them yourself. So they contain scams and you can pass in a scan file to your batch process your images, or do it all in bulk whatever. But what can end

up happening is the image. The progressive jpeg in beds like eight versions of itself, and the first ones will look really disgusting, and that's not a good customer experience. You're probable to build a scan file that says, just build me three scans like medium high, very high quality, and do it that way so you avoid the really really low quality end of progressive JPEGs and just opt into like medium high and super high res. That's what I tend

to do. I think I could buy into that if there was a way for the high DPI displays to know to pick the like for it to just not bother loading the super high res one unless it's high DPI. Well, you can with the image tag, with the picture tag or the image tag even these days, with you can specify images to be associated with it with

the device's DPI. The browser is smart enough. So then why wouldn't I just use the picture tag and use multiple JPEGs rather than a progressive each each one of those complicated Yeah, each one of those multiple JPEGs would have multiple JPEGs inside it, so for every use case you could potentially for every one of them have a slightly faster LTP. Progressive is I think sort of a real benefit. I'll give another scenario. I'll give another scenario another thing that

I encountered with so lot are people building their website. Let's say with white background, a dark background image and white text, and then what would happen is that until the dark image would actually load, the text would be white on white. So the text would be there, you just couldn't see it. So even have so at a certain point in time, we actually would have like image placeholders, kind of like what you get in like in YouTube

style thing. But or I think Medium kind of introduced was with the first Yeah, to introduce that just so that you could get you would get the feeling that the page how the page should look like, and see that text

faster than otherwise. But but I do have a question before we were running a long and I do and there are a few questions that I did want to get to talk about because I assume that with at least some of your customers, you're running into scenarios where let's say you've got poor ironp but looking at the site, it's because they have a lot of let's say third party scripts or pixels, and then you say, well, you know, you want to improve INP get rid of your pixels or get rid of half your

pixels and say we can't we need them for our marketing campaigns, or alternatively, their score is poor because they're using like some sort of heavy framework, client side rendered whatnot. Like, what are you going to tell them rebuild, re architect your entire solution? Like what do you do in those scenarios? It's yeah, it's difficult. It's really difficult to advise because the answers

are very complex. And one thing I find really interesting is if you read anything on web dot dev, this is always the same break up your long tasks. It's like, well, how step by step, how does one break up a long task? Be goes? If I've got a function and JavaScript runs like run to completion, so function can't be interrupted or paused halfway through. It has to finish. So if you've got a click handler that has to do x amount of work, telling someone to break that up is

really difficult because well when do I do it? So what I try and tell clients is it's just gonna be really difficult, It's gonna be hard to do. But the biggest I was with a client last week. The biggest culprit of theirs was they did loads of synchronous Google tag Manager stuff. On every click, they track everything. Someone clicks the menu open, it gets tracked. They close it again, it gets tracked. They click in the

soot field, it gets tracked. They don't type anything that gets trapped, and all of that is like that measures like okay, ten cent of people who enter, who clicked in the search box never typed anything, so why why didn't they type? So it's valuable business data, but it all happens

synchronously. So for them when the biggest things, and like you say, it's a third party tag manager, is just fulfill the user need immediately and then sling all of that tracking work into like a set time out or request idle callback or you know soon not these schedular got yield. So to look for the obvious things. First look for the obvious things like okay, tracking,

move that into the next task. When you still end up with a task that's really large and you can't break it down any further, it's really hard to work out what if you've got a function it needs to necessarily do quite a lot of heavy lifting. That's when you start to get into trouble. And I'm not. I'm not. I will admit i've been a first person's admit on a JavaScript podcast. I'm not a very proficient hardcore JavaScript developer. I never have been. When it comes to breaking up long tasks.

All I can really tell clients is I can show you the tooling, we can look at what it's doing, but you need to decide, like which of this thing needs to happen immediately, which of this needs to happen for the user? And what can you do safely elsewhere right party If you've got really agreed times, that's actually what's That's actually what we ended up doing at

Next Insurance for our currently work. So we had like treat not terrible but kind of mediocre I n P. But we were really anxious about having good coed vitals across the board even when I and P lands. So we introduced party town and the improvement was dramatic. So now we really have excellent I n P. But aside from maybe third party scripts, like, I'm really

surprised when people have really long tasks. I mean unless you're building a really sophisticated web application that does something you know, like super heavy, in which case you know that kind of brings us back to the web applications where you where these issues are kind of different. Then I'm really surprised at having really long tasks like what are you doing like computing pie to the millions digit what? Like? What's what's all this computation about? Do you know what?

I've got anyone listening? I am for hire and ironp ticks in on the twelfth of March, so get in touch. But I've got a full section of my workshop that starts out with we always blame JavaScript, and you know, like JavaScript is yellow Indeed tools, it's a big yellow slide. We always blame JavaScript, and the next side is purple for layer and recout style. But it's usually going to be a CSS with IP. What you'll find

happening all the time is got to be some synchronous layout threshing. So the JavaScript cope head might be quite minimal, but you know someone's getting I had a client where they had a list of two hundred and fifty product images and they want to line the image wits up with the image with an element outside of that instead of getting the wits of the element outside and then applying that with to the two hundred and fifty images. They got a NOE list of

the images. Then for each one, have e's image, make it that big, have eximage, and they did that all synchronously. Took five seconds. Layout thrashing, severe layout threshing. So oftentimes what I find and what I try and tell clients and developers that in training, everyone's clicked to blame JavaScript. But seriously, go and look for your purple and then purple is going to be either recalut style or it's going to be layout im in the

right order as you're looking at them. Recoup style layout. If you've got long recount styles and short layout, that is because you've got complex CSS selectors, or you've got a lot of CSS, or you've got a lot of HTM out. If you've got a long layout task that's going to be structurally the page is quite complex to layout. You might have a lot of overlapping things. You might have a lot of grid or FlexBooks that relies on each other, so very heavy as to describe it. Pages that look like tables

of data but aren't that are built using things like flexbox. Generally, you want a simple by the layer of the page. There make sure you don't add things to the DOM, but the dom wider. So a lot of the time long tasks are going to be CSSE recock style and layer I recock styles. Your cost going look at the cost of your CSS selectors, the amount of CSS or the size of the CSS object model, and the dome.

Yeah, two points I'd like to mention. So in the context of we talked about layout thrashing, one of the things to take into account is force three flows. It's like you you kind of mentioned it. It's, you know, a quick explanation. When when you modify the DOM inside JavaScript, then in most cases the browser will try to not relay out the page until it absolutely has to, So basically it will try to run all the JavaScript and only then when the JavaScript is done, actually apply the layout changes

that result from the DOM changes you've made. But if you if you kind of ask the browser the dome about let's say, the size or position of an element, you're kind of forcing it. You're forcing its hand, You're telling it you must apply all all the changes that you've done in order to

be able to answer that question. That's called a force reflow, and layout thrashing is when you set something ask something, set something as something, and you're forcing the browser to reflow like on every iteration of the loop, as it were. So in that case, it's it's beneficial to break it into even two loops, like do all the sets and then do all the gets or or something or or do all the gets and then do all the sets

whatever, but don't interleave the gets and the sets together. And I had a similar situation, but you know, we don't have time to go into the details you kind of described it. The other thing I'd like to mention is the CSS content visibility at a setting, which you can if you have a super complex page, you can at least say, well, all these areas that are below the fold, you know, you know, don't try

to lay them out now because nobody sees them. And if you know that they can't impact what the user is actually saying, then that can really speed up that sort of thing. Yeah. Yeah, I've got a really it's a nasty CSS selector, but I used it on my I profiled it and it turns out even the nasty CSS selector is faster than the cost of laying out long blog posts. I've got certain articles on my site there tens of

thousands of words, really really long. Most users aren't going to scroll all the way to the bottom, so most people aren't going to see everything. So I've got a selector which is main content space H two till the H two. So any H two you anywhere after the second AGE two, or you could do H two ent of type two. Everything after the second H

two content visibility auto. So everything after the second H two. So you've got an H one, an H two here, maybe an H two here, that's going to be pretty far down the article already by the time you're at the second H two, you're quite far down. That's what I do is I say put content visibility also on everything after that, so the majority of the article never gets rendered until something starts scrolling towards it, and that

more than halved layout costs for me on my particularly long blog pages. The only downside is, unless you're careful, you can get weird effects with the scroll bars. The scroll bar like rows and strains. You've got visible scroll bars. Yeah. The best way to check if that's working is go to the layer's panel and if the document layer is rendered really short or not really short. With the document layer is rendered, say maybe fifteen thousand pickles tall.

Then you scroll all the way down to the bottom of the page, then go back to the layer's panel and it says, oh, it's actually seventeen. That's how you know it worked because the layers pannel is what the brows actually rendered. So try this hack. Go to the layers pannel, see how big the document layer is. Then go back to your browser, roll all the way to the bottom of the page, go back to the layers pannel, and if that figure has changed from fifteen thousand to anything else,

it means the trip worked. But you're absolutely right. If that number is very different. Let's say let's say rendered runded fifteen thousand, but then it ended up being forty five thousand, that scroll bar is going to get a lot shorter. So so two things. So first of all, there's also the content what's it called intrinsic layout height or something, which you can

kind of use to contrinsic layout. Yeah. And the other yeah, and the other thing you can do is that when the user scrolls, you can remove the auto or something along these lines and they change it to visible, so there'll be like a jump when they start scrolling, but at least that will only or at least you can know something a on these lines, So you're you're kind of it's it's all built on intersection observer anyway, so you could hook into that and say, as we get closer, turn it from

also sensible or but that happens automatically. But you're absolutely right. If you're going to do this, you need contain intrinsic size. To say, every paragraph is roughly three hundred pixels tall, so every element you put contrain containing intrinsic size one pixel by three fifty or whatever, and that that should minimize the jumping that you're describing. Yeah, I think I think we need We are nearing the end of our show and we need to move into picks.

So is there anything else you really would like to mention? Honestly from me, not much at all. Just i NP is the next thing to worry about for most sites that are benchmarking core went vitals. So if you haven't been taking it seriously already twelfth of March, if you haven't seen the announcement yet, if you don't know where to look for your I m P scores, ask your marketing team or your SEO team or whoever's in charge to give you access to search console and go look for coll ed vitals in there,

and I'll tell you how to start looking. And you need any help with it, you can always get in touch with me. You can tweet at me. I've got some resources around IMP. That's the only real pressing thing that's on my mind at the moment. Do you know, as long as Google invent a new metric every two years, I've got a job for life.

Well, the next one, I think that's the next big change that's probably going to land is when they start they make soft navigations official, so even like in multipage application single page applications, they'll start measuring the navigations between pages that happen on client side rendered apps. But I don't know what the impact will be. Will it make scores worse or better? It'll be interesting to see. Yeah, I think better. I think sites will get it'll

be easy to optimize them and the scores will get better as well. I think that's my prediction. Time will tell. All right, I've got a hard stop that was thirty seconds ago, So let's go ahead and wrap up. First of all, Harry If people want to find you, where should they find you at? Regressively, CSS wizardry everywhere, so mastered on or X, or my website or email Gmail. If anyone needs anything, we've got any questions or wants any of the resources that I've spoken about, you

can find me at CSS wizardy everywhere. All right, Thanks. Now with that, we'll go ahead and wrap up get to picks. Picks are where we just talk about something that was interesting or that we liked or that's on our mind that could be dech related or not. I will actually go first this time. So we talked about image optim so I will drop a link to image optim It is, like I said, the best tool as far as I'm aware, for being able to resize images so that they're sid Well.

Yeah, it's brute force effective. So yeah, yeah, yeah it does. It does way better than it. It just takes a long time, you know, you just sit there and you wait. Okay, So there's that, and then of other things. I've been playing around more with Home Assistant. I now have it to the point where there's a sensor downstairs and I've almost I have the path to get it so that the temperature is changing based on the downstairs temperature. The thermostat is turning on or off based

on the downstairs temperature rather than the temperature that's in the thermostat itself. I just I don't have it quite working yet because I basically have to set four different events of like if the temperature goes here, if the temperature goes there, turn on turn off. If it goes here, if it goes there, turn on turn off. But I got one of the events set up, so I know I can set up the other ones. And then I

just ordered. Ikea has Zigbee stuff, and so I just ordered some of that and I'll I don't know if i'll get it this week or next or whatever, but they've got some switches and whatnot. The thermostat is z Wave, the temperature sensor is ZIGB. I'm using the Home Assistant made sky Connect for the Zigbi devices and some I can't remember what it is that they recommend, but it's on their website. Is the one they recommend for the zwave

devices. And so well, we'll see where all this goes. It is a pain in the butt to set up, but if you are looking for an alternative to a smart home, without all of that data being constantly monitored and stored by Google and Amazon. There's a path. It's it doesn't seem like it's a pretty one. It seems like it might be a really good market opportunity because I just don't Ikea actually has a smart app. I haven't tried it out because I don't really want all my data going to Ikea either,

because I'm sure that they don't. They're not even really a tech company per se. So whereas I at least trust that Google spying on me privately, you know, Ikia will just get hacked it. All the data will be out there unless they're maybe they're keeping it in some Ikeia cupboard. Yeah, so so anyway, and then I don't I don't recall if I've been talking much about the aquarium stuff that I'm doing, but it's just so fun.

It's such a good hobby. So I've got two aquariums set up, and I'm I'm going to set up a few more and try some different things, different plants, different fish. I kind of found the fish that I like. H One is just referred as autos, and they are bottom feeders. They they must have algae in order to survive. So if you don't have algae in your tank, it's actually good to have a little algae in

your tank. But if you don't have algae in your tank, you gotta put in some fresh vegetables and let them let them, or blanched vegetables and let them eat that. And then then the other ones are the the neon tetras. They just look so cool you have to buy. They say at least six of them, but I'm gonna say probably at least ten of them because the schooling behavior that you want to see. What's cool about them,

other than they look beautiful, is that they swim around together. And if you only have six of them, they don't they're not gonna do it as much. So you gotta get you know, probably ten of them. And they say you need like a you know, ten gallon tank for six or a twenty gallon tank for more, but you know, if there's room in the tank, you can put ten in a ten gallon tank. It'll be fine. And then I've got a mystery snail and a fancy guppy and they

all they all are in our main tank. Well in our main tank. It's not a fancy guppy it's a beta, but the beta is a mild tempered beta, so it's not attacking the other fish and the autos or bottom dwellers and the the neon tetras or mid dwellers, and the beta is a top dweller. So they they kind of have like it's only a ten gallon tank, but they have enough space that they don't have to to, you know, get in fights with each other anything. But it's just it's it's

a really cool hobby. It's it's uh, I'd recommend it, and it's it's just it's therapeutic to you know, it's art. You know, you build the tank. You're not just throwing in some gravel from from pet Smarter Petco and then dropping some fish in. You know, you'd like you gotta select the aqua soil and you you know, you pattern the sandy way you want it. You put a hill, you put some stem plants, you

put some other plants. It's just and then and then you actually have less upkeep than if you were to go the you know, the typical gravel you know, painted gravel route, because then the right bacteria in there, it becomes an ecosystem and it all cycle although there is a little bit of prep work you have to do to let the tank sit and cycle before you put the fish in so that that the right bacteria are there to help them live.

Because if they're not there, then the fish, the first fish you put in the tank, if you don't know about that, they'll die. Uh. But anyway, like there's there's less upkeep once once the ecosystem is going, you know, very very little feeding that you need to do, very little cleaning that you need to do, you know small. You don't change the whole tank. You just do like a ten or twenty percent water change now and then. But it's it's it's it's very it's it brings joy

to my life. So you can pick the aquarium hobby and with that I'll pass over to Dan. So I like my dog dogs, fish beat fish any the other week in my in my book, but that's not my pick. So my first pick, you know, how can I not pick it?

So? Uh, you know, it's the Apple Vision Pro. I don't have it, I'm not planning on getting it anytime soon, but from the videos I saw I've seen, it's simultaneously amazing and ridiculous, So you know, I got to, you know, to to say that it's it's a brave product, but I'm just not seeing the killer app for it yet and I'm not and people, you know, I I've seen people like videos of people walking with it on the street, like that's like an invitation to

getting beat up. I think, yeah, anyway, So so that would be my first pick. My my second pick is we're watching uh this show on uh on Netflix. It's called Griselda. It's not like a great show, but it's it's nice. We enjoy it, like if you're into the Narcos kind of thing. Uh, It's it's interesting. It turns out that she was like a drug kingpin in Miami in the seventies onward, and it's a TV show with Sofia Viergawa is actually, you know, playing pretty good

in the lead role and it's fun. So that would be my my second pick. And oh, one more thing that I wanted to pick. So when we discussed recording this episode, one of the things that I initially hoped that we'd get a chance to talk about was cashing rules. But since we haven't gotten around to it before we run out of time, I would like to recommend Harry's from the Performance Now conference, the twenty twenty three talk about cashing, rules, everything, and I had questions I wanted to ask,

but I'll guess I will save them for another day. But in the interim I highly recommend that talk. And finally, I'm like hoping for peace in the Middle Eastern Ukraine and that would be will be my pick for today. So over to you, Harry, if you've got anything that you'd like to shout out about, anything at all? Yeah, so nothing, nothing specific, nothing as relatable as yours. I'm missing cycling. I had a lot

of cycling, but the weather's just been terrible. So that's me. My next thing to focus on outside of tech is getting back on the bike. It's hanging on the wall, just looking very very lonely and unused. I was obsessed with cashing last year, so sort of summertime onwards. I just got obsessed with cashing because I had a client with some real cific cash problems. That was my tech obsession for sort of fall and winter last year.

My new obsession is memory management. I've got a client who's trying to depug memory leaks. They don't care about col ad vitals. They don't care about load times diameter. The browser. Memory leaks in the browser keeps crashing their their android app is a webz and it keeps crashing the android app and customers are complaining. So I'm now obsessed with the memory panel, which is very underdocumented, and yeah, let's talk. Let's talk about it because I'm actually

doing similar work. We've got some issues with node based services. Uh and and ultimately you use the same memory panel, you take a memory dump, and then you effectively use the same panel. So I it's it's yeah, it's it's not an easy panel to use, but it's fairly rare that you run into real memory issues with with browser applications. You know, we should probably talk about it, you know, schedule some time after this podcast.

I'd really love to hear about some of your insights and maybe I can also make some suggestions. So maybe we should schedule about it. Yeah. I'm new to my performance management journey, but I'm writing a talk called memory management for mere Mortals, where I am the mere mortal and I just talked about Okay, I had a client who had this. I even told my client, I don't think I'm the right guy for this job. I do very web like loading performance. I don't do like No, we're committing the right

person to this job. So I did all the research and I was like, Okay, we can do it, and found some really interesting insights. The memory channel hasn't really been changed for nearly ten years, maybe longer, but that's what I'm obsessed with at the moment, so I might either write a blog post about that or that. There's definitely a talk upcoming, yeah, Dan, if you want to talk about it specifically after this, Daniel,

let's that's we can probably a good idea. I'll ping you on on X all right, Well, all right, well that thanks for coming on. It's been great to have you, and you know, especially have you and Dan going back and forth and dropping all those knowledge bombs on us and we uh hope to see you again. Yeah, it's been great. I was very privileged to be invited on. I've seen I've seen the podcast for years now and I've finally got an invite, so I'm really grateful. Yeah,

all right, well we'll cut you later. Audios