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