Robin Marx is a Web Protocol and Performance Expert at Akamai. They dive deep into the fascinating world of networking performance, where experts share invaluable resources and insights to optimize your web development projects. The speakers recommend essential tools and books like "High-Performance Browser Networking" by Ilya Grigorik and Barry Pollard's work on HTTP 2, and they dissect the nuances of modern web protocols such as HTTP 2 and HTTP 3. Special guest Robin Marx joins us to unveil the complexities of networking, emphasizing the importance of understanding how your server and browser interact to maximize efficiency.

But it's not all technical; they also share some lighter moments. Discover TV shows like Netflix’s "Eric" and "Criminal Minds Evolutions," explore engaging articles from Big Think, and indulge in some geeky humor with a segment of dad jokes. Whether you're tuning in for professional insight or just some good old tech banter, this episode has something for everyone.

Socials

Picks

Robin Marx [00:00:05]:
Hey, folks.

Charles Max Wood [00:00:05]:
Welcome back to another episode of JavaScript Jabber. This week on a panel, we have Dan Shapiro.

Dan Shappir [00:00:11]:
Hello from a very warm and sunny Tel Aviv.

Charles Max Wood [00:00:15]:
We also have Steve Edwards.

Steve Edwards [00:00:18]:
Hello from a cool and cloudy Portland, and I'm so jealous of Dan right now.

Dan Shappir [00:00:23]:
I don't know. It's really, really warm. I mean, scorching, I think, would be another term for it.

Steve Edwards [00:00:30]:
What is it in Celsius?

Dan Shappir [00:00:33]:
It went as high. Well, today is actually kind of better, but it went as high as 30 something, 33, 34.

Steve Edwards [00:00:42]:
I'd still take another cold any day.

Charles Max Wood [00:00:45]:
It's warm here. I'm Charles Max Wood from Top End Devs. And, this week, we have a special guest, and that's Robin Marks. Robin, do you wanna say hello?

Robin Marx [00:00:55]:
Hello. This is Robin Marks from currently kinda sunny, but very soon to be very wet and rainy Belgium, which which kinda sums up Belgium in 1 sense, I guess.

Dan Shappir [00:01:06]:
That's in chocolate.

Robin Marx [00:01:09]:
Chocolate and fries.

Charles Max Wood [00:01:12]:
That's I'm partial to Belgian waffles. Anyway so yeah. So do you wanna give us a little bit of background as far as, I see network and protocol performance? So so what that's kind of a broad topic. So you wanna give us a little bit of background as to what we're talking about?

Robin Marx [00:01:28]:
Yeah. It really is a broad topic. Like I was saying to Dan before, I started out as a game developer. And if you try to network games, that is that is a very, very complex undertaking.

Charles Max Wood [00:01:40]:
Yeah.

Robin Marx [00:01:40]:
That kinda got me interested in the whole networking business for real. And then I got the opportunity to work on research for HTTP 2. So this was way back in 2015. HTTP 2 was brand new, And the research was like, you know, it claims all these magical things, if you remember this. Like, HP2 is gonna be twice as fast, and, you know, websites were gonna 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.

Robin Marx [00:02:15]:
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? Mhmm. And that spiraled out of control into an actual PhD in, in networking performance where I eventually get It's

Dan Shappir [00:02:30]:
not often it's not often we have an actual like, we we bring somebody over to talk about a topic, and that person act has an actual PhD in that topic. Right?

Robin Marx [00:02:40]:
Well, happy to be 1 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 1 on this 1 aspect, which, which I 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 with that. Yeah.

Dan Shappir [00:03:08]:
I think it's actually a good thing because a lot of developers and web developers really take networking as a given, which is which is kind of,

Robin Marx [00:03:20]:
I

Dan Shappir [00:03:20]:
don't know, amusing or a bit on the 1 hand, and a huge blind spot on the other because networking does have, like, huge impact on on everything we do. I mean, at the end of the day, what we do is primarily delivering stuff over the network.

Robin Marx [00:03:37]:
I couldn't agree more. And that's also why I was interested in coming coming on this podcast specifically, because usually the network is a black box. Right? You don't really need to know how it works. You it just works. But you have some features that allow you to to manipulate what the network does, especially the layer years. You have things like preloads and lazy loading of images and async before JavaScripts, and especially recently a fetch priority, they can use. And all those features, like, very directly tune what the network protocol is doing. Mhmm.

Robin Marx [00:04:12]:
But in practice, people don't really understand what's happening under the hood, and they make terrible mistakes with these, with these features making things slower instead of faster. And that's what I'm trying to do a little bit, like teach people a bit more about how it works under the hood so that they might not make the same mistakes over and over again.

Dan Shappir [00:04:33]:
I I have a a question to kick us off, Something that really has me curious for for a long time and and can also, like, get our discussion networking details potentially. Like, I remember, hearing that if your HTML is under 64k, then that's like this big performance win. Is this actually true?

Robin Marx [00:05:05]:
Oh, it's very interesting you used 64 k. The usual number is 14 k.

Dan Shappir [00:05:10]:
Right. Maybe I got confused. I remember the 4 I remember a 4. And

Robin Marx [00:05:18]:
It's it's excellent that you chose that number because, yeah, as a result, it's it's depends. So 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, more until you're actually gaining the speed that you want. So that's

Dan Shappir [00:05:48]:
And this is a TCP thing. Right?

Robin Marx [00:05:50]:
TCP and quick transport protocol thing. Yeah. And so most servers, most default configurations of servers say that you can only send about 14 kilobytes in that first response. That's about 10 packets, about 10 TCP packets. That's where that comes from. And then you double it to 20, then to 40, then to AD, and so on. So that's where that comes from. The point is that's a default Linux configuration.

Robin Marx [00:06:17]:
Most people don't run default configurations, especially if you're doing a CDN or a or a hosting provider. They often bump that to, like I said, 64 kilobytes. I think the biggest we've seen in practice is a 120 kilobytes on 1 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, 3 gs, for example. So conceptually, yes. The smaller your, initial HTML is, the more chance you have that it will get delivered in the 1st round trip, and and that you will get the benefit from that. But in practice, it's super difficult to to find that exact sweet spot.

Robin Marx [00:06:59]:
It's not always 14 kilobytes, not always 64. It really depends on your setup. And even if you get there, it's only 1 round trip that you that you win. Right? Which in some cases can be huge, but especially if you're using a CDN, 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 to look at this kind of stuff. Like, you probably know my colleague from Akamai, Tim Harish. Yes.

Robin Marx [00:07:34]:
Who, like, super optimizes his personal website. He is running into this kind of stuff.

Dan Shappir [00:07:39]:
He's doing, like, toy models and stuff. Right?

Robin Marx [00:07:42]:
Yeah. He does scale modeling. And it's, and he just every minute of his free time, he spends optimizing his site super fast.

Steve Edwards [00:07:52]:
But he has to know

Robin Marx [00:07:54]:
I was

Charles Max Wood [00:07:54]:
engaged. Right?

Robin Marx [00:07:56]:
Hey. He's, he's doing very good stuff. But so, yeah, to answer your question, it's not a huge boost, and it's difficult to tune, and it's not always 64 kilobytes.

Dan Shappir [00:08:08]:
I just

Robin Marx [00:08:08]:
say that's

Dan Shappir [00:08:09]:
days of, especially in these days where, like, the HTML is kinda created for you by some sort of a meta framework that does hydration, and you have very little control over Yeah. The size and how things are done. Exactly.

Robin Marx [00:08:23]:
Exactly. But, sir, something that Tim was doing was manually shortening the names of the CSS classes so that his first 14 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

Dan Shappir [00:08:44]:
That made a difference what with broccoli compression and stuff like that, making the names a little bit shorter actually made that difference for him?

Robin Marx [00:08:53]:
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 he wants to pass in the 1st round trip to to decline.

Dan Shappir [00:09:08]:
Cool. So you are starting to talk about, like, HTTP 2. Now that kind of assumes that everybody knows what HTTP 2 actually is. I I think everybody I assume most people know what HTTP is, but people don't necessarily know what HTTP 1 or 1.1, then 2, then 3 are, and what are the differences between them? Can you maybe elaborate on that?

Robin Marx [00:09:36]:
Do you have time to do a PhD?

Charles Max Wood [00:09:41]:
Getting into OSI and stuff?

Robin Marx [00:09:43]:
The the executive summary then. So very simply, for HTP1, you could load 1 resource, 1 file over the connection at a time. So you often have multiple connections up to 6, typically open. And then HTTP 2 changed that that you can, request and download multiple files of the same connection at the same time. That was like a big Multiplex. Multiplex. Yes. That was the big innovation that HTTP 2 brought.

Robin Marx [00:10:12]:
You didn't need, like, 30 connections per web page anymore. You needed 1 per domain, which severely simplified a lot of things. And now HP 3, is basically the same thing as HTTP 2 at that layer. At the HTTP layer, they're basically the same protocols. HTTP 3 is very different because at the layer below that, right, the OSI layer, the transport protocol, we swap out TCP, transport control protocol, for something called QUIC. And QUIC then does a lot of magic at the at the lower layers to better deal with packet loss, to better deal with slow networks, and especially add more encryption.

Dan Shappir [00:10:53]:
Maybe you can elaborate on that a little bit because I recall from the early days, people used to say that whoever try like, I actually work at the 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 avoids TCP ends up reinventing TCP. So I'm kind of curious as to what was the motivation for replacing TCP in HTTP 2 with QUIC in HTTP

Robin Marx [00:11:39]:
3. Yeah. So I love that quote. Right? You end up reinventing TCP, because in practice, that's what QUIC did. QUIC is very similar to TCP, except in a very a few key areas, it's not, but mostly it is. It's still reliable. It still has connection setup. It still has test control, that kind of stuff.

Robin Marx [00:11:57]:
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, and the firewalls don't know about that feature, they're like, oh, don't know if this is a good thing or if this is an attacker trying some shenanigans. I'm gonna play it safe, and I'm just gonna drop that traffic. So if you want to change anything about TCP, you 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? IP v 4 versus IP v 6. IP v 6 is more than 20 years old, and still we have very low adoption, because of exactly that reason.

Robin Marx [00:12:50]:
And so what I said with QUIC was, you know, we are going to encrypt everything. On TCP, you basically only encrypt the HTTP parts, your credit cards and your passwords, obviously. Now with QUIC, you also encrypt everything else. You also encrypt the packet numbers and the acknowledgements and the window and that kind of stuff. All of that is encrypted and quick. The idea being that if firewalls and other stuff can't read what's in the packets, they can't bork or they can't break when we when we decide to update QUIC in the in the future.

Dan Shappir [00:13:25]:
This is really amusing. So we 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 1 upmanship.

Robin Marx [00:13:47]:
Kind of exactly like that. Yes. And I have to nuance that because some people still don't understand this. You can still perfectly firewall QUIC. QUIC is very firewallable, but you need to do a lot more work. You need to actually read the RFCs. And if there's a new version of QUIC, you're you're, you have to implement that new version of QUIC before you can actually start firewalling it, which is not the case with TCP. Right? So it's 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 server side.

Dan Shappir [00:14:30]:
So you said that 1 big difference is the fact that, QUIC is encrypted from the get go. You mentioned the fact that it prevents firewalls from from creating issues. I think it also, reduces the the amount of handshake that you need to do because of TCP. You first did the TCP handshake, 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 is also that, you know, TCP is kind of old. It's like, what, 50 years old? How old is TCP? And, yeah, and nobody was thinking, for example, cellular networks back when, TCP started. So a lot of of how modern networks behave is very different from what the situation was when TCP was created. Is that also a motivation for QUIC, or am I misunderstanding?

Robin Marx [00:15:28]:
It's definitely part of it. Right? You want TCP to be evolvable. You need to add additional stuff, but you can't because that takes a decade. Right? So that's why you want QUIC to be able to I I like to say that QUIC is like the we took everything we learned about TSP in the past 30 years. We took all the best practices that we knew and that we want to, and that we put into 1 big package, and that's now that's now quick. With with regards to not being prepared for for newer technologies, I'm not quite in that camp. I think TCP has well held up incredibly well. You can even run TCP on top of Starlink through the satellites and just it just works.

Robin Marx [00:16:13]:
Right? But there are inefficiencies. There are definitely inefficiencies. It can be better, and that's what QUIC 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 5 years or anything. I think I think that will still be around for quite a while, even with 5 g and everything.

Dan Shappir [00:16:36]:
Now I hope you can understand you can answer this honestly given that you work for, in Akamai, I think, who is a CDN provider.

Robin Marx [00:16:47]:
Yes.

Dan Shappir [00:16:48]:
Mhmm. Often, our control over whether or not we use HTTP 2 or HTTP 3 kind of depends on which CDN we choose. Some CDNs, I think, or maybe today, all of them support. But the 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 HTTP 3 versus HTTP 2?

Robin Marx [00:17:27]:
The final part of the question is quite easy. I think you can still just get by with HTP 2. Perfect. Right? We've been doing that for 10 years almost. Again, HP 3 and QUIC give you extra benefits. It can make it a little bit extra fast, especially in challenging conditions. It's not like HP 2 is suddenly not not good enough or not good anymore. And that leads into the part of the first question on the CDN part is right now, it's very challenging to, let's say, do self hosted HTTP.

Robin Marx [00:18:00]:
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 0 RTT and actual multi pods and connection migration, that's that's something that could requires a lot of technical depth and security, to get right. So most people can't do that by themselves. You need a CBN right now because they invested upfront in the whole, deployment of it, which is also a downside because it's becoming 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 of open standard, you kind of have to use 1 of the big companies, at least for now. And I think that's gonna last for a couple more years.

Charles Max Wood [00:18:53]:
So so you can't use something like, NGINX or and and, you know, I'm trying to think of what

Robin Marx [00:19:03]:
Yeah. So NGINX is a good example because it's the 1 of the only, I guess, very popular off the shelf servers that has an HTTP 3 implementation. Apache Okay. Does not have it, and as far as I know, doesn't have plans. Node. Js does not have it. Right? Right. And even NGINX is only in the beta state right now.

Robin Marx [00:19:23]:
It's it's not being sold as this is production ready. And even if you would run NGINX, like I said, the real advanced features that will give you the the big performance boosts are not gonna come out of the box. You're gonna need some custom setup or or specific, configuration to get those. Yeah.

Charles Max Wood [00:19:45]:
Are there are there any off the shelf ones that are working on it beside NGINX that you know of?

Robin Marx [00:19:51]:
Caddy is a big example. Caddy. I guess,

Dan Shappir [00:19:54]:
they Another show, I think.

Charles Max Wood [00:19:56]:
Yeah. We've had, Brian? Is that his name? Holt?

Robin Marx [00:20:01]:
Matt Matt Holt?

Charles Max Wood [00:20:02]:
Matt Holt. Matt Holt. That's it.

Robin Marx [00:20:04]:
Yep. So so Kaddy was quite early on. They used a very good go quick code library there. But even there, they say it's production ready. Actually, there are several key features that Kaddy does not support, that I try to bug them about, like, every 6 months. So it's like, I should have say, there's there's almost no way right now to get all the performance benefits or the robustness benefits that you get from the CDN or a big hosting provider by running it yourself.

Steve Edwards [00:20:38]:
Okay.

Dan Shappir [00:20:41]:
Not not surprising to be to be on and I 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 you want to take advantage of some. That that's my take on it. I I'm sorry, but that's just how I look at it. Maybe it's the my history at Wix speaking.

Dan Shappir [00:21:13]:
I don't know. But, but that's just my my view on things.

Charles Max Wood [00:21:19]:
Yeah. And see, I I come at it from completely the opposite side of things. I mean, I 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 gonna 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 a Vercel or Heroku or something. But as far as, like, my stuff, I mean, I self hosted all, and the reason is is because it cost me less. I get exactly what I want.

Charles Max Wood [00:21:55]:
It it cost yeah.

Dan Shappir [00:21:57]:
It costs less if your time has no value. Let's put it this way.

Charles Max Wood [00:22:01]:
That I I also disagree with that because once I had my deploy set up, the deploys are fast and easy. It doesn't take any

Dan Shappir [00:22:08]:
deploy. It's look. I'm I'm less familiar with the, the world of, of Ruby on Rails, 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 you're on 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. And, and then 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 1 more advantage in that it can be a bit faster.

Dan Shappir [00:22:48]:
Although although to be honest and putting quick aside, using a CDN is kind of a prerequisite for performance if you've got an international audience for your website.

Robin Marx [00:23:03]:
I'd agree with that last part wholeheartedly,

Dan Shappir [00:23:05]:
Dan.

Robin Marx [00:23:06]:
I think if you're really focused on performance, there's you should be using a CDM. There's really no argument against that. For the earlier parts, I'm kind of in the middle, you know. I work for a CDM, so I I do think it's a good thing to, 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 more sense for for people.

Dan Shappir [00:23:32]:
I won't argue with that. You know, there are if for no other reason than freedom of information and, you know, you have the right to do what they what it 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 of somebody else. But going back to the the topic, at hand, you gave, what I consider to be a really interesting talk, and the fact that it had swords in it helped. In in the in the in the latest Performance Now conference. Yeah. That 1.

Robin Marx [00:24:21]:
Let let me boost the the fewer numbers of this 1 then. So

Dan Shappir [00:24:25]:
Is that like underwear?

Robin Marx [00:24:28]:
No. No. These are actual sporting swords that we use. So these are not from a movie or anything. These are just, to make safe for actual sparring, for actual, hitting each other.

Steve Edwards [00:24:39]:
Is that how you handle conflict resolution?

Robin Marx [00:24:42]:
Absolutely.

Charles Max Wood [00:24:43]:
It's kind of a permanent solution.

Robin Marx [00:24:45]:
In in the talk, Dan mentions I call my coworker on stage to, to teach him a lesson. That's what it's yeah.

Dan Shappir [00:24:52]:
It was Tim, I think, wasn't it? Yeah. Yeah. It was Tim. The aforementioned Tim. Yeah.

Steve Edwards [00:24:56]:
Yeah. That puts you on the cutting edge of conflict resolution there, doesn't it? Yeah.

Dan Shappir [00:25:02]:
So so getting back to the to your talk, what you were talking about, as I recall, was about about we mentioned that HTTP 2 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, and yeah. So maybe you can talk about that.

Robin Marx [00:25:38]:
Yeah. So I've actually thought long and hard because usually when I explain this, I have a PowerPoint. Right? I show visuals. How do I explain this with just audio? So I come up with a metaphor, for a, a warehouse, like a store, right? Let's imagine you're 10 people are going to the store and you all want to check out, but there's only 1 register. So only 1 person doing the checkout. What happens in real life is you whoever arrives at the register first gets done fully. They pay and then the next 1 and then the next 1. Imagine if that was not the case, imagine if the person doing the checkout would say, like, okay.

Robin Marx [00:26:18]:
I'm gonna take 1 item of the first 1, the first cart. I'm gonna scan that. Then I'm gonna just gonna skip you for a moment. Go go to the second 1. Take 1 item from your cart, scan that. Go to the third 1, 1 item, all the way to the 10th, and then I'm gonna come back to the front and then 1 item for each again.

Steve Edwards [00:26:36]:
That sounds amazingly efficient.

Dan Shappir [00:26:38]:
Right? Well, if if you think about it, that's kind of like how, CPUs work when you do when when yeah. In in a in an in modern operating systems, you know, obviously, if you have got multi cores, then that's great. But usually, you have more processes or threads going on than the numbers of number of cores that you have.

Robin Marx [00:27:00]:
Exactly.

Dan Shappir [00:27:01]:
And sometimes sharing or time slicing or resource sharing or whatever you decide to call it.

Robin Marx [00:27:06]:
Yeah. Rather than scheduling. So so in in some cases, it's very obvious. Like, let's say that

Dan Shappir [00:27:11]:
Oh, round robin scheduling, not round robin marks scheduling.

Robin Marx [00:27:17]:
I wish I would done that. There you go.

Steve Edwards [00:27:20]:
Dan earned that 1.

Robin Marx [00:27:23]:
0, it's this kind of stream. And so it's it's easy to see when it becomes positive. Let's say the first person has 200 items, but the 3rd person in line only has 3 items. Right? In the first scheme, the 3rd person would have to wait a long time for the first guy to be done. In the second 1, the third person actually done much earlier. And you're not dealing the first 1 by that much because it's just like, let's say, 3 items more. So those are like the the 2 extremes. Right? You either do everything sequentially, back to back, or you do something called so round robin ask you you share bandwidth in this in this case.

Robin Marx [00:28:03]:
And in practice, you want to you want to change what happens based on the type of resource. Like, the the multiplex and the bandwidth sharing is good for images, for example, because most images can be rendered incrementally. Mhmm. 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 JavaScript and CSS, those have to be downloaded in full every last byte before they can actually be applied to the page. So if you start doing the the multiplexing, the wall running for JavaScript and CSS, you're delaying that very, very heavily, and they can actually

Dan Shappir [00:28:51]:
By the way, another resource that might benefit from slicing or whatever, round robin, whatever we decide to call it, is HTML because HTML can actually be parsed, like, in parts. 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 closing curly bracket at the end. You can't

Robin Marx [00:29:28]:
Exactly. Yeah.

Dan Shappir [00:29:30]:
Until you have that, you can't really execute the code. And and I I wonder why it's that's the case with CSS. It seems that CSS could be somewhere in the middle, I'm thinking.

Robin Marx [00:29:40]:
Because you have the cascade.

Dan Shappir [00:29:42]:
Oh, yeah. Because you need to cascade everything. You can't partially cascade.

Robin Marx [00:29:47]:
But it's true that both JavaScript and CSS can be parsed and compiled in a 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.

Steve Edwards [00:30:01]:
Right.

Robin Marx [00:30:01]:
To actually load the the JavaScript, to execute the function that it's trying to do, for example. Right? And that's what's and and so to make the story around, so those are the, like, the 2 options, multiplexing. But it turns out it's right. Sometimes you really want 1 and sometimes the other and sometimes something in in between. It turns out that a lot of servers in in HP 2, 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 you want JavaScript and CSS to be sequential? I don't really care. I'm just gonna send them, multiplexed as well.

Robin Marx [00:30:41]:
And so by conceptually, HP2 could be as fast or even faster than HP1 different connections. In practice, it was not because this whole multiplexing thing was usually just going all the wrong directions because of implementation bugs.

Dan Shappir [00:30:58]:
Wait a minute. With HTTP 1.1, 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 1 domain. We the the browser actually opened usually 6 TCP connections and just that it did downloaded 6 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?

Robin Marx [00:31:31]:
Kind of. Yes. The problem that you get in there is that you're sharing the bandwidth, 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 at the beginning, everything goes well. Right? We are not filling the pipe yet, so everything doubles, doubles, doubles. So 6 connections are all doubling it more or less the same time. So they very quickly reach that bandwidth limits, and then you get, like, a massive amount of packet loss because they all overextend whatever they might safely use at more or less the same time.

Robin Marx [00:32:14]:
So you suddenly have a big drop of bandwidth usage because now you need to stop because you had too much loss. You need to retransmit all those lost packets and so on and so forth. While with HTTP 23, you have 1 connection, and that 1 connection can much much better decide how to ramp up that bandwidth because it it knows that it's the only 1 that matters for this particular site or or for this particular, domain.

Dan Shappir [00:32:42]:
I wish it I wish it was the 1 connection. I mean, in this in this day and age of third party scripts and pixels and the fact that that if you have, like, cores and not cores and you actually tend ends up being even 2 connections per domain, you very quickly even even with HTTP 2 can get to a pretty high number of of active connections.

Robin Marx [00:33:06]:
Yes. But the crucial difference there is that most of those extra connections don't download a ton of data. Like, 3rd parties usually only only load, like, 1 file or something. It's still gonna be 1 or sometimes 2 connections that download the bulk of the actual data. Right? And before, it used to be 6 or maybe even 12 connections at the the bulk loading. So you

Dan Shappir [00:33:30]:
Now you said that the server has kind of ignored 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 tell try to tell the servers what to do, and can we, as web developers, impact what the browser is saying?

Robin Marx [00:33:49]:
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 the short summary is, 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 telescope

Dan Shappir [00:34:12]:
and the hands Maybe even a term the better term would be more urgent and less urgent, not so much important.

Robin Marx [00:34:19]:
Mhmm. Perfectly fine because in practice, it's actually called urgency. Very good. So let's use urgent. So the browser says, like, okay, a JavaScript in the head is gonna be more urgent than a JavaScript in the bottom of the page, for example. Right? That's a a power that you as a developer have to to give the browser a couple of hints. So the browser then says, okay. I'm gonna assign an urgency or priority to each resource based on those hints.

Robin Marx [00:34:45]:
You could also have, like, async and defer, also manipulate JavaScript 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 then also says you should either send them sequentially, so 1 by 1, or they can be, multiplexed. They can share bandwidth.

Dan Shappir [00:35:12]:
Oh, the browser says that?

Robin Marx [00:35:14]:
The browser says this. Yes.

Dan Shappir [00:35:16]:
But I don't think you as a or we as as web developers can actually control that. It's it's I don't recall an an API for that.

Robin Marx [00:35:24]:
Yeah. So that's that's the big problem in my opinion. You can control some of that, but very indirectly. So for example

Charles Max Wood [00:35:34]:
you guys just answered a question that came in on Twitter, by the way, asking about bandwidth limits. That's on the browser side. Right? It's not on the Internet side or the server side.

Robin Marx [00:35:43]:
No. No. No. It's bandwidth 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 Oh, okay. In the back end.

Charles Max Wood [00:35:56]:
So so it's not the browser then. It's my it's my ISP?

Robin Marx [00:36:01]:
It's usually the Wi Fi link. Uh-huh. But whether or not you say the Wi Fi is property of the ISP or not, that's Okay. That's something I guess.

Charles Max Wood [00:36:10]:
So so maybe my connection whatever connects me to my cable modem

Robin Marx [00:36:16]:
or USB. Yeah. Yeah.

Charles Max Wood [00:36:17]:
Fiber whatever doohickey that I have in my house.

Robin Marx [00:36:21]:
Truly a problem. Same with 3 t 14. Okay. That's usually limited because you're also sharing that with multiple people usually. Right. Multiple people on the Wi Fi or on the 4 g mast, makes

Dan Shappir [00:36:34]:
it easy.

Robin Marx [00:36:34]:
Okay. So getting back to what I was, talking about, you can't control that directly, but some features implement that in 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, change its priority, which is, you know, again, somewhat, unexpected for some then. So that's a good example. 1 way to explicitly control this, though, is that new thing that I talked about before, which is fetch priority. And that's your Yeah.

Robin Marx [00:37:19]:
They also understand where that name is coming from priority. So that indicates how how important is it this resources to

Dan Shappir [00:37:26]:
Yeah. To our listeners who are not aware or familiar with it, it's an attribute that you can put on stuff like images or scripts or literally anything that downloads a resource. Also, it exists in the browser's 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 browser's, automatic priority assignment. And the and and like you said, there are some obvious values like, HTML itself is obviously high or highest. Likewise, CSS upfront is high or highest. It's well, if if it's in the head as well.

Robin Marx [00:38:19]:
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

Charles Max Wood [00:38:40]:
not in the spec?

Robin Marx [00:38:41]:
No. There is no spec for that at all. The spec only says this is the mechanism to send these values to

Charles Max Wood [00:38:47]:
the server.

Robin Marx [00:38:49]:
What what what you put, what actual values you use is not specked 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? In Chrome, fonts are highest priority equal to, CSS and HTML, highest priority.

Robin Marx [00:39:15]:
In Firefox, fonts are low priority.

Dan Shappir [00:39:21]:
Yeah. Because and and and I can understand where it comes from. Because on the 1 hand, you want fonts to download as quickly as possible because they really impact or 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 of because the 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 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.

Dan Shappir [00:40:14]:
1 option is show the text in whatever built in font you have, and then switch over to the desired font. Want to have it? Another 1 is no, don't show any thing 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 at all until the font 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 and 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 depend it impacts the the priority you assigned to the actual font resource.

Robin Marx [00:41:19]:
Yes. But the point is, and it's 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 gonna change the prioritization of the fonts. That would make more sense with your explanation, I would agree. That's not what happens at all. With Firefox, all fonts are just low priority, whether or not you have defined it as a fallback or not, or or treat that as not. And, there are several other examples, especially for JavaScript because this this is JavaScript to a server.

Robin Marx [00:41:58]:
Right?

Dan Shappir [00:41:59]:
Mhmm.

Robin Marx [00:41:59]:
For example Yeah. If if you tag, a JavaScript that's async or defer in Chrome, it will give it a low priority. Well, default JavaScript is a high priority, and Firefox doesn't care about that at all. In Firefox, if async a deferred, that's exactly the same priority as a normal JavaScript somewhere in the body. It doesn't make any difference there at all. So for Firefox, for example, it matters much more in which order you have your JavaScripts defined than in Chrome, for example. Right? And 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 1 of the browsers, but then completely goes into the macro other browsers.

Robin Marx [00:42:55]:
And, like, seconds difference seconds difference, just because of what the browsers are doing differently on the same page. And the problem is that people, of course, mostly test on Chrome, or you can get only can only get core web vitals and stuff from Chrome. And so if the if the slower browsers happen to be Safari and Firefox, people usually miss that. And and, you know, it's difficult to get them to pay attention to that.

Charles Max Wood [00:43:26]:
So, I guess, how do you go about solving this? I mean, you could test it on the other browsers. But

Robin Marx [00:43:33]:
so at this point, you really can't. So fetch priority is helps a little bit. Right? Because at least you can you can be very clear to the browser. Like Mhmm. Like, a good example is your largest comments will paint image. Right? So the the most important image on your page, all the browsers are giving us a low or lowest priority by default. You can say fetch priority high.

Dan Shappir [00:43:58]:
You can Actually, that's no longer accurate. That's no longer accurate for Chrome. Chrome, if it identifies that it thinks an image might be the largest Contentful Paint image, it would actually automatically assign for it the higher priority as I recall.

Robin Marx [00:44:14]:
It's it's a bit more general than that. If it figures out the image isn't the viewport, then it changes it too high.

Dan Shappir [00:44:21]:
Yeah. Like I said still.

Robin Marx [00:44:23]:
But but the initial priority that I requested with is they'll simply low. They will just send an

Dan Shappir [00:44:27]:
update by

Robin Marx [00:44:28]:
when they, figure it out.

Dan Shappir [00:44:30]:
But but I totally agree with you that if you know as the content creator that a particular resource is going to be or likely be your LCP, then you should give it a a high, fetch priority and hope that that the server even cares.

Robin Marx [00:44:51]:
You need a compliance server. But assuming that. Right? Indeed. But then then it becomes a problem. Right? Because now you've you've given developers something called fetch priority high, and they really should only be using that on, like, 1 or 2 images. What most developers do in practice is they just put it on all the images. Right? Because it makes things faster.

Dan Shappir [00:45:14]:
Like I tell my kids, if everything is urgent, then nothing is urgent. Right?

Robin Marx [00:45:18]:
Exactly. Exact I've literally seen this last week. This was a site, and it was preloading, 15 different images, all with fetch priority high in the preload. And none of the 15 images was the largest console paint image. And 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 below that, they had their key JavaScript that they really needed to start rendering. So the JavaScript was delayed by their 15 preloaded images that were useless because none of them was even the large count for painters. And it's like this this is 1 of those problems that I'm trying to explain.

Robin Marx [00:46:09]:
It's like, you give developers these high level features like preload, like fetch priority, like async and defer. 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 to really get right in in practice. I'm always reminded of the it was a year or 2 years ago, like, when native lazy loading came out on images.

Dan Shappir [00:46:41]:
Oh, yeah.

Robin Marx [00:46:42]:
If you remember that that that, WordPress.

Dan Shappir [00:46:44]:
With yeah. With WordPress. That they made everything lazy loaded.

Robin Marx [00:46:47]:
Yeah. They made everything lazy loading because lazy loading is good for performance. But they also lazy loaded the large colorful paint images.

Dan Shappir [00:46:55]:
Yeah. It it's worth a very quick explanation. What 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 viewport. That means though that in order to to know whether or not to lazy load an image, the browser needs to know exactly where that image is located on the page and what its size is, etcetera. And that means that it it can't immediately know that upfront. So it it kinda needs to do some layout before it it can know. So it actually delays the in the the the loading of of lay images that are marked as lazy load loaded until it knows where you know, how the page is laid out, which introduces a delay that you don't want for your primary image.

Dan Shappir [00:47:53]:
So yeah. So by making marking everything as lazy loaded because you might think, hey. I don't know. It's I'll mark it as lazy loaded. 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.

Robin Marx [00:48:12]:
Yeah. Exactly. And and the point I want to make there, it's 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 1. 2, the tooling, especially when features are new, tooling is often lagging behind. There is no big red button that's going like, oh, I noticed you're lazy loading your, LCP image.

Robin Marx [00:48:43]:
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 node. You shouldn't have to. But in practice, you you do, or you or you can make easy mistakes, sadly.

Dan Shappir [00:49:11]:
So what, you know, if if somebody wants you 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 we get between us.

Robin Marx [00:49:33]:
Oh, that's a very broad topic.

Dan Shappir [00:49:36]:
No. Just just a quick laundry list or or or checklist that people can take away from our conversation here

Robin Marx [00:49:44]:
Yeah.

Dan Shappir [00:49:44]:
Technical items.

Robin Marx [00:49:46]:
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 gonna say they do everything correctly. In fact, several of the larger CDNs and hosting providers have big issues when it comes to to HTTP 3 implementations specifically. But they're likely to be closer to the optimal than what you can get yourself. That's that's it. And then on the front end, use these special features in a very limited fashion.

Robin Marx [00:50:22]:
If you're using preload, if you're using fetch 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 AB testing to see what actually, what actually happens.

Dan Shappir [00:50:44]:
And a great tool to do that AB testing If

Robin Marx [00:50:55]:
If if you'd asked me this a year ago, I would have said, yes. Web page test is the best. Since then, I I think you probably know, I it feels like, that sort of web page test is a very good tool, but it 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 to keep it super relevant, in my opinion. There are some long standing especially network level bugs. It's very difficult to debug network level stuff with web pages nowadays, in my opinion, that you just don't fix. And so for me personally, I've switched mostly to a different tool called debugbear.

Dan Shappir [00:51:44]:
Oh. Debugbear of them.

Robin Marx [00:51:47]:
Who also have a free, speed test. It's in some areas, it's less advanced than web page test for sure. But in others, especially when it comes to networking features and things like, oh, you you you're doing something wrong with your LCP or you're preloading too much, that kind of stuff, is very, very well integrated into debug bares.

Dan Shappir [00:52:06]:
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. Plea please don't do it. It's like at at that level.

Robin Marx [00:52:31]:
So just to fit in there, I love Lighthouse, for its audits. I think the audits are amazing.

Dan Shappir [00:52:38]:
Yeah. Exactly.

Robin Marx [00:52:40]:
But for network level stuff, live

Dan Shappir [00:52:43]:
transcription, it's

Robin Marx [00:52:44]:
it's not a good

Dan Shappir [00:52:45]:
Yeah. Yeah. I know. I know. It's it's it's not it's it's it's simulation. It's it is of of network limit limits is let's put it this way. I I've got some results out of it, which obviously made no sense.

Robin Marx [00:53:00]:
Mhmm. I 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.

Dan Shappir [00:53:22]:
The the score from my perspective is is good for 1 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 number as as a performance budget, to see whether or not because there's a good chance that if it's significantly significantly degraded, then you potentially introduced an a a real issue. But I definitely wouldn't look be looking at it as an absolute number.

Robin Marx [00:53:55]:
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's so much simulation and emulation going on at that layer that you might miss things or small regressions might show up as much larger impact

Dan Shappir [00:54:16]:
Oh, yeah. For sure.

Robin Marx [00:54:18]:
In that way. So yeah.

Dan Shappir [00:54:21]:
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, that you have compression enabled. I mean, so often I see people accidentally disabling compression, and obviously caching.

Robin Marx [00:54:42]:
Yep. The the fastest thing is the thing you don't even have to send. Yep. That is yeah. Yeah. I, of course, agree. And, again, those are things that CDNs help you get 95% of the way as well. Right? So the main reasons to use the CDN is because you get this caching, and usually automatic compression, out of the box there as well.

Robin Marx [00:55:08]:
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 HTTP 23 and all these features only come into play when you've optimized most of the other stuff first.

Dan Shappir [00:55:29]:
I'll start with the inverse. If 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 loadings, 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 or, like, for an internal app. I mean, obviously, nobody wants any something to load loading performance might not be the most important consideration. And in those scenarios, then then the client side rendering might be good enough. If on the other hand, you're building an ecommerce site, a marketing site, anything that needs to be indexed, it just, you know and and and and its client side rendered, then there's no point really about in talking about anything else until you fix that.

Robin Marx [00:56:35]:
I I largely agree with that. Yes. The the nuance I always try to say is, like, it's always about priorities and and developer cycles that you have to spend. Right?

Dan Shappir [00:56:47]:
Oh, yeah.

Robin Marx [00:56:48]:
I I disagree that it's just because it's an internal tool or a b to 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 a 4 g or 3 g connection train. And it was really critical. I I looked up something within 5 minutes, and it just couldn't because it's it's crap. So you 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 things might think might they might make things a bit slower.

Dan Shappir [00:57:30]:
Or tentatively, 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 an internal if it's an internal app, then you you that you have open in 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 once it's once your it's loaded rather than the 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.

Steve Edwards [00:58:24]:
Yeah.

Charles Max Wood [00:58:24]:
So we have a question on Twitter that's asking if there are other good online resources like books or blogs or whatever that that people can go and learn more about this stuff.

Robin Marx [00:58:38]:
So the best resources are if you, Google Robin Marks networking, then you will find other good stuff. No. III

Charles Max Wood [00:58:46]:
hear that guy's real smart.

Robin Marx [00:58:47]:
So That that's it. III do like I'm I'm 1 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, by Ilya Grigorik, which is available for free online at

Dan Shappir [00:59:14]:
Mhmm.

Robin Marx [00:59:15]:
And now take notes. It's h pbn.c0. So h high performance browser networking, h pbn.c0, which is a free online book, which is slightly outdated by now, even though it's been updated with some things. It for example, I don't think it covers HTTP 3 yet. But it's, it's still a very good resource to get with the basics. It explains how the how the networks work underlyingly, what things like control and that kind of stuff are. It's still an excellent resource. And then you have, the HTTP 2 book by Barry Pollard, who is now at Google.

Robin Marx [01:00:00]:
Mhmm. So the Google

Dan Shappir [01:00:01]:
Yeah. We've had them on our show, like, once or

Charles Max Wood [01:00:03]:
twice. Of them.

Robin Marx [01:00:07]:
So, for people watching the stream, it's this 1. Right? Again, wouldn't say outdated. It's just not very recent. But it it explains HP2 in an amazing way. And, again, it gives you a lot of insight into why things work the way they do and how that works. And a lot of what what's in HP3 and QUIC 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 Marks on on Google.

Robin Marx [01:00:41]:
Also look up Barry 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 blogging a lot on the web.dev, among others. And so pretty much anything that Gary writes is is good for this kind of topic, I guess.

Dan Shappir [01:01:08]:
Both both of you have written quite a bit for Smashing Magazine as I recall, and, you got a series of of of posts there. Barry is and a lot of work there. I think he actually even worked with them on improving the the loading performance of National Magazine itself.

Robin Marx [01:01:24]:
Exactly. So, yeah, I think, Barry and then, performance in general, like, networking performance in general, the go to guys, of course, Harry Roberts, who was also here a couple of weeks ago, I think, or a couple

Dan Shappir [01:01:40]:
of months ago. Yes. We had him as as as a guest on our show as well. He he's great. And if you mentioned Harry, and again, we talked about your talk. Go in YouTube and just look for the Performance Now conference, and there 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 hints. Harry talked about these.

Dan Shappir [01:02:05]:
We were talking about caching. Harry also talked about that. And, of course, your own talk that I mentioned with the swords about, how brow how web servers and browsers handle priority and how they mess it up so often.

Robin Marx [01:02:21]:
Yep. And and any other talk from Performance Now, it was it was a great great addition last year. Yeah.

Charles Max Wood [01:02:30]:
Awesome. Well, I'm gonna push this into pics. Before we do that, Robin, where do people find you? You mentioned Twitter, I think, before we got started.

Robin Marx [01:02:40]:
Yeah. So I'm at Twitter. My handle is programming art. Like I said at the start, this is from when I still thought I could be an artist. I gave that up. So it's not now it's just the programming part, but I can't change the handle. So So the handle is programming art. You can also find my Mastodon link in the profile there because III don't even know it by heart.

Robin Marx [01:03:04]:
And then, I'm actually a lot on LinkedIn nowadays as well because that's where most of the Akamai, related people are, as well. And you can always feel free to reach out, to send me an email or or or DM or anything. We're always happy to talk about this kind of stuff.

Charles Max Wood [01:03:23]:
Awesome. Alright. Well, let's do our picks. Dan, do you wanna start us off with picks?

Dan Shappir [01:03:29]:
Yeah. Sure. So 2 things really. The first is kind of, work related. So it's it's really funny. I've started working at Sisense as principal engineer, and I'm learning the the 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.

Dan Shappir [01:04:02]:
Long story long story short, saw some things, started 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 30 fives. And, and and yeah. And yeah. And whoops. It it it basically in 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, and, yeah, it touches a lot of things. So yeah.

Dan Shappir [01:04:47]:
Anyway, so that's, so pick number 1 is, I don't know, like, be careful of, how big a bite you choose to take when you were starting with a new code base. I don't know. On the other hand, it's it's an interesting way to go. You you you make yourself make make everybody aware that you're there very quickly. Let's put it this way. So that's that's my kind of pick number 1. And the other pick is an actual pick is, a show on Netflix that we recently watched and enjoyed, very much. It's called Eric.

Dan Shappir [01:05:26]:
It's with, Benedict Cumberbatch. He's an amazing actor. The show is really kind of out there. It's a miniseries sort of a thing. I don't remember. They have, like, 8 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.

Dan Shappir [01:05:58]:
It has, police brutality and corruption. It has, gay rights. It has, substance abuse. It has homelessness, like everything bad that you can associate with New York in the eighties is kinda 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 Cumberbatch, especially, he plays this person who has severe addiction issues that are that are maybe compounded by or 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.

Charles Max Wood [01:06:54]:
Awesome. Steve, what are your picks?

Steve Edwards [01:06:58]:
Well, I'll go with before we get to the high point of of our episode, I do have 1 semi legit pick. There's an article I saw on Hacker News, and this is a little area that I've I've 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 they're needed to do 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 in the show notes. And now for the I gotta 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.

Steve Edwards [01:08:07]:
So cheese has holes. Right?

Dan Shappir [01:08:09]:
Yep.

Steve Edwards [01:08:10]:
More cheese equals more holes.

Dan Shappir [01:08:13]:
Mhmm.

Steve Edwards [01:08:13]:
More holes equals less cheese, so, therefore, more cheese equals less cheese. Yep. Gotta think about that. The logic is a little twisted there. So here's 1 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.

Steve Edwards [01:08:38]:
No 1 expects the Spanish in physician. And then, Robin is holding his head 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.

Dan Shappir [01:09:00]:
I'd 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 gonna tell us some dad jokes, I'm going to mention this, old video that, from, like, I don't know, 8 years back that ran on Nickelodeon about, people about kids who are the victims of of dad jokes and how they cope with it. It's it's a really funny video.

Steve Edwards [01:09:28]:
Oh, it's great. I think I might have mentioned it before as a pic myself, but, yeah, it's,

Dan Shappir [01:09:33]:
for

Steve Edwards [01:09:33]:
those of you who watch it, that's, in real life, that's what my kids go through on a regular basis.

Charles Max Wood [01:09:39]:
Alright. I'm gonna throw out some picks. So my first pick, is a card game. It's 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 kinda like that. You have a 4 by 3 grid.

Charles Max Wood [01:10:00]:
If you get, if you get 3 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 1 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 what the penalty is. But then everybody tallies their scores up. And, I mean, that that's the game right there. It's board game geek rate weights it at 1.06.

Charles Max Wood [01:10:41]:
So it you know, we play with kids. My 8 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 1 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.

Charles Max Wood [01:11:09]:
I think they've put out, like, 3 or 4 episodes on it now. And it's

Dan Shappir [01:11:12]:
Oh, yeah. They came up with a new season because as I recall, like, they had, like, 2 season 1 or 2 seasons, and then, like, they had to stop because of COVID or something. So

Charles Max Wood [01:11:23]:
Yeah. I they

Dan Shappir [01:11:23]:
just they just couldn't film more episodes and eventually just had to let all the actors go or something like that.

Charles Max Wood [01:11:29]:
Yeah. So they're the the whole squad is back. So in the 1st season, they're chasing the guy that, like, provides the serial killer kits to the serial killers. Right? They catch him. So in the 2nd season right there, there there's a there's a twist on that that they're trying to chase down, and I don't wanna 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.

Charles Max Wood [01:12:07]:
So if that bothers you it's not it's not egregious. Like, some shows, it it it gets on my nerves because it's like every other word is an f bomb. And it's like, you you could just speak English. Right? And just drop

Robin Marx [01:12:19]:
a couple.

Charles Max Wood [01:12:20]:
But, anyway, the this one's not bad, in that regard, but there is more of it if you liked the original TV series.

Steve Edwards [01:12:30]:
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? Truly interesting. I I'd read a book by the guy. His name is John Douglas.

Dan Shappir [01:12:51]:
Uh-huh.

Steve Edwards [01:12:51]:
And he was the FBI agent that, created the whole behavioral sciences unit at the FBI.

Charles Max Wood [01:12:57]:
Oh, nice.

Steve Edwards [01:12:58]:
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 and Yeah.

Dan Shappir [01:13:07]:
I was confused because there was a show called Mindhunter about that guy on Netflix.

Steve Edwards [01:13:13]:
Yeah. I don't when

Dan Shappir [01:13:14]:
the show was a movie. I don't remember. It was kind of kind of based or inspired by reality.

Charles Max Wood [01:13:20]:
I didn't watch this, so I don't know.

Steve Edwards [01:13:22]:
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, there's a specific murder that started it, and I can't remember who it is. Larry Jean Bell is 1 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 in psychology 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.

Steve Edwards [01:14:09]:
Shocker.

Dan Shappir [01:14:10]:
Oh, yeah.

Steve Edwards [01:14:10]:
Of course. But but to read about

Charles Max Wood [01:14:13]:
And there's all this internal drama and strife.

Dan Shappir [01:14:15]:
Yeah. And you mean it they don't solve a case every 30 minutes? Like

Steve Edwards [01:14:19]:
No. No. No. It's yeah.

Charles Max Wood [01:14:21]:
It takes a long minutes.

Steve Edwards [01:14:23]:
Yeah. It takes a long time. But if you look up John Douglas and all of his books, he's the guy that started it all.

Robin Marx [01:14:29]:
Nice. I'm waiting for HBO Max to launch in my country, which is in, like, 2 weeks because I will I will finally be able to rewatch True Detective. Have

Steve Edwards [01:14:40]:
you ever watched Oh, yeah.

Dan Shappir [01:14:41]:
You have

Steve Edwards [01:14:42]:
I've started

Robin Marx [01:14:43]:
season 1 is

Steve Edwards [01:14:46]:
I still have yet to finish the very first season. I've watched, like, 4 or 5 episodes, but I don't have it. And I haven't been able to sit down and watch it. I still gotta watch the end of that first 1.

Robin Marx [01:14:54]:
Well, there's a pic

Charles Max Wood [01:14:55]:
from Robin.

Robin Marx [01:14:56]:
Oh, yeah. Yeah. True detective. Alright. I'm gonna throw

Charles Max Wood [01:15:01]:
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 than, marathons, mostly because I 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.

Charles Max Wood [01:15:30]:
So, anyway, I'm I my legs hurt. They hurt. But, anyway, I'm using TrainingPeaks to train, and I bought just a really short, like, get back into running, run the whole way for a 10 k because I had really let it go. Right? The last marathon I ran was 5 years ago. And so, anyway, so I've been working through that, and I think the the training program I bought was $5. You can get a premium TrainingPeaks 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.

Charles Max Wood [01:16:09]:
And, you know, if you have a trainer, then you can add your trainer to it. They can anyway, that that's what you get out of paying for it. And, yeah, the features are just convenient enough to kinda 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 syncs with my Garmin watch. So I have a Garmin Forerunner 235 that I bought when I trained for the marathon 5 years ago. And so it just syncs it up to my phone. So all I have to or well, it syncs to my phone through the Garmin app, and then the Garmin app syncs 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.

Charles Max Wood [01:16:52]:
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 75 hard, which is, it's a mental toughness program, people. It's funny because I talked to some of the 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.

Charles Max Wood [01:17:22]:
But so so the program, I guess I'll pick 75 hard as well. There's a book for it. It's called the book on mental toughness. It's by Andy Frisella. He's the guy that came up with it. And, he you have to go get the book on his website, andyfrisella.com. But, and he has a podcast as well called Real AF. And he he gets into politics and all kinds of stuff.

Charles Max Wood [01:17:46]:
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 1 of them, and then I'll do weights or something for the other 1. But, anyway, 1 of them is drink a gallon of water, so I just drink 2 of these, in a day. And, yeah, I'll 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 I'll drop all the links in the in the comments so that you can get them. But, anyway, those are my picks.

Charles Max Wood [01:18:28]:
Robin, what are your picks?

Robin Marx [01:18:30]:
Alright. I'm gonna go through quickly. I have several categories that I've noticed. So 1 is is workouts and training. So I'm gonna pitch the my sword fighting sports, obviously, or pickets. Some people are not not aware. It's actually a sport that you can do with sword fighting. It's called HEMA, historical European martial arts.

Dan Shappir [01:18:50]:
So it's not the same as fencing or something like

Robin Marx [01:18:53]:
that? No. It's much more focused on the earlier weapons. Fencing is like a more modern offshoot of what we try 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 and all that kind of stuff. So if you're interested there, look look it up. It might be a local club for you, somewhere out there.

Robin Marx [01:19:27]:
Then we have books. I've been really enjoying, the 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.

Robin Marx [01:19:47]:
Especially the audiobook is cool. The series, I've been very much enjoying The Boys on Amazon.

Dan Shappir [01:19:54]:
Season 4?

Robin Marx [01:19:56]:
Season 4. Yeah. I've actually rewatched season 3 to to catch up again. I mean Yeah.

Dan Shappir [01:20:01]:
I probably need to do the same once I decide to watch it.

Robin Marx [01:20:04]:
For those who don't know that, it's it's an alternative superhero series. It's very gory. They do see the f word every second sentence, I guess. But it adds to the flavor, Chuck. So

Dan Shappir [01:20:19]:
Yeah. I'd say it's the least of the potential issues with that.

Robin Marx [01:20:25]:
Yeah. It's definitely an adults 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 then finally, a game that I've been enjoying is Hades Hades 2. So, yeah, the original Hades, which was game of the year a couple of years ago. It's a very fast paced hack and slash type of game.

Robin Marx [01:20:53]:
And now they have a second 1 in the early access, where most early access games are usually very buggy and and not feature complete. This 1 is, has more content and feels more polished than the first 1 at release. And I've been enjoying that 1, thoroughly. So people are still on the fence about that 1. I hardly recommend it, story and gameplay.

Charles Max Wood [01:21:18]:
What what platform is that on? Is that on a console or Steam or what?

Robin Marx [01:21:23]:
Various consoles and Steam. I I play it with a PlayStation controller on the computer, which is the best of both worlds for me.

Steve Edwards [01:21:32]:
Nice. There

Robin Marx [01:21:34]:
we go. That's it for me.

Charles Max Wood [01:21:36]:
Well, thanks for coming, Robin. This was really fascinating.

Robin Marx [01:21:39]:
Oh, thank you guys for having me.

Dan Shappir [01:21:41]:
And, it was a great it was a great show. Thank you very much for coming on.

Robin Marx [01:21:46]:
Fantastic. Alright. Like I said, if if anyone has any questions, feel free to reach out. I overshare on these things.

Charles Max Wood [01:21:53]:
Oh, all good. Alright. Till next time, folks. Max out.