 A topic that's come up a lot recently is server-side rendering. Yeah. And it's a hot topic. Hot topic, lots of nuance, lots of opinions around it. Yeah, lots of feelings. What is server-side rendering? In a nutshell, server-side rendering is, and this is particularly important for JavaScript-heavy client-side apps, you take your application and you think of it almost like you pre-boot it up on the server. So you stamp out all the DOM nodes, you get everything kind of in place. You have your CSS in place, so it paints really fast and you send all that down to the client and you get a really nice, fast first paint, right? Because everything's just already there in the document. But it comes with a cost, right? If you're server-side rendering something, it's going to potentially improve a few metrics, like potentially first paint, first meaningful paint, first contentful paint. How quickly people get text on the screen. But it also comes at the cost of you shipping down a much larger payload of HTML to your users. And that can have the impact of pushing out everything else, including your JavaScript. So you get this really fast first paint, showing people something on the screen. You can see it, but then you can't necessarily interact with it. It's like, you end up on a shopping page, it renders really quickly, and then you start tapping on buttons. And unless everything is end-to-end server-side rendered, the user might have bits of the experience that are not necessarily complete or ready. And I've experienced this recently. I was driving through the woods and was on a way slower mobile connection than I usually am. And yeah, I landed on a page and I knew it was server rendered because I was like, I can't click on any of this and I know exactly why. And it can be frustrating. It can be. I mean, for different, you know, verticals, maybe server-side rendering makes sense. You know, if I'm a publisher, I might care more, like really heavily about making sure that the article text can be seen pretty early on. But people use server-side rendering for lots of different reasons. So some people use it to optimize those metrics. Other people will do it because they're trying to make sure that Googlebot and search crawlers can see their content. Especially because not all crawlers can run JavaScript. Yeah, so we've said, Google have said that, you know, the crawler can understand JavaScript to some extent. And that's great in everything. What I recommend if folks are unsure is to go check out the Webmaster Tools. There's like a little tool there, right? Fetch as Google. Fetch as Google. It lets you render your page the same way that the Googlebot would. And we now know that that's powered by Chrome 41. Yeah. We've got some docs on that now. You can leave them down in the show notes. Link them up in the magic boxes. And that's great. But you should check that out, see if it's actually busted in any way, you know, before. It can be surprising because you're like, oh, it runs JavaScript. So I'm just going to assume it runs like latest JavaScript. And that is not always the case. No, Chrome 41 came out a while back, right? It's probably old enough to drive. And so there are definitely times when, you know, I forget to include polyfills for search crawlers that you sometimes need to, you know, even polyfill things like promises depending on the crawler. So people should just be careful, right? I think actually in the article you mentioned, there are even some debugging tips because you do fetch as Google and you might just see like a blank page and it's hard to know then, OK, well, what's missing, right? Is my application actually broken or like you're saying, am I missing a polyfill? And so there are some tips in there how you can kind of debug that and figure out, you know, which is it. I've totally been bitten by this before. I was missing a web animations polyfill once and I was just like, I guess like this whole thing's just broken and I was able to debug it. And I was like, oh, I just need to include this one fine. It may not be quite as complex and broken as folks think. There are some possible ideals. I know that, you know, when some people are thinking about building mobile websites, progressive web apps, you know, we'll tell them that the architecture pattern of choice is the application shell because you can easily cache pieces of your UI that don't need to be fetched from the network on repeat visits, improves your performance and so on. But then they're like, well, yeah, but I kind of need to server-side render my content too because I may be tested and server-side rendering is improving my SEO and it's supposed to get a little bit complicated. I mean, one possible balance you could find there is use your architecture of choice, for your performance architecture of choice for your normal users and then conditionally serve the server-side rendered version to, you know, Googlebot or other search crawlers. Yeah, do a little UA sniffing maybe. I didn't say that. Yeah, I didn't say that. Well, I actually didn't say that. It's OK, Matt said that. Matt said that. So folks should be, you know, there's a lot of nuance to this problem. We're not talking about it in terms of performance. I know that everyone's going to have different things that they care about. Just be, you know, take a holistic look at server-side rendering and where, you know, where they're trade-offs, where, you know, maybe just using it for SEO over other things might make sense. And just, you know, use your tools. Exactly, yeah. Tools, tools not rules, right? Tools not rules. That's what the smart kids say, yeah. No, is there a sign-off of some sort you have for this episode? It's totally time for the end of the episode now. Thanks for watching. Totally tool and tips.