WEBVTT 1 00:00:06.480 --> 00:00:11.279 Well, hello, hello everybody, and welcome back to another exciting episode of 2 00:00:11.400 --> 00:00:19.039 JavaScript Jebber and this day, well, I'm supposed to introduce our panel first, 3 00:00:19.079 --> 00:00:23.679 and then our guest Steve has corrected me, so you got me aj 4 00:00:24.120 --> 00:00:28.559 I'm your hostess with the mostess or whatever. And then we got Dan Hey, 5 00:00:30.280 --> 00:00:37.079 and we also have Harry Roberts, also known as the infamous CSS Wizardry 6 00:00:38.560 --> 00:00:42.679 nothing to do with well, hello everyone. Yeah, I don't write any 7 00:00:42.679 --> 00:00:47.039 CSS anymore. Also, I picked that domain when I was seventeen years old, 8 00:00:47.119 --> 00:00:50.679 So that's a portion retail for everyone watching. Don't let your children pick 9 00:00:50.719 --> 00:00:54.560 their own domain names. Yeah, but parents need to really be on the 10 00:00:54.600 --> 00:00:58.320 ball on that one, especially with the credit cards being like twelve year olds 11 00:00:58.320 --> 00:01:00.679 have credit cards. Now, I don't know how that happened, but that's 12 00:01:00.679 --> 00:01:06.680 the thing I haven't seen that that's terrifying. It has it built into the 13 00:01:06.760 --> 00:01:10.719 iPhone. It's like the credit card that you can create a subcredit anyway. 14 00:01:11.319 --> 00:01:18.200 But today's topic is what are we what do we doing? Not child that 15 00:01:18.400 --> 00:01:27.280 child? I think today I'm talking about web performance. Yeah, not the 16 00:01:27.280 --> 00:01:33.359 bottles. Well, we can have a drink afterwards if we want. Yeah, 17 00:01:33.480 --> 00:01:36.159 No, I'm I'm jealous. You know, it looks like a really 18 00:01:36.239 --> 00:01:41.599 nice collection anyway, So let's go ahead and jump right in and Harry, 19 00:01:41.640 --> 00:01:48.519 why don't you tell us why you're famous and your most three recent controversial tweets? 20 00:01:52.599 --> 00:01:53.760 Well, I would. I don't think I'm famous. I certainly wouldn't. 21 00:01:53.959 --> 00:01:56.840 I mean, I think if you do. If you work in the 22 00:01:56.879 --> 00:02:00.519 web performance space, you might have my I've come across my website before. 23 00:02:00.560 --> 00:02:07.760 But Mike most controversial tweets, I don't know. I don't really tweet controversial 24 00:02:07.760 --> 00:02:13.879 things anymore. Probably the most controversial ever was when Imagure i mg u R 25 00:02:14.000 --> 00:02:17.240 dot com switched to a single page, fully client rendered app. Don't if 26 00:02:17.240 --> 00:02:21.639 you've noticed, if you look at an X profile now a Twitter profile when 27 00:02:21.639 --> 00:02:24.680 you're logged out, it doesn't show X's, it doesn't show tweets chronologically. 28 00:02:24.719 --> 00:02:30.360 It shows them in the most liked first find out. Seeing my own profile 29 00:02:30.439 --> 00:02:34.439 logged out, and it reminded me of a tweet from quite a while ago. 30 00:02:34.479 --> 00:02:38.520 I really went on an Imagure immature because they switched a fully client or 31 00:02:38.520 --> 00:02:45.039 rendered status so that in group. Honestly, you're probably right. I've never 32 00:02:45.080 --> 00:02:46.919 heard it set out loud I've never tried set out loud untill just now, 33 00:02:47.479 --> 00:02:53.199 but they switched one simple image tag out for about two point seven meg of 34 00:02:53.280 --> 00:02:58.039 javascripts, and I got flamed for that one. People like you don't understand 35 00:02:58.039 --> 00:03:00.719 the business case of imager. They need to serve ads. They can serve 36 00:03:00.759 --> 00:03:02.080 ads, but need to serve the image first, and the white people willtop 37 00:03:02.120 --> 00:03:06.039 turning up. So I got flamed for that one. I got flamed for 38 00:03:06.080 --> 00:03:13.280 saying people shouldn't use emojis in professional contexts or gifts in presentations. People. 39 00:03:13.400 --> 00:03:15.000 Really one guy wanted to fight me for that one, but I'm not a 40 00:03:15.039 --> 00:03:21.280 very controversial person. It doesn't really suit my style and certainly doesn't suit business 41 00:03:22.360 --> 00:03:24.919 about famous though, I have to say that I said it before we started 42 00:03:24.919 --> 00:03:30.080 recording, and I promised to say it again that in the particular space of 43 00:03:30.159 --> 00:03:35.840 web performance, you, Harry, are one of my tech heroes. And 44 00:03:36.280 --> 00:03:38.879 I've been following your content for a long time. You know, your talks, 45 00:03:40.080 --> 00:03:46.000 you your posts, and I've learned a lot. So yeah, thank 46 00:03:46.039 --> 00:03:49.280 you. That really means a lot, especially because, as we were saying, 47 00:03:49.479 --> 00:03:53.919 just before we started streaming, you and I met like years ago. 48 00:03:53.159 --> 00:03:58.360 I reckon, we must have met six eight years ago and we have stayed 49 00:03:58.360 --> 00:04:00.240 in such ever since, but never again in person, which is a real 50 00:04:00.280 --> 00:04:02.759 shame. But that really means a lot, because likewise I keep eyeing what 51 00:04:02.759 --> 00:04:06.000 you're getting up to, and yeah, that means a lot, thank you. 52 00:04:06.639 --> 00:04:13.800 Yeah, so I wanted to have you on the show because there are 53 00:04:13.800 --> 00:04:19.360 a lot of interesting things going on in the web performance space, and in 54 00:04:19.480 --> 00:04:26.480 particular we are a few months away literally actually a one month away I think 55 00:04:26.519 --> 00:04:33.720 now from Google switching up Cowork vitals. I mean they've kind of kind of 56 00:04:33.800 --> 00:04:42.040 done it before when they changed the meaning of CLS commulative layout Shift. They 57 00:04:42.199 --> 00:04:47.279 have modified LCP over time a little bit in certain ways, but this is 58 00:04:47.399 --> 00:04:51.360 by far the biggest change that they're making. So maybe we can start with 59 00:04:51.439 --> 00:04:59.480 that. Yeah, I mean swapping first in put the layout and replacing it 60 00:04:59.519 --> 00:05:03.439 with IMP I think is it's drastic. It's a huge change, and I 61 00:05:03.480 --> 00:05:08.879 think a lot of businesses are going to struggle, speaking purely on it. 62 00:05:08.959 --> 00:05:15.519 Gotally, I have clients who've got twenty two million good URLs in search console 63 00:05:15.519 --> 00:05:18.720 and in what is it, the twelfth of March, so it looks like 64 00:05:19.720 --> 00:05:24.879 one month and two weeks or whatever. It is these companies are going to 65 00:05:24.879 --> 00:05:28.759 have twenty three million bad URLs in search console. The difference is stark, 66 00:05:29.439 --> 00:05:31.519 and one thing I do kind of worry about, and it's not Google fault 67 00:05:31.519 --> 00:05:35.720 at all, but people have known this update was coming for a long long 68 00:05:35.759 --> 00:05:40.240 time and people are kind of I've not had a single client who's trying to 69 00:05:40.240 --> 00:05:44.160 get ahead of the curve here. I worked with the client only last week 70 00:05:44.279 --> 00:05:49.279 who were kind of only just starting to really worry about this, because I 71 00:05:49.279 --> 00:05:53.120 don't think I don't think a lot of companies were just how big the shift 72 00:05:53.199 --> 00:05:56.879 is going to be. I think it needed to happen. I think IMP 73 00:05:57.000 --> 00:06:02.160 is a much more suitable replacement for first Delay, but I do think it 74 00:06:02.240 --> 00:06:05.839 may have helped a bit in a stop gap period because the difference between the 75 00:06:05.839 --> 00:06:10.639 two as well, you know, is just enormous, and trying to go 76 00:06:10.720 --> 00:06:14.600 from FID to IMP in one hot this is going to be a real struggle 77 00:06:14.600 --> 00:06:18.480 for a lot of companies. So maybe it's worthwhile to set the stage a 78 00:06:18.519 --> 00:06:23.319 little bit on that, to maybe talk a little bit about what co work 79 00:06:23.399 --> 00:06:28.759 vitals are, what I f ID was or is but you know soon will 80 00:06:28.800 --> 00:06:32.360 be deceased, and what IMP is that replaces it to give a little bit 81 00:06:32.360 --> 00:06:38.639 of context happily. Yeah, so without slides or visual aids, I guess 82 00:06:38.680 --> 00:06:42.920 the best way to talk about core revitals would be Site speed has been a 83 00:06:43.000 --> 00:06:46.519 thing for well over a decade now, a long long time, but historically 84 00:06:46.560 --> 00:06:51.000 we had to lean on archaic and kind of esoteric events like the browser's load 85 00:06:51.000 --> 00:06:55.759 event. We talk about load times, but a load time is invisible to 86 00:06:56.000 --> 00:06:59.600 a visitor that they don't know what the load event is. You can have 87 00:06:59.600 --> 00:07:03.199 a really feeling page with a terrible load time, and the load time would 88 00:07:03.240 --> 00:07:08.319 be completely irrelevant to what the customer experienced. So Google, to their credit 89 00:07:08.959 --> 00:07:13.279 very thoroughly researched, have tried to get some one size fits all metrics, 90 00:07:13.879 --> 00:07:17.079 metrics that can apply to every site in the world, and try to quantify 91 00:07:17.079 --> 00:07:21.319 the user experience of how fast that site felt. The nearest equivalent to a 92 00:07:21.399 --> 00:07:26.000 load time would be the largest contentual paint, which is simply one was the 93 00:07:26.040 --> 00:07:30.279 biggest bit of content presented on screen. We've got culative layershift, which you 94 00:07:30.279 --> 00:07:33.199 already mentioned, which is did the page move around as it was loading or 95 00:07:33.240 --> 00:07:36.639 as you were interacting with it. That's not a performance metric at all. 96 00:07:36.720 --> 00:07:42.759 Isn't measure steed one bit, but it does measure the user experience and sort 97 00:07:42.759 --> 00:07:46.199 of measures with this page frustrating to load. And finally, yeah, we 98 00:07:46.279 --> 00:07:49.639 had first input delay. And the whole point of first input delay is, 99 00:07:49.959 --> 00:07:53.480 in fact, I've got a really good analogy for first input delay and I 100 00:07:53.600 --> 00:07:58.399 inp and purely coincidentally, I'm sat in the right place for it. First 101 00:07:58.399 --> 00:08:03.120 input delay is when someone clicks a button for the first time on that page, 102 00:08:03.600 --> 00:08:07.839 how long did it take before the web application could start responding. And 103 00:08:07.839 --> 00:08:09.600 it only measures the first click, and it only measures how long before the 104 00:08:09.639 --> 00:08:16.319 application could start repon responding. So this misses out to I must have some 105 00:08:16.680 --> 00:08:20.639 kind of emojis. I don't know what that was. So anyway, that 106 00:08:22.279 --> 00:08:26.519 miss two crucial things. The first thing that misses is it only measures the 107 00:08:26.560 --> 00:08:28.240 first click on a page. Now, if the first click happens to be 108 00:08:28.319 --> 00:08:33.159 really slow, but the next two hundred clicks are really fast, you only 109 00:08:33.200 --> 00:08:37.120 measure on the really bad one. Conversely, if the first click is really 110 00:08:37.159 --> 00:08:41.360 fast and all the next ones are slow, it looks like your page is 111 00:08:41.399 --> 00:08:46.000 really click The problem with that is it's really easy to gain you could wait 112 00:08:46.039 --> 00:08:48.159 for a use as a click before booting all your JavaScript. You could say, 113 00:08:48.639 --> 00:08:52.000 well, wait for the first click and that's just gonna be a click 114 00:08:52.039 --> 00:08:54.879 on anything and it'll respond really quickly. Then load all your JavaScript. You 115 00:08:54.960 --> 00:08:58.320 know that every subsequent click will be slow, but you know it won't get 116 00:08:58.320 --> 00:09:03.720 measured. That's the first problems first into the day, to just what quick 117 00:09:05.240 --> 00:09:09.519 is doing. Although yeah, let's let's let's put that. You know, 118 00:09:09.840 --> 00:09:11.840 quick is an interesting topic, but let's push it off a little bit. 119 00:09:13.320 --> 00:09:16.759 I did want to say that in most cases you really didn't need to even 120 00:09:16.919 --> 00:09:20.639 gain uh f i D that much because you just got to do the FID 121 00:09:20.840 --> 00:09:26.039 score almost regardless of what. Oh yeah, by definition, I said that 122 00:09:26.120 --> 00:09:31.000 like we kind of that measurement kind of won in the sense that, you 123 00:09:31.039 --> 00:09:35.799 know, if anybody was a laggard and I worked at Twicks, and initially 124 00:09:35.799 --> 00:09:39.120 when we started we were even bad at FID, and then we fixed it 125 00:09:39.240 --> 00:09:45.159 and now Wicks has good f I D and it's that's that's that there's nothing 126 00:09:45.200 --> 00:09:48.080 more to do in that context. So if you look at most web pages, 127 00:09:48.120 --> 00:09:52.279 they just have really good FID and it it's like that if if you 128 00:09:52.320 --> 00:09:56.960 know, like have an examined in school and everybody gets an A or an 129 00:09:56.960 --> 00:10:01.440 A plus, then you know that test is kind of meaning is meaningless. 130 00:10:01.639 --> 00:10:07.399 It doesn't really provide any information. So we needed to replace if I do 131 00:10:07.559 --> 00:10:13.759 with something else. Yeah, exactly. So that was the kind of core 132 00:10:13.799 --> 00:10:18.120 problem was that it was like ninety websites past FID despite we all know that 133 00:10:18.240 --> 00:10:24.039 JavaScript is a huge runtime bottleneck, so how could ninety plus websites be passing 134 00:10:24.120 --> 00:10:28.759 that metric. The second problem with FID is that it didn't measure how long 135 00:10:28.799 --> 00:10:33.519 it actually took to do the work. The way I explain this to non 136 00:10:33.519 --> 00:10:37.120 technical stakeholders, very non technical stakeholders, is imagine you went to a bar 137 00:10:39.279 --> 00:10:41.600 and you wanted to order a drink. Now, if you get to the 138 00:10:41.639 --> 00:10:45.440 bar and the bar is really busy, there are hundreds of people and only 139 00:10:45.480 --> 00:10:48.559 one bartender, it's going to take you a long time before you can place 140 00:10:48.559 --> 00:10:50.519 your order for your drink. And that's first. In book delay, it 141 00:10:50.559 --> 00:10:54.440 measures your first order for your first drink, and it only measures how long 142 00:10:54.480 --> 00:10:56.200 it took you to order the drink, So it doesn't matter how quick the 143 00:10:56.200 --> 00:10:58.399 bartender is or how long it took them to get the drink to you that 144 00:10:58.399 --> 00:11:03.519 doesn't get it doesn't get counted, whereas interact from to the next paint. 145 00:11:03.200 --> 00:11:07.919 The analogy would be you might go to a really really busy bar and you 146 00:11:09.000 --> 00:11:09.879 might order a drink, and it might take you a long time to order 147 00:11:09.879 --> 00:11:13.279 that drink because there are so many other customers there. But if you just 148 00:11:13.399 --> 00:11:18.320 order a glass of water or a bottle of beer, then the bartender can 149 00:11:18.360 --> 00:11:20.960 produce that drink very very quickly. If you order a really complicated cocktail, 150 00:11:22.440 --> 00:11:26.759 then the processing time of the drink will be increased. If you just stay 151 00:11:26.799 --> 00:11:28.960 at the bar and they slide it over the bar too and you take the 152 00:11:30.039 --> 00:11:31.720 drink, that's your presentation delay, and they can get the drink to you 153 00:11:31.799 --> 00:11:35.279 very quickly. However, if you say, oh, I'm going to go 154 00:11:35.320 --> 00:11:39.080 and set over in the corner and the bartenders to bring the drink over to 155 00:11:39.120 --> 00:11:43.159 you, that's your presentation delay. So what ironp does. It doesn't just 156 00:11:43.240 --> 00:11:46.639 measure how long it takes to order your drink. It measures howing it to 157 00:11:46.679 --> 00:11:50.639 make your drink and how it took for the bartender to put the drink in 158 00:11:50.679 --> 00:11:54.039 your hand. And it does that for every drink you order, not just 159 00:11:54.039 --> 00:11:56.480 the first drink, so I think I feel like first time. But the 160 00:11:56.519 --> 00:12:00.039 lay was really easy to gain for those two reasons. It was only the 161 00:12:00.039 --> 00:12:03.679 first click, and it only measured the delay to start the work. I 162 00:12:03.799 --> 00:12:07.279 NP is much harder the past because it measures well between ninety eight and one 163 00:12:07.360 --> 00:12:11.639 hundreds percentile, so more or less your very worst clicks, and it's not 164 00:12:11.679 --> 00:12:16.759 even clicked. It's interactions, so keypressers and stuff like that, and then 165 00:12:16.759 --> 00:12:18.519 how I'm accepted to process that, and how except to display that to you. 166 00:12:20.000 --> 00:12:22.639 It measures a lot lot lot more work. And that's why most sites 167 00:12:22.679 --> 00:12:30.039 are going to go from green to red overnight. It's a few more thoughts 168 00:12:30.080 --> 00:12:35.080 both about FID and I and P. So from the get go, I 169 00:12:35.080 --> 00:12:41.480 had prompt issues, let's say, with FID, and I was very upfront 170 00:12:41.600 --> 00:12:43.840 with the people, with the great excellent people at Google about it, you 171 00:12:43.879 --> 00:12:50.919 know, Anny Sullivan, Michael your Wise while he was there, and others. 172 00:12:52.679 --> 00:13:00.240 Patrick And the problem is that in many cases, if your website was 173 00:13:00.360 --> 00:13:07.320 especially slow in loading, you actually got better FID because if your JavaScript took 174 00:13:07.360 --> 00:13:11.360 a long time to download, so long in fact, that the user interacted 175 00:13:11.399 --> 00:13:18.080 with the page before the JavaScript actually even loaded, then when and on the 176 00:13:18.080 --> 00:13:22.440 other hand, the page had let's say SSR or SSG, so the content 177 00:13:22.639 --> 00:13:26.919 was actually already visible. Then you would click a button that would literally do 178 00:13:26.080 --> 00:13:33.279 nothing because the JavaScript wasn't even wired up yet, and from the fid's perspective, 179 00:13:33.360 --> 00:13:37.639 it would be you know, instantly responsive. You know, the response 180 00:13:37.679 --> 00:13:43.279 would be effectively nothing, but your FID would be excellent. And that was 181 00:13:43.399 --> 00:13:48.080 one of the issues that we had that again at Wicks that initially, when 182 00:13:48.120 --> 00:13:54.679 we started to improve the download speed of the delivery of the JavaScript, they 183 00:13:54.720 --> 00:14:00.120 actually had, you know, hit this kind of valley where it seemed to 184 00:14:00.159 --> 00:14:05.679 be getting initially worse before it started getting better, simply because you know, 185 00:14:05.799 --> 00:14:11.320 we were the pages were getting interactive sooner and that problem I just described was 186 00:14:11.399 --> 00:14:16.159 less likely to happen. But yeah, you know, yeah, go for 187 00:14:16.240 --> 00:14:20.120 it. Sorry. I've run into the exact same thing on client sites. 188 00:14:20.679 --> 00:14:26.600 Clients very aggressively deferring their JavaScript would end up passing fit purely because even clicking 189 00:14:26.639 --> 00:14:31.840 a native browser input like a button, you don't have to wait for the 190 00:14:31.919 --> 00:14:35.879 JavaScript devan handles to be attached. Browsers have their own event handles attached the 191 00:14:35.879 --> 00:14:39.919 buttons already, so exactly as you say, if someone interacts with an interactive 192 00:14:39.960 --> 00:14:43.919 element before the JavaScript is booted, it will still capture a valid input. 193 00:14:45.679 --> 00:14:48.960 Even that input doesn't do anything because it's the other thing first input delay and 194 00:14:50.480 --> 00:14:54.399 iron p well, sorry, just imp Even if there isn't a UI up 195 00:14:54.480 --> 00:14:58.200 day afterwards, even if there isn't a next paint, you still capture a 196 00:14:58.279 --> 00:15:01.240 score for every click. So what that means is, in the case of 197 00:15:01.320 --> 00:15:03.720 FIT, the button doesn't have to do anything. It doesn't have to do 198 00:15:03.720 --> 00:15:07.399 anything at all. It only captures the fact that you clicked a button, 199 00:15:07.559 --> 00:15:11.360 and if it needed to do something, we could have done it immediately. 200 00:15:11.639 --> 00:15:16.720 So exactly as you say, a big risk was people really really aggressively deferring 201 00:15:16.720 --> 00:15:20.320 and lightloading their javascripts could sort of skirt around the system purely because the chance 202 00:15:20.360 --> 00:15:26.519 of someone clicking before the JavaScript had run was actually quite high. Now, 203 00:15:26.840 --> 00:15:33.200 you talked about the fact that you're seeing customers and it maybe it's worthwhile to 204 00:15:33.279 --> 00:15:39.600 mention that you work as a freelance consultant and you work with customers looking organizations 205 00:15:39.600 --> 00:15:46.679 looking to improve their performance of the websites, so you're obviously exposed to a 206 00:15:46.720 --> 00:15:54.720 lot of poor performing websites and a lot. Yeah, you mentioned that you're 207 00:15:54.759 --> 00:16:00.919 seeing scenarios where they currently have really good FID and even LCP and CLS and 208 00:16:02.039 --> 00:16:07.399 consequently are really passing coed vitals on most of their pages in for example, 209 00:16:07.480 --> 00:16:11.360 in the Google Search console, but that once they switch over to I and 210 00:16:11.440 --> 00:16:18.039 P that the situation will be much worse. Now, it's interesting because I 211 00:16:18.200 --> 00:16:22.799 brought up this concern with the people from Google a while back. I don't 212 00:16:22.840 --> 00:16:27.320 remember if it was with any or with Rick or with Michael one of them, 213 00:16:27.799 --> 00:16:36.200 and their response was that according to their tests, most what they saw 214 00:16:36.480 --> 00:16:42.080 was that most organizations that have a poor I and P or will have poor 215 00:16:42.080 --> 00:16:48.639 I and P also already have poor LCP. So their argument was that the 216 00:16:49.039 --> 00:16:59.559 overall ratio of passing websites won't change that much because the score for like you 217 00:16:59.559 --> 00:17:03.359 said, this score for that interactivity, the interactivity score will drop, but 218 00:17:03.799 --> 00:17:10.039 it will have less a lesser impact on the overall commodative score of all speed 219 00:17:10.119 --> 00:17:15.759 core work vitals. Would you agree with that or not based on your person 220 00:17:17.680 --> 00:17:21.759 Yes, I haven't seen things that necessarily corroborate that, And do you know 221 00:17:21.759 --> 00:17:25.759 what I don't have? I really don't have the access to the data that 222 00:17:25.799 --> 00:17:30.240 they do. So I look at a small enough number of data sets that 223 00:17:30.759 --> 00:17:33.960 non no two look alike, and every single site seems to have unrelated issues. 224 00:17:34.039 --> 00:17:40.640 So you know, really I see sites that. Yeah, so I've 225 00:17:40.640 --> 00:17:42.920 got a client at the moment who doing really well in LCP, really bad 226 00:17:42.920 --> 00:17:47.799 in CLS, and I n P their LCP is great, It's been great 227 00:17:47.839 --> 00:17:51.960 forever. I don't typically tend to see patterns, but I'm looking at a 228 00:17:51.960 --> 00:17:56.680 really small scale. So I'm not talking HD archive. I'm not talking you 229 00:17:56.680 --> 00:18:00.079 know, Google's crook data. Based at large and on my own clients, 230 00:18:00.200 --> 00:18:04.079 I can't really there's not contently decipher or see any patterns that suggest that. 231 00:18:07.880 --> 00:18:12.160 I have to say. That kind of surprises me to an extent because I 232 00:18:12.240 --> 00:18:18.359 would expect for you to be seeing the same issues over and over and over 233 00:18:18.440 --> 00:18:25.160 again. Yeah, I mean, really, it's really surprising. Some issues 234 00:18:25.200 --> 00:18:30.640 are really common. But we've had I think the performance industry and people who 235 00:18:30.640 --> 00:18:33.880 care about performance even a little bit. Why is the fact that some things 236 00:18:33.880 --> 00:18:37.039 are always just gonna will always cause you problems? Client side rendering is a 237 00:18:37.119 --> 00:18:41.079 terrible idea. So if you want to be fast, certain things are just 238 00:18:41.119 --> 00:18:45.160 starting to get filtered out, and those same mistakes that I would see five 239 00:18:45.240 --> 00:18:48.319 years ago are far less common now. What I'm seeing on a per project 240 00:18:48.400 --> 00:18:56.640 basis is every client has pretty significantly different problems to the last. So, 241 00:18:56.680 --> 00:19:00.200 you know, that kind of moves us over to the next part of the 242 00:19:00.240 --> 00:19:04.759 conversation. I guess because when we were talking about, you know, what 243 00:19:04.799 --> 00:19:11.079 we should discuss on this podcast, I thought that an excellent topic would be 244 00:19:11.519 --> 00:19:15.839 to talk about, you know, what you are encountering in various customer site 245 00:19:15.880 --> 00:19:22.519 obviously without naming names unless you really unless you really want to, yeah, 246 00:19:22.759 --> 00:19:30.480 but probably you know, yeah, basically, yeah, basically things like on 247 00:19:30.559 --> 00:19:34.680 the practical side, you know, things that you tend to see in you 248 00:19:34.720 --> 00:19:40.880 know, mistakes that people tend to make, but also amusing stories if you 249 00:19:40.880 --> 00:19:45.039 can share them. Yeah. Well, like I said before, it used 250 00:19:45.079 --> 00:19:49.440 to be five years ago everyone had gone full client side reacts and that's always 251 00:19:49.440 --> 00:19:53.599 gonna start. And then everyone now knows that service side render and then rehydration 252 00:19:53.720 --> 00:19:59.680 is faster, not perfect, but certainly faster. So of the age old 253 00:19:59.680 --> 00:20:04.000 problem seems to be filtered out. I was I think, well, I 254 00:20:04.039 --> 00:20:06.880 think I don't know, how about it was a tweet of mind that was 255 00:20:06.920 --> 00:20:11.000 responsible for a lighthouse check for are you lazy loading your LCPM? And because 256 00:20:11.039 --> 00:20:17.160 that was so commonplace even before WordPress plugins enabled that by accident, all these 257 00:20:17.200 --> 00:20:22.039 really common problems. I think even just non performance engineers are now so aware 258 00:20:22.079 --> 00:20:26.359 of web performance that basic mistakes, certainly on the projects I'm seeing, don't 259 00:20:26.359 --> 00:20:32.480 really get made so much anymore. Where if I can interject, for one 260 00:20:32.519 --> 00:20:40.640 thing you mentioned, you mentioned client side rendered React you know, basically websites 261 00:20:40.839 --> 00:20:45.279 or projects that initially started with the create React app, yes, I have 262 00:20:45.799 --> 00:20:52.000 essentially by definition will have poor core performance as is measured by core advitors. 263 00:20:52.640 --> 00:20:57.799 And that's not rising because obviously, you know, if you need to download 264 00:20:59.240 --> 00:21:03.799 a ton ofavascript, then you know, run that JavaScript, makes several AJAX 265 00:21:03.839 --> 00:21:10.079 requests, run more JavaScript and only then actually start showing stuff, then obviously 266 00:21:10.160 --> 00:21:14.640 that's going to be much lower than a website that just download stuff from the 267 00:21:14.680 --> 00:21:18.559 get go. But the interesting thing is that I'm when when speaking with various 268 00:21:19.240 --> 00:21:26.039 let's call them larger companies, companies that build let's call them quote unquote web 269 00:21:26.079 --> 00:21:30.079 applications, a lot of them still work this way. Uh, if if 270 00:21:30.160 --> 00:21:37.440 the app, if the web app is not seoed. Uh. If if 271 00:21:37.519 --> 00:21:44.160 it's you know, if it's something that's behind a login screen or whatever, 272 00:21:45.039 --> 00:21:51.440 then from their perspective, you know it's it's it's so it's okay to work 273 00:21:51.480 --> 00:21:56.680 this way. So I'm kind of agreeing the market's splitting on this regard, 274 00:21:56.839 --> 00:22:00.720 Like some sites care about load performance and a lot of sites really don't. 275 00:22:03.400 --> 00:22:04.759 Yeah, and I do agree with that sentiment. So, for example, 276 00:22:06.880 --> 00:22:11.640 my accountancy software is all web based and it's slow. But if I look 277 00:22:11.680 --> 00:22:15.440 into my accountancy software, I have to do it, and I know it's 278 00:22:15.480 --> 00:22:19.200 going to take me at least thirty minutes anyway, But I don't mind it 279 00:22:19.240 --> 00:22:23.839 being slow as long as once it's there, it's usable. And the sensitivity 280 00:22:23.839 --> 00:22:27.240 there is a lot less than if I just want to find out if I 281 00:22:27.279 --> 00:22:32.119 just want to quickly buy some groceries on the way home or something really quick, 282 00:22:32.119 --> 00:22:33.480 I try to buy something quickly and leave. Again, there's a lot 283 00:22:33.519 --> 00:22:37.799 more friction and a lot more sensitivity. If the task itself should be a 284 00:22:37.839 --> 00:22:41.160 two minute tests, you don't want to spend ten percent at that time just 285 00:22:41.160 --> 00:22:45.160 waiting, Whereas if the tasks are thirty minute tests, you don't mind the 286 00:22:45.200 --> 00:22:48.240 different cost. I don't have any research to prove this, but I do 287 00:22:48.319 --> 00:22:52.640 sympathize with the use case of we're a web app. I'd be happy to 288 00:22:52.680 --> 00:22:55.759 wait for photoshop in the browser. I wouldn't be happy to wait the same 289 00:22:55.799 --> 00:23:00.240 amount of time to work out what time my next train is. There is 290 00:23:00.240 --> 00:23:04.440 no way of quantifying that sensitivity, but I do believe it exists, and 291 00:23:04.640 --> 00:23:08.359 I do think that there is there's no definition between what's a web app and 292 00:23:08.400 --> 00:23:12.920 what's a website. One thing I do think is if you're a company who 293 00:23:14.000 --> 00:23:17.359 can name five different pages on your website, Oh, we've got the homepage, 294 00:23:17.559 --> 00:23:22.119 a product details page, a product listing page, a search page. 295 00:23:22.480 --> 00:23:23.960 If you've just listened four different pages, you're not a single page app. 296 00:23:25.119 --> 00:23:27.200 So don't build a single page app building the page. If you can name 297 00:23:27.279 --> 00:23:30.799 pages, you aren't a single page app. Trello is a single page at 298 00:23:30.799 --> 00:23:33.960 Google. Sheet is a single page app. Your e com site is not 299 00:23:34.000 --> 00:23:37.960 a single page app because you've got your homepage, your category page, your 300 00:23:37.960 --> 00:23:41.799 product listing page, your product details page, you've got your faqu's page. 301 00:23:41.960 --> 00:23:51.160 They're all different pages. So a mass Twitter is I mean Twitter and Facebook, 302 00:23:51.200 --> 00:23:53.519 Right, would you say that the feed is one app, and then 303 00:23:53.559 --> 00:23:57.680 because it seems like the the in between is don't try to build a single 304 00:23:57.720 --> 00:24:03.160 page app where you literally everything that you do in a single application. I 305 00:24:03.200 --> 00:24:07.000 agree, that's I mean, that's beyond silly, except that you know that's 306 00:24:07.000 --> 00:24:10.720 what's been done the last ten years and and there's no sense and if you 307 00:24:10.799 --> 00:24:15.559 have a lot of interactive stuff doing server reloads for every single interaction, but 308 00:24:15.880 --> 00:24:19.519 like there is some sort of delineation, like your feed is a single paye 309 00:24:19.559 --> 00:24:25.559 ab, your account settings is a single paye ab, but your feed and 310 00:24:25.559 --> 00:24:29.240 your account settings are not the same ap it. I mean, so so 311 00:24:29.480 --> 00:24:32.759 if I can, if I can touch on that. So we've had Alex 312 00:24:32.839 --> 00:24:38.119 Russell on on the podcast actually twice, and I think we had them almost 313 00:24:38.160 --> 00:24:42.079 a year ago the last time. And the distinction that he kind of makes 314 00:24:42.440 --> 00:24:49.559 is based on the amount of interactions, like is it is it something that 315 00:24:51.200 --> 00:24:56.799 you like click? Like are you clicking a few times to maybe a few 316 00:24:56.880 --> 00:25:00.400 dozen times or are you going to be clicking hundreds of times? And now 317 00:25:00.440 --> 00:25:04.400 I don't remember exactly where Alex draws the line. I know that he's done 318 00:25:04.599 --> 00:25:08.279 a bunch of research on this topic. You you know, you can chase 319 00:25:08.400 --> 00:25:14.559 check his website, which is slightly late I think is No, that's actually 320 00:25:14.599 --> 00:25:18.759 that is handled. I always forget frequently not yeah, I and frequently noted, 321 00:25:19.039 --> 00:25:23.039 so you can check his Yeah, he's he's funny like that. So 322 00:25:25.599 --> 00:25:30.119 anyway, so he's done research on this topic. Uh, and and that's 323 00:25:30.240 --> 00:25:36.000 the delineation that he makes. And I kind of concur with that. So 324 00:25:36.160 --> 00:25:37.519 I don't know where the cluster point is and I wouldn't. I don't use 325 00:25:37.680 --> 00:25:41.319 I agree with him, but the way I've always would, I'm not. 326 00:25:41.480 --> 00:25:44.960 I kind of I've never heard him say that, but I agree with him. 327 00:25:44.960 --> 00:25:48.240 The way I've always described it to my clients is how big is the 328 00:25:48.240 --> 00:25:51.319 feedback route. If you've got Photoshop in the browser, you don't want to 329 00:25:51.319 --> 00:25:55.720 wait a full round trip before you notice the pixels turning green. If you've 330 00:25:55.759 --> 00:25:57.799 got Google sheets, you don't want to notice a full round trip of latency 331 00:25:57.880 --> 00:26:03.759 before sell A and cell B gets summed together. So if your feedback loop 332 00:26:03.279 --> 00:26:07.759 where you expect feedback is instant, then that is what I would consider more 333 00:26:07.759 --> 00:26:11.440 app like if read and write are almost one to one, whereas if you 334 00:26:11.480 --> 00:26:15.400 look at an e commerce site or buying. Yeah, just look at an 335 00:26:15.400 --> 00:26:18.960 e commerce site or a news website. You don't have feedback loops. You 336 00:26:18.960 --> 00:26:22.079 spend most time consuming, especially on a news website, your scroll, you 337 00:26:22.240 --> 00:26:25.680 read, your scroll, you read. That. Didn't want to be a 338 00:26:25.680 --> 00:26:30.599 single page app if you are flicking through an article every half a second, 339 00:26:30.000 --> 00:26:34.079 which you wouldn't ever be doing. But it's not until you're doing really frequent 340 00:26:34.079 --> 00:26:37.400 and you need that feedback loop to be super tight, that you need to 341 00:26:37.400 --> 00:26:41.119 build things in the browser. So I think for the most common news cases, 342 00:26:41.200 --> 00:26:48.200 eCOM publishing, certainly publishing a single page app is not the right process. 343 00:26:48.480 --> 00:26:51.920 Now your checkout flow, that might be a single page app, because 344 00:26:52.119 --> 00:26:53.960 it might be a case of like as you say, it's behind a log 345 00:26:53.960 --> 00:26:59.240 in, it's not indexed anyway. By the time someone's got into the checkout 346 00:26:59.279 --> 00:27:03.759 process, they asked statistically less sensitive. Studies have shown that once people have 347 00:27:03.759 --> 00:27:06.599 committed to buying something, they are more like to stick with it, so 348 00:27:06.599 --> 00:27:08.759 they're less sensitive to site speed. There your check out, So that could 349 00:27:08.759 --> 00:27:12.279 be an SPA. That's absolutely find because by and large every pages the same, 350 00:27:12.400 --> 00:27:17.559 just different form details, your address, you're billding details, discout code, 351 00:27:17.599 --> 00:27:19.079 et cetera. That's where your feedback loop is. Okay, I've got 352 00:27:19.119 --> 00:27:22.160 my credit card in my hand and I'm going to do that. So I 353 00:27:22.160 --> 00:27:26.319 think Alex says interactions. I think I'm saying the exact same thing, which 354 00:27:26.359 --> 00:27:30.640 is nice because Alex is very smart. But I always describe to the clients 355 00:27:30.640 --> 00:27:33.279 as where do you want that feedback loop? Trello, you want to drag 356 00:27:33.319 --> 00:27:38.559 a card from one column to another and see it land there instantaneously. If 357 00:27:38.599 --> 00:27:45.200 you're clicking a related product that's another page, and that feels like the feedback 358 00:27:45.200 --> 00:27:48.279 weroop doesn't need to get anyways near as instant as dragging a card from one 359 00:27:48.279 --> 00:27:55.000 column to another. So going back to the topic of the issues that you 360 00:27:55.160 --> 00:28:02.680 encounter as as a consultant coming in on ICE mostly to assist with projects where 361 00:28:02.680 --> 00:28:07.480 performance is an issue. What are common problems that you encounter and what are 362 00:28:07.680 --> 00:28:18.880 amusing problems that you encounter? Really common problems are things like festicization of things 363 00:28:18.880 --> 00:28:25.160 like microservices, micro front ends, composable commerce, and single page apps. 364 00:28:25.200 --> 00:28:27.440 They're really common. So nearly every site I look at your single page app, 365 00:28:27.839 --> 00:28:30.799 you're struggling with performance, maybe not because of your own fault but because 366 00:28:32.440 --> 00:28:36.359 you weren't aware that co ed vitals doesn't play very nicely with single page apps 367 00:28:36.559 --> 00:28:40.000 at present at least. So I've got loads of clients at the moment who 368 00:28:40.119 --> 00:28:45.200 their sites are pretty fast from a cold start, but the fact they an 369 00:28:45.240 --> 00:28:47.960 SKA means a lot that data gets lost, so they appear a lot slower 370 00:28:47.960 --> 00:28:51.759 than they are. One thing I keep coming across is and two projects in 371 00:28:51.759 --> 00:28:55.519 a row now is composable commerce. And it's like, right, we've got 372 00:28:55.559 --> 00:29:00.759 to make API calls to X different third parties. That's all latency. That 373 00:29:00.799 --> 00:29:03.880 all just goes into time first bite. Paralyze as much of it as you 374 00:29:03.920 --> 00:29:07.480 can, but it's still kind of for the most part, only as fast 375 00:29:07.559 --> 00:29:15.319 as the slowest response. Then you move to like your server, your client 376 00:29:15.359 --> 00:29:21.759 rendered so rehydrates, and you move into the client rendered version, the rehydrated 377 00:29:21.839 --> 00:29:25.960 version. All those API calls now happen on the client side. And I've 378 00:29:26.000 --> 00:29:30.240 seen this in two projects in a row. Everyone loves to have API dot 379 00:29:30.319 --> 00:29:33.119 company dot com on a different domain, which means immediately across origin request, 380 00:29:33.119 --> 00:29:37.079 which means immediately you've got pre flight requests. There are two projects in a 381 00:29:37.160 --> 00:29:41.720 row. Never really noticed it before. But full round trips of latency in 382 00:29:41.880 --> 00:29:45.920 band on every request to the API end point because they weren't cashing their pre 383 00:29:45.960 --> 00:29:49.519 flight requests. These are rare things I see that do They don't amuse me, 384 00:29:51.079 --> 00:29:53.640 but I feel like you designed this problem for yourselves. If you've just 385 00:29:53.680 --> 00:29:57.079 had Company dot com slash API, get rid of all those problems. But 386 00:29:57.119 --> 00:30:02.880 because everyone loves to have a PI dot Company dot com, you now enforced 387 00:30:02.880 --> 00:30:06.039 pre flight requests. Hold on. I want to push back on that. 388 00:30:06.240 --> 00:30:11.720 So can you think of a reason why people are doing that? Because I 389 00:30:11.240 --> 00:30:15.720 know of some reasons why it's beneficial, But like, are you just dismissing 390 00:30:15.720 --> 00:30:18.720 a wholesale or do you think that people don't actually have the problems they what 391 00:30:19.200 --> 00:30:23.000 do you understand what the impetus for the API was other than cuteness, Because 392 00:30:23.039 --> 00:30:26.799 I don't think it's just cuteness, although I'm sure that plays a part. 393 00:30:27.279 --> 00:30:30.160 I don't think it's just cuteness. And I don't have like a list answers 394 00:30:30.200 --> 00:30:34.519 to why. But architectural simplic simplification, Like a lot of companies just hang 395 00:30:34.599 --> 00:30:38.319 things off domain so they can share them internally a lot easier. They can 396 00:30:38.359 --> 00:30:42.759 deploy as their own sort of architecture on its own kind of its own standalone 397 00:30:42.759 --> 00:30:47.079 product. But yeah, I just feel like a lot of problems like that 398 00:30:47.119 --> 00:30:51.079 would be the performance problems it brings. I'd like if we could just stick 399 00:30:51.119 --> 00:30:59.400 this on Slash API slash and using resources like preconnect or something like that doesn't 400 00:30:59.440 --> 00:31:03.720 mostly solve that problem. I mean, you're going to be waiting for the 401 00:31:03.799 --> 00:31:07.599 JavaScript to download in most cases anyway before making those API calls, so you 402 00:31:07.599 --> 00:31:15.000 could at least use that JavaScript download time to pre connect to that API endpoint. 403 00:31:15.440 --> 00:31:19.440 So pre connect wouldn't work because pre connect will open a CAUSE. You 404 00:31:19.480 --> 00:31:23.519 can open a CAUSE enabled connection, but you don't explain why you need it. 405 00:31:23.599 --> 00:31:26.599 So what a pre flight does is it says, oh, you've got 406 00:31:26.640 --> 00:31:30.240 a request headed that we don't We don't like that, you can't you can't 407 00:31:30.319 --> 00:31:33.160 hit us with that request. Did you actually get cores on subdomains? I 408 00:31:33.279 --> 00:31:37.359 forget you do, yes, cross origin and a subdomain is a new origin. 409 00:31:37.519 --> 00:31:41.319 So I've got a client at the moment, and if they just move 410 00:31:41.400 --> 00:31:45.799 from company dot com slash dot, if I move from api dot to slash 411 00:31:45.880 --> 00:31:52.000 API, they would remove all the CAUSE issues because cross origin a subdomain and 412 00:31:52.279 --> 00:31:55.920 a different subdomain, a different port would put you in that cross origin category. 413 00:31:56.759 --> 00:32:00.400 Oh so it's also a different port. No, it's either either. 414 00:32:00.680 --> 00:32:06.039 It's either. Okay, yeah, that you come in issues with local hosts 415 00:32:06.039 --> 00:32:07.839 on that all the time, which is one of the reasons that tell people 416 00:32:07.039 --> 00:32:13.559 to like use domain or whatever. But so for that, I think that 417 00:32:13.720 --> 00:32:21.000 in the modern era, I think that the reasons that we did API dot 418 00:32:21.039 --> 00:32:27.160 whatever don't hold as much water as they used to. One of the reasons 419 00:32:27.480 --> 00:32:34.759 had to do with cookie policies and all browsers that are out there today other 420 00:32:34.920 --> 00:32:40.759 than your Xbox and your Wii have browsers and those you don't really you're not 421 00:32:40.839 --> 00:32:47.359 as worried about, like clickjacking and cross origin forgery of a bank website on 422 00:32:49.000 --> 00:32:52.440 those you know, legacy systems that people still use all the time but are 423 00:32:52.480 --> 00:32:57.200 never going to get updated. But all of the browsers that you have on 424 00:32:57.319 --> 00:33:01.599 phones and on desktops where you're likely to do work work, the cookie settings 425 00:33:02.160 --> 00:33:08.240 are now such that you can you can set a few flags like HTTPS only, 426 00:33:09.000 --> 00:33:15.480 server side only, strict origin policy, you know, a few things 427 00:33:15.519 --> 00:33:19.960 like that, and you can get all the benefits that you would have gotten 428 00:33:20.200 --> 00:33:27.400 by having your APIs go through a separate domain where you you didn't necessarily want 429 00:33:27.440 --> 00:33:35.359 to mix up the chance that your authentication middleware would be allowing cross site requests 430 00:33:36.640 --> 00:33:42.519 via via API and accidentally get authenticated with a cookie when they shouldn't have been 431 00:33:44.559 --> 00:33:46.920 a j You're absolutely right. I'm not really thought about it like you've made 432 00:33:46.920 --> 00:33:51.319 me realized. The whole point of using API dot is you're opting in to 433 00:33:51.440 --> 00:33:55.240 cause enabled requests. You're opting into cause you want cause to stop things leaking. 434 00:33:57.319 --> 00:34:00.000 But now we've got other ways around that. I guess we don't need. 435 00:34:00.119 --> 00:34:00.960 So I guess the whole punk people did use a got was like, 436 00:34:01.039 --> 00:34:04.839 no, no causes a benefit for us, it's a feature. We want 437 00:34:04.839 --> 00:34:07.079 to strict credentials. We want to make sure we don't need anything. So 438 00:34:07.079 --> 00:34:10.079 that's why if we put it on API dot we get all that for free. 439 00:34:10.159 --> 00:34:13.519 Yeah, it's a performance hit, but so you're absolutely right. I 440 00:34:13.519 --> 00:34:16.800 guess the simplest answer is causes a feature, not a bug. Yeah so, 441 00:34:17.079 --> 00:34:22.320 but but I agree. I believe that you can get all of the 442 00:34:22.320 --> 00:34:28.559 same security features today and and be reasonably assured that if somebody hasn't updated their 443 00:34:28.599 --> 00:34:35.679 browser for the last year or two, which is most people that that they 444 00:34:35.719 --> 00:34:38.000 still have that in their browser, Like it's been part of browsers long enough 445 00:34:38.000 --> 00:34:42.480 that I think, I'm pretty sure that it's safe to do. But I 446 00:34:42.519 --> 00:34:45.320 mean, my advice would be, if you're going to tell somebody switch over 447 00:34:45.559 --> 00:34:52.199 from API to slash API slash, that's great as long as the security concerns 448 00:34:52.280 --> 00:34:58.960 follow. Oh yeah, absolute in a replace. Yeah, you just said 449 00:34:59.000 --> 00:35:02.960 something that really amused me. AJ about the note updating your browser, because 450 00:35:04.000 --> 00:35:07.199 whenever I go on my wife's computer for some reason and I open up the 451 00:35:07.239 --> 00:35:12.519 browser and I see that red button saying you must update now, I'm like, 452 00:35:14.119 --> 00:35:19.159 how did you not update? My My wife probably updates her browser about 453 00:35:19.199 --> 00:35:22.719 as frequently as she updates her operating system, which is, when I sit 454 00:35:22.840 --> 00:35:27.360 down at it, I can tell that there's nothing that she's immediately using for 455 00:35:27.400 --> 00:35:31.280 something that can't be restarted from and I restart the computer. So about twice 456 00:35:31.320 --> 00:35:35.960 a year when she asked me to do something on her computer, her browser 457 00:35:36.000 --> 00:35:42.039 gets updated. And that's because she has a techy husband. Yeah, yeah, 458 00:35:42.039 --> 00:35:45.239 I really don't think. I don't think I'm I think it right. 459 00:35:45.280 --> 00:35:47.079 I think it's really easy for people like us, who are very tech fluent 460 00:35:47.119 --> 00:35:53.159 and who surrounded by every day it's second nature to us. But people aren't 461 00:35:53.199 --> 00:35:57.480 in tech. Why don't need to update it? It works? It works, 462 00:35:57.320 --> 00:36:05.119 so title call back in iOS seventeen, I don't care. So basically, 463 00:36:05.119 --> 00:36:07.880 you're saying that the fact that Windows ninety five, I think, like 464 00:36:07.960 --> 00:36:13.760 couldn't run for more than thirty nine days straight without the restart was the feature 465 00:36:13.880 --> 00:36:19.480 rather than a bug that I mean, you know, we give Microsoft a 466 00:36:19.559 --> 00:36:23.119 lot of crap for the you know, your computer is restarting and in you 467 00:36:23.119 --> 00:36:30.000 know, sixty seconds, But they're not. I mean, they are servicing 468 00:36:30.079 --> 00:36:35.519 people who are non professionals and who are you know, they're servicing the lay 469 00:36:35.519 --> 00:36:42.639 people, you know, like the average person you know. So so the 470 00:36:43.199 --> 00:36:47.559 average Mac user is someone who is it like, they're in a different tier 471 00:36:47.719 --> 00:36:53.519 of work or a different tier of economics than the average Windows user, although 472 00:36:53.519 --> 00:36:58.280 you'll be surprised, like I know, like I don't want to, you 473 00:36:58.280 --> 00:37:02.119 know, say anything bad about you know, designers, but I have seen 474 00:37:02.199 --> 00:37:09.719 some that like we're kind of unaware about tech. But tell me, like 475 00:37:10.039 --> 00:37:15.559 Harry, don't you like you know, come into a project feeling all good 476 00:37:15.639 --> 00:37:21.639 about telling them how they should optimize this or optimize that, and then run 477 00:37:21.639 --> 00:37:25.639 into like a twelve megabyte gift that they're downloading, you know, in their 478 00:37:25.639 --> 00:37:31.480 homepage or something like that. Yeah, luckily that's less frequent, and that's 479 00:37:31.519 --> 00:37:37.960 almost always a CMSA too, like a CMSUS uploaded that. So yeah, 480 00:37:37.960 --> 00:37:42.880 I like when I find really impactful, interesting or exciting things to tell people. 481 00:37:43.000 --> 00:37:46.079 But part of my standard process is, let's look for anything silly. 482 00:37:46.199 --> 00:37:52.000 Let's I take waterfall shots and I organize them by largest and smallest resource. 483 00:37:52.519 --> 00:37:57.079 And I once found a one point two megabyte fab icon, and that's because 484 00:37:57.119 --> 00:38:00.840 of the designer who was asked to export the fabicon took the entire spritesheet. 485 00:38:00.880 --> 00:38:05.360 It was back when people you sketch, and it was the entire icon sept 486 00:38:05.400 --> 00:38:08.800 for the entire website, and they couldn't be bothered exporting the fabicon, so 487 00:38:08.840 --> 00:38:14.599 they just set the bounding box to cover the falyc on the neededs and that 488 00:38:14.679 --> 00:38:20.639 the the fabic on the ico ended up being this enormous bank of data every 489 00:38:20.880 --> 00:38:23.000 icon for the site, and it's had a bounding rectangle around there. When 490 00:38:23.000 --> 00:38:27.039 they needed they exported that, it contangled the data for all the others. 491 00:38:27.559 --> 00:38:30.719 Is that right, you've got one point two megabyte faicon after Jesus it was 492 00:38:31.039 --> 00:38:37.239 unwieldy, Well there's your problem, Like just that's really low hanging through. 493 00:38:37.880 --> 00:38:43.039 Yeah. By the way, one thing that I've also encountered in many cases, 494 00:38:43.360 --> 00:38:50.119 like you know, when websites, especially created by designers, is that 495 00:38:51.079 --> 00:38:57.320 they construct the images so like you have something which is an image which should 496 00:38:57.360 --> 00:39:01.079 have been let's say, well i'll call it a JPEG, but you know, 497 00:39:01.199 --> 00:39:07.880 a lossy compressed image. But they've actually because they use some sort of 498 00:39:07.880 --> 00:39:14.039 of the software for actually doing it, and they worked in layers. They 499 00:39:14.079 --> 00:39:21.199 actually create multiple layers, and then they and and they need their transparency because 500 00:39:21.199 --> 00:39:24.800 they're now layering them one on top of the other. So they're all PNGs. 501 00:39:25.400 --> 00:39:30.119 So what could have been one jpeg ends up being comprised of like five 502 00:39:30.199 --> 00:39:37.760 PNGs. Yeah. I mean I've seen back when I used to do a 503 00:39:37.800 --> 00:39:40.559 lot of very front end work, kind of slicing other people's photoshop files. 504 00:39:42.039 --> 00:39:46.079 My biggest gripe when people make flat looking at UIs when I say flatly, 505 00:39:46.159 --> 00:39:50.039 I don't mean the design style. I mean something looks like it could be 506 00:39:50.079 --> 00:39:53.880 a flattened signal image, just a raster image exported as a JPEG, not 507 00:39:53.920 --> 00:39:58.400 even with any transparency by the way. They made the images by layering things 508 00:39:58.480 --> 00:40:01.440 up in Photoshop with loads different blends modes. But I'll have to like isolate 509 00:40:01.480 --> 00:40:05.599 it, flatten it myself, make it transparent, put a background on it, 510 00:40:05.639 --> 00:40:12.519 and then it was all just nightmarish. So like that. Designers then, 511 00:40:13.000 --> 00:40:16.119 and I say designers front and developer as people our colleagues might use sort 512 00:40:16.119 --> 00:40:21.480 of blend modes in the browser to kind of achieve the effect, but then 513 00:40:21.480 --> 00:40:25.760 that just has runtime overhead that can get really sluggish on very heavy pages when 514 00:40:25.800 --> 00:40:30.840 you've got images and elements interacting with each other and the kind of intersection of 515 00:40:30.840 --> 00:40:32.960 their blend modes. So yeah, that's not the stuff I'd tend to run 516 00:40:34.000 --> 00:40:37.199 into very often because I don't get to work on very I love my clients 517 00:40:37.280 --> 00:40:39.039 so much, I love you all very much, but I don't get to 518 00:40:39.079 --> 00:40:44.280 work on very creative projects. Normally it's just a case of here's our asset 519 00:40:44.320 --> 00:40:47.960 library of every product wesell and that's it. I guess if you look at 520 00:40:47.960 --> 00:40:52.480 WIS, you'll see things that are much more creative. Well, one of 521 00:40:52.519 --> 00:40:55.840 the more creative pages that I saw at Wix. It was actually an internal, 522 00:40:57.519 --> 00:41:00.440 an internal website built so WIGS does a whole bun a lot of dog 523 00:41:00.480 --> 00:41:05.760 footing. All the wigs stuff is actually built on wis or as much as 524 00:41:05.800 --> 00:41:09.480 possible, and certainly all the marketing pages that Wix users are built on WIGS. 525 00:41:10.000 --> 00:41:14.519 And I was asked to look at one of those marketing pages back in 526 00:41:14.559 --> 00:41:19.079 the day and they you know, talked about waterfalls. In this case, 527 00:41:19.119 --> 00:41:22.920 it was literally an image of a waterfall. So they created a beautiful page 528 00:41:22.239 --> 00:41:28.159 that had this waterfall running down the entire page, and it was built as 529 00:41:28.360 --> 00:41:37.440 one image that was ten screens long. So so I basically told them, 530 00:41:37.639 --> 00:41:45.159 let's split this image up and lazy load the rest. Something along these lines, 531 00:41:45.440 --> 00:41:51.639 so don't have a really creative thing. I saw somebody gaining LCP that 532 00:41:51.920 --> 00:41:57.000 that wasn't intended to game. That that really destroyed LCP because of the huge 533 00:41:57.000 --> 00:42:00.239 image that, Oh, I know, you reminded me of a funny story 534 00:42:00.280 --> 00:42:04.400 about you broke an image into smaller pieces. So I had a client and 535 00:42:04.400 --> 00:42:09.079 if everyone's watching just looks at like my little rectangle I'm in here, that's 536 00:42:09.119 --> 00:42:13.920 your LC. Let's say that's your LCP image on your on your homepage. 537 00:42:14.400 --> 00:42:16.280 This client was struggling to get it fast enough because the image it was quite 538 00:42:16.280 --> 00:42:20.079 detailed. They were struggling to optimize it enough that it looked nice but was 539 00:42:20.119 --> 00:42:23.559 still fast even if they're preloading whatever. It's all they did because they sliced 540 00:42:23.559 --> 00:42:29.639 it into four images and then put them right next to each other, and 541 00:42:29.719 --> 00:42:36.079 the image loaded like in a random order, but it was about four times 542 00:42:36.079 --> 00:42:38.280 faster because the image each file was about a quarter of the size. So 543 00:42:38.639 --> 00:42:43.360 whichever one of those four images arrived first was the LCP, then the subsequent 544 00:42:43.400 --> 00:42:46.679 three were ignored. It was a horrible loading experience. You'd see this image 545 00:42:46.719 --> 00:42:51.719 go h and it would a bit random, so sometimes the second image will 546 00:42:51.760 --> 00:42:54.440 be first, or the third will be first. Yeah, it is worth 547 00:42:54.599 --> 00:42:59.639 It is worth noting, by the way that in the discussions of the W 548 00:42:59.719 --> 00:43:02.880 three see Web Performance Working Group, one of the items that keeps coming up 549 00:43:04.440 --> 00:43:09.559 is how to deal with images that get progressively rendered, like when should you 550 00:43:10.159 --> 00:43:15.800 measure when? When is the NCP? When should the NCP be measured for 551 00:43:15.119 --> 00:43:21.840 progressively enhanced images? Uh? And you know it's it's one of those cases. 552 00:43:21.920 --> 00:43:24.360 It's kind of hard to say, well, that's a pretty big topic. 553 00:43:24.360 --> 00:43:28.159 AJ was going to say something before we move on. Yeah, do 554 00:43:28.199 --> 00:43:30.719 you know why that happens? That's splitting it up into four made it load 555 00:43:30.760 --> 00:43:40.639 faster. Prioritize one of them a babula, So prioritize it seems it can 556 00:43:40.960 --> 00:43:47.800 give high protis one of them. The compression algorithm is based on pixel with, 557 00:43:50.119 --> 00:43:53.599 so if you depending on how you vary the pixel with when it analyzes 558 00:43:53.639 --> 00:44:00.440 the image, it compresses differently. So sometimes just randomly resizing an image, 559 00:44:00.960 --> 00:44:04.800 you'll get better compression because you happen to hit one of the default boundaries that 560 00:44:04.840 --> 00:44:07.000 will try. There is a tool that you can use. Have you heard 561 00:44:07.039 --> 00:44:14.199 of image optum? Yeah? Yeah, yeah, So image optum will basically 562 00:44:14.400 --> 00:44:23.519 brute force every possible dictionary size in the compression algorithm and find which dictionary size 563 00:44:23.639 --> 00:44:31.480 happens to be the best one. And on an im too mac max it 564 00:44:31.800 --> 00:44:38.599 will take a couple of minutes for a relatively small image file, so it 565 00:44:38.599 --> 00:44:45.079 it really does brute force every combination that it can, but it will reduce 566 00:44:45.360 --> 00:44:51.239 the file size is much much smaller than probably any other program. That's the 567 00:44:51.440 --> 00:44:55.000 other I did not know that I thought you were talking about I thought you 568 00:44:55.039 --> 00:45:00.719 was talking from a browser's perspective, how I think size that is on the 569 00:45:00.719 --> 00:45:07.320 algorithm for me, by the way, in that context, i'd highly recommend 570 00:45:07.920 --> 00:45:13.440 watching that talk from the Performance Now conference. Who was it that gave it? 571 00:45:13.480 --> 00:45:20.280 I need to find it about about how HDP two downloads multiple resources in 572 00:45:20.320 --> 00:45:23.119 parallel, the prioritization. That talk about prioritization. You know which talk I'm 573 00:45:23.119 --> 00:45:30.599 talking about? Was it from three? Yes, it was Robin Marx. 574 00:45:30.639 --> 00:45:32.719 He was talking about, Yes, exact loading up the cutting edge. It 575 00:45:32.760 --> 00:45:37.440 was incredible, it was It was the exact kind of content I lived for. 576 00:45:37.559 --> 00:45:43.400 It was really really good Robin Mark's resource loading at the cutting edge. 577 00:45:44.599 --> 00:45:47.440 Yeah, it's an incredible talk because he talks exactly about that kind of a 578 00:45:47.480 --> 00:45:52.760 scenario where you're using the HDP too to download to you know, to download 579 00:45:52.800 --> 00:45:59.039 these four images effectively in parallel, and it depending on the browser and on 580 00:45:59.119 --> 00:46:04.719 the CDN on the server, it might download faster or it might download slower, 581 00:46:05.400 --> 00:46:09.000 and you know, it really kind of depends. Thest is, if 582 00:46:09.000 --> 00:46:13.159 you download all four images in parallel, you just slow all four of them 583 00:46:13.199 --> 00:46:15.679 down. But if your braws AER and server talking the same kind of paroraitization 584 00:46:15.800 --> 00:46:19.719 language. It'll do image one, two, three, and then four in 585 00:46:19.840 --> 00:46:22.360 order. And that's how you can gain lcp is because you can be fairly 586 00:46:22.400 --> 00:46:27.480 certain that instead of all four images are arriving at the same time, you 587 00:46:27.519 --> 00:46:31.079 get one then two than to read them for and it's we must say that 588 00:46:31.280 --> 00:46:36.920 please don't gain the metrics because you're doing more harm. You're doing more harm 589 00:46:36.960 --> 00:46:38.559 than good. At the end of the day, the metrics. You know, 590 00:46:38.719 --> 00:46:42.639 Google might care a bit, a little bit about the metrics, but 591 00:46:42.679 --> 00:46:45.079 the ones who really care a lot are your visitors. And they don't care 592 00:46:45.079 --> 00:46:49.559 about because the score. They care because of their experience, and if their 593 00:46:49.639 --> 00:46:53.800 experience is shitty, then they will leave and then you'll write it right now. 594 00:46:54.960 --> 00:46:59.159 I had this discussion today and it made me realize something really interesting about 595 00:46:59.239 --> 00:47:01.239 LCP as and Max. I've been saying this for quite a long time, 596 00:47:01.280 --> 00:47:05.519 and I know my friend Andy Davis has been saying this for a long long 597 00:47:05.559 --> 00:47:08.440 time. Largest isn't always the most important bit of content. If you go 598 00:47:08.480 --> 00:47:12.760 to the left hands a website, or you go to the British Airways website, 599 00:47:13.000 --> 00:47:15.639 the biggest bit of content is a picture of an airplane. Most important 600 00:47:15.639 --> 00:47:21.920 bit of content is the form inside of it, so we need starios like 601 00:47:21.920 --> 00:47:23.679 that. I tell clients you need custom metrics as well. Use the element 602 00:47:23.719 --> 00:47:28.480 timing API. We don't care how soon a user could see that picture of 603 00:47:28.480 --> 00:47:30.920 an airplane. We care how quickly they could see the form for booking a 604 00:47:30.920 --> 00:47:36.000 flight. So I've got a client at the moment they have a really they're 605 00:47:36.079 --> 00:47:40.840 LCP sitewide is I think it was two point six seconds. As far as 606 00:47:40.880 --> 00:47:45.159 colle vitals is concerned, we only need to find one hundred milliseconds. But 607 00:47:45.719 --> 00:47:50.119 they read a study somewhere that said somebody else improved LCP by one second and 608 00:47:50.239 --> 00:47:52.679 made ten percent more money, So they want to get their LCP down to 609 00:47:52.800 --> 00:47:58.960 one point six seconds. It's going to be really difficult for this website because 610 00:47:59.119 --> 00:48:01.440 they hit a lot of third party domains to build the page. A lot 611 00:48:01.480 --> 00:48:05.760 of the plages are still client rendered, so it's going to be really difficult 612 00:48:05.800 --> 00:48:07.400 for them to hit one point six seconds. So I said to them, 613 00:48:07.440 --> 00:48:10.920 kind of as a joke, was I know what we could do. Why 614 00:48:10.920 --> 00:48:15.920 don't we redesign. It's an e commerce website. We redesign all the product 615 00:48:15.920 --> 00:48:17.599 pages. So the heading is the biggest bit of content and the image is 616 00:48:17.599 --> 00:48:21.679 really small, then you'll have a really good LCP because text is fast and 617 00:48:21.679 --> 00:48:23.880 images are slow. No, no, we can't do that because weally people 618 00:48:23.880 --> 00:48:25.559 see the image. I was like, so, do you care about the 619 00:48:25.599 --> 00:48:30.320 metric or do you care about the customer experience? What we need to measure 620 00:48:30.320 --> 00:48:31.639 is how should And then I said to them, you don't care about the 621 00:48:31.679 --> 00:48:35.639 largest bit of content. Your image just happens to be the largest. What 622 00:48:35.639 --> 00:48:38.360 we need to measure is how soon someone could see the image. If you 623 00:48:38.480 --> 00:48:43.159 just want to get a one point six LCP, just just to say you've 624 00:48:43.159 --> 00:48:45.280 got a one point six LGP, we'll just make sure your LCP is an 625 00:48:45.280 --> 00:48:49.480 eight to one and not an image nice And we can't do that. We 626 00:48:49.480 --> 00:48:52.519 can't do that. So funnily enough, I was working on a page where 627 00:48:53.360 --> 00:49:01.519 the hero image was only really slightly larger then the title text. So I 628 00:49:01.599 --> 00:49:06.320 said, you know, if if we make the text just a little bit 629 00:49:06.400 --> 00:49:13.719 bigger, my name is just smaller. Yeah. Well, it's interesting because 630 00:49:13.760 --> 00:49:15.800 the LCP. I've read the LCP spec inside out, So I wrote an 631 00:49:15.880 --> 00:49:19.960 article about how to because it comes back. Actually, this brings us nicely 632 00:49:20.000 --> 00:49:27.360 down back to progressive images. But the LGP algorithm also uses intersectional observer to 633 00:49:27.360 --> 00:49:30.800 see how much of the element is in view. So I've got certain clients 634 00:49:30.840 --> 00:49:36.639 where if the if the mobile phone screen is short enough, the hero image 635 00:49:36.840 --> 00:49:40.079 is majority off screen, there is the h one. But someone on a 636 00:49:40.119 --> 00:49:45.639 higher resolution or slightly longer like if someone on an iPhone Mex, then the 637 00:49:45.679 --> 00:49:47.320 image well not on an iPhone obviously, if we don't cat dry estate. 638 00:49:47.440 --> 00:49:52.639 If someone's on a big phone, the image is far enough in viewport that 639 00:49:52.760 --> 00:49:57.920 it becomes LCP. So the exact same page on different mobile devices is really 640 00:49:57.920 --> 00:50:01.719 difficult. So that's why when you look at pay Speed Insights or Crooks and 641 00:50:01.760 --> 00:50:06.719 it just says desktop and mobile, it's really important to remember that inside of 642 00:50:06.760 --> 00:50:09.519 desktop and mobile there are also a lot of varieties. What I'll find is 643 00:50:10.280 --> 00:50:14.519 I don't like Lighthouse as a tool for me professionally, it's too simple, 644 00:50:14.559 --> 00:50:20.000 it's too basic, But clients love it. Web page tests their mobile devo 645 00:50:20.239 --> 00:50:29.360 vice screen sizes are smaller than Lighthouse. Yes, I'll run a Lighthouse test. 646 00:50:30.480 --> 00:50:32.760 Yeah, I'll have like to run a Lighthouse test and it'll come up 647 00:50:32.800 --> 00:50:37.960 with a different LTP to the webpage test that I'm running, so there's loads 648 00:50:37.960 --> 00:50:39.960 of disparity there. But yeah, I read the spec inside out, and 649 00:50:40.000 --> 00:50:42.960 the first thing it does, or one of the first things it does, 650 00:50:43.400 --> 00:50:45.679 is it calculates how much is even on screen, because if the image is 651 00:50:45.719 --> 00:50:50.159 bigger than the h one, but the image is majority of screen, like 652 00:50:50.199 --> 00:50:52.639 you say, then we just don't count what we can't see. And that 653 00:50:52.639 --> 00:50:55.840 brings on to the progressive images thing, which I think it's been a frustration 654 00:50:55.920 --> 00:51:00.360 for years. There is no there is no even though customer experience is better, 655 00:51:01.159 --> 00:51:07.280 there is no benefit to performance scoring using a progressive japeg, which I 656 00:51:07.440 --> 00:51:12.119 just think is unfair, or any progressive format. Yeah, I agree. 657 00:51:13.079 --> 00:51:22.000 Why would you want to use a progressive j peg because you get content, 658 00:51:22.480 --> 00:51:29.360 You get meaningful potentially meaningful content on the screen faster, do you really? 659 00:51:30.519 --> 00:51:37.079 Because I remember progressing JPEGs and they just kind of sucked, So you'd have 660 00:51:37.119 --> 00:51:39.199 to you probably want to do You're probably want to build them yourself. So 661 00:51:39.320 --> 00:51:44.400 they contain scams and you can pass in a scan file to your batch process 662 00:51:44.400 --> 00:51:46.559 your images, or do it all in bulk whatever. But what can end 663 00:51:46.639 --> 00:51:52.119 up happening is the image. The progressive jpeg in beds like eight versions of 664 00:51:52.159 --> 00:51:55.199 itself, and the first ones will look really disgusting, and that's not a 665 00:51:55.199 --> 00:51:59.639 good customer experience. You're probable to build a scan file that says, just 666 00:51:59.639 --> 00:52:04.679 build me three scans like medium high, very high quality, and do it 667 00:52:04.719 --> 00:52:08.840 that way so you avoid the really really low quality end of progressive JPEGs and 668 00:52:09.000 --> 00:52:15.119 just opt into like medium high and super high res. That's what I tend 669 00:52:15.119 --> 00:52:19.880 to do. I think I could buy into that if there was a way 670 00:52:20.119 --> 00:52:24.760 for the high DPI displays to know to pick the like for it to just 671 00:52:24.840 --> 00:52:29.480 not bother loading the super high res one unless it's high DPI. Well, 672 00:52:29.519 --> 00:52:31.880 you can with the image tag, with the picture tag or the image tag 673 00:52:31.960 --> 00:52:37.000 even these days, with you can specify images to be associated with it with 674 00:52:37.199 --> 00:52:42.920 the device's DPI. The browser is smart enough. So then why wouldn't I 675 00:52:42.960 --> 00:52:46.920 just use the picture tag and use multiple JPEGs rather than a progressive each each 676 00:52:46.960 --> 00:52:52.599 one of those complicated Yeah, each one of those multiple JPEGs would have multiple 677 00:52:52.639 --> 00:52:55.760 JPEGs inside it, so for every use case you could potentially for every one 678 00:52:55.800 --> 00:53:00.000 of them have a slightly faster LTP. Progressive is I think sort of a 679 00:53:00.079 --> 00:53:07.960 real benefit. I'll give another scenario. I'll give another scenario another thing that 680 00:53:07.000 --> 00:53:13.239 I encountered with so lot are people building their website. Let's say with white 681 00:53:13.280 --> 00:53:17.760 background, a dark background image and white text, and then what would happen 682 00:53:17.960 --> 00:53:22.679 is that until the dark image would actually load, the text would be white 683 00:53:22.719 --> 00:53:27.039 on white. So the text would be there, you just couldn't see it. 684 00:53:27.599 --> 00:53:31.199 So even have so at a certain point in time, we actually would 685 00:53:31.239 --> 00:53:37.239 have like image placeholders, kind of like what you get in like in YouTube 686 00:53:37.400 --> 00:53:43.280 style thing. But or I think Medium kind of introduced was with the first 687 00:53:43.639 --> 00:53:49.000 Yeah, to introduce that just so that you could get you would get the 688 00:53:49.079 --> 00:53:52.320 feeling that the page how the page should look like, and see that text 689 00:53:53.000 --> 00:53:58.559 faster than otherwise. But but I do have a question before we were running 690 00:53:58.599 --> 00:54:00.679 a long and I do and there are a few questions that I did want 691 00:54:00.679 --> 00:54:05.599 to get to talk about because I assume that with at least some of your 692 00:54:05.639 --> 00:54:14.840 customers, you're running into scenarios where let's say you've got poor ironp but looking 693 00:54:14.880 --> 00:54:19.360 at the site, it's because they have a lot of let's say third party 694 00:54:19.360 --> 00:54:22.119 scripts or pixels, and then you say, well, you know, you 695 00:54:22.159 --> 00:54:25.400 want to improve INP get rid of your pixels or get rid of half your 696 00:54:25.400 --> 00:54:32.360 pixels and say we can't we need them for our marketing campaigns, or alternatively, 697 00:54:34.559 --> 00:54:39.320 their score is poor because they're using like some sort of heavy framework, 698 00:54:39.360 --> 00:54:44.440 client side rendered whatnot. Like, what are you going to tell them rebuild, 699 00:54:44.679 --> 00:54:47.920 re architect your entire solution? Like what do you do in those scenarios? 700 00:54:50.719 --> 00:54:53.480 It's yeah, it's difficult. It's really difficult to advise because the answers 701 00:54:53.480 --> 00:54:57.880 are very complex. And one thing I find really interesting is if you read 702 00:54:57.880 --> 00:55:00.440 anything on web dot dev, this is always the same break up your long 703 00:55:00.480 --> 00:55:04.920 tasks. It's like, well, how step by step, how does one 704 00:55:04.960 --> 00:55:07.079 break up a long task? Be goes? If I've got a function and 705 00:55:07.199 --> 00:55:12.880 JavaScript runs like run to completion, so function can't be interrupted or paused halfway 706 00:55:12.880 --> 00:55:15.880 through. It has to finish. So if you've got a click handler that 707 00:55:15.079 --> 00:55:19.719 has to do x amount of work, telling someone to break that up is 708 00:55:19.760 --> 00:55:22.760 really difficult because well when do I do it? So what I try and 709 00:55:22.760 --> 00:55:25.480 tell clients is it's just gonna be really difficult, It's gonna be hard to 710 00:55:25.480 --> 00:55:30.280 do. But the biggest I was with a client last week. The biggest 711 00:55:30.320 --> 00:55:34.360 culprit of theirs was they did loads of synchronous Google tag Manager stuff. On 712 00:55:34.400 --> 00:55:38.039 every click, they track everything. Someone clicks the menu open, it gets 713 00:55:38.119 --> 00:55:40.679 tracked. They close it again, it gets tracked. They click in the 714 00:55:40.719 --> 00:55:45.400 soot field, it gets tracked. They don't type anything that gets trapped, 715 00:55:46.360 --> 00:55:51.639 and all of that is like that measures like okay, ten cent of people 716 00:55:51.679 --> 00:55:53.880 who enter, who clicked in the search box never typed anything, so why 717 00:55:53.920 --> 00:55:58.599 why didn't they type? So it's valuable business data, but it all happens 718 00:55:58.599 --> 00:56:00.199 synchronously. So for them when the biggest things, and like you say, 719 00:56:00.199 --> 00:56:06.519 it's a third party tag manager, is just fulfill the user need immediately and 720 00:56:06.559 --> 00:56:10.280 then sling all of that tracking work into like a set time out or request 721 00:56:10.280 --> 00:56:15.920 idle callback or you know soon not these schedular got yield. So to look 722 00:56:15.960 --> 00:56:20.719 for the obvious things. First look for the obvious things like okay, tracking, 723 00:56:20.960 --> 00:56:22.960 move that into the next task. When you still end up with a 724 00:56:22.960 --> 00:56:27.239 task that's really large and you can't break it down any further, it's really 725 00:56:27.280 --> 00:56:30.400 hard to work out what if you've got a function it needs to necessarily do 726 00:56:30.440 --> 00:56:32.599 quite a lot of heavy lifting. That's when you start to get into trouble. 727 00:56:32.840 --> 00:56:37.119 And I'm not. I'm not. I will admit i've been a first 728 00:56:37.119 --> 00:56:43.280 person's admit on a JavaScript podcast. I'm not a very proficient hardcore JavaScript developer. 729 00:56:43.320 --> 00:56:45.280 I never have been. When it comes to breaking up long tasks. 730 00:56:45.280 --> 00:56:49.000 All I can really tell clients is I can show you the tooling, we 731 00:56:49.039 --> 00:56:51.960 can look at what it's doing, but you need to decide, like which 732 00:56:52.000 --> 00:56:53.280 of this thing needs to happen immediately, which of this needs to happen for 733 00:56:53.320 --> 00:56:59.159 the user? And what can you do safely elsewhere right party If you've got 734 00:56:59.239 --> 00:57:05.480 really agreed times, that's actually what's That's actually what we ended up doing at 735 00:57:05.480 --> 00:57:09.760 Next Insurance for our currently work. So we had like treat not terrible but 736 00:57:09.880 --> 00:57:16.239 kind of mediocre I n P. But we were really anxious about having good 737 00:57:16.280 --> 00:57:22.039 coed vitals across the board even when I and P lands. So we introduced 738 00:57:22.039 --> 00:57:25.800 party town and the improvement was dramatic. So now we really have excellent I 739 00:57:25.960 --> 00:57:31.840 n P. But aside from maybe third party scripts, like, I'm really 740 00:57:32.400 --> 00:57:38.559 surprised when people have really long tasks. I mean unless you're building a really 741 00:57:38.599 --> 00:57:45.239 sophisticated web application that does something you know, like super heavy, in which 742 00:57:45.280 --> 00:57:50.320 case you know that kind of brings us back to the web applications where you 743 00:57:51.199 --> 00:57:57.079 where these issues are kind of different. Then I'm really surprised at having really 744 00:57:57.199 --> 00:58:01.639 long tasks like what are you doing like computing pie to the millions digit what? 745 00:58:01.920 --> 00:58:07.320 Like? What's what's all this computation about? Do you know what? 746 00:58:07.400 --> 00:58:13.079 I've got anyone listening? I am for hire and ironp ticks in on the 747 00:58:13.079 --> 00:58:15.559 twelfth of March, so get in touch. But I've got a full section 748 00:58:15.599 --> 00:58:21.159 of my workshop that starts out with we always blame JavaScript, and you know, 749 00:58:21.199 --> 00:58:23.360 like JavaScript is yellow Indeed tools, it's a big yellow slide. We 750 00:58:23.440 --> 00:58:28.760 always blame JavaScript, and the next side is purple for layer and recout style. 751 00:58:29.639 --> 00:58:32.559 But it's usually going to be a CSS with IP. What you'll find 752 00:58:32.719 --> 00:58:37.039 happening all the time is got to be some synchronous layout threshing. So the 753 00:58:37.079 --> 00:58:40.519 JavaScript cope head might be quite minimal, but you know someone's getting I had 754 00:58:40.519 --> 00:58:44.440 a client where they had a list of two hundred and fifty product images and 755 00:58:44.480 --> 00:58:46.960 they want to line the image wits up with the image with an element outside 756 00:58:46.960 --> 00:58:51.320 of that instead of getting the wits of the element outside and then applying that 757 00:58:51.320 --> 00:58:53.119 with to the two hundred and fifty images. They got a NOE list of 758 00:58:53.119 --> 00:58:55.280 the images. Then for each one, have e's image, make it that 759 00:58:55.320 --> 00:58:59.960 big, have eximage, and they did that all synchronously. Took five seconds. 760 00:59:00.119 --> 00:59:06.480 Layout thrashing, severe layout threshing. So oftentimes what I find and what 761 00:59:06.519 --> 00:59:10.239 I try and tell clients and developers that in training, everyone's clicked to blame 762 00:59:10.320 --> 00:59:15.519 JavaScript. But seriously, go and look for your purple and then purple is 763 00:59:15.559 --> 00:59:21.320 going to be either recalut style or it's going to be layout im in the 764 00:59:21.400 --> 00:59:25.559 right order as you're looking at them. Recoup style layout. If you've got 765 00:59:25.559 --> 00:59:30.280 long recount styles and short layout, that is because you've got complex CSS selectors, 766 00:59:30.840 --> 00:59:34.679 or you've got a lot of CSS, or you've got a lot of 767 00:59:34.800 --> 00:59:40.039 HTM out. If you've got a long layout task that's going to be structurally 768 00:59:40.039 --> 00:59:44.480 the page is quite complex to layout. You might have a lot of overlapping 769 00:59:44.519 --> 00:59:47.239 things. You might have a lot of grid or FlexBooks that relies on each 770 00:59:47.280 --> 00:59:54.639 other, so very heavy as to describe it. Pages that look like tables 771 00:59:54.639 --> 00:59:59.519 of data but aren't that are built using things like flexbox. Generally, you 772 00:59:59.519 --> 01:00:02.280 want a simple by the layer of the page. There make sure you don't 773 01:00:02.360 --> 01:00:07.880 add things to the DOM, but the dom wider. So a lot of 774 01:00:07.880 --> 01:00:13.159 the time long tasks are going to be CSSE recock style and layer I recock 775 01:00:13.199 --> 01:00:15.159 styles. Your cost going look at the cost of your CSS selectors, the 776 01:00:15.199 --> 01:00:20.280 amount of CSS or the size of the CSS object model, and the dome. 777 01:00:22.960 --> 01:00:27.360 Yeah, two points I'd like to mention. So in the context of 778 01:00:27.679 --> 01:00:31.320 we talked about layout thrashing, one of the things to take into account is 779 01:00:32.159 --> 01:00:37.440 force three flows. It's like you you kind of mentioned it. It's, 780 01:00:37.679 --> 01:00:43.679 you know, a quick explanation. When when you modify the DOM inside JavaScript, 781 01:00:44.400 --> 01:00:50.280 then in most cases the browser will try to not relay out the page 782 01:00:50.360 --> 01:00:52.880 until it absolutely has to, So basically it will try to run all the 783 01:00:52.960 --> 01:01:00.559 JavaScript and only then when the JavaScript is done, actually apply the layout changes 784 01:01:00.000 --> 01:01:07.039 that result from the DOM changes you've made. But if you if you kind 785 01:01:07.079 --> 01:01:12.000 of ask the browser the dome about let's say, the size or position of 786 01:01:12.039 --> 01:01:15.280 an element, you're kind of forcing it. You're forcing its hand, You're 787 01:01:15.320 --> 01:01:21.239 telling it you must apply all all the changes that you've done in order to 788 01:01:21.320 --> 01:01:24.960 be able to answer that question. That's called a force reflow, and layout 789 01:01:25.000 --> 01:01:30.320 thrashing is when you set something ask something, set something as something, and 790 01:01:30.360 --> 01:01:37.280 you're forcing the browser to reflow like on every iteration of the loop, as 791 01:01:37.320 --> 01:01:39.920 it were. So in that case, it's it's beneficial to break it into 792 01:01:39.960 --> 01:01:45.400 even two loops, like do all the sets and then do all the gets 793 01:01:45.880 --> 01:01:49.079 or or something or or do all the gets and then do all the sets 794 01:01:49.159 --> 01:01:53.159 whatever, but don't interleave the gets and the sets together. And I had 795 01:01:53.159 --> 01:01:57.400 a similar situation, but you know, we don't have time to go into 796 01:01:57.400 --> 01:02:00.159 the details you kind of described it. The other thing I'd like to mention 797 01:02:00.440 --> 01:02:07.159 is the CSS content visibility at a setting, which you can if you have 798 01:02:07.199 --> 01:02:12.320 a super complex page, you can at least say, well, all these 799 01:02:12.760 --> 01:02:15.679 areas that are below the fold, you know, you know, don't try 800 01:02:15.719 --> 01:02:20.599 to lay them out now because nobody sees them. And if you know that 801 01:02:20.639 --> 01:02:25.639 they can't impact what the user is actually saying, then that can really speed 802 01:02:25.760 --> 01:02:32.079 up that sort of thing. Yeah. Yeah, I've got a really it's 803 01:02:32.119 --> 01:02:36.639 a nasty CSS selector, but I used it on my I profiled it and 804 01:02:36.679 --> 01:02:39.800 it turns out even the nasty CSS selector is faster than the cost of laying 805 01:02:39.800 --> 01:02:44.639 out long blog posts. I've got certain articles on my site there tens of 806 01:02:44.679 --> 01:02:47.440 thousands of words, really really long. Most users aren't going to scroll all 807 01:02:47.440 --> 01:02:50.679 the way to the bottom, so most people aren't going to see everything. 808 01:02:51.119 --> 01:02:58.440 So I've got a selector which is main content space H two till the H 809 01:02:58.480 --> 01:03:01.039 two. So any H two you anywhere after the second AGE two, or 810 01:03:01.039 --> 01:03:06.039 you could do H two ent of type two. Everything after the second H 811 01:03:06.119 --> 01:03:10.800 two content visibility auto. So everything after the second H two. So you've 812 01:03:10.840 --> 01:03:14.239 got an H one, an H two here, maybe an H two here, 813 01:03:14.679 --> 01:03:16.440 that's going to be pretty far down the article already by the time you're 814 01:03:16.440 --> 01:03:19.719 at the second H two, you're quite far down. That's what I do 815 01:03:19.840 --> 01:03:23.360 is I say put content visibility also on everything after that, so the majority 816 01:03:23.360 --> 01:03:27.960 of the article never gets rendered until something starts scrolling towards it, and that 817 01:03:28.079 --> 01:03:32.159 more than halved layout costs for me on my particularly long blog pages. The 818 01:03:32.199 --> 01:03:37.039 only downside is, unless you're careful, you can get weird effects with the 819 01:03:37.079 --> 01:03:42.400 scroll bars. The scroll bar like rows and strains. You've got visible scroll 820 01:03:42.440 --> 01:03:45.039 bars. Yeah. The best way to check if that's working is go to 821 01:03:45.079 --> 01:03:50.159 the layer's panel and if the document layer is rendered really short or not really 822 01:03:50.199 --> 01:03:53.360 short. With the document layer is rendered, say maybe fifteen thousand pickles tall. 823 01:03:54.159 --> 01:03:57.000 Then you scroll all the way down to the bottom of the page, 824 01:03:57.000 --> 01:03:59.400 then go back to the layer's panel and it says, oh, it's actually 825 01:03:59.440 --> 01:04:02.360 seventeen. That's how you know it worked because the layers pannel is what the 826 01:04:02.360 --> 01:04:08.239 brows actually rendered. So try this hack. Go to the layers pannel, 827 01:04:08.280 --> 01:04:11.639 see how big the document layer is. Then go back to your browser, 828 01:04:12.199 --> 01:04:14.119 roll all the way to the bottom of the page, go back to the 829 01:04:14.159 --> 01:04:16.719 layers pannel, and if that figure has changed from fifteen thousand to anything else, 830 01:04:17.320 --> 01:04:20.400 it means the trip worked. But you're absolutely right. If that number 831 01:04:20.440 --> 01:04:25.519 is very different. Let's say let's say rendered runded fifteen thousand, but then 832 01:04:25.519 --> 01:04:28.840 it ended up being forty five thousand, that scroll bar is going to get 833 01:04:28.840 --> 01:04:31.440 a lot shorter. So so two things. So first of all, there's 834 01:04:31.480 --> 01:04:36.920 also the content what's it called intrinsic layout height or something, which you can 835 01:04:38.039 --> 01:04:43.159 kind of use to contrinsic layout. Yeah. And the other yeah, and 836 01:04:43.559 --> 01:04:47.480 the other thing you can do is that when the user scrolls, you can 837 01:04:47.559 --> 01:04:51.639 remove the auto or something along these lines and they change it to visible, 838 01:04:51.760 --> 01:04:56.519 so there'll be like a jump when they start scrolling, but at least that 839 01:04:56.679 --> 01:05:00.920 will only or at least you can know something a on these lines, So 840 01:05:01.239 --> 01:05:08.519 you're you're kind of it's it's all built on intersection observer anyway, so you 841 01:05:08.519 --> 01:05:10.880 could hook into that and say, as we get closer, turn it from 842 01:05:11.960 --> 01:05:15.239 also sensible or but that happens automatically. But you're absolutely right. If you're 843 01:05:15.239 --> 01:05:19.039 going to do this, you need contain intrinsic size. To say, every 844 01:05:19.039 --> 01:05:24.280 paragraph is roughly three hundred pixels tall, so every element you put contrain containing 845 01:05:24.280 --> 01:05:29.519 intrinsic size one pixel by three fifty or whatever, and that that should minimize 846 01:05:29.519 --> 01:05:32.880 the jumping that you're describing. Yeah, I think I think we need We 847 01:05:32.880 --> 01:05:36.239 are nearing the end of our show and we need to move into picks. 848 01:05:36.719 --> 01:05:42.840 So is there anything else you really would like to mention? Honestly from me, 849 01:05:43.119 --> 01:05:45.039 not much at all. Just i NP is the next thing to worry 850 01:05:45.079 --> 01:05:49.760 about for most sites that are benchmarking core went vitals. So if you haven't 851 01:05:49.800 --> 01:05:53.760 been taking it seriously already twelfth of March, if you haven't seen the announcement 852 01:05:53.840 --> 01:05:56.559 yet, if you don't know where to look for your I m P scores, 853 01:05:56.679 --> 01:06:00.400 ask your marketing team or your SEO team or whoever's in charge to give 854 01:06:00.440 --> 01:06:02.800 you access to search console and go look for coll ed vitals in there, 855 01:06:02.840 --> 01:06:05.679 and I'll tell you how to start looking. And you need any help with 856 01:06:05.719 --> 01:06:08.440 it, you can always get in touch with me. You can tweet at 857 01:06:08.480 --> 01:06:12.159 me. I've got some resources around IMP. That's the only real pressing thing 858 01:06:12.280 --> 01:06:15.159 that's on my mind at the moment. Do you know, as long as 859 01:06:15.159 --> 01:06:18.159 Google invent a new metric every two years, I've got a job for life. 860 01:06:19.159 --> 01:06:23.519 Well, the next one, I think that's the next big change that's 861 01:06:23.559 --> 01:06:29.559 probably going to land is when they start they make soft navigations official, so 862 01:06:30.280 --> 01:06:38.880 even like in multipage application single page applications, they'll start measuring the navigations between 863 01:06:39.519 --> 01:06:44.239 pages that happen on client side rendered apps. But I don't know what the 864 01:06:44.320 --> 01:06:47.039 impact will be. Will it make scores worse or better? It'll be interesting 865 01:06:47.079 --> 01:06:53.360 to see. Yeah, I think better. I think sites will get it'll 866 01:06:53.360 --> 01:06:56.280 be easy to optimize them and the scores will get better as well. I 867 01:06:56.280 --> 01:07:03.159 think that's my prediction. Time will tell. All right, I've got a 868 01:07:03.199 --> 01:07:09.199 hard stop that was thirty seconds ago, So let's go ahead and wrap up. 869 01:07:09.559 --> 01:07:12.280 First of all, Harry If people want to find you, where should 870 01:07:12.280 --> 01:07:16.840 they find you at? Regressively, CSS wizardry everywhere, so mastered on or 871 01:07:17.719 --> 01:07:23.599 X, or my website or email Gmail. If anyone needs anything, we've 872 01:07:23.599 --> 01:07:27.239 got any questions or wants any of the resources that I've spoken about, you 873 01:07:27.280 --> 01:07:31.719 can find me at CSS wizardy everywhere. All right, Thanks. Now with 874 01:07:31.760 --> 01:07:40.280 that, we'll go ahead and wrap up get to picks. Picks are where 875 01:07:40.320 --> 01:07:45.119 we just talk about something that was interesting or that we liked or that's on 876 01:07:45.159 --> 01:07:49.920 our mind that could be dech related or not. I will actually go first 877 01:07:49.920 --> 01:07:55.760 this time. So we talked about image optim so I will drop a link 878 01:07:55.840 --> 01:08:03.400 to image optim It is, like I said, the best tool as far 879 01:08:03.440 --> 01:08:15.960 as I'm aware, for being able to resize images so that they're sid Well. 880 01:08:16.039 --> 01:08:21.159 Yeah, it's brute force effective. So yeah, yeah, yeah it 881 01:08:21.199 --> 01:08:24.640 does. It does way better than it. It just takes a long time, 882 01:08:24.680 --> 01:08:27.920 you know, you just sit there and you wait. Okay, So 883 01:08:27.960 --> 01:08:31.399 there's that, and then of other things. I've been playing around more with 884 01:08:31.479 --> 01:08:36.920 Home Assistant. I now have it to the point where there's a sensor downstairs 885 01:08:38.600 --> 01:08:43.239 and I've almost I have the path to get it so that the temperature is 886 01:08:43.359 --> 01:08:48.600 changing based on the downstairs temperature. The thermostat is turning on or off based 887 01:08:48.640 --> 01:08:56.239 on the downstairs temperature rather than the temperature that's in the thermostat itself. I 888 01:08:56.359 --> 01:08:59.720 just I don't have it quite working yet because I basically have to set four 889 01:08:59.720 --> 01:09:02.960 different events of like if the temperature goes here, if the temperature goes there, 890 01:09:03.079 --> 01:09:05.039 turn on turn off. If it goes here, if it goes there, 891 01:09:05.079 --> 01:09:08.359 turn on turn off. But I got one of the events set up, 892 01:09:08.359 --> 01:09:10.880 so I know I can set up the other ones. And then I 893 01:09:12.159 --> 01:09:18.279 just ordered. Ikea has Zigbee stuff, and so I just ordered some of 894 01:09:18.279 --> 01:09:23.000 that and I'll I don't know if i'll get it this week or next or 895 01:09:23.039 --> 01:09:28.079 whatever, but they've got some switches and whatnot. The thermostat is z Wave, 896 01:09:28.680 --> 01:09:33.840 the temperature sensor is ZIGB. I'm using the Home Assistant made sky Connect 897 01:09:33.840 --> 01:09:39.600 for the Zigbi devices and some I can't remember what it is that they recommend, 898 01:09:39.680 --> 01:09:42.640 but it's on their website. Is the one they recommend for the zwave 899 01:09:42.720 --> 01:09:45.920 devices. And so well, we'll see where all this goes. It is 900 01:09:45.960 --> 01:09:49.680 a pain in the butt to set up, but if you are looking for 901 01:09:49.720 --> 01:09:56.279 an alternative to a smart home, without all of that data being constantly monitored 902 01:09:56.319 --> 01:10:00.079 and stored by Google and Amazon. There's a path. It's it doesn't seem 903 01:10:00.119 --> 01:10:02.319 like it's a pretty one. It seems like it might be a really good 904 01:10:02.319 --> 01:10:08.479 market opportunity because I just don't Ikea actually has a smart app. I haven't 905 01:10:08.640 --> 01:10:12.600 tried it out because I don't really want all my data going to Ikea either, 906 01:10:12.680 --> 01:10:16.079 because I'm sure that they don't. They're not even really a tech company 907 01:10:16.119 --> 01:10:20.439 per se. So whereas I at least trust that Google spying on me privately, 908 01:10:21.039 --> 01:10:24.159 you know, Ikia will just get hacked it. All the data will 909 01:10:24.159 --> 01:10:29.960 be out there unless they're maybe they're keeping it in some Ikeia cupboard. Yeah, 910 01:10:30.760 --> 01:10:35.880 so so anyway, and then I don't I don't recall if I've been 911 01:10:36.239 --> 01:10:41.760 talking much about the aquarium stuff that I'm doing, but it's just so fun. 912 01:10:41.800 --> 01:10:45.039 It's such a good hobby. So I've got two aquariums set up, 913 01:10:45.479 --> 01:10:48.720 and I'm I'm going to set up a few more and try some different things, 914 01:10:48.760 --> 01:10:53.119 different plants, different fish. I kind of found the fish that I 915 01:10:53.239 --> 01:10:58.159 like. H One is just referred as autos, and they are bottom feeders. 916 01:10:58.199 --> 01:11:00.640 They they must have algae in order to survive. So if you don't 917 01:11:00.640 --> 01:11:04.720 have algae in your tank, it's actually good to have a little algae in 918 01:11:04.720 --> 01:11:08.279 your tank. But if you don't have algae in your tank, you gotta 919 01:11:08.439 --> 01:11:13.359 put in some fresh vegetables and let them let them, or blanched vegetables and 920 01:11:13.399 --> 01:11:16.359 let them eat that. And then then the other ones are the the neon 921 01:11:16.439 --> 01:11:19.920 tetras. They just look so cool you have to buy. They say at 922 01:11:20.000 --> 01:11:23.680 least six of them, but I'm gonna say probably at least ten of them 923 01:11:24.119 --> 01:11:27.520 because the schooling behavior that you want to see. What's cool about them, 924 01:11:27.560 --> 01:11:30.840 other than they look beautiful, is that they swim around together. And if 925 01:11:30.840 --> 01:11:33.680 you only have six of them, they don't they're not gonna do it as 926 01:11:33.760 --> 01:11:38.119 much. So you gotta get you know, probably ten of them. And 927 01:11:38.399 --> 01:11:42.359 they say you need like a you know, ten gallon tank for six or 928 01:11:42.359 --> 01:11:45.760 a twenty gallon tank for more, but you know, if there's room in 929 01:11:45.760 --> 01:11:48.119 the tank, you can put ten in a ten gallon tank. It'll be 930 01:11:48.199 --> 01:11:56.960 fine. And then I've got a mystery snail and a fancy guppy and they 931 01:11:57.000 --> 01:12:00.680 all they all are in our main tank. Well in our main tank. 932 01:12:00.720 --> 01:12:04.560 It's not a fancy guppy it's a beta, but the beta is a mild 933 01:12:04.600 --> 01:12:09.479 tempered beta, so it's not attacking the other fish and the autos or bottom 934 01:12:09.560 --> 01:12:15.159 dwellers and the the neon tetras or mid dwellers, and the beta is a 935 01:12:15.199 --> 01:12:18.840 top dweller. So they they kind of have like it's only a ten gallon 936 01:12:18.920 --> 01:12:21.680 tank, but they have enough space that they don't have to to, you 937 01:12:21.680 --> 01:12:25.199 know, get in fights with each other anything. But it's just it's it's 938 01:12:25.239 --> 01:12:29.159 a really cool hobby. It's it's uh, I'd recommend it, and it's 939 01:12:29.199 --> 01:12:31.319 it's just it's therapeutic to you know, it's art. You know, you 940 01:12:31.399 --> 01:12:35.319 build the tank. You're not just throwing in some gravel from from pet Smarter 941 01:12:35.439 --> 01:12:39.600 Petco and then dropping some fish in. You know, you'd like you gotta 942 01:12:39.640 --> 01:12:42.960 select the aqua soil and you you know, you pattern the sandy way you 943 01:12:43.000 --> 01:12:45.680 want it. You put a hill, you put some stem plants, you 944 01:12:45.720 --> 01:12:48.000 put some other plants. It's just and then and then you actually have less 945 01:12:48.079 --> 01:12:53.960 upkeep than if you were to go the you know, the typical gravel you 946 01:12:53.960 --> 01:12:57.840 know, painted gravel route, because then the right bacteria in there, it 947 01:12:57.920 --> 01:13:02.119 becomes an ecosystem and it all cycle although there is a little bit of prep 948 01:13:02.159 --> 01:13:05.359 work you have to do to let the tank sit and cycle before you put 949 01:13:05.399 --> 01:13:09.720 the fish in so that that the right bacteria are there to help them live. 950 01:13:09.720 --> 01:13:12.279 Because if they're not there, then the fish, the first fish you 951 01:13:12.319 --> 01:13:14.239 put in the tank, if you don't know about that, they'll die. 952 01:13:15.159 --> 01:13:21.159 Uh. But anyway, like there's there's less upkeep once once the ecosystem is 953 01:13:21.199 --> 01:13:25.039 going, you know, very very little feeding that you need to do, 954 01:13:25.199 --> 01:13:29.000 very little cleaning that you need to do, you know small. You don't 955 01:13:29.279 --> 01:13:31.079 change the whole tank. You just do like a ten or twenty percent water 956 01:13:31.159 --> 01:13:40.039 change now and then. But it's it's it's it's very it's it brings joy 957 01:13:40.079 --> 01:13:45.000 to my life. So you can pick the aquarium hobby and with that I'll 958 01:13:45.079 --> 01:13:53.560 pass over to Dan. So I like my dog dogs, fish beat fish 959 01:13:53.600 --> 01:13:57.479 any the other week in my in my book, but that's not my pick. 960 01:13:58.359 --> 01:14:00.920 So my first pick, you know, how can I not pick it? 961 01:14:01.479 --> 01:14:08.079 So? Uh, you know, it's the Apple Vision Pro. I 962 01:14:08.079 --> 01:14:13.479 don't have it, I'm not planning on getting it anytime soon, but from 963 01:14:13.520 --> 01:14:19.039 the videos I saw I've seen, it's simultaneously amazing and ridiculous, So you 964 01:14:19.079 --> 01:14:26.880 know, I got to, you know, to to say that it's it's 965 01:14:26.920 --> 01:14:34.319 a brave product, but I'm just not seeing the killer app for it yet 966 01:14:34.399 --> 01:14:40.319 and I'm not and people, you know, I I've seen people like videos 967 01:14:40.359 --> 01:14:45.199 of people walking with it on the street, like that's like an invitation to 968 01:14:45.239 --> 01:14:49.279 getting beat up. I think, yeah, anyway, So so that would 969 01:14:49.279 --> 01:14:57.720 be my first pick. My my second pick is we're watching uh this show 970 01:14:58.000 --> 01:15:08.119 on uh on Netflix. It's called Griselda. It's not like a great show, 971 01:15:08.520 --> 01:15:11.319 but it's it's nice. We enjoy it, like if you're into the 972 01:15:11.439 --> 01:15:15.880 Narcos kind of thing. Uh, It's it's interesting. It turns out that 973 01:15:17.000 --> 01:15:24.279 she was like a drug kingpin in Miami in the seventies onward, and it's 974 01:15:24.319 --> 01:15:29.560 a TV show with Sofia Viergawa is actually, you know, playing pretty good 975 01:15:30.119 --> 01:15:35.239 in the lead role and it's fun. So that would be my my second 976 01:15:35.279 --> 01:15:41.439 pick. And oh, one more thing that I wanted to pick. So 977 01:15:42.039 --> 01:15:47.359 when we discussed recording this episode, one of the things that I initially hoped 978 01:15:47.399 --> 01:15:54.680 that we'd get a chance to talk about was cashing rules. But since we 979 01:15:54.840 --> 01:15:58.399 haven't gotten around to it before we run out of time, I would like 980 01:15:58.479 --> 01:16:04.000 to recommend Harry's from the Performance Now conference, the twenty twenty three talk about 981 01:16:04.319 --> 01:16:11.560 cashing, rules, everything, and I had questions I wanted to ask, 982 01:16:11.680 --> 01:16:16.039 but I'll guess I will save them for another day. But in the interim 983 01:16:16.079 --> 01:16:21.840 I highly recommend that talk. And finally, I'm like hoping for peace in 984 01:16:23.039 --> 01:16:27.880 the Middle Eastern Ukraine and that would be will be my pick for today. 985 01:16:28.720 --> 01:16:30.960 So over to you, Harry, if you've got anything that you'd like to 986 01:16:31.000 --> 01:16:38.920 shout out about, anything at all? Yeah, so nothing, nothing specific, 987 01:16:39.000 --> 01:16:42.840 nothing as relatable as yours. I'm missing cycling. I had a lot 988 01:16:42.840 --> 01:16:45.800 of cycling, but the weather's just been terrible. So that's me. My 989 01:16:45.039 --> 01:16:47.920 next thing to focus on outside of tech is getting back on the bike. 990 01:16:48.359 --> 01:16:54.039 It's hanging on the wall, just looking very very lonely and unused. I 991 01:16:54.079 --> 01:16:57.119 was obsessed with cashing last year, so sort of summertime onwards. I just 992 01:16:57.159 --> 01:17:00.159 got obsessed with cashing because I had a client with some real cific cash problems. 993 01:17:01.119 --> 01:17:05.600 That was my tech obsession for sort of fall and winter last year. 994 01:17:05.920 --> 01:17:10.720 My new obsession is memory management. I've got a client who's trying to depug 995 01:17:10.720 --> 01:17:13.880 memory leaks. They don't care about col ad vitals. They don't care about 996 01:17:13.880 --> 01:17:18.439 load times diameter. The browser. Memory leaks in the browser keeps crashing their 997 01:17:19.279 --> 01:17:24.479 their android app is a webz and it keeps crashing the android app and customers 998 01:17:24.479 --> 01:17:28.039 are complaining. So I'm now obsessed with the memory panel, which is very 999 01:17:28.119 --> 01:17:32.840 underdocumented, and yeah, let's talk. Let's talk about it because I'm actually 1000 01:17:32.880 --> 01:17:43.279 doing similar work. We've got some issues with node based services. Uh and 1001 01:17:43.760 --> 01:17:48.600 and ultimately you use the same memory panel, you take a memory dump, 1002 01:17:48.640 --> 01:17:53.560 and then you effectively use the same panel. So I it's it's yeah, 1003 01:17:53.680 --> 01:18:00.079 it's it's not an easy panel to use, but it's fairly rare that you 1004 01:18:00.239 --> 01:18:09.079 run into real memory issues with with browser applications. You know, we should 1005 01:18:09.079 --> 01:18:12.720 probably talk about it, you know, schedule some time after this podcast. 1006 01:18:13.199 --> 01:18:15.520 I'd really love to hear about some of your insights and maybe I can also 1007 01:18:15.600 --> 01:18:21.199 make some suggestions. So maybe we should schedule about it. Yeah. I'm 1008 01:18:21.239 --> 01:18:26.520 new to my performance management journey, but I'm writing a talk called memory management 1009 01:18:26.560 --> 01:18:30.439 for mere Mortals, where I am the mere mortal and I just talked about 1010 01:18:30.479 --> 01:18:31.640 Okay, I had a client who had this. I even told my client, 1011 01:18:31.800 --> 01:18:33.800 I don't think I'm the right guy for this job. I do very 1012 01:18:33.880 --> 01:18:39.119 web like loading performance. I don't do like No, we're committing the right 1013 01:18:39.159 --> 01:18:41.039 person to this job. So I did all the research and I was like, 1014 01:18:41.079 --> 01:18:43.960 Okay, we can do it, and found some really interesting insights. 1015 01:18:43.960 --> 01:18:47.079 The memory channel hasn't really been changed for nearly ten years, maybe longer, 1016 01:18:48.079 --> 01:18:50.199 but that's what I'm obsessed with at the moment, so I might either write 1017 01:18:50.199 --> 01:18:54.319 a blog post about that or that. There's definitely a talk upcoming, yeah, 1018 01:18:54.399 --> 01:18:58.640 Dan, if you want to talk about it specifically after this, Daniel, 1019 01:18:58.720 --> 01:19:03.680 let's that's we can probably a good idea. I'll ping you on on 1020 01:19:03.960 --> 01:19:09.880 X all right, Well, all right, well that thanks for coming on. 1021 01:19:10.319 --> 01:19:15.479 It's been great to have you, and you know, especially have you 1022 01:19:15.520 --> 01:19:21.199 and Dan going back and forth and dropping all those knowledge bombs on us and 1023 01:19:21.319 --> 01:19:26.960 we uh hope to see you again. Yeah, it's been great. I 1024 01:19:27.000 --> 01:19:30.720 was very privileged to be invited on. I've seen I've seen the podcast for 1025 01:19:30.920 --> 01:19:35.960 years now and I've finally got an invite, so I'm really grateful. Yeah, 1026 01:19:36.319 --> 01:19:41.479 all right, well we'll cut you later. Audios