Noel: Hello and welcome to PodRocket. My name is Noel. And today I'm joined by Harry Roberts. Harry is a consultant web performance engineer, designer, developer, writer, and speaker. He's worked with Google, the UN, Etsy, the BBC, a whole list of other companies. Welcome to the show, Harry. Harry Roberts: Hey, thank you for having me. How's it going? How are you? Noel: Good, good. I'm doing well. I'm doing well. How are you trying to stay cool. Harry Roberts: Trying and failing. Yeah, we were just talking sort of just, I guess before we started recording. It's a heat wave here in the UK and it is intense. British people aren't built for this kind of thing. Noel: Yeah. Yeah. I'm in the Midwest and we have drastic temperature swings as well, but it sounds like you guys are getting a taste of it today too. Harry Roberts: We're not used to it. At least the news has got something different to talk about. The news is all just weather this and sunshine that, and it's busy news days. Noel: Yeah. Yeah. Well, we won't linger on it for too long. Yeah. Let's jump in a little bit. So, we got a whole bunch to cover today. We got some talks you've been given and a book, I think, that recently came out. Harry Roberts: Yeah. Noel: But anyway, let's jump in with your background. So, tell me a little about who you are, where you come from and how you've been spending your time recently. Harry Roberts: All right. So, I'm based in the north of England, a city called Leeds, which is a great little place to sort of live and work. Pretty good. Well, really good tech scene. So, I started as a front end developer here 12 years ago now, long time ago, very, very front end developer. Do you know what, it was so easy being a web developer 12 years ago. You need to know a bit of MooTools, Siesta [inaudible] made you a rockstar. But for the last several years, I focused exclusively on site speed and web performance. So, my background is, well, my last full-time job I suppose, was working for a large organization here in the UK where web forums was a really sort of a really key component of building an effective app/website. So, I just got fascinated with that. And now do that on a sort of self-employed consultancy basis, which is very, very privileged and very, very fun. And yeah, I'm a very lucky boy. Noel: Nice, nice. So, like what kind of drew you to focusing on performance in the web space? Because like there's so many aspects to development. What about performance specifically? Harry Roberts: Honest, I'm not just saying this. I think that's a great question. Because it makes me very introspective and I think the reason I started off as a web designer, right. And I soon realized I'm not very good. I can't make things look nice. What I can do is I can follow rules. I'm really good at following rules. So, with Web perf, for me, it just became a fascination of you can always be a bit faster. You can always improve something. Obviously diminishing returns at some point is pointless. But there's always something to measure, something to optimize, something to fix. And I've got a bit of a maybe obsessive personality in certain ways. Like I like to really deep dive in things and Web perf, it's not unique to Web perf, not at all. But it just gave me a really good opportunity to deep dive into one specific thing and just becoming engrossed. Noel: Nice. Nice. So, yeah, I think that is as good a point of any to jump into like a talk or a YouTube video that you've been doing recently, get your head straight. Is that right? Harry Roberts: Oh yeah. Yeah. Correct. Yeah. Yeah. Noel: Yeah. Awesome. Is there a written component or anything to that or is it just like a talk you've been giving? Harry Roberts: It's just a talk. So, my whole thing is I do get very deep dive. I go way deeper than anyone would reasonably expect on one particular topic. And for the last sort of couple of years, I mean, it is as long as that I've been obsessed with head tags. So, I wrote that up into a bit of the talk, which I've not been able to give very much because of the pandemic. So, I gave it in San Francisco about a month ago, which was very, very cool. Noel: Nice, nice. Is it on YouTube, like easy to find readily available? Harry Roberts: Yeah. Yeah. We can get a link for the show notes for [inaudible 00:04:12]. Noel: Perfect. Awesome. Awesome. Cool. So, yeah, let's talk a little bit about it. I have in the show notes here that you open with noting and talking about cardio centric theory. Can you tell us a little bit about that? Harry Roberts: Yeah, so I mean, this is very indulgent. It's just like for me, I wanted to open the talk with something, a little left field. And one thing that's always interested me is just like, not to a point where anyone could quiz me about it, but like the whole way the brain has learned about itself and all that kind of stuff. And I just started seeing parallels in them, in my client work. Historically humans believed the heart was most important organ. They believed it was like where your knowledge and feelings and where your soul even resided. And for a millennia, it was completely glossed over the fact that the brain is actually hugely important. Harry Roberts: Obviously no one organ is more important than another. But for literally, for thousands of years, humans believed the heart was like the most important thing. So, I just use it as a really cheap segue into parallels with the web. I see it in client work all the time. People just completely gloss over how important the head is and they focus way more on the body. And it's just, honestly, it's a fairly cheap segue to make me sound quasi-intellectual. We talk about ... Yeah. So, I just talk about how humans have always had this fascination with stuff below the head, I suppose. And the parallels in my web dev work are fairly striking. Noel: Nice. Well, we can kind of co-op the fun discarding intellectualism here as a segue here. So, yeah. Tell us about it. Why do devs not think about the head tag and what should they be thinking about in the head tag specifically? Where should we start? What's the biggest problem? Harry Roberts: Yeah. So, I don't think anyone, no one like intentionally doesn't think about it. I think it's as simple as your head tags are the one part of the page that no one ever sees, they're invisible. Unless something's gone drastically wrong, no one ever sees head tags. And therefore it's hard to spot when things go wrong in them. You need to be really forensic in looking for any mistakes or errors. You can soon see if your JavaScript breaks, how your page works, or if an image doesn't load. It's a lot harder to see things in the head, because they are invisible. So, it's not negligence from developers. It's just a very obscure part of the page that because you don't see it, you don't tend to think about it as much. Noel: Yeah. I feel like my impulse there ... Oh, I'm sorry. Go ahead. Harry Roberts: Oh, no, no. Sorry. So, I think the second part of your question is what should they be looking out for. Honestly, so much stuff and I'm sure we'll cover it in the rest of the podcast. But high level things would be stuff that isn't allowed in there. I see that quite a lot. There are certain things that aren't allowed in the head tags. There's some like interesting trivia around that. And also just stuff that could live elsewhere. So, stuff that can go in your head tag, could go elsewhere. It's just about being conservative, keeping them as small as possible, I suppose. Noel: Yeah. So, you noted some like weird, interesting, like trivia surrounding what is, isn't allowed in the head tag. Tell me about that. Harry Roberts: All right. So, the fundamental part, or like the thing with the web is, it's like inherently and infinitely backwards compatible. So, Chrome 104 will still correctly render the first webpage ever made, which is a huge responsibility for browser vendors, like a huge responsibility. But that means that we've got to support a long tail of the web. That also means that old browsers need to be able to manage new things well. So, if someone's stuck on a browser, maybe a corporate machine, they're stuck on like Chrome 70, that still needs to honor new things. So, what makes that very, very interesting is there's a finite list of elements that are legally sort of like us per the spec allowed in your head tags. That list can never change because if the W3 or someone decided, oh, we've got this new element, you can put that in your head tag, any browser that was, or any version that was released before that decision to add a new element, isn't going to handle it properly. Harry Roberts: So, the way it manifests itself currently is people like might put a span or a div or an input in their head. Browsers see that and think, whoa, this isn't allowed here. You're not allowed that in the head tags. So, on the fly, the browser early terminates the head. So, I see it all the time with cross site request forgery tokens, it'll that the input type equals hidden. It'll be in the head tags and any browser that sees that will be like, whoa, you're not allowed an input here. This must be an error. And the browser on the fly, close the head tag early, and it'll push that input and everything after it, into the body tags, which is when you do start to get problems, things do become visible. You do see things get broken. So, yeah, that's why. And this is the real trivia of it. Harry Roberts: The link element. So, link REL equals StyleSheet, link REL equals Preload, link REL equals prerender, link REL equals canonical. That is like, yeah, everyone's got that drawer in their kitchen where you just keep all the miscellaneous crap. You can't think of a place for this place. So, it goes in that one draw, it's like a dumping ground for everything. That's what the link tag has become for the head. Any new functionality that is added to the head tags is added by the link tag. So, link REL equals prerender. Basically we just hang everything off the link tag. Now it's become a dumping ground. So, that's why we've got so many things attached to the link element. Because it's just like a miscellaneous dumping ground for new features we want to add to the head, but we can't do via a new element. Noel: Enjoying the podcast, consider hitting that follow button for even more great episodes. Why is the head, I guess, why is that problem unique to the head tag? Because like we add new tags to the body periodically. There's new tags that didn't exist in old versions, but we don't worry about old browsers not handling those well. Why do we worry more about the tags in the head? Harry Roberts: Do you know what that's a really good question and I'm not entirely sure. I think what it seems like is it's just somehow hard coded somewhere, but browsers should sort of almost throw an error if they encountered something they don't recognize. So, I think there's basically, at some point there was a finite list made of legal elements for the head and that now can't be changed. And I presume that list wasn't ever created for the body. Because of course you're absolutely right. Like if we can add things to the body, if we can create new elements, like picture or source, or we can create whatever. Noel: Yeah. There's like article template tags now, like all kinds of stuff. Yeah. Harry Roberts: Exactly. It stands the reason we should be able to add those to the head. I think it must be a historical legacy thing that we just can't ... It just seem like a bit of a restrictive design, doesn't it? Like to create up finite list and leave it that way. But yeah. Noel: [inaudible 00:10:57] it's always a balance, right? Like it could just be something in the spec where it's like, oh, the body. Like it's in the spec that the body needs to be able ... When rendering the body browsers need to be able to handle unexpected tags. But the head, if it hits something unexpected, it's supposed to throw an error, like it's meta information as it were. Harry Roberts: It could all be. And do you know what I reckon that's going to be homework for me now, to work that out. Because that is a very good question. And I'm amazed no one's asked me that before. Because it's a really seems like quite an obvious question now. No offense. Noel: No, no worries. No worries. Yeah. It's all good. Cool. But yeah, that makes sense to me. So, yeah. I guess that touches on something that you spoke briefly about before, on errors, like being invisible when they're in the head and not really observable at all. Why is that? Because my impulse would be like, well, if there's something breaking in the head, it's going to break something on the page most likely. Like if my font isn't loading or something, it's going to not render correctly. Why are head tags or things happening in the head tag, particularly invisible. Harry Roberts: Okay. So, what I mean by problems is, I mean, specifically from a site speed point of view. So, a missing fal icon, for example, you would notice that in the browser tab. So, there are certain errors in the head you would notice, or yeah. If your Google font isn't loading properly, you will notice that in the body. From a performance point of view, though, it's not until you start interrogating the page like with webpage test or with dev tools, it's not until you do it deliberately that you're going to find errors in the head from a performance point of view. So, in the talk, I hit up on some really obscure things that only affect about eight and a half thousand webpages on the entire internet. The entire internet is only about eight and a half thousand pages actually affected. And that's just like, if you've got a meta tag for your content security policy, anywhere inside the head tags or anywhere in the middle of a head tag, sorry, you're going to get double downloads and you're going to get just loads of problems. Harry Roberts: It's going to slow things down dramatically. I had a client roll out to... most of those 8,000 sites actually were controlled by the same client, they rolled this thing out and they were just terrified. All these sites, this network of sites is just slowed down dramatically. And they were throwing money at hosting solutions. They were like, well, the problem must be CloudFlare. It must be the host. It must be this. It must be that. And they spent thousands maxing out all their sort of hosting accounts. And I was like, well, if you look at it through webpage tests or like a waterfall, you can actually see the problems, not on the server at all. Harry Roberts: And it's one of those, it's easy if you know the answer kind of things. And that's a lot of my work is, it's easy if you know the answer. My client was stressing about hosting kind of things like, is the server slower? They're not beefy enough. And I just ran one waterfall test and I was like, okay, well, your problem is clearly in the head because of X, Y, and Z. And I can see that. But you have to go looking for it deliberately because visibly the site rendered just fine. I mean very, very slowly, but it rendered just fine. So, when I talk about the errors being invisible, I'm talking from a pure Web Perth point of view, and you do need to go and look at it from a different angle. Noel: Yeah. Gotcha. Gotcha. That makes sense. Are there particular tools, I mean, you mentioned like it's one of those kinds of problems where it's easy if you know the answer already, but it can be hard to know what you're looking for, what might be going wrong. Is there, like if devs want to check their own sites for their health in this area, what do you recommend? Harry Roberts: Well, bit a shame of self promotion. I developed a little tool or CSS sort of plugin called CT as in Computed Tomography, like a CAt Scan of CT scan. We'll stick like that in the show notes as well. But all these rules around the head tag are very fiddly and some are a bit counterintuitive and some actually work contrary to each other. Some are a bit not paradoxical. I don't know the word I'm looking for is, but some of these things just seem a bit nonsensical. So, I built a tool called CT where a developer can just drop it in their code base, or can use it as a bookmarklet, if I didn't remember it's bookmarklets. Noel: Nice. Yeah. I do. I remember them. Harry Roberts: It was inspect your heads and it'll say, swap these two lines around, or this bit of JavaScript's blocking this HTML, blah, blah, blah. So, you can do it. I mean, I've built a tool that makes it very, very easy. Noel: Nice. Harry Roberts: Without that tool or before that tool was invented or created, sorry, it was just a very, not laborious. But I've got like, I've been doing this so long. I've got like a sixth sense with waterfall charts. If developers are interested in looking more forensically, I going beyond this tool and looking forensically, I don't have, obviously we're not recording or screen sharing. So, people have to sort of visualize what I'm about to describe. If you're ever debugging Chrome, it's dead easy to see where your head tags are. Because Chrome loads all webpages in two phases. So, if you open dev tools and go to the network panel or you run a webpage test and you're testing in Chrome, you'll see an initial bunch of requests all happening at the exact same time. And that's going to be JavaScript CSS in the head. Then you might see one or two image requests like in a separate batch of work. Harry Roberts: And then the third thing you'll see is a big just boom, a big waterfall of the rest of the body. So, it makes it that easy to proxy where your problems are. You look at a waterfall chart and in Chrome, you can see immediately there's my head tags. It's a few star sheets, a few image, sorry, a few star sheets, a few scripts. Then the body is very visibly separate. Or an even simpler pro tip. Because you can't load images out of the head tags. Because if you put an image tag in the head, it'll throw an error and it'll move into the body. The very first image tag that you see in a waterfall chart is a guarantee that you're in the body. So, everything before that first image request is your head tags. That's the easiest way to proxy it. Noel: Oh, nice. Sure. Yeah. Yeah. And easy to filter and find those in dev tools and you can like pin it and find a baseline from there. Yeah. Awesome. Awesome. So, I guess, we can kind of talk some specifics then there is maybe an interesting way to discuss this. So, we're talking about the way that Chrome is making requests based on how it's parsing the page. Does that behavior inform how we should be structuring data in any way? Like that loading pattern, does that help us decide what should and shouldn't be in the head tags or what order things should be in? Harry Roberts: Oh yeah, yeah. Yeah. Very much. Chrome has got a very meticulous scheduling and queuing logic, I guess. If you look at Safari, it's quite indiscriminate. Safari just is like, boom, just request everything in the HDML. It does it all at the same time. Chrome is a lot more deliberate. Chrome will actually create like a nice little shopping list of things they want. So, any blocking CSS in the head is going to be given the highest priority. Chrome assigns it a priority of highest, which means dedicate a lot of bandwidth to this, request it early, request it fast. The next thing would be blocking or synchronous JavaScript in the head, that gets high priority. Now, as soon as you move that JavaScript out of the head and into the body, it'll get medium priority. So, what that means is if you've got a JavaScript file that is just needed to make one little widget in the page interactive, maybe don't have that in the head. Harry Roberts: Maybe move that into part of the page where the widget is so that it doesn't block the rendering of the whole page. And it also means that Chrome can actually sort of simmer down and sort of relax a bit with how it requests it. And it won't donate bandwidth to a lower priority file that it could have given to a higher priority one. So, you're absolutely right. Yeah. The way we actually construct our pages in general can affect scheduling and queuing and requesting. Safari is like I say, a little more indiscriminate. It will just tend to request everything as fast as it can, which actually seems to work out. Harry Roberts: Because Safari is almost always faster than Chrome. So, Safari has much less logic, but seems to operate a lot quicker. I think Chrome operates more towards or optimizers, sorry, more towards edge cases. Chrome's a far more prevalent browser. Well, Safari is iOS. And iOS is a very privileged, very Western thing. Whereas Chrome heavily, heavily tied to Android. More like to be used in more emerging economies. So, I think Chrome is just more optimizing towards edge cases and making slower geographical regions a lot faster. Noel: Oh, interesting. Interesting. Yeah. Harry Roberts: Whereas Safari can just get away with, well, there's fast devices generally using fast countries, whatever. And they're just a bit less forensic. Noel: Yeah. Yeah. There's less conservative with bandwidth maybe as well. Maybe Chrome is trying to figure out what requests actually need to be made before it makes them stuff like that versus just firing everything off. Yeah. Yeah. That makes sense to me. And it's probably one of those things too, like you said, Chrome seems a little bit more defensive. Like it's the new like Safari's the new IE and they're like, oh, well it's working and everything. But Safari it's probably because they're just trying, optimizing for a much narrower case. Yeah. Emily: Hey, this is Emily. One of the producers for PodRocket. I'm so glad you're enjoying this episode. You probably hear this from lots of other podcasts, but we really do appreciate our listeners. Without you there would be no podcasts. And because of that, it would really help if you could follow us on Apple Podcasts so we can continue to bring you conversations with great devs like Evan You and Rich Harris. In return we'll send you some awesome PodRocket stickers. So, check out the show notes on this episode and follow the link to claim your stickers as a small thanks for following us on Apple Podcasts. All right. Back to the show. Noel: Okay. You mentioned one, like, pulling script tags out of the head when they might not be necessary for a bulk of the logic that's occurring on the site. Are there any other easy wins stuff that maybe doesn't need to be in the head tag that is often included? Harry Roberts: Not much. I mean some third parties that are asynchronous. So, actually if you've got a file in the head, any file that would defer attribute on it, you might as well pull out of the head. Defer by definition. Like the spec says, defer means that this file will run at DOMContentLoad. So, it doesn't matter where in the page the file is it will always run at DOMContentLoad. So, in essence, you might as well stick that near the closing body tag. When it comes to practice, what you'll notice is that even though defer will run always at DOMContentLoad. If you have it in the head, it will get requested marginally earlier than if you put it at the closing body. So, it's not a blanket rule. You'll need to look at your own site and see. Harry Roberts: But yeah, deferred scripts can almost always be moved out of the head because they're always guaranteed to run late anyway. And the other one I often recommend is, it's very specific, but the Facebook tracking stuff, I just recommend, because that's not needed to build the page at all. Most ad blockers are going to block it anyway. So, it's not necessary. It's not required to build the page. Anything like that, either stick it in a tag manager or stick that near the closing body tag. That stuff that doesn't need to be in the head. Noel: Gotcha. Tell me more about how a tag manager can abstractly help with this problem. Harry Roberts: So, a quick prime [inaudible 00:22:32] doesn't know what a tag manager is. Basically as a developer, you'll get asked, oh, can we put analytics on the site? And you can do that. And then the next day it's like, oh, can we put this on the site? And you think, yeah, I'm a little bit busy, but I'll try to have after lunch. And the next day you're asked, oh, can we put the pin trust thing on the site? And as a developer, you're just like, this needs to go in a backlog. I can't just keep having these on the fly requests. As a marketing team, you're going to be thinking, why is it taking so long just to get the Pinterest thing on the side? So, what developers do now is they put a tag manager on there and then the marketing team can go and copy and paste effectively, whatever they like into a tag manager and deploy it via that conduit. Harry Roberts: Now the good thing about tag managers, and I am generally pro tag manager, is that if your tag manager is asynchronous, everything inside is asynchronous by default. So, it moves a lot of stuff off the critical path. The flip side of that is that, and this is tragic, as a developer, you will have linting in your text editor. You've got pre-commit hooks, you'll have local like tests, you'll have end-to-end session and unit tests. You'll have CI, you'll have security auditing. You might be PCI complaint. You might have to have like actual security audits. You've got all of these things, that effectively stop you getting code to live. They stop you getting code to production. You've got your ultimate test. You've got all this stuff that just means that as a developer, you are second guest, every step of the way. With a tag manager, your marketing team could literally go and copy and paste a 15 year old answer from stack overflow, put it straight into production with no QA, no testing, no nothing. Harry Roberts: Here in the UK...it all sounds like a made up story, it's just convenient numbers, but they're a billion pound retailer here in the UK, It's very convenient, It's around 1 billion, but they move about a billion pounds a year. And they took their own site offline by pasting something dodgy into a tag manager. And the first thing is that all the developers were stressing, like what have we done? What did we deploy this morning? What's happened? Has anything changed on prod? What's happened? And so one of the developers eventually worked out, oh no, someone's pasted something that's a tag manager, which just hides the page. So, the site wasn't down, it was just invisible. But tag managers, when used properly, they can abstract a lot of the third party noise off of the critical path and make everything asynchronous kind of by the default. Noel: Yeah. Yeah. I guess I hadn't really considered potential performance improvements via using a tag manager. But I guess if you're not thinking about it otherwise, and it's like, oh, well, if we're in a tag manager, we can kind of lean on whatever, whoever's managing the tag manager developing it to kind of have your best interests at heart and that they want your page to load quickly generally. Harry Roberts: Yeah. Yeah, exactly. One really interesting technique, and I've only seen it as far as I'm aware, I've only seen it once. There's a retailer here in the UK called Shoe and they sell, predictably, they sell shoes. And their old head of eCommerce was a very, very performance focused guy. And he actually, he like instilled this, started this thing of using two tag managers. So, it was one tag manager that goes in the head and only a very small number of people have login details for that one. And that has your analytics, anything that's needed to build the page or needed for business insights needed for stuff. Important stuff that tag manager goes in the head. Harry Roberts: They had a second tag manager, which was in the closing body tag. And in there it'll be stuff like, okay, here's your Facebook retargeting. Here's your Pinterest retargeting. Here's all your stuff that's A, potentially going to be blocked by an ad blocker anyway, B isn't needed to build the page and can happen after the fact. All that stuff can run while someone's browsing whereas actually rendering the page is a blocker to them browsing. So, that's a really smart idea, but it just has the operational overhead of running two tag managers, I suppose. Noel: Yeah. Yeah. Doesn't seem like a terrible idea at all. Nice. So, that's interesting because one of the points you make in your talk is like concerning self-hosting and what URLs are actually being requested. So, how does that play into this equation and why do you make that recommendation? Harry Roberts: So, a lot of the points we're going to talk about are instantly mooted if files are asynchronous. So, Google analytics for example, is asynchronous. So, we can leave that on the Google analytics.com domain with no worries. The problem comes when a file is synchronous and hosted on a third party domain, and there are several different problems that happen or that manifest themselves. The first problem from a performance point of view is that just finding that domain is costly, doing the DNS, TCP, PTLS can be hundreds of milliseconds. I've saved clients, hundreds of milliseconds and then by extension hundreds of thousands of dollars a year, just by self hosting static files like people linking out to code.jquery.com. Don't do it. It's going to cost you hundreds of milliseconds to find that file. If the files versioned, it is by definition, like a static file. Harry Roberts: So, there's no dynamicism ... Whatever. There's no dynamic aspect to it. Exactly. So, you can safely self host that. Other things like if that third party has an outage, you're kind of done for. If you were linking to code.jquery and you've got synchronous jQuery getting called into the head and code.jquery goes down, which I don't know if it has, and I'm not picking on jQuery this could easily happen with Google fonts. It could happen with them. Any Unix based browser is going to have, basically the page is going to be blank for 80 seconds. So, if that third party has an outage Chrome or any browser, sorry, is going to just keep trying to find that file for 80 seconds. It's a OS level thing, a TCP time out, time on Unix is set to 20, 80 seconds. Harry Roberts: On windows it's only 20. But best case scenario, your windows users see a blank page for 20 seconds. That's enough for someone to believe the site is down, potentially go elsewhere. So, yeah, self host all the way. Interesting things are things like Optimizly, which has to be synchronous, because it has to run experiments, but is also dynamic. And you have to go and link out to like cdm.optimizly.com. That's very, very expensive. So, one technique which Casper Mattresses used, this is actually very, very smart. What they do is just every 15 minutes, they would curl the cdn.optimizly.com JavaScript file onto a locally hosted version that they had themselves. And that would save them hundreds of milliseconds, made them hundreds of thousands of dollars a year by having the benefit of the dynamic file, but every 15 minutes or so, just curling it into a file they hosted themselves. So, they've got kind of that hybrid benefit of optimizing these managing the functionality, but they're still getting to self host it. Noel: Right. Yeah. That makes sense. So, I guess, why is it that requesting an external file is so much inherently slower? Harry Roberts: Simply opening TCP connections. So, the web for the most part runs on TCPIP, H3 runs on UDP. So, it's a little different. But fundamentally opening connections to new domains comes at a cost and that's a time cost. So, a DNS lookup is usually pretty fast, but if it's an origin that the browsers never hit before that IP address won't be cached. So, that could be hundreds of milliseconds. TCP could be another couple of hundred, SSL or TLS. I've seen cases recently, a very, very, very, very high profile case. And I've actually been in talked with them about it. Because they're like surprised to see it as well. Right away you can lose on like a three, fast 3G, slow 4G connection. You can easily lose a second for every domain you're trying to hit. So, yeah, that's the performance cost. Noel: Yeah. Yeah. So, let's see. Say your dev and you got head tag and you have all these third party request you making at the top. How do you go about figuring out which of those are safe to pull in? We said like, version things are easy. Is there anything else which may indicate that this should be something would be easy to self host in delivery yourself? Harry Roberts: I think the only thing is static files. So, if it's got a version in there, that's your candidate immediately. The things I see most commonly are also, it's really bad practice. And I wish people would stop doing it. I don't necessarily want anyone to go out of business, but like Unpackaged, for example, UN, PCKG web is unpackaged. Noel: Yeah. Yeah, yeah. Harry Roberts: That method of linking to files is slow by default. It's an anti pattern and I'm not trying to like be mean to anyone. But the fact that site exists is a problem. Because it encourages people to do this. And it's like, well, you are leaving your files in someone else's infrastructure. That's obviously a risk. I mean, imagine if someone just did a denial of service attack against Unpackage, I probably shouldn't say that. Because that might give someone nasty an idea. But like imagine the havoc that would because across the web. Harry Roberts: So, even though sites existing like CDNJS or like js.cloudflare.com or whatever that is, all these services existing in the first place is a huge anti pattern that encourages this, encourages people to do this. I mean the flip side is that if any of those files on those third parties are async, it's all mooted, it's safe. I still wouldn't do it. I'd still self host them. But we're only worried about synchronous files. And basically, yeah, as soon as that's a static file, whether that's jQuery, whether that's Google font, whatever it is, just try and self host them. Noel: Gotcha. I guess as a counterpoint, would it not make sense to like, again, we're talking about the overhead of DNS, like IP lookup, if we could get everything that isn't locally requested from some other domain, does that save us a little bit of time? Like one specific other domain? Harry Roberts: No, not really. So, the problem we've got it is not even just the DNS, TCPA and TLS. There's things like files have these priorities. I mentioned that earlier. So, like Chrome will assign highest priorities to certain files, lowest to others. Within TCP streams, those files can be cross-referenced against each other. So, a server and a browser could coordinate and say, okay, well we've got this shopping list and this TCP stream should dedicate a hundred percent of its bandwidth to this file. And then to this and then to this, and then to this. That could only happen within TCP streams. And TCP streams could only happen on the same IP address. The moment you've got one style sheet on your domain and one style sheet on Google font, those TCP streams can't see each other. So, those files can't be prioritized against one another. Harry Roberts: So, that's another thing we're losing. So, I mean, I'm working with some pretty big clients at the moment, who've got like cdn.client.com and they've got nearly all of their files coming from there. If you're cramming like 90% of your files over a third party domain, that's not as bad. Because you're kind of inverting the problem, aren't you? You're only requesting HTML from yourself. But even still, I would always recommend, I've got a really, really big client at the moment. And their biggest sticking block is, organizationally they're very siloed. So, what they've got is like API.so-and-so.com. They've got static.whatever.com and all these different teams have different sub domains. And you can see it in waterfall charts. So, I did a proof of concept where we collapsed all those domains into one and it's like a second faster, which is a huge, huge number. Huge number. Noel: Yeah. It seems the most like counterintuitive because I guess it makes sense from like the performance like client browser side, but I understand organizationally why big teams end up doing this. Like API, CDN and all these things. And I feel like that's pretty common. So, is there any other, anything changing here? Is there any other end game or is it always, is it eventually going to be, you have to start hosting everything from the domain that the browser is sitting on or is there anything else that can be done? Harry Roberts: So, yeah, the client I'm talking about at the moment I said to them, look, I know you're never going to do this. You need a reorg. And it's one of the biggest organizations in the UK. And it's like, I know this is never going to happen. So, it's a recommendation, but the actual technical aspect is the least of it. It's like the way your organization works is not going to ... So, for them, there is no end game. Other than computing at the edge. So, the proof of concept I made for them was using an edge worker with CloudFlare. Harry Roberts: And you can just proxy files to a different origin. And what is wild is even the overhead of proxy files through a different origin, the overhead of doing that was less than actually serving the file from different origins. So, the proof concept I sort of said to them, look, this has an overhead of rooting these files through another domain, but even rooting those files through that domain is faster than requesting from five different ones. So, you could fix the problem at the edge with a CloudFlare worker or any kind of edge compute kind of thing. Noel: That's interesting. So, how in, again, I don't want to like get too in the weeds here. But in this scenario where there was all these specific subdomains that were being requested before, and then you were like flattening them in a worker to make all those requests go out. How did you determine in the worker, which subdomain the actual resource lived at? Harry Roberts: It was a pretty manual process. I can't remember exactly what the code was. It was a while ago. It's a boiler plate. But you have to basically pass in a certain request header for how I did it. So, to override a host. So, you have passing an ex hosts thing and any request that has the ex hosts header, you just then map that to a hard coded alternative domain. So, that proof of concept was only a proof of concept. It was very hard coded. Noel: Yeah. But I guess yeah. Feasible. You could add some JavaScript to the front end, that makes all those requests go to whatever domain you actually want them to be going to. And then it's uses another header to direct your worker to tell it where to go. Harry Roberts: Yeah, exactly. Noel: Yeah. Yeah. Interesting. Very cool. Very cool. Yeah. We have had really good luck on a smattering of projects like using edge workers and it's insane how fast, CloudFlare specifically, end workers are. They're so good. Harry Roberts: Yeah. They've opened up a lot of opportunities for me with clients. So, when I tend to work with clients, I don't work with clients very long, to be honest. It'll be only a couple of weeks at a time. And I never get given right. I deploy access. It would take longer to get me set up with local environments than it would to actually do the audit. So, cloud flow outline workers in general, give me a really good opportunity to show them proof of concepts. Like I haven't deployed this, I've done this with an edge worker. I've rooted it through my own CSS wizard, dev domain. But here's what it would look like in theory, if you had to do it yourself. So, edge workers are really good proof of concepts for me to demo things to clients. Noel: Yeah, totally. Yeah. Yeah. We have, it's like permanent solutions in there and we also have like little, it's easy for quick proof of concept spin up stuff. And again, it's like pretty performance. So, you can get pretty close to what we actually see in prod if we had a deployment out. So, yeah. We've had similar. Harry Roberts: Yeah. Great online- Noel: Similar experiences. Yeah. So, I think kind of the last big point I've gotten here in my notes concerning the content of the head tag itself and like where requests are going is the order of things in the head tag or a couple points concerning the order of things. Can you tell us a little bit about that? Why does order matter? What can and can't we do in certain order in the head tags? Harry Roberts: Yeah. So, like I say, anything that's asynchronous is removed from the equation. So, we won't discuss anything asynchronous, because it doesn't block anyway. But there's certain fundamental things about how all browsers work, that a lot of developers simply aren't aware of. Which is not their fault. Just simply no one's told them. The biggest shocker that I tend to see, although the thing that shocks developers the most, CSS blocks JavaScript execution. If you put your style sheets first, none of your CSS are going to, none of your JavaScript is going to run until CSS is fully parsed. And that terrifies a lot of developers because they think, well, CSS is like render blocking and it should go first. Well that CSS is going to block the execution of any subsequent JavaScript. And that can have profound effects. Like in the worst case scenarios, I've seen clients like lose nearly a second because their CSS is blocking their JavaScripts. Harry Roberts: The reason it does this is very simple. The JavaScript could ask a CSS question. It could say like get compute style. What's the color of the background of the body? Thing is the browsers know, if that JavaScript is going to ask a CSS question until after it's executed the JavaScript. There's no preparse, there's no kind of look ahead. So, what the browser will defensively do is if it knows it's currently downloading any CSS, it will not run the JavaScript until it's downloaded and parsed that CSS just on the off chance that the JavaScript asks a CSS question. Nine times out 10, especially in the head, it will not be asking a CSS question because the body's not rendered yet. See, there's nothing to get compute style of. So, nine times out of 10, JavaScripts in the head is not going to be asking CSS questions. But even still browsers will not run that JavaScript until the CSS has been dealt with. The way this affect developers in the real world is usually with analytics packages. Harry Roberts: What you'll find is that there'll be inline sort of async snippets, synchronous JavaScript, but create asynchronous injected files. They won't run until the CSS is finished. So, they'll find that their AB testing tool, or their tag manager, or their analytics doesn't fire until quite late, which is all being blocked by the CSS that's in flight. So, that's one thing. That's one really important thing with the order of the head tags is that yeah, your CSS will block your JavaScript from running, which can be very detrimental. Harry Roberts: And there's other simpler stuff like character encodings for example. HTML is parsed line by line. So, the browser can only deal with things as it finds them. Most browsers are going to be UTF-8, but you might have a page that's UTF-16. If you put your character in coding, halfway down the head tag, what the browser will do is it will start parsing the page in the browser saying, which is probably UTF-8, then it'll find the UTF-16 character coding halfway down the head. It'll be like, oh, [inaudible 00:41:26]. Brilliant, got to start again now. And it'll reparse the page. So, basically it'll have to parse everything previously again. So, all things like that are important for in the terms of source order. Noel: Nice. Nice. Does the CT scan tool you put together, look for these kinds of things like ordering. Harry Roberts: Yes. So, it looks for order. And it also looks for things like, it's very crude, but it's like CT, it's written CSS, which is the most inappropriate syntax for this kind of work. Honestly, it's so unfit of a purpose. My background is CSS and I just wanted to kind of mess around and do things fun. It's very crude. But part of what CT will do is it will use like an nth child selector. And it will say if it finds a meta character encoding or a meta CSP that isn't nth child five or less, basically it'll just check, was this meta tag more than the fifth child? If so, throw a warning. So, it will say as like, if you've got 10 elements in the head before you've got your character encoding, CT will notice that and say, move this as early as you can in your head tags. Noel: Gotcha. Nice. Is this, is the CT, is it usable? Can I put it in the middle of a linting or a CI process somewhere? Harry Roberts: I mean, you could, but it wouldn't be much used to you because it's just a visible thing. Because it is just written in CSS. All it will do is throw a red box around an element that is faulty. So, it wouldn't be any use. I mean, you could put it in CI, but it would be of no use to, because you have to look at it basically you have to have eyeballs on it. Noel: Sure. Yeah. That makes sense. All right. Then I kind of have one last kind of in the weeds question here that is concerning this, I guess this whole idea. So, we're kind of talking about all these things to be aware of and difficulties and how to structure head tags, where to put things and stuff. And I'll say just kind of anecdotally, I feel like over the past several years I've been having to do less and less mindful structuring, putting data in my head tag at all, because I feel like my tools, like my bundler and then even web pack and everything. My build pipeline is doing a lot of that lifting for me. Do you think that this problem is becoming less of one over time as our build tooling becomes better? Or do you think that there are still pits we're falling into? Harry Roberts: No, you're good. That's a very good question. This gives me an opportunity to show off. A lot of those tools are getting it wrong. One of the biggest, biggest, biggest front end frameworks, I'm not going to name them, because that would be rude. But one of the biggest ones was getting it quite dramatically wrong. And the co-founder's a really nice guy and I dropped him a message on Twitter. Like, hey, do you want to work together on this? Get it fixed. And he is very receptive and I just built some proof of concept. And I said, look, this is how your framework's currently doing things suboptimal, would you mind discussing it? And he was very receptive. So, now that framework is now doing things much, much better. I got a lot of pushback from other people on his team and he was great. Harry Roberts: He was like, yeah, you've proved it to me. He had a complete lack of ego about it. He was great. But then were working alongside other third parties who were like a little more suspicious. So, it was a little harder to get through. But now current versions, newer versions of this are getting it way better. But certain things are still getting it wrong. And you know what, it's not even new tools. It's older tools. Like if you look at things like Magento, you get so little access to the head tags, Droop or whatever. Older tools get it wrong as well. So, it's quite unfortunate. Sometimes I'll work with clients. I'm like, oh, just change these around. It's like, yeah, we can't, we don't have access to that. Harry Roberts: And that's really annoying. And it kind of in a weird way sort of proves my point. People are just generally unaware of how important their head tags are to the point where people who build CMSs or build frameworks, they sort of set off on the wrong foot from the outset. So, part of what I've done in the last couple of years is I've reached out to different frameworks and tools and generally people are really receptive and it's everyone wants to push the web forward. So, I've not had any pushback. Noel: Nice. Nice, good. That's good to hear. So, it sounds like still something to be aware of, even if you're using the latest and greatest frameworks build tooling and everything. Still be mindful. Cool. Cool. Well, I feel like that's as good a note to wrap this up on as any. Is there anything else you want to point listeners to, projects you're working on? Harry Roberts: Tell you what we can, if you don't mind, we could give listeners a discount code because I've just ... We'll work together and get like a specific discount code for this podcast, I guess. Noel: Yeah, I think we can do that. Yeah, sure. Harry Roberts: Basically a couple of weeks ago I released the new video course. One of my favorite is bits of workshops that I run and the bit that ... Well, it's a bit that I enjoy a lot, but attendees seem to love. It is like secret and hidden bits of dev tools for performance testing. Chrome specifically is the most powerful, fully featured set of developer tools for performance like hands down. But a lot of the features are just under or even unexplained. So, I made a video course a few weeks ago, which I had a ton of fun putting together it's like 12 videos long and it just goes into like, look at all these cool, hidden tips and tricks and features that you didn't know existed. So, that's been my current side project. My main side projects at the moment are riding bikes. Because it's nice and sunny. So, I'm not really ... Noel: I see your bike in the background. Harry Roberts: But only side project really for personal stuff, non-client stuff has been this video course. So, we'll get a little discount code together for listeners and see if people want to have a look at it, they're more than welcome to go and grab a copy. Noel: Cool. Well, thank you so much for coming out and chatting with me here. It's been a pleasure. Thank you for kind of letting me get in the weeds a little bit and pick your brain. It's been awesome. Harry Roberts: No, it's been great. And I don't want to sound patronizing or anything, but you have had some very good questions there stuff I'd not considered before. So, yeah. No, thank you for that. I really enjoyed it. Noel: Oh, of course. Of course. Yeah. Again, it was my pleasure. So, yeah. Thank you so much. And hopefully we can chat again soon and have you back on. Harry Roberts: Yeah, that'd be great. I'll be down for that. Noel: Cool. Harry Roberts: Yeah. Thanks for your time. Noel: Take it easy. Speaker 4: Thanks for listening to PodRocket. You can find us at PodRocket Pod on Twitter, and don't forget to subscribe, rate and review on Apple Podcasts. Thanks.