WEBVTT 1 00:00:05.240 --> 00:00:09.240 Hey, folks, welcome back to another episode of JavaScript Jabber. This week, 2 00:00:09.320 --> 00:00:13.640 on a panel, we have Dan Shapier, Hello from a very warm 3 00:00:13.919 --> 00:00:19.879 and sunny Tel Aviv. We also have Steve Edwards. Hello from a cool 4 00:00:19.920 --> 00:00:23.640 and cloudy Portland. And I'm so jealous of Dan right now. I don't 5 00:00:23.679 --> 00:00:29.000 know. It's really really warm. I mean scorching, I think would be 6 00:00:29.039 --> 00:00:34.840 another term for it. What is it in Celsius? It went as high, 7 00:00:35.039 --> 00:00:37.679 well, today's actually kind of better, but it went as I is, 8 00:00:37.759 --> 00:00:44.000 thirty something, thirty three, thirty four. I'd still takes a never 9 00:00:44.079 --> 00:00:49.000 cold any day. It's warm. Here. I'm Charles Maxwood from Top End 10 00:00:49.039 --> 00:00:53.119 Devs, and this week you have a special guest and that's Robin Marx. 11 00:00:53.240 --> 00:00:56.840 Robin, do you want to say hello? Hello? This is Robin Marx 12 00:00:56.880 --> 00:01:00.960 from currently kind of sunny but very to be very wet and rainy Belgium, 13 00:01:03.399 --> 00:01:07.239 which which kind of sums of Belgium in one sense. I guess that's in 14 00:01:07.319 --> 00:01:15.359 chocolate chocolate them fries. I'm partial to Belgian waffles anyway. So yeah, 15 00:01:15.400 --> 00:01:18.480 So do you want to give us a little bit of background? As far 16 00:01:18.519 --> 00:01:23.959 as I see network and protocol performance, So that's kind of a broad topic, 17 00:01:25.040 --> 00:01:26.920 so you want to give us a little bit of background as to what 18 00:01:26.920 --> 00:01:30.519 we're talking about. Yeah, it really is a broad topic. Like I 19 00:01:30.560 --> 00:01:34.560 was saying to that before I started out as a game developer, and if 20 00:01:34.560 --> 00:01:40.439 you try to network games is that is a very very complex undertaking. Yeah, 21 00:01:40.519 --> 00:01:44.159 that kind of got me interested in the whole networking business for real. 22 00:01:44.920 --> 00:01:49.280 And then I got the opportunity to work on research for HTTP two. So 23 00:01:49.319 --> 00:01:55.040 this was way back in twenty fifteen. HDP two was brand new, and 24 00:01:55.120 --> 00:01:57.239 the research was like, you know, it claims all these magical things if 25 00:01:57.239 --> 00:02:00.400 you remember this, like HP two was going to twice as fast and you 26 00:02:00.439 --> 00:02:05.599 know, websites, we're going to be much much better loading. And so 27 00:02:05.680 --> 00:02:08.560 within a month of researching that, it very quickly turned out that that was 28 00:02:08.599 --> 00:02:14.360 not the case, right, absolutely not. Sometimes it was even much slower. 29 00:02:15.080 --> 00:02:15.960 And that really got me hooked. It was like, you know, 30 00:02:16.199 --> 00:02:21.439 how can this be when everybody's claiming A and it turns out to be B. 31 00:02:22.439 --> 00:02:28.599 And that spiraled out of control into an actual PhD in a networking performance 32 00:02:28.919 --> 00:02:34.479 where it's not often it's not often we have an actual like we bring somebody 33 00:02:34.520 --> 00:02:38.520 over to talk about a topic and that person actually has an actual PhD in 34 00:02:38.599 --> 00:02:42.639 that topic. Right, Well, happy to be one of the few. 35 00:02:44.520 --> 00:02:46.400 Although it's it's also a downside. I have to tell you. You do 36 00:02:46.560 --> 00:02:51.960 get like I don't know what to say, like too focused on this one, 37 00:02:52.639 --> 00:02:57.520 on this one aspect, which I'll definitely have right. I'm interested in 38 00:02:57.599 --> 00:03:02.080 all parts of performance, but I usually overemphasize the networking part a bit too 39 00:03:02.120 --> 00:03:08.039 much, and that's not always the liking of everyone. But yeah, I 40 00:03:08.120 --> 00:03:14.879 think it's actually a good thing because a lot of developers and web developers really 41 00:03:14.919 --> 00:03:21.280 take networking as a given, which is kind of I don't know, amusing 42 00:03:21.479 --> 00:03:24.039 or on the one hand, and a huge blind spot on the other, 43 00:03:24.280 --> 00:03:30.120 because networking does have like a huge impact on everything we do. I mean, 44 00:03:30.120 --> 00:03:34.639 at the end of the day, what we do is primarily delivering stuff 45 00:03:34.800 --> 00:03:38.639 over the network. I couldn't agree more. And that's also why I was 46 00:03:39.120 --> 00:03:46.000 interested in coming on this podcast specifically, because usually the network is a black 47 00:03:46.039 --> 00:03:49.080 box, right You don't really need to know how it works. It just 48 00:03:49.120 --> 00:03:53.560 works. But you have some features that allow you to manipulate what the network 49 00:03:53.599 --> 00:03:59.759 does, especially the literaars you of things like preloads and lazy loading of images, 50 00:03:59.840 --> 00:04:05.639 and ACMD for javascripts, and especially recently a fetch priority they can use 51 00:04:06.120 --> 00:04:11.680 and all those features like very directly tune what the network protocol is doing. 52 00:04:12.919 --> 00:04:15.959 But in practice people don't really understand what's happening under the hoods, and they 53 00:04:16.000 --> 00:04:21.279 make terrible mistakes with these with these features, making things slower and stead faster. 54 00:04:23.480 --> 00:04:27.560 And that's what I'm trying to do a little bit like these people a 55 00:04:27.600 --> 00:04:30.759 bit more about how it works under the hoods, so that they might not 56 00:04:30.920 --> 00:04:35.199 make the same mistakes over and over again. I have a question to kick 57 00:04:35.240 --> 00:04:41.720 us off, something that really has me curious for a long time and can 58 00:04:41.759 --> 00:04:46.480 also like get our discussion into some of the protocol and networking details potentially. 59 00:04:47.240 --> 00:04:56.160 Like I remember hearing that if your htm man is under sixty four K, 60 00:04:57.279 --> 00:05:04.560 then that's like this big performance win. Is this actually true? Oh, 61 00:05:04.600 --> 00:05:09.399 it's very interesting. Use sixty four K. The usual number is fourteen K, 62 00:05:10.800 --> 00:05:18.240 right, Maybe I got confused. I remember four and it's it's excellent 63 00:05:18.240 --> 00:05:23.360 that you show that number because the answer resulways is it depends. So where 64 00:05:23.360 --> 00:05:29.319 this comes from is something called congestion control. So this is actually a protocol 65 00:05:29.360 --> 00:05:31.800 level limit if you set up a new connection, the server can only send 66 00:05:31.920 --> 00:05:36.399 back a limited amount of data because you don't know how fast the link is 67 00:05:36.519 --> 00:05:40.000 yet, right, So the way it works is you send back a little 68 00:05:40.000 --> 00:05:43.360 bit of data, you get confirmation everything works. You can send a bit 69 00:05:43.399 --> 00:05:46.040 more, a bit more, more, and more until you're actually gaining the 70 00:05:46.079 --> 00:05:50.120 speech that you want. And it is the DCP thing, right, DSP 71 00:05:50.199 --> 00:05:57.720 and Quick Transport Protocol thing. Yeah, and so most servers, most default 72 00:05:57.720 --> 00:06:02.480 configurations of servers say that you can only send about fourteen kilobytes in that first 73 00:06:03.000 --> 00:06:08.040 response. That's about ten packets, about ten t top packets. That's where 74 00:06:08.040 --> 00:06:11.319 that comes from. And then you double it to twenty, then to forty 75 00:06:11.319 --> 00:06:15.160 eight into ad into one. So that's where that comes from. The point 76 00:06:15.199 --> 00:06:19.839 is that's a default Linux configuration. Most people don't run default configurations, especially 77 00:06:19.839 --> 00:06:24.800 if you're doing a CDN or a hosting provider. They often bump that to 78 00:06:26.360 --> 00:06:29.040 like I said, sixty four kilobytes. I think the biggest we've seen in 79 00:06:29.040 --> 00:06:33.759 practice is one hundred and twenty kilobytes on one of the CDNs. And then 80 00:06:33.800 --> 00:06:38.000 they also tune this based on the network, so they might go a bit 81 00:06:38.040 --> 00:06:40.800 higher if they know it's a cable network, and they might go a bit 82 00:06:40.839 --> 00:06:45.879 lower if they know it's like treat G for example. So conceptually, yes, 83 00:06:46.800 --> 00:06:50.439 the smaller you're initially CML is the more chance you have that it will 84 00:06:50.439 --> 00:06:55.160 get delivered in that first round trip and that you will get the benefit from 85 00:06:55.160 --> 00:07:00.439 that. But in practice it's super difficult to define that exact sweet pot always 86 00:07:00.439 --> 00:07:03.519 fourteen kilobytes, not always sixty four. Uh, it really depends on you 87 00:07:03.560 --> 00:07:08.959 I've set up and even if you get there, it's only one round trip 88 00:07:09.000 --> 00:07:15.199 that you that you win, right, which in some cases can be huge, 89 00:07:15.800 --> 00:07:19.600 but especially if you're using a CDM, it shouldn't matter too much there. 90 00:07:20.480 --> 00:07:25.399 So this is usually something I say, first look at everything else you 91 00:07:25.439 --> 00:07:29.240 can optimize, and when that's done, then you might start looking at this 92 00:07:29.319 --> 00:07:31.879 kind of stuff. Like you probably know my colleague from Malchamite, Tim Rick, 93 00:07:33.240 --> 00:07:38.279 who like super optimizes his personal website. He is running into this kind 94 00:07:38.319 --> 00:07:43.040 of stuff we're doing, like time models and stuff. Right, Yeah, 95 00:07:43.160 --> 00:07:48.079 he does scale modeling and it's uh, and he just every minute of his 96 00:07:48.120 --> 00:07:56.920 free time he spends optimizing his site super fast. Yeah right, hey, 97 00:07:58.040 --> 00:08:01.079 he's uh, he's doing very good stuff. Let's so yeah, to answer 98 00:08:01.079 --> 00:08:05.879 your question, it's not a huge boost, and it's difficult to tune, 99 00:08:05.399 --> 00:08:11.600 and it's not always sixty four kilobytes, especially in these days where like the 100 00:08:11.759 --> 00:08:16.560 HTML is kind of created for you by some sort of a meta framework that 101 00:08:16.639 --> 00:08:20.319 does hydration and you have very little control over the size and how things are 102 00:08:20.399 --> 00:08:26.879 done exactly exactly. Let's up. Something that Tim was doing was manually shortening 103 00:08:28.720 --> 00:08:33.960 the names of the CSS classes so that his first fourteen kilobytes would be shorter, 104 00:08:35.039 --> 00:08:37.919 and then the bigger part of the page was falling in stupid stuff like 105 00:08:37.960 --> 00:08:41.799 that. I wouldn't recommend anybody actually do that, but if you're a performance 106 00:08:41.840 --> 00:08:45.120 geek then you know that's the kind of stuff you can made the difference, 107 00:08:45.279 --> 00:08:50.440 what with broadly compression and stuff like that, making the names a little bit 108 00:08:50.480 --> 00:08:54.080 shorter actually made that difference for him. Not that individually he did a lot 109 00:08:54.120 --> 00:08:58.480 of those small different tricks, but like in combination, they all add up 110 00:08:58.519 --> 00:09:05.120 to to reduce just enough so that he could get whatever you wanted to pass 111 00:09:05.120 --> 00:09:11.080 in their first round trip to decline. Cool. So you were starting to 112 00:09:11.159 --> 00:09:16.799 talk about like HTTP two. Now that kind of assumes that everybody knows what 113 00:09:16.000 --> 00:09:22.480 HIDP two actually is I think everybody. I assume most people know what HTTP 114 00:09:22.840 --> 00:09:28.039 is, but people don't necessarily know what HDP one or one point one then 115 00:09:28.080 --> 00:09:31.080 two, then three are and what are the differences between them? Can you 116 00:09:31.080 --> 00:09:41.679 maybe elaborate on that? Do you have time to do a PhD then getting 117 00:09:41.679 --> 00:09:48.639 into OSI and stuff executive summary, It so very simply is top one, 118 00:09:48.200 --> 00:09:52.360 you could load one resource, one file over the connection at the time, 119 00:09:52.840 --> 00:09:58.720 so you often have multiple connections up to six typically open. And then ACP 120 00:09:58.840 --> 00:10:03.600 two changed that that you can request and download multiple files of the same connection 121 00:10:03.679 --> 00:10:09.399 at the same time. That was like multiplex. Yes, that was the 122 00:10:09.399 --> 00:10:13.679 big innovation that HCP two brought. You didn't need like thirty connections per web 123 00:10:13.720 --> 00:10:18.960 page anymore. You needed one per domain, which severely simplified a lot of 124 00:10:20.000 --> 00:10:26.519 things. And now HP three is basically the same thing as HDP two at 125 00:10:26.559 --> 00:10:30.960 that layer, At the HDP layer, they're basically the same protocols. HCDP 126 00:10:31.679 --> 00:10:35.799 three is very different because at a layer below that, right OSI layer, 127 00:10:35.840 --> 00:10:41.519 the transport protocol, we swap out TCP Transport Control Protocol for something called quick 128 00:10:41.440 --> 00:10:46.320 and quick. Then there's a lot of magic at the lower layers to better 129 00:10:46.360 --> 00:10:50.399 deal with packet loss, to better deal with slow networks, and especially add 130 00:10:50.399 --> 00:10:56.000 more encryption. Maybe you can elaborate on that a little bit, because I 131 00:10:56.039 --> 00:11:01.159 recalled from the early days people used to say that whoever try like I actually 132 00:11:01.159 --> 00:11:05.960 worked at a company that like a long time ago, that implemented our own 133 00:11:07.000 --> 00:11:13.639 protocol over UDP instead of working in DCP because we had very special requirements. 134 00:11:13.600 --> 00:11:18.360 I know that video also does that for various reasons. But there's this famous 135 00:11:18.399 --> 00:11:24.480 saying that goes that whoever, like you know, circumvents TCP or a voids 136 00:11:24.519 --> 00:11:31.639 CCP ends up reinventing DCP. So I'm kind of curious as to what was 137 00:11:31.679 --> 00:11:39.559 the motivation for replacing TCP and HDP two with quick in HDP three. Yeah, 138 00:11:39.600 --> 00:11:43.840 so I love that quote, right, you end up reinventing TCP, 139 00:11:43.039 --> 00:11:48.240 because in practice that's what Quick did. Quick is very similar to TCP, 140 00:11:48.600 --> 00:11:52.519 except a very few key areas it's not, but mostly it is. It's 141 00:11:52.559 --> 00:11:56.000 still reliable, it's a less connection set up, it's still ass catest control 142 00:11:56.080 --> 00:12:00.639 that kind of stuff. The reason why we move so quick is that you 143 00:12:00.679 --> 00:12:05.759 can't practically evolve TCP anymore. So if you try to add features to TCP, 144 00:12:05.399 --> 00:12:09.759 which we tried for decades. The problem is a lot of firewalls, 145 00:12:09.799 --> 00:12:16.840 especially expect to see certain TCP things, and if they see something new, 146 00:12:16.000 --> 00:12:20.279 a new feature being added, the firewalls don't know about that feature. They're 147 00:12:20.320 --> 00:12:22.039 like, oh, I don't know if this is a good thing or if 148 00:12:22.039 --> 00:12:26.600 this is an attacker trying some shenanigans. I'm going to play it safe and 149 00:12:26.639 --> 00:12:31.320 I'm just going to drop that traffic. So if you want to change anything 150 00:12:31.360 --> 00:12:35.639 about TCP, you're in for like a decade of waiting because all the different 151 00:12:35.639 --> 00:12:39.919 firewalls and everything else needs to get update. And you actually see this with 152 00:12:39.000 --> 00:12:43.639 IP as well, right, IBV four versus IBD six. IPv six is 153 00:12:43.679 --> 00:12:48.320 more than twenty years old, and still we have very low adoption because of 154 00:12:48.360 --> 00:12:54.039 exactly that reason. And so this sad with QUICK was you know we are 155 00:12:54.120 --> 00:13:00.720 going to encrypt every day on TCP. You basically only encrypt the HTT parts 156 00:13:01.720 --> 00:13:05.399 your credit cards and your passwords. Obviously, now with quick you also encrypt 157 00:13:05.399 --> 00:13:09.919 everything else. You also encrypt the packet numbers and the acknowledgments and the window 158 00:13:09.960 --> 00:13:13.159 and that kind of stuff. All of that is encrypted in QUICK. The 159 00:13:13.200 --> 00:13:18.879 idea being that if firewalls and other stuff can't read what's in the packets, 160 00:13:18.679 --> 00:13:24.159 they can't work or they can't break when we when we decide to update quick 161 00:13:24.200 --> 00:13:28.200 in the in the future, this is really amazing. So we have firewalls 162 00:13:28.200 --> 00:13:33.480 in place to do a certain thing, and now we are implementing the protocol 163 00:13:33.519 --> 00:13:37.799 in such a way as in order to prevent them from doing that thing, 164 00:13:37.080 --> 00:13:41.360 because it turns out that doing that thing creates issues for us. This is 165 00:13:41.440 --> 00:13:46.679 really kind of amusing. It's a game of one appmanship, kind of kind 166 00:13:46.720 --> 00:13:50.240 of exactly like that. Yes, and I have to move on stard because 167 00:13:50.240 --> 00:13:56.799 some people still don't understand this. You can still perfectly firewall quick. Quick 168 00:13:56.919 --> 00:13:58.679 is very fire wallable, but you need to do a lot more work. 169 00:14:00.279 --> 00:14:03.120 You need to actually read the RFCs. There's a new version of quick your 170 00:14:03.320 --> 00:14:07.720 you have to implement that new version of quick before you can actually start firewalling, 171 00:14:09.240 --> 00:14:15.120 which is not the case with TCP. Right. So it's kind of 172 00:14:16.200 --> 00:14:20.080 you have this wild ecosystem where everybody can do whatever they want, and that 173 00:14:20.159 --> 00:14:24.679 has turned out not to be very healthy in practice for evolvability. And they 174 00:14:24.720 --> 00:14:30.879 try to enforce this now from the browser and service side. So you said 175 00:14:30.919 --> 00:14:35.600 that one big difference is the fact that Quick is encrypted from the get go. 176 00:14:35.279 --> 00:14:41.159 You mentioned the fact that it prevents firewalls from creating issues. I think 177 00:14:41.200 --> 00:14:46.960 it also reduces the amount of handshake that you need to do because with TCP, 178 00:14:46.080 --> 00:14:50.320 or first did the tcpnhake and then you did the TLS handshake, and 179 00:14:50.360 --> 00:14:56.039 now you can all do it all in just a single handshake. I seem 180 00:14:56.080 --> 00:15:00.159 to recall, and maybe I'm recalling incorrectly that part of the motivation. And 181 00:15:00.200 --> 00:15:03.919 it's also that you know, TCP is kind of old. It's like watch 182 00:15:03.000 --> 00:15:09.679 fifty years old? How old is TCP? And yeah, and nobody was 183 00:15:09.759 --> 00:15:15.559 thinking, for example, cellular networks back when TCP started. So a lot 184 00:15:15.639 --> 00:15:22.240 of how modern networks behave is very different from what the situation was when TCP 185 00:15:22.440 --> 00:15:26.080 was created. Is that also a motivation for Quick? Or am I misunderstanding 186 00:15:28.720 --> 00:15:31.919 It's definitely part of it, right. You want TSP to be evolvable, 187 00:15:33.039 --> 00:15:37.240 you need to add additional stuff, but you can't because it takes a decade, 188 00:15:37.799 --> 00:15:41.480 right, So that's why you want QUICK to be able to I'd like 189 00:15:41.519 --> 00:15:46.759 to say that Quick is like we took everything, we learned about TCP in 190 00:15:46.759 --> 00:15:50.120 the past thirty years. We took all the best practices that we knew and 191 00:15:50.159 --> 00:15:52.879 that we want to and that we put into one big package. And that's 192 00:15:52.919 --> 00:15:58.440 now. Let's not quick with regards to not being prepared for newer technologies. 193 00:16:00.240 --> 00:16:06.679 I'm not quite in that camp. I think TCP has held up incredibly well. 194 00:16:07.039 --> 00:16:11.159 You can even run CCP on top of starlink through the satellites and just 195 00:16:11.679 --> 00:16:17.159 it just works right. But there are inefficiencies. They're definitely inefficiencies. It 196 00:16:17.200 --> 00:16:21.080 can be better, and that's what Quick tries to bring to the table, 197 00:16:21.120 --> 00:16:23.360 to add additional features, to make it faster, to make it more robust. 198 00:16:26.120 --> 00:16:27.960 But it's not like we have to drop TCP in the next five years 199 00:16:29.000 --> 00:16:30.639 or anything. I think. I think that will still be around for quite 200 00:16:30.679 --> 00:16:37.759 a while, even with five G and everything. Now. I hope you 201 00:16:37.759 --> 00:16:42.600 can understand how you can answer this honestly, given that you work for an 202 00:16:44.600 --> 00:16:51.720 how come I think with a CDN provider, Yes, and often our control 203 00:16:51.879 --> 00:16:59.879 over whether or not we use HDP two or HDP three kind of depends on 204 00:17:00.039 --> 00:17:04.440 which CDN we choose. Some CDNs, I think, or maybe today all 205 00:17:04.480 --> 00:17:08.759 of them support well the question that I'm trying to ask, really, is 206 00:17:10.480 --> 00:17:15.799 suppose I'm setting up, you know, my web presence, how important is 207 00:17:15.839 --> 00:17:22.200 it for me to make sure that it's served by HDB three versus HDP two. 208 00:17:26.079 --> 00:17:29.880 The final part of the question is quite easy. I think you can 209 00:17:30.119 --> 00:17:33.119 still just get by with HDP two perfect right, We've been doing that for 210 00:17:33.240 --> 00:17:40.079 ten years almost again. It's between and quick. Give you extra benefits can 211 00:17:40.119 --> 00:17:44.480 make it a little bit extra fast, especially in challenging conditions. It's not 212 00:17:44.519 --> 00:17:48.440 like HP two is suddenly not good enough or not good anymore. And that 213 00:17:48.519 --> 00:17:53.440 leads into the part of the first question, in the CDN part is right 214 00:17:53.480 --> 00:17:57.960 now, it's very challenging to, let's say, do self hosted HDP two 215 00:18:00.599 --> 00:18:03.319 at least if you want all the fancy new features, right, the actual 216 00:18:03.319 --> 00:18:07.359 features that make it very much faster or that will really see you change the 217 00:18:07.400 --> 00:18:11.480 metrics, those are super difficult to deploy yourself. Things like zero RGT and 218 00:18:11.519 --> 00:18:19.440 actual multipads and connection migration. That's something that requires a lot of technical debt 219 00:18:19.599 --> 00:18:26.720 and security to get right. So most people counted about themselves you need a 220 00:18:26.759 --> 00:18:30.920 CDN right now because they invest it upfront in the whole deployment of it. 221 00:18:32.400 --> 00:18:37.640 Which is also a downside because it's coming very centralized. Right. If you 222 00:18:37.680 --> 00:18:40.480 want to be on this cutting edge, if you want to use this latest 223 00:18:40.480 --> 00:18:45.200 and greatest features, even though it's like an open protocol, open standard, 224 00:18:45.839 --> 00:18:51.160 you kind of have to use one of the big companies at least for now, 225 00:18:51.200 --> 00:18:53.079 and I think that's going to last for a couple more years. So 226 00:18:53.960 --> 00:19:02.000 you can't use something like Engine X or you know, I'm trying to think 227 00:19:02.039 --> 00:19:06.160 of what Yeah, so and X is a good example because it's the one 228 00:19:06.200 --> 00:19:10.160 of the only I guess, very popular off the shelf servers that has an 229 00:19:10.160 --> 00:19:15.039 AH feature implementation does not have it and as far as I know, doesn't 230 00:19:15.039 --> 00:19:19.240 have plans. No, yes, does not have it right right, And 231 00:19:19.319 --> 00:19:23.400 even Engine X is only in the beta state right now, It's it's not 232 00:19:23.519 --> 00:19:27.519 being sold as this production ready. And even if you would run Engine X, 233 00:19:27.720 --> 00:19:33.400 like I said, real advanced features that will give you the big performance 234 00:19:33.440 --> 00:19:37.359 boosts are not going to come out of the box. You're going to need 235 00:19:37.400 --> 00:19:45.559 some custom setup or specific configuration to get those. Are there are there any 236 00:19:45.599 --> 00:19:48.359 off the shelf ones that are working on it beside it Engine X, you 237 00:19:48.359 --> 00:19:56.279 know, Caddy is a big examples. Another show. I think, Yeah, 238 00:19:56.319 --> 00:20:02.920 we've had Brian, that is, Matt Holt, Matt Hole, Matt 239 00:20:02.920 --> 00:20:07.000 Hole, that's it. Yeah. So so Caddy was quite early on. 240 00:20:07.319 --> 00:20:11.039 They used a very good go quick go library there, but even there they 241 00:20:11.039 --> 00:20:17.440 say it's production ready. Actually, there are several key features that Caddy does 242 00:20:17.480 --> 00:20:22.519 not support, and I tried to bug them about like every six months. 243 00:20:22.759 --> 00:20:30.160 Uh so it's like I should say, there's there is almost no way right 244 00:20:30.200 --> 00:20:34.079 now to get all the performance benefits of the robustness benefits that you get from 245 00:20:34.119 --> 00:20:41.480 the CDN or a big hosting provider by running it yourself. Okay, not 246 00:20:41.480 --> 00:20:47.920 not surprising to be to be on. And I'll be blunt unless you know, 247 00:20:48.000 --> 00:20:52.000 unless you have some very very good reason, which I don't know what 248 00:20:52.119 --> 00:20:59.240 it is, you don't want to be self hosted. It's just not it's 249 00:20:59.440 --> 00:21:03.880 just not worth the hassle. It's the economies of scale you want to take 250 00:21:03.920 --> 00:21:07.799 advantage of. Some that's my take on it. I'm sorry, but that's 251 00:21:07.880 --> 00:21:12.359 just how I look at it. Maybe my history E Twicks speaking, I 252 00:21:12.359 --> 00:21:19.319 don't know, but that's just my view on things. Yeah, and see 253 00:21:19.319 --> 00:21:22.640 I come at it from completely the opposite side of things. I mean, 254 00:21:22.680 --> 00:21:30.519 I self host everything I do. I encourage most of my clients. I 255 00:21:30.519 --> 00:21:33.640 mean, once I'm into the handoff where you know I'm not going to be 256 00:21:33.680 --> 00:21:37.440 maintaining things anymore, then yeah, I might push them to something that's managed 257 00:21:37.519 --> 00:21:41.720 just because they don't need to hire somebody to manage it for them. Right. 258 00:21:41.759 --> 00:21:45.720 That doesn't make as much sense as going with a vercell or Heroku or 259 00:21:45.759 --> 00:21:48.640 something. But as far as like my stuff, I mean, I self 260 00:21:48.680 --> 00:21:52.400 host it all. And the reason is is because it costs me less. 261 00:21:52.680 --> 00:21:57.599 I get exactly what I want, right, But yeah, it costs less 262 00:21:57.759 --> 00:22:02.559 if your time has no value. Let's put it this way. That I 263 00:22:02.559 --> 00:22:04.880 I also disagree with that because once I had my deploy set up, the 264 00:22:04.920 --> 00:22:10.440 deployees are fast and easy. It doesn't take not the deploy. It's look, 265 00:22:10.640 --> 00:22:18.200 I'm less familiar with the the world of Ruby on REOs, but it's 266 00:22:18.240 --> 00:22:22.319 the maintenance. It's it's making sure that you're always all patched up, that 267 00:22:22.400 --> 00:22:26.799 you're you know, if something goes down, that your own call to to 268 00:22:26.799 --> 00:22:30.920 to fix it. It's it's it's a it's just it's a it's a chore. 269 00:22:32.160 --> 00:22:36.279 Let's put it this way very bluntly. Uh and uh and in a 270 00:22:36.319 --> 00:22:40.880 lot of In many cases it's easier to pay somebody to do it for you 271 00:22:40.920 --> 00:22:44.440 and again benefit from the economies of scale. And here we hear that you've 272 00:22:44.440 --> 00:22:49.960 got one more advantage in that it can be a bit faster. Although although 273 00:22:49.960 --> 00:22:56.200 to be honest and putting quick aside, using a c d N is kind 274 00:22:56.240 --> 00:23:00.519 of a prerequisite for performance if you've got an international audience for your website. 275 00:23:03.200 --> 00:23:07.079 I agree with that last part wholeheartedly. Then I think if you're really focused 276 00:23:07.079 --> 00:23:11.519 on performance, there's you should be using a CDM. There's really no argumenticats 277 00:23:11.599 --> 00:23:15.240 that. For the earlier parts, I'm kind of in the middle. You 278 00:23:15.240 --> 00:23:18.000 know, I work for a CDM, so I do think it's a good 279 00:23:18.000 --> 00:23:22.119 thing to get someone else to do that for you. But I do feel 280 00:23:22.200 --> 00:23:27.240 very strongly that you should have the option to just do it yourself if you 281 00:23:27.319 --> 00:23:33.640 want to, right, because it does make sense for people. I won't 282 00:23:33.759 --> 00:23:37.119 argue with that. You know there are if for no other reason, then 283 00:23:37.279 --> 00:23:42.720 freedom of information, and you know you have the right to do whatever it 284 00:23:42.759 --> 00:23:48.839 is that you want to get within certain legal and moral boundaries. But but 285 00:23:49.119 --> 00:23:53.359 other than that, yes, you know you don't want to necessarily be dependent 286 00:23:53.440 --> 00:24:00.440 on the terms and conditions of somebody else. But going back to the topic 287 00:24:00.759 --> 00:24:07.720 at hand, you gave what I considered to be a really interesting talk UH 288 00:24:07.759 --> 00:24:14.400 and the fact that it had swords in it helped UH in in the in 289 00:24:14.440 --> 00:24:21.680 the in the latest UH Performance Now conference. Yeah, that one let me 290 00:24:21.720 --> 00:24:26.759 boost the fewer numbers of this one. Then, So is that like andwell, 291 00:24:27.279 --> 00:24:33.039 no, no, these actual sporting sorts that we use is from a 292 00:24:33.079 --> 00:24:37.519 movie or anything. These are just made safe for actual sporting, for actual 293 00:24:37.200 --> 00:24:44.240 hitting each other. Is that how you handle conflict resolution? Absolutely kind of 294 00:24:44.279 --> 00:24:48.079 a permanent solution. And the talk Dan mentions, I call my coworker on 295 00:24:48.160 --> 00:24:52.200 stage two to teach him a lesson. It was Tim. I think, 296 00:24:52.319 --> 00:24:57.240 wasn't it afore mentioned? Tim? Yeah, that puts you on the cutting 297 00:24:57.319 --> 00:25:03.880 edge of conflict resolution, there, doesn't it. Yeah. So, getting 298 00:25:03.920 --> 00:25:07.799 back to the to your talk, what you were talking about, as I 299 00:25:07.880 --> 00:25:15.079 recall, was about we mentioned that h gdp TO introduced multiplexing, and and 300 00:25:15.319 --> 00:25:22.160 people assume that it was a great thing and that it will utilize the network 301 00:25:22.240 --> 00:25:27.720 much more efficiently and get stuff down faster, And it turned out that that's 302 00:25:27.880 --> 00:25:36.319 not necessarily the case. And yeah, So maybe you can talk about that. 303 00:25:37.079 --> 00:25:41.720 Yeah, So I actually thought long and hard because usually when I explained 304 00:25:41.720 --> 00:25:45.160 this, I have a PowerPoint, right, actual visuals. How do I 305 00:25:45.200 --> 00:25:49.920 explain this with just audio? So I come up with a metaphor for a 306 00:25:51.839 --> 00:25:56.440 warehouse like a store. Right, Let's imagine ten people going to the store 307 00:25:56.440 --> 00:25:59.480 and you all want to check out that there's only one register, only one 308 00:25:59.519 --> 00:26:04.000 person do to check out. What happens in real life is you whoever arrives 309 00:26:04.000 --> 00:26:08.359 at the register or first gets done fully, they pay, and then the 310 00:26:08.400 --> 00:26:12.920 next one and then the next one. Imagine if that was not the case. 311 00:26:14.000 --> 00:26:18.920 Imagine if the person doing the checkout would say like, Okay, I'm 312 00:26:18.920 --> 00:26:22.440 going to take one item of the first one the first card, I'm going 313 00:26:22.480 --> 00:26:25.759 to scan that. That is going to skip you for a moment. The 314 00:26:25.759 --> 00:26:29.519 second one tick, one item from your card, scan that, go to 315 00:26:29.559 --> 00:26:32.240 the third one, one item all the way to the tenth, and then 316 00:26:32.279 --> 00:26:34.440 I'm going to come back to the front, and then one item for each 317 00:26:34.440 --> 00:26:40.640 Again. That sounds amazingly efficient, right, Well, if you think about 318 00:26:40.640 --> 00:26:47.799 it, that's kind of like how CPU's work when you do when when yeah, 319 00:26:47.920 --> 00:26:51.839 in in modern operating systems, you know Obviously, if you have got 320 00:26:52.000 --> 00:26:56.839 multi coores, then that's great, but usually you have more processes or threads 321 00:26:56.880 --> 00:27:00.880 going on than the numbers of number of cores that you have exactly in some 322 00:27:02.000 --> 00:27:07.279 time time slicing or resource sharing or whatever you decide to call it round robin 323 00:27:07.359 --> 00:27:11.440 scheduling. So in some cases it's very obvious, like let's say that round 324 00:27:11.519 --> 00:27:21.200 robin scheduling not ground robin Marx, I wish there you go and earned that 325 00:27:21.240 --> 00:27:27.160 one. Oh, it's this kind of stream, so it's easy to see 326 00:27:27.160 --> 00:27:32.480 when it becomes positive. Let's say the first person has two hundred items, 327 00:27:33.440 --> 00:27:37.960 but the third person online only has three items. Right in the first scheme, 328 00:27:37.200 --> 00:27:40.680 the third person would have to wait a long time for the first guy 329 00:27:40.799 --> 00:27:44.240 to be done. In the second one, the third person actually done much 330 00:27:44.279 --> 00:27:48.319 earlier, and you're not dealing the first one by that much because it's just 331 00:27:48.319 --> 00:27:52.480 like, let's see three items. More So, those are like the two 332 00:27:52.880 --> 00:27:56.279 extremes, right, you either do everything sequentially back to back, or you 333 00:27:56.400 --> 00:28:02.279 do something called round robin and ask you you share bandswidth in this in this 334 00:28:02.359 --> 00:28:07.720 case and in practice, you want to you want to change what happens based 335 00:28:07.720 --> 00:28:11.039 on the type of resource like the multiples in the band. Sharing is good 336 00:28:11.079 --> 00:28:17.440 for images, for example, because most images can be rendered incrementally, so 337 00:28:17.480 --> 00:28:18.880 even if you just get a little bit of the image in, you might 338 00:28:19.039 --> 00:28:23.119 already render like a blurry or a low quality version of that, and then 339 00:28:23.200 --> 00:28:26.960 it gets better the more quality you get, the more data you get in. 340 00:28:29.160 --> 00:28:33.680 But very crucially for things like javedscript and CSS, those have to be 341 00:28:33.759 --> 00:28:38.680 downloaded in full, every last bite before they can actually be applied to the 342 00:28:38.720 --> 00:28:45.160 page. So if you start doing the multiples in the robbining for childskin CSS, 343 00:28:45.200 --> 00:28:51.720 you're delaying that very, very heavily, and they can explo By the 344 00:28:51.720 --> 00:28:57.039 way, another resource that might benefit from slicing or whatever round robin whatever we 345 00:28:57.119 --> 00:29:03.559 decide to call it is HTML because htmil can actually be parsed like in parts. 346 00:29:04.000 --> 00:29:08.160 Uh. Whereas again, like you said, with JavaScript, JavaScript is 347 00:29:08.200 --> 00:29:15.000 actually a funny story these days because it actually can get parsed into bytecode I 348 00:29:15.039 --> 00:29:22.920 think while it's being streamed. But the execution can't start until everything is downloaded, 349 00:29:22.000 --> 00:29:26.160 because you know, you need that clothing curly bracket at the end. 350 00:29:27.039 --> 00:29:33.079 You can't until you have that, you can't really execute the code. And 351 00:29:33.079 --> 00:29:37.200 and I wonder why that's the case with CSS. It seems that CSS could 352 00:29:37.200 --> 00:29:41.039 be somewhere in the middle. I thinking, because you have the cascade. 353 00:29:41.240 --> 00:29:45.799 Oh yeah, because you need to cascade everything, you can't partially cascade. 354 00:29:47.039 --> 00:29:51.839 But it's true that bothelscript and CSS can be parsed and compiled in the streaming 355 00:29:51.839 --> 00:29:55.480 fashion, right, so you can process some of this and you do some 356 00:29:55.599 --> 00:29:57.559 work while it's coming in. That's not the point. It's the point that 357 00:29:57.599 --> 00:30:03.319 you need everything to actually execute, right, to actually load the childscript to 358 00:30:03.400 --> 00:30:08.079 execute the function that it's trying to do, for example, right, And 359 00:30:08.160 --> 00:30:11.480 that's what's and so to make the story around, so those are the like 360 00:30:11.519 --> 00:30:15.960 the two options multiplexing. But it turns out, right, sometimes you really 361 00:30:15.960 --> 00:30:22.119 want one and sometimes the other and sometimes something in between. And it turns 362 00:30:22.160 --> 00:30:26.960 out that a lot of servers and HP two it was mostly the servers got 363 00:30:26.960 --> 00:30:32.359 it very, very wrong. They just ignored what the browser was telling them. 364 00:30:32.799 --> 00:30:33.960 They're just like, oh, browser, you want the child's going to 365 00:30:34.000 --> 00:30:37.720 see us to be sequential. I don't really care. I'm just going to 366 00:30:37.799 --> 00:30:45.720 send them multiplexed as well. And so why conceptually a SP two could be 367 00:30:45.880 --> 00:30:49.000 as faster, even faster than as to be one different connections. In practice, 368 00:30:49.039 --> 00:30:53.920 it was not, because this whole multiplexing thing was usually just going all 369 00:30:53.960 --> 00:31:00.000 the wrong directions because of implementation books. Wait a minute with AQTP one point 370 00:31:00.200 --> 00:31:03.079 one, as you said, actually, what we had is, let's say 371 00:31:03.079 --> 00:31:07.319 we have let's simplify the scenario. Let's say it's just the one domain we 372 00:31:07.480 --> 00:31:12.559 are. The browser actually opened usually six TCP connections, and just that they 373 00:31:12.839 --> 00:31:18.759 downloaded six resources in parallel, so there was no multiplexing, but there was 374 00:31:18.799 --> 00:31:26.400 still bandwidth restrictions. So effectively, you you just you you kind of got 375 00:31:26.400 --> 00:31:30.599 the same kind of slicing, only at the lower level. Kind of. 376 00:31:30.680 --> 00:31:37.759 Yes, the problem that you get in there is that you're sharing the bandwidths, 377 00:31:37.240 --> 00:31:42.319 like you say, but the connections don't know that there are multiple connections 378 00:31:42.359 --> 00:31:45.400 active at the same time, so they're all at the same time doing this 379 00:31:45.440 --> 00:31:49.400 congestion control thing that I was talking about earlier, trying to find the bandwidth. 380 00:31:49.839 --> 00:31:53.319 So the beginning, everything goes, well, right, we're not filling 381 00:31:53.319 --> 00:31:57.519 the pipe yet, so everything doubles, doubles, doubles, so six connections 382 00:31:57.519 --> 00:32:00.599 are all doubling it more or less, say in time. So they very 383 00:32:00.640 --> 00:32:06.119 quickly riched that bandwidth limits, and then you get like a massive amount of 384 00:32:06.200 --> 00:32:12.799 packet loss because they all over extend whatever they might safely use at more or 385 00:32:12.839 --> 00:32:15.920 less the same time. So you suddenly have a big drop of bands with 386 00:32:16.079 --> 00:32:20.799 usage because now you need to stop because you have too much loss. You 387 00:32:20.799 --> 00:32:22.319 need to retransmit all those lost packets, and so on and so forth. 388 00:32:23.440 --> 00:32:28.640 While with a SPEAK two and three you have one connection, and that one 389 00:32:28.680 --> 00:32:37.559 connection can much much better decide how to ramp up that bandwidth because it knows 390 00:32:37.559 --> 00:32:42.279 that it's the only one that matters for this particular cite, for this particular 391 00:32:42.640 --> 00:32:45.519 So I wish it. I wish it was the one connection. I mean 392 00:32:45.559 --> 00:32:50.119 in this in this day and age of third party scripts and pixels and the 393 00:32:50.200 --> 00:32:53.559 fact that if you have like cores and not go a course, then you 394 00:32:53.640 --> 00:32:59.960 actually tend that ends up being even two connections per domain. You very quick 395 00:33:00.720 --> 00:33:06.240 even with a GDP two can get to a pretty high number of active connections. 396 00:33:06.640 --> 00:33:10.319 Yes, but the crucial difference there is that most of those extra connections 397 00:33:10.599 --> 00:33:15.000 don't download a ton of data like turn parties usually only only load like one 398 00:33:15.039 --> 00:33:19.920 file or something. It's still going to be one or sometimes two connections that 399 00:33:19.960 --> 00:33:24.119 download the bulk of the actual data, right, and before it used to 400 00:33:24.200 --> 00:33:30.279 be six or maybe even twelve connections the boatloading. So you now you said 401 00:33:30.440 --> 00:33:34.839 that the servers kind of ignore what the browser is telling them to do. 402 00:33:35.359 --> 00:33:37.960 So my question is, you know, regardless of that fact for a minute, 403 00:33:37.960 --> 00:33:42.960 how does the browser actually try to tell the servers what to do? 404 00:33:43.000 --> 00:33:50.039 And can we as web developers impact what the browser is saying. Excellent question, 405 00:33:50.160 --> 00:33:54.079 and that's where the aforementioned talk was about. Right, It's like a 406 00:33:54.119 --> 00:34:01.160 whole hour just on that question. So again the short summary, So browsers 407 00:34:01.160 --> 00:34:07.480 basically look at the HTML and then try to decide, Okay, this is 408 00:34:07.480 --> 00:34:12.119 probably an important resource, this is probably less important. So for example, 409 00:34:12.119 --> 00:34:15.480 the JavaScript in the head maybe even a term. The better term would be 410 00:34:15.559 --> 00:34:21.920 more urgent and less urgent not so much importance perfectly. Finally, because braxe 411 00:34:22.000 --> 00:34:24.920 is actually called urgency very good, So let's use urgent. So the browser 412 00:34:24.960 --> 00:34:29.360 says, like, okay, JavaScript in the hent is going to be more 413 00:34:29.480 --> 00:34:31.480 urgent than a child skipt in the bottom of the page, for example. 414 00:34:31.840 --> 00:34:36.760 Right, that's a power that you use. The developer have to give the 415 00:34:36.800 --> 00:34:39.199 browser a couple of hints, and so the browser then says, Okay, 416 00:34:39.239 --> 00:34:44.840 I'm going to assign an urgency or a priority to each resource based on those 417 00:34:44.920 --> 00:34:50.840 hints. You could also have like a sink and defer also manipulate tavescript urgency 418 00:34:50.920 --> 00:34:54.039 or importance, let's say. And the browser then tells the server, Okay, 419 00:34:54.639 --> 00:35:00.159 I'm requesting these resources now, and this is like the urgency or the 420 00:35:00.159 --> 00:35:04.519 the priority in which you should be delivering them. And the browser and also 421 00:35:04.559 --> 00:35:08.480 says you should either send them sequentially so one by one, or they can 422 00:35:08.519 --> 00:35:14.840 be multiplexed, they can share bandwidth. How the browser says that. The 423 00:35:14.880 --> 00:35:17.480 browser says this, yes, but I don't think you as a or we 424 00:35:17.760 --> 00:35:23.360 as as web developers can actually control that. I don't recall an API for 425 00:35:23.480 --> 00:35:28.679 that. Yeah, So that's that's the big problem in my opinion. You 426 00:35:28.760 --> 00:35:34.480 can control some of that, but very indirectly. So for example, I 427 00:35:34.480 --> 00:35:37.039 think you guys just answered the question that came in on Twitter, by the 428 00:35:37.039 --> 00:35:39.599 way, asking about bus limits. That's on the browser side, right, 429 00:35:39.599 --> 00:35:43.880 It's not on the internet side of the server side. No, no, 430 00:35:43.760 --> 00:35:50.199 no, it's bandwood limits are almost always the last mile. So usually let's 431 00:35:50.199 --> 00:35:52.840 say the Wi Fi link or from the ISP to the to the to the 432 00:35:52.880 --> 00:35:59.199 computer. Okay, so it's not the browser then it's my it's my ISP. 433 00:36:00.280 --> 00:36:06.320 It's usually the Wi Fi link. But whether or not you say the 434 00:36:06.360 --> 00:36:10.840 Wi Fi is property of the ISP or not, that's okay. So maybe 435 00:36:10.880 --> 00:36:19.760 my connection whatever connects me to my cable modem or fiber whatever do hicky that 436 00:36:19.800 --> 00:36:24.519 I have in my house usually problem same with tree T fourteen. Okay, 437 00:36:25.800 --> 00:36:30.480 that's usually limited because you're also sharing that multiple people usually write multiple people on 438 00:36:30.519 --> 00:36:37.800 the Wi Fi and the four G mast Okay, So getting back to what 439 00:36:37.840 --> 00:36:45.599 I was talking about. You can't control that directly, but some features implement 440 00:36:45.679 --> 00:36:50.440 that an indirect way. So let's say something like preload right, Preloading a 441 00:36:50.519 --> 00:36:57.840 JavaScript file implicitly changes its priority. Preloading a font changes its priority. Preloading 442 00:36:57.840 --> 00:37:02.400 an image does not by default sas this priority, which is you know, 443 00:37:02.519 --> 00:37:09.679 again somewhat unexpected for some then, So that's a good example. One way 444 00:37:09.840 --> 00:37:14.719 to explicitly control this, though, is that new thing that I talked about 445 00:37:14.719 --> 00:37:20.239 before, it's just fetch priority. Yeah, they alsouner said. Where the 446 00:37:20.320 --> 00:37:23.719 name is coming from priority, So that indicates how how important is it this 447 00:37:25.000 --> 00:37:30.039 resources too? Yeah? To our listeners are not aware of familiar with it. 448 00:37:30.039 --> 00:37:35.119 It's an attribute that you can put on stuff like images or scripts or 449 00:37:35.199 --> 00:37:40.039 literally anything that downloads or resource. Also, it exists in the browsers fetch 450 00:37:40.239 --> 00:37:49.039 dom API. You can literally specify low, high, or auto, which 451 00:37:49.079 --> 00:37:54.000 auto basically says the browser decides what to do, so you can kind of 452 00:37:54.000 --> 00:38:01.480 override the browsers automatic priority assignment and the and and like you said, there 453 00:38:01.480 --> 00:38:08.039 are some obvious values like htm man itself is obviously high or highest. Likewise 454 00:38:08.119 --> 00:38:16.079 csays up front is high or highest. Uh, well if it's in the 455 00:38:16.199 --> 00:38:22.440 head as well. And this is where it gets complex, because there's it 456 00:38:22.480 --> 00:38:25.960 turns out there's a big difference between what you as a developer might expect things 457 00:38:27.000 --> 00:38:32.480 to be and what browsers actually do. Chrome does things very differently from Safari 458 00:38:32.599 --> 00:38:37.599 and very different again from Firefox. They do not agree on what priority should 459 00:38:37.599 --> 00:38:42.679 be for individual things. So that's exactly in spe No, there is no 460 00:38:42.800 --> 00:38:45.840 spec for that at all. Spec only says this is the mechanism to send 461 00:38:45.880 --> 00:38:52.280 these values to the server. Ah, what you put, what actual values 462 00:38:52.280 --> 00:38:55.679 you use, It's not spect by anyone. I tried, I tried, 463 00:38:55.719 --> 00:39:00.719 I tried for a long time to get a suspect this nobody actually wanted that 464 00:39:00.360 --> 00:39:04.599 you get the wild Wild West. The best example of this is fonts. 465 00:39:05.360 --> 00:39:14.800 Okay, and Chrome fonts are highest priority, equal to CSS and HCML highest 466 00:39:14.840 --> 00:39:22.039 priority. In Firefox, fonts are low priority. Yeah, because and I 467 00:39:22.039 --> 00:39:27.320 can understand where it comes from, because on the one hand, you want 468 00:39:27.400 --> 00:39:31.440 fonds to download as quickly as possible because they really impact well, let's put 469 00:39:31.440 --> 00:39:37.119 it differently. It kind of depends on what browsers do with the text before 470 00:39:37.159 --> 00:39:43.400 the fonts arrive, which it can be controlled by CSS attribute, but I 471 00:39:43.440 --> 00:39:49.440 think has different defaults for the different browsers. So if the text is because 472 00:39:49.679 --> 00:39:54.400 the browser, unless it's told in some other way, won't actually start downloading 473 00:39:54.400 --> 00:40:00.639 the font until it has both the HTML and the CSS because it can't know 474 00:40:00.760 --> 00:40:05.239 which fonts it actually needs until it has both. But by that point in 475 00:40:05.320 --> 00:40:08.360 time, theoretically it could already show the text, it just doesn't have the 476 00:40:08.400 --> 00:40:14.199 font yet. So there are very different strategies of what to do about it. 477 00:40:14.800 --> 00:40:22.239 One option is show the text in whatever built in font you have and 478 00:40:22.280 --> 00:40:27.840 then switch over to the desired font once to have it. Another one is 479 00:40:27.920 --> 00:40:31.079 no, don't show anything, because it will be the wrong font and will 480 00:40:32.119 --> 00:40:37.760 be displayed all bad and things will move around once the actual font arrives, 481 00:40:37.800 --> 00:40:40.519 So don't show the text it all until the phont arrives. And then there 482 00:40:40.559 --> 00:40:45.679 are kind of like the in between solutions that show it for a short time 483 00:40:46.199 --> 00:40:52.159 with that font and then switch over or don't show anything unless it takes longer 484 00:40:52.719 --> 00:40:58.599 than some period of time and then switch over to the fallback. And the 485 00:40:58.719 --> 00:41:04.440 different strategies that you choose obviously also impact the priority you assigned to the font, 486 00:41:04.519 --> 00:41:07.400 because you want to be able to show the text as quickly as possible. 487 00:41:07.920 --> 00:41:14.400 So whether or not you're showing something in the fallback depends the impacts the 488 00:41:14.880 --> 00:41:21.519 priority you assigned to the actual font resource. Yes, but the point is, 489 00:41:22.239 --> 00:41:27.039 and it's more than that. Here the browser chooses for every single font. 490 00:41:27.320 --> 00:41:30.800 It's not like if you determine the fallback font in CSS that the browser 491 00:41:30.880 --> 00:41:36.599 is going to change the prioritization of the fonts. That would make more sense 492 00:41:36.599 --> 00:41:39.920 with your explanation, I would agree that's not what happens at all. If 493 00:41:39.920 --> 00:41:44.679 Firefox, all fonts are just low priority, whether or not you have to 494 00:41:44.719 --> 00:41:51.360 find it as a fallback or not, or treat that as not. And 495 00:41:52.360 --> 00:41:57.840 there are several other examples, especially for JavaScript, because this is childscript t 496 00:41:58.039 --> 00:42:04.159 sv right. For example, if you tag a childscript is async or defer 497 00:42:05.119 --> 00:42:09.320 in Chrome, it will give it a low priority well default cholviskit is a 498 00:42:09.400 --> 00:42:15.400 high priority, and Firefox doesn't care about that at all. If Firefox if 499 00:42:15.480 --> 00:42:20.679 acync a defer that's exactly the same priority as a normal travescript somewhere in the 500 00:42:20.719 --> 00:42:24.719 body, it doesn't make any difference there at all. So for Firefox, 501 00:42:24.760 --> 00:42:30.480 for example, it matters much more than which order you have your jawscripts defined 502 00:42:30.440 --> 00:42:37.559 than in Chrome for example. Right. So it's all these tiny little differences 503 00:42:37.559 --> 00:42:45.519 between browsers that make it very difficult to get consistent performance benefits. I've seen 504 00:42:45.559 --> 00:42:47.880 this very often, that the way a site is built where it's very well 505 00:42:47.880 --> 00:42:53.159 in one of the browsers, but then completely goes into the mark on other 506 00:42:53.239 --> 00:43:01.159 browsers and like seconds difference, seconds difference just because of what the browsers are 507 00:43:01.159 --> 00:43:06.000 doing different on the same page. And the problem is that people will of 508 00:43:06.000 --> 00:43:09.920 course mostly test on Chrome or you can get and we can only get Corbet 509 00:43:10.000 --> 00:43:14.679 vitals and stuff from Chrome, and so if the slower browsers happened to be 510 00:43:14.719 --> 00:43:22.880 safari in Firefox, people usually missed that, and and you know it's difficult 511 00:43:22.880 --> 00:43:27.280 to get them to pay attention to that. So I guess how do you 512 00:43:27.320 --> 00:43:29.960 go about solving this? I mean, you could test it on the other 513 00:43:30.000 --> 00:43:37.400 browsers, but so at this point you really can't. So fetch priority is 514 00:43:37.840 --> 00:43:42.159 helps them a little bit, right because at least you can you can be 515 00:43:42.320 --> 00:43:46.000 very clear to the browser. Like a good example is your largest common foot 516 00:43:46.000 --> 00:43:52.000 paint image, right, so the most important image on your page. All 517 00:43:52.000 --> 00:43:55.199 the browsers are giving this a lower lowest priority by default. You can say 518 00:43:55.400 --> 00:44:00.960 fetch priority high. You can use it is no longer cure it. That's 519 00:44:00.960 --> 00:44:06.920 no longer accurate for Chrome. Chrome if it identifies that it thinks an image 520 00:44:07.000 --> 00:44:10.559 might be the largest content for paint image, it would actually automatically assigned for 521 00:44:10.639 --> 00:44:15.679 it the higher priority. As I recall, it's it's a bit more general 522 00:44:15.679 --> 00:44:20.280 than that. If it figures out the image isn't the view port, then 523 00:44:21.199 --> 00:44:27.400 high, but the initial priority that requests pasifly low. They will just send 524 00:44:27.400 --> 00:44:32.119 any figured out. But I totally agree with you that if you know, 525 00:44:32.280 --> 00:44:37.719 as the content creator that a particular resource is going to be or likely B 526 00:44:38.000 --> 00:44:45.199 or l c P, then you should give it a high fetch priority and 527 00:44:45.360 --> 00:44:53.400 hope that that the server even cares you need a compliance server. But assuming 528 00:44:53.440 --> 00:44:59.360 that right, indeed, but that that becomes a problem, right because now 529 00:44:59.360 --> 00:45:04.239 you've given developers something called fetch priority high, and they really should only be 530 00:45:04.400 --> 00:45:07.679 using that on like one or two images. What most developers do in practice 531 00:45:07.760 --> 00:45:12.440 is they just put it on all the images, right, because it makes 532 00:45:12.480 --> 00:45:15.840 sense fast. Like I tell my kids, if everything is urgent, then 533 00:45:15.840 --> 00:45:21.840 nothing is urgent, right, exactly exactly. I've literally seen this last week. 534 00:45:22.760 --> 00:45:30.039 This was a site and it was preloading fifteen different images, all would 535 00:45:30.079 --> 00:45:34.639 fetch priority high in the pre load, and none of the fifteen images was 536 00:45:34.760 --> 00:45:39.920 the largest colon foot paint image. And the way the browser works because if 537 00:45:39.960 --> 00:45:45.159 you if you preload an image with fetch priority high, it becomes the same 538 00:45:45.480 --> 00:45:51.000 priority as JavaScript in the head. So they had a bunch of preloads on 539 00:45:51.039 --> 00:45:54.599 the top of the head and beloaded. They had their key JavaScript that they 540 00:45:54.639 --> 00:45:59.760 really needed to start rendering, so the JavaScript was delayed by their fifteen pre 541 00:45:59.840 --> 00:46:04.159 loaded images that were useless because none of them was even the large con painted 542 00:46:06.440 --> 00:46:08.840 and it's like, this is one of those problems that I'm trying to explain. 543 00:46:08.920 --> 00:46:14.679 It's like you give developers these high level features like preload, like fetch 544 00:46:14.719 --> 00:46:19.360 priority, like a sync and DFER, they don't really understand what they're doing 545 00:46:19.440 --> 00:46:23.840 under the hood, and they start misusing them, abusing them, and things 546 00:46:23.840 --> 00:46:29.840 can very easily go wrong because these protocol levels, things are so finicky to 547 00:46:29.920 --> 00:46:37.360 you to really get right in practice. I'm always reminded of it was a 548 00:46:37.440 --> 00:46:40.440 year or two years ago, like when native lazy loading came out on images. 549 00:46:40.480 --> 00:46:45.960 Oh if you remember that that word press, Yeah, with the WordPress 550 00:46:45.960 --> 00:46:50.199 that they made everything lazyloaded. Yeah, they made everything lazy loading because laser 551 00:46:50.239 --> 00:46:53.400 loading is good for performance, but they also lazy loaded the large skindle of 552 00:46:53.440 --> 00:46:58.960 paying images. Yeah, it's worth a very quick explanation. What happens is 553 00:46:59.039 --> 00:47:04.320 with lazy loading images, the browser doesn't start loading an image until it actually 554 00:47:04.360 --> 00:47:07.920 needs it. And by needs it, I mean that it's in the initial 555 00:47:07.039 --> 00:47:12.639 viewpoint. That means though, that in order to know whether or not to 556 00:47:12.719 --> 00:47:16.599 lazyload an image, the browser needs to know exactly where that image is located 557 00:47:16.639 --> 00:47:22.360 on the page and what its size is et cetera. And that means that 558 00:47:23.320 --> 00:47:30.480 it can't immediately know that upfront, so it kind of needs to do some 559 00:47:30.679 --> 00:47:38.760 layout before it can know. So it actually delays the loading of images that 560 00:47:38.800 --> 00:47:44.039 are marked as daisy load loaded until it knows where, you know, how 561 00:47:44.079 --> 00:47:50.679 the page is layed out, which introduces a delay that you don't want for 562 00:47:50.920 --> 00:47:57.079 your primary image. So yeah, so by making marking, everything is daisy 563 00:47:57.119 --> 00:47:59.920 loaded, because you might think, hey, I don't know it's I'll mark 564 00:48:00.079 --> 00:48:04.559 it as days ago that it's in the initial viewport, so probably no impact. 565 00:48:05.199 --> 00:48:08.199 No, it has a negative impact. You don't want to put it 566 00:48:08.760 --> 00:48:15.679 on your hero image. Yeah, exactly. And the point I want to 567 00:48:15.679 --> 00:48:20.800 make there it's the WordPress developers didn't do this because they're stupid or anything, 568 00:48:20.880 --> 00:48:25.599 right, It's just that it's so difficult to know exactly how these features are 569 00:48:25.599 --> 00:48:30.440 going to work. In practice, they're not often very well explained. That's 570 00:48:30.440 --> 00:48:36.119 one to the tooling, Especially when features are new, tooling is often lagged 571 00:48:36.159 --> 00:48:39.800 behind. There's no big red button that's going like, oh, I notice 572 00:48:39.840 --> 00:48:45.199 you're lazy loaning your LCP image. You really shouldn't do that. That's not 573 00:48:45.320 --> 00:48:51.480 included, and so people are not really given the chance to really do this 574 00:48:51.559 --> 00:48:55.320 correctly without knowing everything below the stack, which of course you don't want to. 575 00:48:55.679 --> 00:48:59.119 You don't want to know how fetch priority works on the dood. You 576 00:48:59.159 --> 00:49:06.840 shouldn't have to, but in practice you do, or you can make easy 577 00:49:06.880 --> 00:49:19.559 mistakes, sadly, So what you know, if somebody wants to do networking 578 00:49:19.880 --> 00:49:24.360 properly correctly, you know what would be the main things to look for. 579 00:49:24.599 --> 00:49:29.119 I'll let you say it, and then I have some of my own and 580 00:49:29.159 --> 00:49:35.079 we will see what overlap we get between us. That's a very broad topic. 581 00:49:37.119 --> 00:49:42.840 Just start a quickly laundry list or or or checklist that people can take 582 00:49:42.880 --> 00:49:46.679 away from our conversation here, I guess again. On the server side, 583 00:49:46.679 --> 00:49:51.840 it's very easy. Don't do it yourself. Use a CDN, use a 584 00:49:51.880 --> 00:49:57.800 hosting provider. I'm not going to say they do everything correctly. In fact, 585 00:49:57.840 --> 00:50:01.159 several of the larger CDNs and hosting providers have big issues when it comes 586 00:50:01.159 --> 00:50:09.239 to two HTP three implementations specifically, but they're likely to be closer to the 587 00:50:09.280 --> 00:50:14.480 optimal than what you can get yourself. That's that side. And then on 588 00:50:14.519 --> 00:50:22.760 the front end, use these special features in a very limited fashion. If 589 00:50:22.760 --> 00:50:25.440 you're using pre load. If you're using fatch priority and stuff, only use 590 00:50:25.480 --> 00:50:31.519 them in a very limited way and ideally start without them. See what that 591 00:50:31.559 --> 00:50:35.920 does, and then sprinkle them in where you think you might need them, 592 00:50:36.360 --> 00:50:39.840 and test the hell out of it. Do good performance a B testing to 593 00:50:39.840 --> 00:50:45.559 see what actually what actually happens. And a great tool to do that they 594 00:50:45.679 --> 00:50:50.880 be testing with is web page test. I mean you can, you can 595 00:50:50.960 --> 00:50:57.639 get very you don't agreeting. If you'd ask me this a year ago, 596 00:50:58.679 --> 00:51:02.639 I would have said, yes, pitch tests is the best. Since then, 597 00:51:04.480 --> 00:51:07.880 I think you probably know it feels like that sort of web pitch sess 598 00:51:07.960 --> 00:51:13.440 is a very good tool. But they got acquired by the company Catchpoint a 599 00:51:13.480 --> 00:51:17.000 couple of years ago, and it feels like, I'm not sure if it's 600 00:51:17.000 --> 00:51:20.960 true, but it feels like they've kind of abandoned the project a bit, 601 00:51:21.639 --> 00:51:25.400 or they're not at least not investing enough into it to keep it super relevant. 602 00:51:25.440 --> 00:51:30.199 In my opinion, there are some long setting, especially network level bugs. 603 00:51:30.360 --> 00:51:34.599 It's very difficult to debook network level stuff with web pitch tests nowadays in 604 00:51:34.599 --> 00:51:38.480 my opinion, that you just don't fix. And so for me personally, 605 00:51:38.559 --> 00:51:45.239 I've switched mostly to a different tool called the debug bear. Oh debug Bear, 606 00:51:46.360 --> 00:51:52.360 who also have a free speed test. It's in some areas it's less 607 00:51:52.480 --> 00:51:54.880 advanced than my page test, for sure, but in others, especially when 608 00:51:54.880 --> 00:51:59.920 it comes to networking features and things like oh, you're doing something wrong with 609 00:51:59.920 --> 00:52:02.039 you l CP, or you're preloading too much, that kind of stuff is 610 00:52:02.320 --> 00:52:07.639 very very well integrated into deeper Bears. Well, if you want to look 611 00:52:07.679 --> 00:52:13.519 at it from the level of somebody telling you whether or not you're following best 612 00:52:13.559 --> 00:52:17.000 practices, then Lighthouse is probably the easiest thing to use. It's it's it 613 00:52:17.079 --> 00:52:22.880 won't give you a network breakdown, you won't actually necessarily understand what's going on, 614 00:52:22.360 --> 00:52:25.480 but it will give you like, hey, you're doing this stupid thing. 615 00:52:25.760 --> 00:52:32.159 Please please don't do it like at that level, So just thick in 616 00:52:32.199 --> 00:52:37.400 there. I love Lighthouse for its audits. I think the audits are amazing, 617 00:52:37.519 --> 00:52:45.119 Yeah, exactly. But for network level stuff, it's not a good 618 00:52:45.199 --> 00:52:47.360 Yeah, yeah, I know, I know. It's it's it's not it's 619 00:52:47.440 --> 00:52:54.239 it's it's simulation. It's is of of network limit limits is let's put this 620 00:52:54.280 --> 00:52:59.639 way. I've got some results out of it which obviously made no sense. 621 00:53:01.800 --> 00:53:05.480 I think it's a great tool, but like every tool, you need to 622 00:53:05.480 --> 00:53:08.320 be able to how interpret and to use it correctly. And too many people 623 00:53:08.760 --> 00:53:14.199 just run Lighthouse, take whatever performance score it gives you, and then pretend 624 00:53:14.280 --> 00:53:16.920 like that's what you should be looking at, which is in my opinion, 625 00:53:16.960 --> 00:53:21.440 not true. But the audits are amazing. I use the audits almost daily. 626 00:53:22.320 --> 00:53:27.320 Far from my perspective. Is good for one thing. It's not as 627 00:53:27.320 --> 00:53:32.559 an absolute number, but it's an interesting indicator for regressions. So if you're 628 00:53:32.639 --> 00:53:38.079 kind of doing a performance budget, you can use that numbers as a performance 629 00:53:38.119 --> 00:53:45.159 budget to see whether or not because there's a good chance that if it's sufficiently 630 00:53:45.239 --> 00:53:52.159 significantly degraded, then you potentially introduce a real issue. But I definitely wouldn't 631 00:53:52.360 --> 00:53:55.679 be looking at it as an absolute number. Again, to an extent, 632 00:53:57.039 --> 00:54:01.920 if it's about front end features, I agree. If it's about seeing regressions 633 00:54:01.920 --> 00:54:07.280 in your network setup or on your CDM behavior, I think it's less useful 634 00:54:07.840 --> 00:54:10.880 because there is so much simulation and emulation going on at that layer that you 635 00:54:12.000 --> 00:54:15.679 might miss things, or small regressions might show up as much larger impacting. 636 00:54:15.840 --> 00:54:22.480 Oh yeah, for sure. In that way to what you stated, I 637 00:54:22.480 --> 00:54:25.039 would add some of the obvious things that I don't know if you might even 638 00:54:25.119 --> 00:54:31.119 consider them networking or not, but make sure that you have compression enabled. 639 00:54:31.280 --> 00:54:38.760 I mean, so often I see people accidentally disabling compression and obviously caching. 640 00:54:42.280 --> 00:54:45.880 Yep. The fastest thing is the thing you don't even have to send ye 641 00:54:47.360 --> 00:54:52.559 that is of course agree. And again those are things that CDNs help you 642 00:54:53.440 --> 00:54:57.599 get ninety five percent of the way as well. Right, So the main 643 00:54:57.639 --> 00:55:01.480 reasons to use the CDN is because you get this cashing and usually automatic impression 644 00:55:02.519 --> 00:55:09.320 out of the box there as well. I would also go as far as 645 00:55:09.320 --> 00:55:15.480 to say, and I've always said, this is network optimizing the network is 646 00:55:15.519 --> 00:55:20.199 not the first thing you should be thinking about, right. The differences between 647 00:55:20.239 --> 00:55:24.800 AHP two and three and all these features only come into play when you've optimized 648 00:55:24.840 --> 00:55:30.840 most of the other stuff. First, I'll start with the inverse. If 649 00:55:31.000 --> 00:55:37.480 you're like so many sites are still using client side rendering. If you're using 650 00:55:37.519 --> 00:55:40.280 client side rendering, then regardless of anything else that you might be doing, 651 00:55:40.719 --> 00:55:47.639 you won't get a good initial loading results. Now you might not necessarily care, 652 00:55:49.119 --> 00:55:51.920 I mean, if you're building a page which is not intended to be 653 00:55:52.000 --> 00:55:59.519 indexed, if it's behind some sort of authentication, if it's a dashboard or 654 00:55:59.760 --> 00:56:04.960 like for an internal app. I mean, obviously nobody wants any something to 655 00:56:05.079 --> 00:56:08.840 load, especially slow, but the loading performance might not be the most important 656 00:56:08.840 --> 00:56:15.239 consideration. And in those scenarios then then a client side rendering might be good 657 00:56:15.360 --> 00:56:20.280 enough. If, on the other hand, you're building an e commerce site, 658 00:56:20.920 --> 00:56:24.760 a marketing site, anything that needs to be indexed, it just you 659 00:56:24.800 --> 00:56:30.920 know, and and and it's client side rendered, then there's no point really 660 00:56:30.960 --> 00:56:36.519 about in talking about anything else until you fix that. I largely agree with 661 00:56:36.559 --> 00:56:42.639 that. Yes, the new ones I always try to say is like it's 662 00:56:42.679 --> 00:56:47.320 always about priorities and developer cycles that you have to spend right. Oh yeah, 663 00:56:47.360 --> 00:56:52.239 I disagree that it's just because it's an internal tool or a bt B 664 00:56:52.440 --> 00:56:57.400 tool that you shouldn't care about performance. I've had many times where I've tried 665 00:56:57.440 --> 00:57:00.639 to go onto the company portal on the four or to your treaty connection train, 666 00:57:01.280 --> 00:57:05.320 and it was really critical I looked up something within five minutes, and 667 00:57:05.320 --> 00:57:12.480 it just couldn't because it's it's crap. So I think people usually dismiss performance 668 00:57:12.519 --> 00:57:19.039 a bit too early in those kinds of situations. But I do agree, 669 00:57:19.079 --> 00:57:22.920 of course, that it's always a matter of priority that in some cases you 670 00:57:22.960 --> 00:57:25.360 might want to add more features first, even though they might think might think 671 00:57:27.360 --> 00:57:34.159 they might make things a bit slower, or alternatively, people care more about 672 00:57:34.920 --> 00:57:38.880 responsiveness in some cases rather than the initial loading speed, Like if you've got 673 00:57:38.920 --> 00:57:45.280 if again, if it's an internal if it's an internal app, then that 674 00:57:45.400 --> 00:57:50.920 you have opened in the context of your work all day long, some sort 675 00:57:51.000 --> 00:57:54.800 of I don't know, CRM or something like that, then you might care 676 00:57:54.880 --> 00:58:00.199 more about how quickly it responds to your actions what once you're loaded, rather 677 00:58:00.239 --> 00:58:05.960 than actual loading. But you're absolutely correct that if you have a large number 678 00:58:06.000 --> 00:58:09.920 of your workers, you know, commuting to the office on the train every 679 00:58:10.000 --> 00:58:15.760 day, and they actually start working on the train and they can't even get 680 00:58:15.760 --> 00:58:20.079 the app to load because it takes such a long time, and obviously it's 681 00:58:20.199 --> 00:58:23.960 it's something that you should be looking at, yes, for sure. So 682 00:58:24.400 --> 00:58:29.280 we have a question on Twitter that's asking if there are other good online resources 683 00:58:29.320 --> 00:58:35.760 like books or blogs or whatever that people can go and learn more about this 684 00:58:35.800 --> 00:58:42.559 stuff. So the best resources are if you google Robin Marx networking, then 685 00:58:45.239 --> 00:58:50.559 no, I hear that, guys, real smart I do like I'm one 686 00:58:50.559 --> 00:58:53.800 of the few people who really focuses on this stuff for the web development community, 687 00:58:54.960 --> 00:59:00.760 and I do think I put out a lot of approachable content on specifically 688 00:59:00.800 --> 00:59:06.039 this topic. The other main resource that I would say always is the the 689 00:59:06.039 --> 00:59:14.199 book High Performance Browser Networking bright Ilia Gregoric, which is available for free online 690 00:59:15.159 --> 00:59:21.440 and now take notes. It's h p b N dot c O, so 691 00:59:21.679 --> 00:59:27.079 h High Performance Browser Networking h p b N dot c O, which is 692 00:59:27.119 --> 00:59:32.840 a free online book which is slightly outdated by now, even though it's been 693 00:59:34.079 --> 00:59:37.920 updated with some things. For example, I don't think it covers HDP three 694 00:59:38.400 --> 00:59:44.920 yet, but it's still a very good resource to get with the basics. 695 00:59:45.239 --> 00:59:49.760 They explains how how the networks work underlyingly what things like and just control and 696 00:59:49.800 --> 00:59:53.320 that kind of stuff are. It's still an excellent resource. And then you 697 00:59:53.440 --> 01:00:00.000 have the h T t B two book by Barry Pollard who is now at 698 01:00:00.039 --> 01:00:04.400 Google. Google. Now we've had them on our show like once, both 699 01:00:04.440 --> 01:00:12.679 of them, so for people watching the stream, that's this one right. 700 01:00:13.760 --> 01:00:17.519 Again, I wouldn't say outdated, it's just not very recent, but it 701 01:00:17.599 --> 01:00:22.159 explains a speed to in an amazing way and again gives you a lot of 702 01:00:22.239 --> 01:00:27.320 insight into why things work the way they do and how that works, and 703 01:00:27.400 --> 01:00:30.719 a lot of what's in age between quick and what we're seeing now started with 704 01:00:30.800 --> 01:00:35.039 this kind of stuff. So it's good to get like the basics done for 705 01:00:35.119 --> 01:00:39.280 this, and then I would basically say, to finalize, don't just look 706 01:00:39.320 --> 01:00:45.800 up Robin Marx on Google. Also look up Very Pollard on Google. Barry 707 01:00:45.880 --> 01:00:52.760 got his job at Google now because he put out such consistently excellent content on 708 01:00:52.039 --> 01:00:57.800 performance and networking performance. He has a ton of excellent blog posts from before 709 01:00:58.360 --> 01:01:02.199 and now he's blotting a lot on the web dev among others, and so 710 01:01:02.360 --> 01:01:07.920 pretty much anything that Arry right is good for this kind of topic. I 711 01:01:07.920 --> 01:01:12.719 guess both of you have written quite a bit for Smashing Magazine, as I 712 01:01:12.800 --> 01:01:16.320 recall, and you've got a series of both there. Barry has done a 713 01:01:16.400 --> 01:01:20.480 lot of work there. I think he actually even worked with him on improving 714 01:01:20.519 --> 01:01:28.960 the performer loading performance of Smashing magazine itself exactly Sea, I think, Barry, 715 01:01:29.880 --> 01:01:35.559 and then performance in general, like networking performances in general, de go 716 01:01:35.719 --> 01:01:38.039 to guys, of course, Harry Roberts, who was also here a couple 717 01:01:38.119 --> 01:01:43.320 of weeks ago. I think yes, we had him as a guest on 718 01:01:43.360 --> 01:01:46.360 that show as well. He's great. And if you mentioned Harry, and 719 01:01:46.400 --> 01:01:52.639 again we talked about your talk. We're going in YouTube and just look for 720 01:01:52.800 --> 01:01:59.159 the Performance Now conference and all the talks are are published in YouTube for free 721 01:01:59.360 --> 01:02:02.440 and there's a lot of great content there. So we were talking about resource 722 01:02:02.480 --> 01:02:07.599 Hans, Harry talked about these, we were talking about cashing. Harry also 723 01:02:07.639 --> 01:02:10.719 talked about that, and of course your own talk that I mentioned with the 724 01:02:10.760 --> 01:02:17.920 swords about how how web servers and browsers handle priority and how they mess it 725 01:02:19.000 --> 01:02:25.320 up so often. Yep, and any other talk from Performance Now. It 726 01:02:25.360 --> 01:02:30.920 was a great, great edition last year. Here awesome. Well, I'm 727 01:02:30.960 --> 01:02:35.159 going to push this in the picks before we do that, Robin, where 728 01:02:35.159 --> 01:02:37.639 do people find you? You mentioned Twitter, I think before we got started. 729 01:02:39.079 --> 01:02:45.360 Yeah, so I'm at Twitter. My handless programming art. Like I 730 01:02:45.360 --> 01:02:49.320 said at the start, this is from when I still thought I could be 731 01:02:49.360 --> 01:02:52.800 an artist. I give that up, so it's not now. It's just 732 01:02:52.800 --> 01:02:57.280 a programming part that I can't change. The anbum so the handless programming art. 733 01:02:59.039 --> 01:03:01.639 You can also find my st on link in the profile there. Because 734 01:03:02.079 --> 01:03:06.360 I don't even know that by heart. And then I'm actually a lot of 735 01:03:06.480 --> 01:03:12.000 LinkedIn nowadays as well, because that's where most of the Akami related people are 736 01:03:13.679 --> 01:03:16.119 as well. You can always feel free to reach out to send me an 737 01:03:16.119 --> 01:03:21.440 email or a DM or anything. I'm always happy to talk about this kind 738 01:03:21.440 --> 01:03:27.360 of stuff. Awesome. All right, Well let's do our picks, Dan, 739 01:03:27.440 --> 01:03:30.400 Do you want to start us off with picks? Yeah? Sure, 740 01:03:30.679 --> 01:03:35.920 So two things really. The first is kind of work related, so it's 741 01:03:35.960 --> 01:03:42.360 really funny. I've started working at size Sense as principal engineer, and I'm 742 01:03:42.920 --> 01:03:51.800 learning the code base or code bases actually, and I was going through what 743 01:03:51.880 --> 01:03:54.159 was being sent over the wire kind of related to what we talked about today, 744 01:03:54.599 --> 01:03:59.840 and I thought it would be interesting to understand how the thing worked by 745 01:04:00.079 --> 01:04:04.199 diving into the networking layer. Long, shorty, long story short. Saw 746 01:04:04.239 --> 01:04:10.519 some things start fixing it, created a PR to fix it. When you 747 01:04:10.639 --> 01:04:15.400 touch networking, it spreads, and pretty soon I've got a PR that touches 748 01:04:15.480 --> 01:04:28.840 close to thirty files and uh and and yeah and yeah and whoops. It 749 01:04:28.920 --> 01:04:32.400 basically both in terms of the code execution and also of the type system. 750 01:04:32.480 --> 01:04:41.559 In the typescript, the scenario of empty server responses was not handled properly and 751 01:04:41.760 --> 01:04:46.320 uh, and yeah, it touches a lot of things. So yeah, 752 01:04:46.360 --> 01:04:51.239 anyway, so that's so pick number one is I don't know, like, 753 01:04:51.880 --> 01:04:58.639 be careful of how big a bite you choose to take when you're starting with 754 01:04:58.760 --> 01:05:01.320 a new code base. I don't no. On the other hand, it's 755 01:05:01.719 --> 01:05:08.480 an interesting way to go. You make yourself, make make everybody aware that 756 01:05:08.519 --> 01:05:13.480 you're there, very very quickly. Let's put it this way. So that's 757 01:05:13.519 --> 01:05:16.719 that's my kind of pick number one. And the other pick is an actual 758 01:05:16.800 --> 01:05:23.639 pick. Is h a show on Netflix that we recently watched and enjoyed very 759 01:05:23.760 --> 01:05:30.239 much. It's called Eric. It's with Benedict Cumberbatch. He's an amazing actor. 760 01:05:31.639 --> 01:05:36.920 The show is really kind of out there. It's a mini series sort 761 01:05:36.960 --> 01:05:41.760 of a thing I don't remember. They have like eight episodes something like that, 762 01:05:41.840 --> 01:05:45.400 and that's it. It takes place in New York in the eighties and 763 01:05:45.760 --> 01:05:53.559 has pretty much everything that you would expect in this kind of a dark drama 764 01:05:54.039 --> 01:05:59.159 about New York in the eighties. So it has a missing kid, it 765 01:05:59.320 --> 01:06:08.320 has uh, police brutality and corruption, it has h gay rights, it 766 01:06:08.519 --> 01:06:15.880 has substance abuse, it has homelessness, like everything bad that you can associate 767 01:06:15.039 --> 01:06:19.320 with New York in the eighties is kind of there. But it's actually we 768 01:06:19.440 --> 01:06:25.280 enjoyed it very much, and like I said, everybody acts. The acting 769 01:06:25.360 --> 01:06:30.639 there is top notch across the board in my opinion, and Benedict Comerbatch especially, 770 01:06:30.159 --> 01:06:38.840 he plays this person who has severe addiction issues that are that are maybe 771 01:06:38.920 --> 01:06:45.039 compounded by our result of being extremely bipolar. Yeah, it's it's it's it's 772 01:06:45.039 --> 01:06:50.559 a very interesting thing. So that would be my other pick for today. 773 01:06:50.599 --> 01:06:57.239 And those are my picks. Awesome, Steve, what are your picks? 774 01:06:58.480 --> 01:07:01.920 Well, I'll go with before we get to that high point of our episode. 775 01:07:01.960 --> 01:07:08.400 I do have one semi legit pick. There's an article I saw on 776 01:07:08.599 --> 01:07:12.920 Hacker News, and this is a little area that I have done a lot 777 01:07:12.960 --> 01:07:18.960 of reading in in terms of cosmology. It's entitled is the Universe Finite or 778 01:07:19.000 --> 01:07:25.960 Infinite? And it talks a lot about the hot Big Bang and some of 779 01:07:26.000 --> 01:07:30.559 the implications of the data that we see in terms of cosmic background radiation and 780 01:07:30.599 --> 01:07:35.400 so on, and whether there needed to be something before the hot Big Bang 781 01:07:35.639 --> 01:07:41.440 with certain requirements. It's totally scientifically geeky if you get into that stuff, 782 01:07:41.440 --> 01:07:46.199 but it's on a website called big Think. So anyway, I'll put the 783 01:07:46.239 --> 01:07:50.679 link in the show notes. And now for the I got to get all 784 01:07:50.719 --> 01:07:54.920 set because I had to move my screen around the high point of all of 785 01:07:54.920 --> 01:08:03.039 our episodes is my dad jokes of the week. So here's some basic logic 786 01:08:03.119 --> 01:08:09.079 for you. And we're into logic puzzles. So cheese has holes, right, 787 01:08:10.440 --> 01:08:15.760 more cheese equals more holes, more holes equals less cheese. So therefore 788 01:08:15.760 --> 01:08:21.239 more cheese equals less cheese. Yep, I got to think about that. 789 01:08:21.560 --> 01:08:27.039 Logic is a little twisted there, So here's one for all you Monty Python 790 01:08:27.079 --> 01:08:31.880 fans. I was in Madrid, Spain, and I got sick, and 791 01:08:31.920 --> 01:08:34.479 I was in a hotel and my hotel told me they have a doctor on 792 01:08:34.640 --> 01:08:38.439 call and I was like, really you do. He says, yeah, 793 01:08:38.479 --> 01:08:46.920 no, one expects the Spanish in physician. And then Robin is holding his 794 01:08:46.960 --> 01:08:53.239 said because he can't believe how good that was. And then finally, my 795 01:08:53.319 --> 01:08:57.359 parents raised me as an only child. That really ticked my brother off. 796 01:09:00.319 --> 01:09:04.079 Uh, now you reminded me that before the show, I said that if 797 01:09:04.119 --> 01:09:09.640 you were going to tell us some dad jokes, which obviously you were going 798 01:09:09.640 --> 01:09:14.359 to tell us some dad jokes. I'm going to mention this old video that 799 01:09:15.000 --> 01:09:19.760 from like I don't know eight years back, that ran on Nickelodeon about people 800 01:09:19.920 --> 01:09:26.359 about kids who are the victims of dad jokes and how they cope with it. 801 01:09:26.319 --> 01:09:29.840 It's it's a really funny video. That's great. I think I might 802 01:09:29.840 --> 01:09:32.439 have mentioned it before as a pick myself, but yeah, it's for those 803 01:09:32.479 --> 01:09:35.079 of you who watch it. That's in real life. That's what my kids 804 01:09:35.119 --> 01:09:41.159 go through on a regular basis. All right, I'm gonna throw out some 805 01:09:41.199 --> 01:09:45.479 picks. So my first pick is a card game is called sky Joe. 806 01:09:45.800 --> 01:09:49.479 I always do a border card game first, so I'm gonna pick sky Joe. 807 01:09:50.600 --> 01:09:55.960 Now, sky Joe is if you've played golf with like base cards, 808 01:09:56.359 --> 01:10:00.319 it's kind of like that you have a four by three grid. If you 809 01:10:00.439 --> 01:10:05.199 get if you get three of a kind in the same column, then you 810 01:10:05.239 --> 01:10:10.399 can remove the column, and then you're trying to get the lowest score, 811 01:10:10.520 --> 01:10:14.000 and you just play until the last person or the first person flips over their 812 01:10:14.079 --> 01:10:17.680 last card face up, and then the game. Everybody else gets one more 813 01:10:17.680 --> 01:10:23.119 shot to fix up their pile. If you are not the low if you 814 01:10:23.199 --> 01:10:26.960 flip over your card right. If you trigger the end and you're not the 815 01:10:27.000 --> 01:10:30.880 lowest score, then I can't there's a penalty. I can't remember the penalty 816 01:10:30.960 --> 01:10:36.119 is. But then everybody Talisa scores up and I mean that that's the game 817 01:10:36.199 --> 01:10:40.840 right there. It's board game. Geek right waits it at one point oh 818 01:10:41.000 --> 01:10:44.239 six, so it you know, we play with kids. My eight year 819 01:10:44.279 --> 01:10:46.640 old loves it when she skunk somebody right or gives them the wrong card. 820 01:10:46.680 --> 01:10:50.920 She thinks it's hilarious. So I'm gonna pick that. Another one that I'm 821 01:10:50.920 --> 01:10:56.279 gonna pick. And this is a TV show. My wife and I have 822 01:10:56.439 --> 01:11:00.239 enjoyed Criminal Minds for a long long time, and they have Criminal Minds Evolutions, 823 01:11:00.239 --> 01:11:04.439 which is just on the streaming service for whatever network they're on, I 824 01:11:04.439 --> 01:11:10.319 can't remember, but they just put out a new season. I think they've 825 01:11:10.319 --> 01:11:12.920 put out like three or four episodes on it now, and it's oh, 826 01:11:13.239 --> 01:11:16.279 they came up with a new season because it's onpo like they had like two 827 01:11:16.399 --> 01:11:20.119 seasons, one or two seasons and then like they had to stop because of 828 01:11:20.199 --> 01:11:26.840 COVID or something. So yeah, I just couldn't fill more episodes and eventually 829 01:11:26.920 --> 01:11:29.920 just had to let all the actors go or something like that. Yeah, 830 01:11:29.960 --> 01:11:34.760 so there, the the whole squad is back. So in the first season 831 01:11:34.800 --> 01:11:41.880 they're chasing the guy that like provides the serial killer kits to the serial killers, 832 01:11:41.960 --> 01:11:45.560 right, they catch him. So in the second season right there, 833 01:11:45.399 --> 01:11:47.920 there's a there's a twist on that that they're trying to chase down. And 834 01:11:48.279 --> 01:11:50.880 I don't want to spoil anything. You get it all in the first episode 835 01:11:50.880 --> 01:11:56.000 anyway, But still, if you like Criminal Minds, it's pretty awesome. 836 01:11:56.079 --> 01:12:00.800 I will say that my wife is much more sensitive to this than I am 837 01:12:00.840 --> 01:12:04.760 because it's not live on TV. There's a little more cursing in it than 838 01:12:04.920 --> 01:12:09.199 there was in the original show. So if that bothers you, it's not. 839 01:12:09.960 --> 01:12:14.159 It's not egregious like some shows. It really gets on my nervous because 840 01:12:14.159 --> 01:12:17.239 it's like every other word is an F bob and it's like you could just 841 01:12:17.239 --> 01:12:21.640 speak English right and just drop a couple. But anyway, this one's not 842 01:12:21.800 --> 01:12:26.720 bad in that regard, but there is more of it. If you liked 843 01:12:26.760 --> 01:12:31.720 the original TV series, Hey Chuck, have you ever you know? I 844 01:12:31.760 --> 01:12:38.720 don't know if you remember another show called Profiler that was on before Criminal Minds 845 01:12:38.720 --> 01:12:41.319 had a blonde gal. I can't remember her name. But have you ever 846 01:12:41.359 --> 01:12:44.920 read anything about where all that started and where all that comes from and who 847 01:12:44.960 --> 01:12:48.359 started the whole FBI profiling It's really interesting. I'd read a book by the 848 01:12:48.359 --> 01:12:51.960 guy's name is John Douglas, uh huh, and he was the FBI agent 849 01:12:53.039 --> 01:12:59.159 that created the whole behavioral Sciences unit at the FBI. He has a book 850 01:12:59.199 --> 01:13:01.520 called mind Hunter, and he's got a bunch of other books since then, 851 01:13:02.720 --> 01:13:06.520 but he talks about how he got into that, and Yeah, I was 852 01:13:06.640 --> 01:13:13.720 confused because there was a show called Mindhunter about that why on Netflix. Yeah, 853 01:13:13.760 --> 01:13:17.880 I don't show. I don't know. It was kind of kind of 854 01:13:18.000 --> 01:13:23.399 based or inspired. I didn't watch. Yeah, I think. I don't 855 01:13:23.399 --> 01:13:26.039 think it was like a documentary or anything. But if you read his books, 856 01:13:26.079 --> 01:13:30.359 it's just fascinating because basically what he did. Uh, there's a specific 857 01:13:30.840 --> 01:13:32.760 murder that started and I can't remember who it is. Larry gan Bell was 858 01:13:32.800 --> 01:13:36.920 one of the first guys they profiled, but he basically went in and spent 859 01:13:38.159 --> 01:13:43.600 hours and hours interviewing serial killers and just figuring out how they thought, what 860 01:13:43.680 --> 01:13:45.359 was their thought process, why do they do certain things? And that's how 861 01:13:45.399 --> 01:13:50.520 they slowly built this ability to to create these profiles of people. And he 862 01:13:50.560 --> 01:13:56.680 talks about some cases where they built a profile about somebody and just absolutely nailed 863 01:13:56.680 --> 01:14:00.680 it. But it's just it's hours and hours of research and like and so 864 01:14:00.000 --> 01:14:03.560 so far, really dark roads to go down. But but you know, 865 01:14:03.560 --> 01:14:08.159 if you ever get into criminal minds like that show and it's not quite as 866 01:14:08.199 --> 01:14:10.920 glamorous as they make it out to be, shocker, Oh yeah, of 867 01:14:10.960 --> 01:14:14.840 course. But but to read about it and there's all this eternal drama and 868 01:14:14.960 --> 01:14:17.039 strife, then yeah, and you mean it. They don't solve the case 869 01:14:17.079 --> 01:14:20.399 every thirty minutes, like no, no, no, it's yeah, it 870 01:14:20.439 --> 01:14:24.560 takes forty minutes. Yeah, it takes a long time. But if you 871 01:14:24.560 --> 01:14:27.800 look up John Douglas and all of his books, uh, he's the guy 872 01:14:27.840 --> 01:14:33.800 that started at all. I'm waiting for HBO Max to launch in my country, 873 01:14:33.800 --> 01:14:36.720 which is in like two weeks, because then will I will finally be 874 01:14:36.800 --> 01:14:42.960 able to rewatch True Detective if you ever watched it, Oh yeah, I've 875 01:14:43.000 --> 01:14:47.720 startpecially one is I still have yet to finish the very first season. I've 876 01:14:47.720 --> 01:14:50.159 watched like four or five episodes, but I don't have it and I haven't 877 01:14:50.159 --> 01:14:51.960 been able to sit down and watch it. I still got to watch the 878 01:14:53.039 --> 01:14:57.920 end of that first one. Oh there's a pick from Robin. Oh yeah, 879 01:14:58.039 --> 01:15:01.520 true, detective. All right, I'm gonna throw a couple more things 880 01:15:01.520 --> 01:15:05.880 and I'll let you finish this out Robin with more picks. So yeah, 881 01:15:06.000 --> 01:15:12.239 keep thinking of them. So I've gotten back into marathon training. I was 882 01:15:12.279 --> 01:15:15.840 doing triathlons for a while. Triathlons are a lot more work to train for 883 01:15:15.079 --> 01:15:20.520 than marathons, mostly because I have to go to the gym and get in 884 01:15:20.560 --> 01:15:25.439 the pool right, and then I have to maintain my bike. With the 885 01:15:25.439 --> 01:15:29.319 marathons, I buy a new pair of shoes when I need it. I 886 01:15:29.359 --> 01:15:33.720 mean, you know, that's about it. So anyway, I'm my legs 887 01:15:33.840 --> 01:15:39.439 hurt. They hurt. But anyway, I'm using Training Peaks to train, 888 01:15:40.000 --> 01:15:44.520 and I bought just to really short like get back into running, run the 889 01:15:44.560 --> 01:15:47.439 whole way for a ten k because I had really let it go right The 890 01:15:47.479 --> 01:15:54.760 last marathon I ran was five years ago, and so anyway, so I've 891 01:15:54.760 --> 01:15:58.680 been working through that and I think the training program I bought was five bucks. 892 01:15:59.079 --> 01:16:01.920 You can get a premium Training Peaks account, but you don't actually have 893 01:16:02.000 --> 01:16:06.039 to have it. There are some nice features that come with it. It 894 01:16:06.079 --> 01:16:11.760 does some automatic stuff for you, and you know, if you have a 895 01:16:11.800 --> 01:16:14.880 trainer, then you can add your trainer to it and they can anyway. 896 01:16:14.880 --> 01:16:18.039 That that's what you get out of paying for it, And yeah, the 897 01:16:18.079 --> 01:16:21.880 features are just convenient enough to kind of make it worth it. But I'm 898 01:16:23.039 --> 01:16:26.199 I'm going on the free plan right now. But training with Peaks works really 899 01:16:26.239 --> 01:16:29.920 well. And then it sinks with my Garmin watch. So I have a 900 01:16:29.960 --> 01:16:33.439 Garmin four Runner two thirty five that I bought when I trained for the marathon 901 01:16:33.479 --> 01:16:39.560 five years ago, and so it just sinks it up to my phone, 902 01:16:39.600 --> 01:16:42.239 so all I have to er, well, it sinks to my phone through 903 01:16:42.279 --> 01:16:45.239 the garment app, and then the garment app sinks it to my watch. 904 01:16:45.000 --> 01:16:47.960 And so when I go out to run, I literally just go and select 905 01:16:48.039 --> 01:16:51.399 my training calendar and then just hit the workout and then just go run. 906 01:16:53.079 --> 01:16:56.119 And so it's it's pretty awesome. So I'm gonna pick that as well. 907 01:16:56.560 --> 01:17:00.000 And then the last thing I'm gonna pick is this Zulu water bottle. You 908 01:17:00.000 --> 01:17:04.399 can see I've got stickers all over it. It's a half gallon water bottle. 909 01:17:05.840 --> 01:17:10.920 So I've been doing seventy five Hard, which is, uh, it's 910 01:17:10.960 --> 01:17:13.920 a mental toughness program. People. It's funny because I talk to some of 911 01:17:14.359 --> 01:17:15.920 the people that who want to do it and they're like, oh, so 912 01:17:15.960 --> 01:17:18.439 you're doing it to lose weight, and I'm like, well, that's kind 913 01:17:18.439 --> 01:17:23.960 of a nice side effect of working your tail off. But so so the 914 01:17:24.039 --> 01:17:28.239 program, I guess I'll pick seventy five hard as well. There's a book 915 01:17:28.319 --> 01:17:31.720 for it. It's called The Book on Mental Toughness. It's by Andy Frazella. 916 01:17:31.760 --> 01:17:38.479 He's the guy that came up with it, and he you have to 917 01:17:38.479 --> 01:17:42.560 go get the book on his website, Andy Frazella dot com. But and 918 01:17:42.640 --> 01:17:45.359 he has a podcast as well called realaf and he gets into politics and all 919 01:17:45.439 --> 01:17:47.640 kinds of stuff. So it may or may not be your cup of tea, 920 01:17:47.720 --> 01:17:50.520 or you may just pick the ones that are about business and stuff. 921 01:17:50.640 --> 01:17:56.800 But anyway, so you go work out twice a day. So I go 922 01:17:56.880 --> 01:17:59.960 do my run for one of them, and then I'll do weights or something 923 01:18:00.039 --> 01:18:03.119 for the other one. But anyway, one of them is drink a gallon 924 01:18:03.119 --> 01:18:08.279 of water. So I just drink two of these in a day. And 925 01:18:09.720 --> 01:18:13.119 yeah, I have to tell you that when I'm when I'm doing this versus 926 01:18:13.159 --> 01:18:17.479 when I'm not, it makes a major major difference. So anyway, so 927 01:18:17.680 --> 01:18:21.680 I'm gonna pick all of that stuff. I'll drop all the links in the 928 01:18:21.800 --> 01:18:28.039 in the comments so that you can get them. But anyway, those are 929 01:18:28.079 --> 01:18:30.600 my picks, Robin, what are your picks? All right, I'm gonna 930 01:18:30.800 --> 01:18:34.000 go through quickly. I have several categories that I've noticed, So one is 931 01:18:34.720 --> 01:18:39.960 workouts in training, So I'm going to pitch to my sword fighting sports. 932 01:18:40.039 --> 01:18:45.159 Obviously your pickets not aware that's actually a sport that you can do with sword 933 01:18:45.159 --> 01:18:50.479 fighting. It's called Hema Historical European martial arts. So it's not the same 934 01:18:50.520 --> 01:18:55.960 as fencing or something. No, No, it's more more focused on the 935 01:18:56.039 --> 01:19:00.119 earlier weapons. Fencing is like a more modern offshoot of what we tried to 936 01:19:00.159 --> 01:19:04.920 do, but it's still very much based on like historical manuscripts and stuff. 937 01:19:05.159 --> 01:19:11.159 It's kind of a combination of sports and living history and what you might not 938 01:19:11.279 --> 01:19:15.880 know, especially people from the US. Even though it's historical European martial arts, 939 01:19:15.880 --> 01:19:20.000 there are a lot of US based clubs and US tournaments and all that 940 01:19:20.039 --> 01:19:24.239 kind of stuff. So if you're interested, there and look it up. 941 01:19:24.239 --> 01:19:27.920 It might be a local club for you somewhere out there. Then we had 942 01:19:27.920 --> 01:19:33.319 books. I've been really enjoying the Bobby first series again. So the first 943 01:19:33.319 --> 01:19:38.680 book is called We Are Legion, We Are Bob by Dennis E. Taylor. 944 01:19:39.479 --> 01:19:45.319 Excellent sci fi series, very what they call cozy sci fi, very 945 01:19:45.319 --> 01:19:50.039 well done, very enjoyable, especially the audiobook. Is cool TV series. 946 01:19:50.279 --> 01:19:58.079 I've been very much enjoying The Boys on Amazon season four. Yeah, I've 947 01:19:58.079 --> 01:20:01.600 actually rewatched season three again and yeah, I probably need to do the same 948 01:20:02.119 --> 01:20:06.119 once I decide to watch it. For those who don't know that it's it's 949 01:20:06.119 --> 01:20:12.039 an alternative superhero series, but very gory. They do see the F word 950 01:20:12.079 --> 01:20:16.159 every second sentence, I guess, but it adds to the flavor. Chuck. 951 01:20:18.039 --> 01:20:25.840 Yeah, it's the least of the ish potential issues with that. It's 952 01:20:25.880 --> 01:20:31.399 definitely an adult only affair. But I I love everything about it, how 953 01:20:31.560 --> 01:20:38.000 how they're the acting, the script, how they're being so satirical on everything. 954 01:20:38.039 --> 01:20:41.439 It's it's great. It's great for me and I. Finally, a 955 01:20:41.520 --> 01:20:47.039 game that I've been enjoying is Hades. Hades two so yet the original Hades, 956 01:20:47.039 --> 01:20:49.439 which was Game of the Year, a couple of years ago. It's 957 01:20:49.479 --> 01:20:54.560 a very fast BASD hacken slash type of game. And now they have the 958 01:20:54.600 --> 01:21:00.800 second one in the early access where most early access game sort of usually very 959 01:21:00.800 --> 01:21:05.800 buggy and not feature complete. This one is has more content and feels more 960 01:21:05.840 --> 01:21:12.039 polished than the first one at release, and I've been enjoying that one. 961 01:21:12.119 --> 01:21:15.600 So people are still on the fence about that one. I can heartily recommended 962 01:21:16.319 --> 01:21:21.039 story endgame. What what platform is that on? Is that on a console 963 01:21:21.159 --> 01:21:26.079 or Steam or what? Various consoles? And Steam? I play with a 964 01:21:26.199 --> 01:21:30.960 PlayStation controller on the computer, which is the best of both worlds for me. 965 01:21:31.359 --> 01:21:36.239 Nice, there we go. All right, Well, thanks for coming 966 01:21:36.319 --> 01:21:41.319 Robin. This was really fascinating. Oh thank you guys for having me. 967 01:21:41.800 --> 01:21:44.399 And it was a great It was a great show. Thank you very much 968 01:21:44.439 --> 01:21:47.479 for coming on. All right, Like I said, if anyone has any 969 01:21:47.520 --> 01:21:53.520 questions, feel free to reach out. I overshare on these things. All 970 01:21:53.560 --> 01:21:56.520 good, All right, till next time, folks. Max out