Hey, folks, welcome back to another episode of JavaScript Jabber. This week, on a panel, we have Dan Shapier, Hello from a very warm and sunny Tel Aviv. We also have Steve Edwards. Hello from a cool and cloudy Portland. And I'm so jealous of Dan right now. I don't know. It's really really warm. I mean scorching, I think would be another term for it. What is it in Celsius? It went as high, well, today's actually kind of better, but it went as I is,
thirty something, thirty three, thirty four. I'd still takes a never cold any day. It's warm. Here. I'm Charles Maxwood from Top End Devs, and this week you have a special guest and that's Robin Marx. Robin, do you want to say hello? Hello? This is Robin Marx from currently kind of sunny but very to be very wet and rainy Belgium, which which kind of sums of Belgium in one sense. I guess that's in chocolate chocolate them fries. I'm partial to Belgian waffles anyway. So yeah,
So do you want to give us a little bit of background? As far as I see network and protocol performance, So that's kind of a broad topic, so you want to give us a little bit of background as to what we're talking about. Yeah, it really is a broad topic. Like I was saying to that before I started out as a game developer, and if you try to network games is that is a very very complex undertaking. Yeah, that kind of got me interested in the whole networking business for real.
And then I got the opportunity to work on research for HTTP two. So this was way back in twenty fifteen. HDP two was brand new, and the research was like, you know, it claims all these magical things if you remember this, like HP two was going to twice as fast and you know, websites, we're going to be much much better loading. And so within a month of researching that, it very quickly turned out that that was not the case, right, absolutely not. Sometimes it was even much slower.
And that really got me hooked. It was like, you know, how can this be when everybody's claiming A and it turns out to be B. And that spiraled out of control into an actual PhD in a networking performance where it's not often it's not often we have an actual like we bring somebody over to talk about a topic and that person actually has an actual PhD in that topic. Right, Well, happy to be one of the few.
Although it's it's also a downside. I have to tell you. You do get like I don't know what to say, like too focused on this one, on this one aspect, which I'll definitely have right. I'm interested in all parts of performance, but I usually overemphasize the networking part a bit too
much, and that's not always the liking of everyone. But yeah, I think it's actually a good thing because a lot of developers and web developers really take networking as a given, which is kind of I don't know, amusing or on the one hand, and a huge blind spot on the other, because networking does have like a huge impact on everything we do. I mean, at the end of the day, what we do is primarily delivering stuff
over the network. I couldn't agree more. And that's also why I was interested in coming on this podcast specifically, because usually the network is a black box, right You don't really need to know how it works. It just
works. But you have some features that allow you to manipulate what the network does, especially the literaars you of things like preloads and lazy loading of images, and ACMD for javascripts, and especially recently a fetch priority they can use and all those features like very directly tune what the network protocol is doing.
But in practice people don't really understand what's happening under the hoods, and they make terrible mistakes with these with these features, making things slower and stead faster. And that's what I'm trying to do a little bit like these people a bit more about how it works under the hoods, so that they might not
make the same mistakes over and over again. I have a question to kick us off, something that really has me curious for a long time and can also like get our discussion into some of the protocol and networking details potentially. Like I remember hearing that if your htm man is under sixty four K, then that's like this big performance win. Is this actually true? Oh, it's very interesting. Use sixty four K. The usual number is fourteen K,
right, Maybe I got confused. I remember four and it's it's excellent that you show that number because the answer resulways is it depends. So where this comes from is something called congestion control. So this is actually a protocol level limit if you set up a new connection, the server can only send back a limited amount of data because you don't know how fast the link is yet, right, So the way it works is you send back a little
bit of data, you get confirmation everything works. You can send a bit more, a bit more, more, and more until you're actually gaining the speech that you want. And it is the DCP thing, right, DSP and Quick Transport Protocol thing. Yeah, and so most servers, most default configurations of servers say that you can only send about fourteen kilobytes in that first response. That's about ten packets, about ten t top packets. That's where
that comes from. And then you double it to twenty, then to forty eight into ad into one. So that's where that comes from. The point is that's a default Linux configuration. Most people don't run default configurations, especially if you're doing a CDN or a hosting provider. They often bump that to like I said, sixty four kilobytes. I think the biggest we've seen in
practice is one hundred and twenty kilobytes on one of the CDNs. And then they also tune this based on the network, so they might go a bit higher if they know it's a cable network, and they might go a bit lower if they know it's like treat G for example. So conceptually, yes, the smaller you're initially CML is the more chance you have that it will get delivered in that first round trip and that you will get the benefit from
that. But in practice it's super difficult to define that exact sweet pot always fourteen kilobytes, not always sixty four. Uh, it really depends on you I've set up and even if you get there, it's only one round trip that you that you win, right, which in some cases can be huge, but especially if you're using a CDM, it shouldn't matter too much there. So this is usually something I say, first look at everything else you can optimize, and when that's done, then you might start looking at this
kind of stuff. Like you probably know my colleague from Malchamite, Tim Rick, who like super optimizes his personal website. He is running into this kind of stuff we're doing, like time models and stuff. Right, Yeah, he does scale modeling and it's uh, and he just every minute of his free time he spends optimizing his site super fast. Yeah right, hey,
he's uh, he's doing very good stuff. Let's so yeah, to answer your question, it's not a huge boost, and it's difficult to tune, and it's not always sixty four kilobytes, especially in these days where like the HTML is kind of created for you by some sort of a meta framework that does hydration and you have very little control over the size and how things are
done exactly exactly. Let's up. Something that Tim was doing was manually shortening the names of the CSS classes so that his first fourteen kilobytes would be shorter, and then the bigger part of the page was falling in stupid stuff like that. I wouldn't recommend anybody actually do that, but if you're a performance geek then you know that's the kind of stuff you can made the difference, what with broadly compression and stuff like that, making the names a little bit
shorter actually made that difference for him. Not that individually he did a lot of those small different tricks, but like in combination, they all add up to to reduce just enough so that he could get whatever you wanted to pass in their first round trip to decline. Cool. So you were starting to talk about like HTTP two. Now that kind of assumes that everybody knows what
HIDP two actually is I think everybody. I assume most people know what HTTP is, but people don't necessarily know what HDP one or one point one then two, then three are and what are the differences between them? Can you maybe elaborate on that? Do you have time to do a PhD then getting into OSI and stuff executive summary, It so very simply is top one, you could load one resource, one file over the connection at the time,
so you often have multiple connections up to six typically open. And then ACP two changed that that you can request and download multiple files of the same connection at the same time. That was like multiplex. Yes, that was the big innovation that HCP two brought. You didn't need like thirty connections per web page anymore. You needed one per domain, which severely simplified a lot of things. And now HP three is basically the same thing as HDP two at
that layer, At the HDP layer, they're basically the same protocols. HCDP three is very different because at a layer below that, right OSI layer, the transport protocol, we swap out TCP Transport Control Protocol for something called quick and quick. Then there's a lot of magic at the lower layers to better deal with packet loss, to better deal with slow networks, and especially add
more encryption. Maybe you can elaborate on that a little bit, because I recalled from the early days people used to say that whoever try like I actually worked at a company that like a long time ago, that implemented our own protocol over UDP instead of working in DCP because we had very special requirements. I know that video also does that for various reasons. But there's this famous saying that goes that whoever, like you know, circumvents TCP or a voids
CCP ends up reinventing DCP. So I'm kind of curious as to what was the motivation for replacing TCP and HDP two with quick in HDP three. Yeah, so I love that quote, right, you end up reinventing TCP, because in practice that's what Quick did. Quick is very similar to TCP, except a very few key areas it's not, but mostly it is. It's still reliable, it's a less connection set up, it's still ass catest control that kind of stuff. The reason why we move so quick is that you
can't practically evolve TCP anymore. So if you try to add features to TCP, which we tried for decades. The problem is a lot of firewalls, especially expect to see certain TCP things, and if they see something new, a new feature being added, the firewalls don't know about that feature. They're like, oh, I don't know if this is a good thing or if this is an attacker trying some shenanigans. I'm going to play it safe and
I'm just going to drop that traffic. So if you want to change anything about TCP, you're in for like a decade of waiting because all the different firewalls and everything else needs to get update. And you actually see this with IP as well, right, IBV four versus IBD six. IPv six is more than twenty years old, and still we have very low adoption because of exactly that reason. And so this sad with QUICK was you know we are
going to encrypt every day on TCP. You basically only encrypt the HTT parts your credit cards and your passwords. Obviously, now with quick you also encrypt everything else. You also encrypt the packet numbers and the acknowledgments and the window and that kind of stuff. All of that is encrypted in QUICK. The idea being that if firewalls and other stuff can't read what's in the packets, they can't work or they can't break when we when we decide to update quick
in the in the future, this is really amazing. So we have firewalls in place to do a certain thing, and now we are implementing the protocol in such a way as in order to prevent them from doing that thing, because it turns out that doing that thing creates issues for us. This is really kind of amusing. It's a game of one appmanship, kind of kind of exactly like that. Yes, and I have to move on stard because
some people still don't understand this. You can still perfectly firewall quick. Quick is very fire wallable, but you need to do a lot more work. You need to actually read the RFCs. There's a new version of quick your you have to implement that new version of quick before you can actually start firewalling, which is not the case with TCP. Right. So it's kind of you have this wild ecosystem where everybody can do whatever they want, and that
has turned out not to be very healthy in practice for evolvability. And they try to enforce this now from the browser and service side. So you said that one big difference is the fact that Quick is encrypted from the get go. You mentioned the fact that it prevents firewalls from creating issues. I think it also reduces the amount of handshake that you need to do because with TCP, or first did the tcpnhake and then you did the TLS handshake, and
now you can all do it all in just a single handshake. I seem to recall, and maybe I'm recalling incorrectly that part of the motivation. And it's also that you know, TCP is kind of old. It's like watch fifty years old? How old is TCP? And yeah, and nobody was thinking, for example, cellular networks back when TCP started. So a lot of how modern networks behave is very different from what the situation was when TCP was created. Is that also a motivation for Quick? Or am I misunderstanding
It's definitely part of it, right. You want TSP to be evolvable, you need to add additional stuff, but you can't because it takes a decade, right, So that's why you want QUICK to be able to I'd like to say that Quick is like we took everything, we learned about TCP in the past thirty years. We took all the best practices that we knew and that we want to and that we put into one big package. And that's now. Let's not quick with regards to not being prepared for newer technologies.
I'm not quite in that camp. I think TCP has held up incredibly well. You can even run CCP on top of starlink through the satellites and just it just works right. But there are inefficiencies. They're definitely inefficiencies. It can be better, and that's what Quick tries to bring to the table, to add additional features, to make it faster, to make it more robust. But it's not like we have to drop TCP in the next five years or anything. I think. I think that will still be around for quite
a while, even with five G and everything. Now. I hope you can understand how you can answer this honestly, given that you work for an how come I think with a CDN provider, Yes, and often our control over whether or not we use HDP two or HDP three kind of depends on
which CDN we choose. Some CDNs, I think, or maybe today all of them support well the question that I'm trying to ask, really, is suppose I'm setting up, you know, my web presence, how important is it for me to make sure that it's served by HDB three versus HDP two. The final part of the question is quite easy. I think you can still just get by with HDP two perfect right, We've been doing that for ten years almost again. It's between and quick. Give you extra benefits can
make it a little bit extra fast, especially in challenging conditions. It's not like HP two is suddenly not good enough or not good anymore. And that leads into the part of the first question, in the CDN part is right now, it's very challenging to, let's say, do self hosted HDP two at least if you want all the fancy new features, right, the actual features that make it very much faster or that will really see you change the
metrics, those are super difficult to deploy yourself. Things like zero RGT and actual multipads and connection migration. That's something that requires a lot of technical debt and security to get right. So most people counted about themselves you need a CDN right now because they invest it upfront in the whole deployment of it.
Which is also a downside because it's coming very centralized. Right. If you want to be on this cutting edge, if you want to use this latest and greatest features, even though it's like an open protocol, open standard, you kind of have to use one of the big companies at least for now,
and I think that's going to last for a couple more years. So you can't use something like Engine X or you know, I'm trying to think of what Yeah, so and X is a good example because it's the one of the only I guess, very popular off the shelf servers that has an AH feature implementation does not have it and as far as I know, doesn't have plans. No, yes, does not have it right right, And even Engine X is only in the beta state right now, It's it's not
being sold as this production ready. And even if you would run Engine X, like I said, real advanced features that will give you the big performance boosts are not going to come out of the box. You're going to need some custom setup or specific configuration to get those. Are there are there any off the shelf ones that are working on it beside it Engine X, you know, Caddy is a big examples. Another show. I think, Yeah, we've had Brian, that is, Matt Holt, Matt Hole, Matt
Hole, that's it. Yeah. So so Caddy was quite early on. They used a very good go quick go library there, but even there they say it's production ready. Actually, there are several key features that Caddy does not support, and I tried to bug them about like every six months. Uh so it's like I should say, there's there is almost no way right now to get all the performance benefits of the robustness benefits that you get from the CDN or a big hosting provider by running it yourself. Okay, not
not surprising to be to be on. And I'll be blunt unless you know, unless you have some very very good reason, which I don't know what it is, you don't want to be self hosted. It's just not it's just not worth the hassle. It's the economies of scale you want to take advantage of. Some that's my take on it. I'm sorry, but that's just how I look at it. Maybe my history E Twicks speaking, I don't know, but that's just my view on things. Yeah, and see
I come at it from completely the opposite side of things. I mean, I self host everything I do. I encourage most of my clients. I mean, once I'm into the handoff where you know I'm not going to be maintaining things anymore, then yeah, I might push them to something that's managed just because they don't need to hire somebody to manage it for them. Right. That doesn't make as much sense as going with a vercell or Heroku or something. But as far as like my stuff, I mean, I self
host it all. And the reason is is because it costs me less. I get exactly what I want, right, But yeah, it costs less if your time has no value. Let's put it this way. That I I also disagree with that because once I had my deploy set up, the deployees are fast and easy. It doesn't take not the deploy. It's look, I'm less familiar with the the world of Ruby on REOs, but it's
the maintenance. It's it's making sure that you're always all patched up, that you're you know, if something goes down, that your own call to to to fix it. It's it's it's a it's just it's a it's a chore. Let's put it this way very bluntly. Uh and uh and in a lot of In many cases it's easier to pay somebody to do it for you and again benefit from the economies of scale. And here we hear that you've
got one more advantage in that it can be a bit faster. Although although to be honest and putting quick aside, using a c d N is kind of a prerequisite for performance if you've got an international audience for your website. I agree with that last part wholeheartedly. Then I think if you're really focused on performance, there's you should be using a CDM. There's really no argumenticats that. For the earlier parts, I'm kind of in the middle. You know, I work for a CDM, so I do think it's a good
thing to get someone else to do that for you. But I do feel very strongly that you should have the option to just do it yourself if you want to, right, because it does make sense for people. I won't argue with that. You know there are if for no other reason, then freedom of information, and you know you have the right to do whatever it is that you want to get within certain legal and moral boundaries. But but other than that, yes, you know you don't want to necessarily be dependent
on the terms and conditions of somebody else. But going back to the topic at hand, you gave what I considered to be a really interesting talk UH and the fact that it had swords in it helped UH in in the in the in the latest UH Performance Now conference. Yeah, that one let me boost the fewer numbers of this one. Then, So is that like andwell, no, no, these actual sporting sorts that we use is from a movie or anything. These are just made safe for actual sporting, for actual
hitting each other. Is that how you handle conflict resolution? Absolutely kind of a permanent solution. And the talk Dan mentions, I call my coworker on stage two to teach him a lesson. It was Tim. I think, wasn't it afore mentioned? Tim? Yeah, that puts you on the cutting
edge of conflict resolution, there, doesn't it. Yeah. So, getting back to the to your talk, what you were talking about, as I recall, was about we mentioned that h gdp TO introduced multiplexing, and and people assume that it was a great thing and that it will utilize the network much more efficiently and get stuff down faster, And it turned out that that's not necessarily the case. And yeah, So maybe you can talk about that.
Yeah, So I actually thought long and hard because usually when I explained this, I have a PowerPoint, right, actual visuals. How do I explain this with just audio? So I come up with a metaphor for a warehouse like a store. Right, Let's imagine ten people going to the store and you all want to check out that there's only one register, only one person do to check out. What happens in real life is you whoever arrives at the register or first gets done fully, they pay, and then the
next one and then the next one. Imagine if that was not the case. Imagine if the person doing the checkout would say like, Okay, I'm going to take one item of the first one the first card, I'm going to scan that. That is going to skip you for a moment. The second one tick, one item from your card, scan that, go to the third one, one item all the way to the tenth, and then I'm going to come back to the front, and then one item for each
Again. That sounds amazingly efficient, right, Well, if you think about it, that's kind of like how CPU's work when you do when when yeah, in in modern operating systems, you know Obviously, if you have got multi coores, then that's great, but usually you have more processes or threads going on than the numbers of number of cores that you have exactly in some time time slicing or resource sharing or whatever you decide to call it round robin
scheduling. So in some cases it's very obvious, like let's say that round robin scheduling not ground robin Marx, I wish there you go and earned that one. Oh, it's this kind of stream, so it's easy to see when it becomes positive. Let's say the first person has two hundred items, but the third person online only has three items. Right in the first scheme, the third person would have to wait a long time for the first guy
to be done. In the second one, the third person actually done much earlier, and you're not dealing the first one by that much because it's just like, let's see three items. More So, those are like the two extremes, right, you either do everything sequentially back to back, or you do something called round robin and ask you you share bandswidth in this in this case and in practice, you want to you want to change what happens based
on the type of resource like the multiples in the band. Sharing is good for images, for example, because most images can be rendered incrementally, so even if you just get a little bit of the image in, you might already render like a blurry or a low quality version of that, and then it gets better the more quality you get, the more data you get in.
But very crucially for things like javedscript and CSS, those have to be downloaded in full, every last bite before they can actually be applied to the page. So if you start doing the multiples in the robbining for childskin CSS, you're delaying that very, very heavily, and they can explo By the way, another resource that might benefit from slicing or whatever round robin whatever we decide to call it is HTML because htmil can actually be parsed like in parts.
Uh. Whereas again, like you said, with JavaScript, JavaScript is actually a funny story these days because it actually can get parsed into bytecode I think while it's being streamed. But the execution can't start until everything is downloaded, because you know, you need that clothing curly bracket at the end. You can't until you have that, you can't really execute the code. And and I wonder why that's the case with CSS. It seems that CSS could
be somewhere in the middle. I thinking, because you have the cascade. Oh yeah, because you need to cascade everything, you can't partially cascade. But it's true that bothelscript and CSS can be parsed and compiled in the streaming fashion, right, so you can process some of this and you do some
work while it's coming in. That's not the point. It's the point that you need everything to actually execute, right, to actually load the childscript to execute the function that it's trying to do, for example, right, And that's what's and so to make the story around, so those are the like the two options multiplexing. But it turns out, right, sometimes you really
want one and sometimes the other and sometimes something in between. And it turns out that a lot of servers and HP two it was mostly the servers got it very, very wrong. They just ignored what the browser was telling them. They're just like, oh, browser, you want the child's going to see us to be sequential. I don't really care. I'm just going to send them multiplexed as well. And so why conceptually a SP two could be
as faster, even faster than as to be one different connections. In practice, it was not, because this whole multiplexing thing was usually just going all the wrong directions because of implementation books. Wait a minute with AQTP one point one, as you said, actually, what we had is, let's say we have let's simplify the scenario. Let's say it's just the one domain we
are. The browser actually opened usually six TCP connections, and just that they downloaded six resources in parallel, so there was no multiplexing, but there was still bandwidth restrictions. So effectively, you you just you you kind of got the same kind of slicing, only at the lower level. Kind of.
Yes, the problem that you get in there is that you're sharing the bandwidths, like you say, but the connections don't know that there are multiple connections active at the same time, so they're all at the same time doing this congestion control thing that I was talking about earlier, trying to find the bandwidth. So the beginning, everything goes, well, right, we're not filling the pipe yet, so everything doubles, doubles, doubles, so six connections
are all doubling it more or less, say in time. So they very quickly riched that bandwidth limits, and then you get like a massive amount of packet loss because they all over extend whatever they might safely use at more or less the same time. So you suddenly have a big drop of bands with usage because now you need to stop because you have too much loss. You need to retransmit all those lost packets, and so on and so forth.
While with a SPEAK two and three you have one connection, and that one connection can much much better decide how to ramp up that bandwidth because it knows that it's the only one that matters for this particular cite, for this particular So I wish it. I wish it was the one connection. I mean in this in this day and age of third party scripts and pixels and the fact that if you have like cores and not go a course, then you
actually tend that ends up being even two connections per domain. You very quick even with a GDP two can get to a pretty high number of active connections. Yes, but the crucial difference there is that most of those extra connections don't download a ton of data like turn parties usually only only load like one file or something. It's still going to be one or sometimes two connections that download the bulk of the actual data, right, and before it used to
be six or maybe even twelve connections the boatloading. So you now you said that the servers kind of ignore what the browser is telling them to do. So my question is, you know, regardless of that fact for a minute, how does the browser actually try to tell the servers what to do? And can we as web developers impact what the browser is saying. Excellent question, and that's where the aforementioned talk was about. Right, It's like a
whole hour just on that question. So again the short summary, So browsers basically look at the HTML and then try to decide, Okay, this is probably an important resource, this is probably less important. So for example, the JavaScript in the head maybe even a term. The better term would be more urgent and less urgent not so much importance perfectly. Finally, because braxe
is actually called urgency very good, So let's use urgent. So the browser says, like, okay, JavaScript in the hent is going to be more urgent than a child skipt in the bottom of the page, for example. Right, that's a power that you use. The developer have to give the browser a couple of hints, and so the browser then says, Okay, I'm going to assign an urgency or a priority to each resource based on those hints. You could also have like a sink and defer also manipulate tavescript urgency
or importance, let's say. And the browser then tells the server, Okay, I'm requesting these resources now, and this is like the urgency or the the priority in which you should be delivering them. And the browser and also says you should either send them sequentially so one by one, or they can be multiplexed, they can share bandwidth. How the browser says that. The browser says this, yes, but I don't think you as a or we as as web developers can actually control that. I don't recall an API for
that. Yeah, So that's that's the big problem in my opinion. You can control some of that, but very indirectly. So for example, I think you guys just answered the question that came in on Twitter, by the way, asking about bus limits. That's on the browser side, right, It's not on the internet side of the server side. No, no, no, it's bandwood limits are almost always the last mile. So usually let's say the Wi Fi link or from the ISP to the to the to the
computer. Okay, so it's not the browser then it's my it's my ISP. It's usually the Wi Fi link. But whether or not you say the Wi Fi is property of the ISP or not, that's okay. So maybe my connection whatever connects me to my cable modem or fiber whatever do hicky that
I have in my house usually problem same with tree T fourteen. Okay, that's usually limited because you're also sharing that multiple people usually write multiple people on the Wi Fi and the four G mast Okay, So getting back to what I was talking about. You can't control that directly, but some features implement that an indirect way. So let's say something like preload right, Preloading a
JavaScript file implicitly changes its priority. Preloading a font changes its priority. Preloading an image does not by default sas this priority, which is you know, again somewhat unexpected for some then, So that's a good example. One way to explicitly control this, though, is that new thing that I talked about before, it's just fetch priority. Yeah, they alsouner said. Where the name is coming from priority, So that indicates how how important is it this
resources too? Yeah? To our listeners are not aware of familiar with it. It's an attribute that you can put on stuff like images or scripts or literally anything that downloads or resource. Also, it exists in the browsers fetch dom API. You can literally specify low, high, or auto, which auto basically says the browser decides what to do, so you can kind of override the browsers automatic priority assignment and the and and like you said, there
are some obvious values like htm man itself is obviously high or highest. Likewise csays up front is high or highest. Uh, well if it's in the head as well. And this is where it gets complex, because there's it turns out there's a big difference between what you as a developer might expect things to be and what browsers actually do. Chrome does things very differently from Safari and very different again from Firefox. They do not agree on what priority should
be for individual things. So that's exactly in spe No, there is no spec for that at all. Spec only says this is the mechanism to send these values to the server. Ah, what you put, what actual values you use, It's not spect by anyone. I tried, I tried, I tried for a long time to get a suspect this nobody actually wanted that you get the wild Wild West. The best example of this is fonts. Okay, and Chrome fonts are highest priority, equal to CSS and HCML highest
priority. In Firefox, fonts are low priority. Yeah, because and I can understand where it comes from, because on the one hand, you want fonds to download as quickly as possible because they really impact well, let's put it differently. It kind of depends on what browsers do with the text before the fonts arrive, which it can be controlled by CSS attribute, but I
think has different defaults for the different browsers. So if the text is because the browser, unless it's told in some other way, won't actually start downloading the font until it has both the HTML and the CSS because it can't know which fonts it actually needs until it has both. But by that point in time, theoretically it could already show the text, it just doesn't have the font yet. So there are very different strategies of what to do about it.
One option is show the text in whatever built in font you have and then switch over to the desired font once to have it. Another one is no, don't show anything, because it will be the wrong font and will be displayed all bad and things will move around once the actual font arrives,
So don't show the text it all until the phont arrives. And then there are kind of like the in between solutions that show it for a short time with that font and then switch over or don't show anything unless it takes longer than some period of time and then switch over to the fallback. And the different strategies that you choose obviously also impact the priority you assigned to the font, because you want to be able to show the text as quickly as possible.
So whether or not you're showing something in the fallback depends the impacts the priority you assigned to the actual font resource. Yes, but the point is, and it's more than that. Here the browser chooses for every single font. It's not like if you determine the fallback font in CSS that the browser is going to change the prioritization of the fonts. That would make more sense
with your explanation, I would agree that's not what happens at all. If Firefox, all fonts are just low priority, whether or not you have to find it as a fallback or not, or treat that as not. And there are several other examples, especially for JavaScript, because this is childscript t sv right. For example, if you tag a childscript is async or defer in Chrome, it will give it a low priority well default cholviskit is a
high priority, and Firefox doesn't care about that at all. If Firefox if acync a defer that's exactly the same priority as a normal travescript somewhere in the body, it doesn't make any difference there at all. So for Firefox, for example, it matters much more than which order you have your jawscripts defined than in Chrome for example. Right. So it's all these tiny little differences
between browsers that make it very difficult to get consistent performance benefits. I've seen this very often, that the way a site is built where it's very well in one of the browsers, but then completely goes into the mark on other browsers and like seconds difference, seconds difference just because of what the browsers are
doing different on the same page. And the problem is that people will of course mostly test on Chrome or you can get and we can only get Corbet vitals and stuff from Chrome, and so if the slower browsers happened to be safari in Firefox, people usually missed that, and and you know it's difficult to get them to pay attention to that. So I guess how do you go about solving this? I mean, you could test it on the other
browsers, but so at this point you really can't. So fetch priority is helps them a little bit, right because at least you can you can be very clear to the browser. Like a good example is your largest common foot paint image, right, so the most important image on your page. All the browsers are giving this a lower lowest priority by default. You can say fetch priority high. You can use it is no longer cure it. That's
no longer accurate for Chrome. Chrome if it identifies that it thinks an image might be the largest content for paint image, it would actually automatically assigned for it the higher priority. As I recall, it's it's a bit more general than that. If it figures out the image isn't the view port, then high, but the initial priority that requests pasifly low. They will just send
any figured out. But I totally agree with you that if you know, as the content creator that a particular resource is going to be or likely B or l c P, then you should give it a high fetch priority and hope that that the server even cares you need a compliance server. But assuming that right, indeed, but that that becomes a problem, right because now you've given developers something called fetch priority high, and they really should only be
using that on like one or two images. What most developers do in practice is they just put it on all the images, right, because it makes sense fast. Like I tell my kids, if everything is urgent, then nothing is urgent, right, exactly exactly. I've literally seen this last week. This was a site and it was preloading fifteen different images, all would fetch priority high in the pre load, and none of the fifteen images was
the largest colon foot paint image. And the way the browser works because if you if you preload an image with fetch priority high, it becomes the same priority as JavaScript in the head. So they had a bunch of preloads on
the top of the head and beloaded. They had their key JavaScript that they really needed to start rendering, so the JavaScript was delayed by their fifteen pre loaded images that were useless because none of them was even the large con painted and it's like, this is one of those problems that I'm trying to explain.
It's like you give developers these high level features like preload, like fetch priority, like a sync and DFER, they don't really understand what they're doing under the hood, and they start misusing them, abusing them, and things can very easily go wrong because these protocol levels, things are so finicky to you to really get right in practice. I'm always reminded of it was a year or two years ago, like when native lazy loading came out on images.
Oh if you remember that that word press, Yeah, with the WordPress that they made everything lazyloaded. Yeah, they made everything lazy loading because laser loading is good for performance, but they also lazy loaded the large skindle of paying images. Yeah, it's worth a very quick explanation. What happens is with lazy loading images, the browser doesn't start loading an image until it actually needs it. And by needs it, I mean that it's in the initial
viewpoint. That means though, that in order to know whether or not to lazyload an image, the browser needs to know exactly where that image is located on the page and what its size is et cetera. And that means that it can't immediately know that upfront, so it kind of needs to do some
layout before it can know. So it actually delays the loading of images that are marked as daisy load loaded until it knows where, you know, how the page is layed out, which introduces a delay that you don't want for your primary image. So yeah, so by making marking, everything is daisy loaded, because you might think, hey, I don't know it's I'll mark it as days ago that it's in the initial viewport, so probably no impact. No, it has a negative impact. You don't want to put it
on your hero image. Yeah, exactly. And the point I want to make there it's the WordPress developers didn't do this because they're stupid or anything, right, It's just that it's so difficult to know exactly how these features are going to work. In practice, they're not often very well explained. That's one to the tooling, Especially when features are new, tooling is often lagged behind. There's no big red button that's going like, oh, I notice
you're lazy loaning your LCP image. You really shouldn't do that. That's not included, and so people are not really given the chance to really do this correctly without knowing everything below the stack, which of course you don't want to.
You don't want to know how fetch priority works on the dood. You shouldn't have to, but in practice you do, or you can make easy mistakes, sadly, So what you know, if somebody wants to do networking properly correctly, you know what would be the main things to look for. I'll let you say it, and then I have some of my own and we will see what overlap we get between us. That's a very broad topic. Just start a quickly laundry list or or or checklist that people can take
away from our conversation here, I guess again. On the server side, it's very easy. Don't do it yourself. Use a CDN, use a hosting provider. I'm not going to say they do everything correctly. In fact, several of the larger CDNs and hosting providers have big issues when it comes to two HTP three implementations specifically, but they're likely to be closer to the optimal than what you can get yourself. That's that side. And then on
the front end, use these special features in a very limited fashion. If you're using pre load. If you're using fatch priority and stuff, only use them in a very limited way and ideally start without them. See what that does, and then sprinkle them in where you think you might need them, and test the hell out of it. Do good performance a B testing to see what actually what actually happens. And a great tool to do that they be testing with is web page test. I mean you can, you can
get very you don't agreeting. If you'd ask me this a year ago, I would have said, yes, pitch tests is the best. Since then, I think you probably know it feels like that sort of web pitch sess is a very good tool. But they got acquired by the company Catchpoint a couple of years ago, and it feels like, I'm not sure if it's true, but it feels like they've kind of abandoned the project a bit, or they're not at least not investing enough into it to keep it super relevant.
In my opinion, there are some long setting, especially network level bugs. It's very difficult to debook network level stuff with web pitch tests nowadays in my opinion, that you just don't fix. And so for me personally, I've switched mostly to a different tool called the debug bear. Oh debug Bear,
who also have a free speed test. It's in some areas it's less advanced than my page test, for sure, but in others, especially when it comes to networking features and things like oh, you're doing something wrong with you l CP, or you're preloading too much, that kind of stuff is very very well integrated into deeper Bears. Well, if you want to look at it from the level of somebody telling you whether or not you're following best
practices, then Lighthouse is probably the easiest thing to use. It's it's it won't give you a network breakdown, you won't actually necessarily understand what's going on, but it will give you like, hey, you're doing this stupid thing. Please please don't do it like at that level, So just thick in there. I love Lighthouse for its audits. I think the audits are amazing, Yeah, exactly. But for network level stuff, it's not a good Yeah, yeah, I know, I know. It's it's it's not it's
it's it's simulation. It's is of of network limit limits is let's put this way. I've got some results out of it which obviously made no sense. I think it's a great tool, but like every tool, you need to be able to how interpret and to use it correctly. And too many people just run Lighthouse, take whatever performance score it gives you, and then pretend like that's what you should be looking at, which is in my opinion, not true. But the audits are amazing. I use the audits almost daily.
Far from my perspective. Is good for one thing. It's not as an absolute number, but it's an interesting indicator for regressions. So if you're kind of doing a performance budget, you can use that numbers as a performance budget to see whether or not because there's a good chance that if it's sufficiently significantly degraded, then you potentially introduce a real issue. But I definitely wouldn't be looking at it as an absolute number. Again, to an extent,
if it's about front end features, I agree. If it's about seeing regressions in your network setup or on your CDM behavior, I think it's less useful because there is so much simulation and emulation going on at that layer that you might miss things, or small regressions might show up as much larger impacting.
Oh yeah, for sure. In that way to what you stated, I would add some of the obvious things that I don't know if you might even consider them networking or not, but make sure that you have compression enabled. I mean, so often I see people accidentally disabling compression and obviously caching. Yep. The fastest thing is the thing you don't even have to send ye that is of course agree. And again those are things that CDNs help you
get ninety five percent of the way as well. Right, So the main reasons to use the CDN is because you get this cashing and usually automatic impression out of the box there as well. I would also go as far as to say, and I've always said, this is network optimizing the network is not the first thing you should be thinking about, right. The differences between AHP two and three and all these features only come into play when you've optimized
most of the other stuff. First, I'll start with the inverse. If you're like so many sites are still using client side rendering. If you're using client side rendering, then regardless of anything else that you might be doing, you won't get a good initial loading results. Now you might not necessarily care, I mean, if you're building a page which is not intended to be indexed, if it's behind some sort of authentication, if it's a dashboard or
like for an internal app. I mean, obviously nobody wants any something to load, especially slow, but the loading performance might not be the most important consideration. And in those scenarios then then a client side rendering might be good enough. If, on the other hand, you're building an e commerce site, a marketing site, anything that needs to be indexed, it just you know, and and and it's client side rendered, then there's no point really
about in talking about anything else until you fix that. I largely agree with that. Yes, the new ones I always try to say is like it's always about priorities and developer cycles that you have to spend right. Oh yeah, I disagree that it's just because it's an internal tool or a bt B
tool that you shouldn't care about performance. I've had many times where I've tried to go onto the company portal on the four or to your treaty connection train, and it was really critical I looked up something within five minutes, and it just couldn't because it's it's crap. So I think people usually dismiss performance
a bit too early in those kinds of situations. But I do agree, of course, that it's always a matter of priority that in some cases you might want to add more features first, even though they might think might think they might make things a bit slower, or alternatively, people care more about responsiveness in some cases rather than the initial loading speed, Like if you've got if again, if it's an internal if it's an internal app, then that
you have opened in the context of your work all day long, some sort of I don't know, CRM or something like that, then you might care more about how quickly it responds to your actions what once you're loaded, rather
than actual loading. But you're absolutely correct that if you have a large number of your workers, you know, commuting to the office on the train every day, and they actually start working on the train and they can't even get the app to load because it takes such a long time, and obviously it's
it's something that you should be looking at, yes, for sure. So we have a question on Twitter that's asking if there are other good online resources like books or blogs or whatever that people can go and learn more about this
stuff. So the best resources are if you google Robin Marx networking, then no, I hear that, guys, real smart I do like I'm one of the few people who really focuses on this stuff for the web development community, and I do think I put out a lot of approachable content on specifically this topic. The other main resource that I would say always is the the book High Performance Browser Networking bright Ilia Gregoric, which is available for free online
and now take notes. It's h p b N dot c O, so h High Performance Browser Networking h p b N dot c O, which is a free online book which is slightly outdated by now, even though it's been updated with some things. For example, I don't think it covers HDP three yet, but it's still a very good resource to get with the basics. They explains how how the networks work underlyingly what things like and just control and
that kind of stuff are. It's still an excellent resource. And then you have the h T t B two book by Barry Pollard who is now at Google. Google. Now we've had them on our show like once, both of them, so for people watching the stream, that's this one right.
Again, I wouldn't say outdated, it's just not very recent, but it explains a speed to in an amazing way and again gives you a lot of insight into why things work the way they do and how that works, and a lot of what's in age between quick and what we're seeing now started with this kind of stuff. So it's good to get like the basics done for this, and then I would basically say, to finalize, don't just look
up Robin Marx on Google. Also look up Very Pollard on Google. Barry got his job at Google now because he put out such consistently excellent content on performance and networking performance. He has a ton of excellent blog posts from before and now he's blotting a lot on the web dev among others, and so pretty much anything that Arry right is good for this kind of topic. I guess both of you have written quite a bit for Smashing Magazine, as I
recall, and you've got a series of both there. Barry has done a lot of work there. I think he actually even worked with him on improving the performer loading performance of Smashing magazine itself exactly Sea, I think, Barry, and then performance in general, like networking performances in general, de go to guys, of course, Harry Roberts, who was also here a couple of weeks ago. I think yes, we had him as a guest on that show as well. He's great. And if you mentioned Harry, and
again we talked about your talk. We're going in YouTube and just look for the Performance Now conference and all the talks are are published in YouTube for free and there's a lot of great content there. So we were talking about resource Hans, Harry talked about these, we were talking about cashing. Harry also talked about that, and of course your own talk that I mentioned with the swords about how how web servers and browsers handle priority and how they mess it
up so often. Yep, and any other talk from Performance Now. It was a great, great edition last year. Here awesome. Well, I'm going to push this in the picks before we do that, Robin, where do people find you? You mentioned Twitter, I think before we got started. Yeah, so I'm at Twitter. My handless programming art. Like I said at the start, this is from when I still thought I could be an artist. I give that up, so it's not now. It's just
a programming part that I can't change. The anbum so the handless programming art. You can also find my st on link in the profile there. Because I don't even know that by heart. And then I'm actually a lot of LinkedIn nowadays as well, because that's where most of the Akami related people are as well. You can always feel free to reach out to send me an email or a DM or anything. I'm always happy to talk about this kind of stuff. Awesome. All right, Well let's do our picks, Dan,
Do you want to start us off with picks? Yeah? Sure, So two things really. The first is kind of work related, so it's really funny. I've started working at size Sense as principal engineer, and I'm learning the code base or code bases actually, and I was going through what was being sent over the wire kind of related to what we talked about today, and I thought it would be interesting to understand how the thing worked by diving into the networking layer. Long, shorty, long story short. Saw
some things start fixing it, created a PR to fix it. When you touch networking, it spreads, and pretty soon I've got a PR that touches close to thirty files and uh and and yeah and yeah and whoops. It basically both in terms of the code execution and also of the type system. In the typescript, the scenario of empty server responses was not handled properly and
uh, and yeah, it touches a lot of things. So yeah, anyway, so that's so pick number one is I don't know, like, be careful of how big a bite you choose to take when you're starting with a new code base. I don't no. On the other hand, it's an interesting way to go. You make yourself, make make everybody aware that you're there, very very quickly. Let's put it this way. So that's that's my kind of pick number one. And the other pick is an actual
pick. Is h a show on Netflix that we recently watched and enjoyed very much. It's called Eric. It's with Benedict Cumberbatch. He's an amazing actor. The show is really kind of out there. It's a mini series sort of a thing I don't remember. They have like eight episodes something like that, and that's it. It takes place in New York in the eighties and has pretty much everything that you would expect in this kind of a dark drama
about New York in the eighties. So it has a missing kid, it has uh, police brutality and corruption, it has h gay rights, it has substance abuse, it has homelessness, like everything bad that you can associate with New York in the eighties is kind of there. But it's actually we
enjoyed it very much, and like I said, everybody acts. The acting there is top notch across the board in my opinion, and Benedict Comerbatch especially, he plays this person who has severe addiction issues that are that are maybe compounded by our result of being extremely bipolar. Yeah, it's it's it's it's a very interesting thing. So that would be my other pick for today. And those are my picks. Awesome, Steve, what are your picks?
Well, I'll go with before we get to that high point of our episode. I do have one semi legit pick. There's an article I saw on Hacker News, and this is a little area that I have done a lot of reading in in terms of cosmology. It's entitled is the Universe Finite or Infinite? And it talks a lot about the hot Big Bang and some of the implications of the data that we see in terms of cosmic background radiation and so on, and whether there needed to be something before the hot Big Bang
with certain requirements. It's totally scientifically geeky if you get into that stuff, but it's on a website called big Think. So anyway, I'll put the link in the show notes. And now for the I got to get all set because I had to move my screen around the high point of all of our episodes is my dad jokes of the week. So here's some basic logic for you. And we're into logic puzzles. So cheese has holes, right, more cheese equals more holes, more holes equals less cheese. So therefore
more cheese equals less cheese. Yep, I got to think about that. Logic is a little twisted there, So here's one for all you Monty Python fans. I was in Madrid, Spain, and I got sick, and I was in a hotel and my hotel told me they have a doctor on call and I was like, really you do. He says, yeah, no, one expects the Spanish in physician. And then Robin is holding his said because he can't believe how good that was. And then finally, my
parents raised me as an only child. That really ticked my brother off. Uh, now you reminded me that before the show, I said that if you were going to tell us some dad jokes, which obviously you were going to tell us some dad jokes. I'm going to mention this old video that from like I don't know eight years back, that ran on Nickelodeon about people about kids who are the victims of dad jokes and how they cope with it.
It's it's a really funny video. That's great. I think I might have mentioned it before as a pick myself, but yeah, it's for those of you who watch it. That's in real life. That's what my kids go through on a regular basis. All right, I'm gonna throw out some picks. So my first pick is a card game is called sky Joe. I always do a border card game first, so I'm gonna pick sky Joe. Now, sky Joe is if you've played golf with like base cards,
it's kind of like that you have a four by three grid. If you get if you get three of a kind in the same column, then you can remove the column, and then you're trying to get the lowest score, and you just play until the last person or the first person flips over their last card face up, and then the game. Everybody else gets one more shot to fix up their pile. If you are not the low if you flip over your card right. If you trigger the end and you're not the
lowest score, then I can't there's a penalty. I can't remember the penalty is. But then everybody Talisa scores up and I mean that that's the game right there. It's board game. Geek right waits it at one point oh six, so it you know, we play with kids. My eight year old loves it when she skunk somebody right or gives them the wrong card. She thinks it's hilarious. So I'm gonna pick that. Another one that I'm
gonna pick. And this is a TV show. My wife and I have enjoyed Criminal Minds for a long long time, and they have Criminal Minds Evolutions, which is just on the streaming service for whatever network they're on, I can't remember, but they just put out a new season. I think they've put out like three or four episodes on it now, and it's oh, they came up with a new season because it's onpo like they had like two seasons, one or two seasons and then like they had to stop because of
COVID or something. So yeah, I just couldn't fill more episodes and eventually just had to let all the actors go or something like that. Yeah, so there, the the whole squad is back. So in the first season they're chasing the guy that like provides the serial killer kits to the serial killers, right, they catch him. So in the second season right there, there's a there's a twist on that that they're trying to chase down. And
I don't want to spoil anything. You get it all in the first episode anyway, But still, if you like Criminal Minds, it's pretty awesome. I will say that my wife is much more sensitive to this than I am because it's not live on TV. There's a little more cursing in it than there was in the original show. So if that bothers you, it's not. It's not egregious like some shows. It really gets on my nervous because it's like every other word is an F bob and it's like you could just
speak English right and just drop a couple. But anyway, this one's not bad in that regard, but there is more of it. If you liked the original TV series, Hey Chuck, have you ever you know? I don't know if you remember another show called Profiler that was on before Criminal Minds had a blonde gal. I can't remember her name. But have you ever read anything about where all that started and where all that comes from and who
started the whole FBI profiling It's really interesting. I'd read a book by the guy's name is John Douglas, uh huh, and he was the FBI agent that created the whole behavioral Sciences unit at the FBI. He has a book called mind Hunter, and he's got a bunch of other books since then, but he talks about how he got into that, and Yeah, I was confused because there was a show called Mindhunter about that why on Netflix. Yeah, I don't show. I don't know. It was kind of kind of
based or inspired. I didn't watch. Yeah, I think. I don't think it was like a documentary or anything. But if you read his books, it's just fascinating because basically what he did. Uh, there's a specific murder that started and I can't remember who it is. Larry gan Bell was one of the first guys they profiled, but he basically went in and spent hours and hours interviewing serial killers and just figuring out how they thought, what
was their thought process, why do they do certain things? And that's how they slowly built this ability to to create these profiles of people. And he talks about some cases where they built a profile about somebody and just absolutely nailed it. But it's just it's hours and hours of research and like and so so far, really dark roads to go down. But but you know, if you ever get into criminal minds like that show and it's not quite as glamorous as they make it out to be, shocker, Oh yeah, of
course. But but to read about it and there's all this eternal drama and strife, then yeah, and you mean it. They don't solve the case every thirty minutes, like no, no, no, it's yeah, it takes forty minutes. Yeah, it takes a long time. But if you look up John Douglas and all of his books, uh, he's the guy
that started at all. I'm waiting for HBO Max to launch in my country, which is in like two weeks, because then will I will finally be able to rewatch True Detective if you ever watched it, Oh yeah, I've startpecially one is I still have yet to finish the very first season. I've watched like four or five episodes, but I don't have it and I haven't been able to sit down and watch it. I still got to watch the end of that first one. Oh there's a pick from Robin. Oh yeah,
true, detective. All right, I'm gonna throw a couple more things and I'll let you finish this out Robin with more picks. So yeah, keep thinking of them. So I've gotten back into marathon training. I was doing triathlons for a while. Triathlons are a lot more work to train for than marathons, mostly because I have to go to the gym and get in the pool right, and then I have to maintain my bike. With the marathons, I buy a new pair of shoes when I need it. I
mean, you know, that's about it. So anyway, I'm my legs hurt. They hurt. But anyway, I'm using Training Peaks to train, and I bought just to really short like get back into running, run the whole way for a ten k because I had really let it go right The last marathon I ran was five years ago, and so anyway, so I've been working through that and I think the training program I bought was five bucks. You can get a premium Training Peaks account, but you don't actually have
to have it. There are some nice features that come with it. It does some automatic stuff for you, and you know, if you have a trainer, then you can add your trainer to it and they can anyway. That that's what you get out of paying for it, And yeah, the features are just convenient enough to kind of make it worth it. But I'm I'm going on the free plan right now. But training with Peaks works really
well. And then it sinks with my Garmin watch. So I have a Garmin four Runner two thirty five that I bought when I trained for the marathon five years ago, and so it just sinks it up to my phone, so all I have to er, well, it sinks to my phone through the garment app, and then the garment app sinks it to my watch. And so when I go out to run, I literally just go and select my training calendar and then just hit the workout and then just go run.
And so it's it's pretty awesome. So I'm gonna pick that as well. And then the last thing I'm gonna pick is this Zulu water bottle. You can see I've got stickers all over it. It's a half gallon water bottle. So I've been doing seventy five Hard, which is, uh, it's a mental toughness program. People. It's funny because I talk to some of the people that who want to do it and they're like, oh, so you're doing it to lose weight, and I'm like, well, that's kind
of a nice side effect of working your tail off. But so so the program, I guess I'll pick seventy five hard as well. There's a book for it. It's called The Book on Mental Toughness. It's by Andy Frazella. He's the guy that came up with it, and he you have to go get the book on his website, Andy Frazella dot com. But and he has a podcast as well called realaf and he gets into politics and all
kinds of stuff. So it may or may not be your cup of tea, or you may just pick the ones that are about business and stuff. But anyway, so you go work out twice a day. So I go do my run for one of them, and then I'll do weights or something for the other one. But anyway, one of them is drink a gallon of water. So I just drink two of these in a day. And yeah, I have to tell you that when I'm when I'm doing this versus when I'm not, it makes a major major difference. So anyway, so
I'm gonna pick all of that stuff. I'll drop all the links in the in the comments so that you can get them. But anyway, those are my picks, Robin, what are your picks? All right, I'm gonna go through quickly. I have several categories that I've noticed, So one is workouts in training, So I'm going to pitch to my sword fighting sports. Obviously your pickets not aware that's actually a sport that you can do with sword
fighting. It's called Hema Historical European martial arts. So it's not the same as fencing or something. No, No, it's more more focused on the earlier weapons. Fencing is like a more modern offshoot of what we tried to do, but it's still very much based on like historical manuscripts and stuff. It's kind of a combination of sports and living history and what you might not
know, especially people from the US. Even though it's historical European martial arts, there are a lot of US based clubs and US tournaments and all that kind of stuff. So if you're interested, there and look it up. It might be a local club for you somewhere out there. Then we had books. I've been really enjoying the Bobby first series again. So the first book is called We Are Legion, We Are Bob by Dennis E. Taylor. Excellent sci fi series, very what they call cozy sci fi, very
well done, very enjoyable, especially the audiobook. Is cool TV series. I've been very much enjoying The Boys on Amazon season four. Yeah, I've actually rewatched season three again and yeah, I probably need to do the same once I decide to watch it. For those who don't know that it's it's an alternative superhero series, but very gory. They do see the F word every second sentence, I guess, but it adds to the flavor. Chuck. Yeah, it's the least of the ish potential issues with that. It's
definitely an adult only affair. But I I love everything about it, how how they're the acting, the script, how they're being so satirical on everything. It's it's great. It's great for me and I. Finally, a game that I've been enjoying is Hades. Hades two so yet the original Hades, which was Game of the Year, a couple of years ago. It's a very fast BASD hacken slash type of game. And now they have the second one in the early access where most early access game sort of usually very
buggy and not feature complete. This one is has more content and feels more polished than the first one at release, and I've been enjoying that one. So people are still on the fence about that one. I can heartily recommended story endgame. What what platform is that on? Is that on a console or Steam or what? Various consoles? And Steam? I play with a PlayStation controller on the computer, which is the best of both worlds for me. Nice, there we go. All right, Well, thanks for coming
Robin. This was really fascinating. Oh thank you guys for having me. And it was a great It was a great show. Thank you very much for coming on. All right, Like I said, if anyone has any questions, feel free to reach out. I overshare on these things. All good, All right, till next time, folks. Max out