DejaVue

The very first episode of DejaVue is here! In this episode, Michael and Alex talk about Server-Side Rendering (SSR) and its benefits, use cases, and challenges. After understanding what SSR actually is and why it could be useful, rendering modes like Static Site Generation (SSG) and Incremental Static Regeneration (ISR) are discussed, as well as compared to dynamic SSR. The episode closes with a summary of the discussed topics and a brief outlook.

Chapters
  • (00:00) - Intro
  • (00:50) - What is Server-Side Rendering (SSR)
  • (05:44) - When would you recommend using SSR
  • (08:46) - Performance benefits with SSR and Hydration
  • (14:39) - Complexity with Server-Side Rendering
  • (17:21) - Static Site Generation (SSG) vs. SSR
  • (27:53) - Incremental Static Regeneration (ISR)
  • (34:11) - Summary


Links and Resources

Creators & Guests

Host
Alexander Lichter
Web Engineering Consultant • Founder • Nuxt team • Speaker
Host
Michael Thiessen
Full-time Vue educator
Editor
Niki Brandner
Sound Engineer

What is DejaVue?

Welcome to DejaVue, the Vue podcast you didn't know you needed until now! Join Michael Thiessen and Alexander Lichter on a thrilling journey through the world of Vue and Nuxt.

Get ready for weekly episodes packed with insights, updates, and deep dives into everything Vue-related. From component libraries to best practices, and beyond, they've got you covered.

Michael:

Welcome to Deja View.

Alex:

Your favorite Vue podcast, you just don't know it yet. And here with me on the microphone is Michael.

Michael:

I am a full time VUE educator and produce lots of content, newsletters, things like that, including this podcast, which I record with Alex.

Alex:

Exactly. And I'm part of the Nuxt core team. I'm also creating quite some content on YouTube stream every now and then Twitch, and I am a web engineering consultant by day. And today, we talk about a topic that might be interesting for most of you, which is server side rendering. What is it?

Alex:

Do you need it? Why would you use it? And what are all these other weird acronyms in that space?

Michael:

Yeah. So let's start with what is server side rendering to begin with, just so that we can start off on the same page. And some of you may not know what it is or the exact specifics. So what would your definition of server side rendering be?

Alex:

Well, I mean, we could go all the way back and say, oh, yeah. My old PHP application is server side rendered because, oh, there's a PHP server and it renders the HTML. But if we are in the JavaScript ecosystem and if we talk about single page applications, then server set rendering means rendering your single page application on the server, mostly a node server, on the initial request. That's very important. So only if you, like, hard reload the page or if you click from an external source, like from Google, then your site will be server rendered.

Alex:

And ideally afterwards, it would just behave as a plain old single page application as before.

Michael:

Yeah. It's interesting to think about historically that websites are have almost always been server side rendered. Like if you go back to the nineties, we, I mean, we had JavaScript back then, but we weren't really building single page apps that just lived in the browser. We were always hitting the server with with every single request, button click, that kind of a thing.

Alex:

Yeah. Absolutely. I mean, then Ajax came and said like, hey, JavaScript can do a bit more here and there, but we're still in a way, we're still torn. It was like, oh, yeah, the server still renders things and we can load more. And there was XML and then finally some good thing like JSON so we can send data.

Alex:

And, yeah, eventually, SPAs were born by saying, why can't we do all of the things in in the in the browser, in the front end, and, like, use the back end more as an API?

Michael:

Yeah. And the this pendulum almost swings back and forth, it seems, between single page apps are the hottest thing. And then, no, they're they're terrible for performance. They've got all these issues. Let's surrender everything on the server.

Michael:

And then, you know, after a couple of years, people are like, wait, but we can do so much more with single page apps. So let's, you know, the the pendulum swings back the other direction. And it almost seems like a bit of, whiplash we've gotten in the web development community here.

Alex:

Yeah. It's true. But I think we can't do without both. Like, ideally, in the future, we have something where the server and the client, they work together hand in hand. We embrace the web standards.

Alex:

And I like to see some moves, for example, what Remix is doing. With, like, okay, we basically have a single page application, but we progressively enhance it. Even with our JavaScripts, you can still send forms. So that's that's super interesting to see. And also what React is doing with server components and what Nuxt server components are doing to say, like, we reduce the amount of JavaScript we need to render some stuff.

Alex:

And, from from there, we can improve performance wise, but also still keep the same mental model of the same framework, not the same code we write.

Michael:

And I like what Nuxt does with the hybrid approach where we try and take the the best of both worlds of server side rendering and, and single page apps and, and basically stay right in the middle to, I mean, you could argue with it's leaning one, one direction or the other, but where we use server side rendering on that first request. And then after that we can bootstrap into a single page app and get the benefits there. So I think that's a pretty neat way to to sort of blend the 2. But yeah, what are what are your thoughts on that?

Alex:

I also think it's really helpful, but, of course, it introduces some more problems, let's say. You have more complexity because you always have to think, oh, what if this is rendered on a server? And for me, like, I remember back in 2017, maybe 2018, something like that, must be 17, when I first got in touch with Nox, I was like, okay. Surface that rendering, super helpful because back then I had a project with public facing. And as we all know, single page applications, well, they don't render HTML, straightaway.

Alex:

The JavaScript generates it, and that's not so nice for search engines. So I thought, okay, server side rendering will solve all my problems. And this, but it introduced some more. Like, okay, when does that server rendering actually happen? Is it every request?

Alex:

And as just mentioned, it's just the initial one, but it's something you it's another concept to understand.

Michael:

So when would you recommend that someone uses server side rendering in their application? So maybe, I guess the the more standard approach of building Vue applications has been, before Nuxt became as popular as it is now, the standard was to build these Vue, single page applications. And the, the one place that I worked at, we actually used Ruby on rails, which is a server side rendered framework, But it actually bootstrapped itself into this, single page app where, you know, that initial page render was done with Ruby on Rails, but then now we've got, a view single page app that's running. What would you say are the reasons you you would want to switch to server side rendering or how how would you think about that? Because you did mention there are some tricks or catches there with with server side rendering.

Alex:

Yes, absolutely. So if you use Vue more or less as progressive enhancement of like, okay, I want to do some interactivity but I don't render my full front end in it, then switching to server side rendering is almost impossible. I know there were some projects saying, oh, yeah, maybe we can do the V eight engine and PHP and whatnot, but it never really took off. And in that case, yeah, render your page in Rails or in Laravel or Django or whatever, and then use Vue on top of it. It's totally fine.

Alex:

But as soon as you have the whole front end under the control of Vue, then it really makes sense thinking about server side rendering when you need search engine optimization. So if it's like a public page you wanna share and when it's performance critical. So typically any kind of landing page, any kind of ecommerce, that's always a very tricky area because lots of things to show, has to be very, like, recent updated data. And it's like the classic example where where service that rendering helps. But even for your blog or portfolio page, you just wanna, like, put out there, then service that rendering makes sense.

Alex:

But now that I think about it, 1 like, we can even go the other way around. We're saying if your application is behind authentication, then we don't really need server side learning at all because no search engine will ever hit that, and, well, people have to log in anyway and to wait a little bit. So that's that's not a big of a deal. So as long as it's not public facing, no serverlessed rendering is needed. And it's also important to mention that you don't have to turn on the switch or turn it off for service thread rendering for your application.

Alex:

You can also say, oh, hey. I have, routes, let's say, /admin, and everything starting with /admin should not be server rendered because it's, well, the admin area. But, hey, my blog page should be server rendered. So you can also, make sure that you have a nice fine grained structure saying, okay, that part should be server and not and that part should.

Michael:

But even if you had, for example, this admin section that's behind authentication, wouldn't you still get some performance benefits from, from having it server side rendered? I guess it would depend on what exactly that that page is rendering.

Alex:

Yeah. So you would definitely have a better perceived performance because what's what happens in detail during service that are rendering is, okay, you send a request and the server returns the HTML. So you see straight away, okay, this is what the page will show. It also ideally includes some inline CSS, so actually have have the styles too. And then the JavaScript is also sent, but that will be downloaded, executed, parsed, and then view Nox will boot up and basically go through the send HTML and more or less convert it over to, like, Vue's representation to their to to Vue's own VDOM representation.

Alex:

And then for interactivity, attach some listeners. And that whole process from, okay, I see the HTML, but right now it's not interactive because there are no listeners and view is not up yet, until the point where it's up, that's called hydration, very important process. And it's a little bit intensive, especially CPU intensive, if you have a, like, a big page or, like, very complex components. And while the perceived performance could be better for people saying, oh, yeah. I see the page, you might have the problem that they wanna click something, but they can't because the listener isn't there yet.

Alex:

And there are also ways to improve that, but I I think that's something to keep in mind. They could improve performance with SSR, but then you have to make sure that the hydration cost is low, that you can ideally delay that or say, hey. These parts shouldn't be hydrated and so on and so on. Right.

Michael:

And which is why Nuxt has that hybrid mode where it switches between the

Alex:

2. Yeah, exactly. And you can even go further. There are ways to delay the hydration, to say, okay, as soon as I interact or scroll, then I want to actually do hydration so I have a better first. Like, the first page load is faster.

Alex:

You get a faster. Largest count of full paint It's one of the metrics that's relevant there.

Michael:

Right.

Alex:

But then you have to be very careful because there's another metric called interaction to next paint, which is a core web vital, same to LCP. And that basically says, oh, if you click something, how long does it take until the UI shows something? And if you say, hey. On click, I I want to do the whole, like, CPU intensive hydration part, it might reduce the value there causing troubles also because your your users, okay. Click.

Alex:

And I wait. Maybe on your, I don't know, MacBook M2, like, with all the fancy devs having that, it's like no problem. But if you're on a mobile device or maybe it's also an older device with German cell phone reception and mobile data, which means it's not that nice, then it might take longer. And people are like, oh, I clicked. When does nothing happen?

Alex:

I click again, and maybe people are frustrated and don't know what's going on.

Michael:

That's an interesting point to bring up with single page apps versus server side rendering, where you have control over the server and how fast it is. You don't have control over the network speed, And you also certainly don't have control over your users' devices, whether they're on, like, you know, my, my phone, which I still have, an old iPhone 6 S, which is like, I don't know, 8 years old now. And certain websites are very, very slow because probably the dev was like, whatever it's fast on my machine. And so the single page app on that case, you're offloading more of the processing and those things to the end user's device versus on the, on the server. So, yeah, that's an interesting trade off to consider.

Alex:

Absolutely. And the the problem is if you have that hydration part, in Vue, especially, what Vue is doing is is doing the same thing on the server, but again, because you want to get to the point where the client is in the same state as the server. So the client will get some values from the server but also has to build up all the components again. And, other frameworks, like, for example, there's QUIC. That's the experience with free zoomability, and there are also lots lots of lots of other ways of dealing with hydration or saying, hey.

Alex:

I use island architecture, which, for example, Iris or Astro is doing, saying, okay. There are parts that are not really necessary to hydrate, and other things that should be interactive. I want to hydrate them and not all aesthetic content. That's something I'm very interested in, especially in the view space to see where this is going.

Michael:

Yeah. Some of these frameworks are have some really interesting approaches with how they very yeah. Incrementally, like progressive progressively do that without having to load a whole bunch of of stuff. It's just like on demand, which is it kinda it kinda breaks my brain to think about because it's a totally new way of thinking about these things.

Alex:

And it once again brings other complexity. Like, oh, yeah. If you don't have to do the whole like, if you don't have to replay or do the same things on the client as on the server, and let's say you send a console log on the server and think why doesn't that appear on a client, you also have to teach developers these concepts. So, the the problem is not only, like, okay, hydration is kind of solved, let's say, but how you actually teach people how that works or make a nice abstraction around that is yet another issue to be solved.

Michael:

Yeah. And it's one of the the trickiest parts of using Nuxt that I've found is that server side rendering introduces these different complexities because you're running it once on the server, but you're not running it exactly the same as it would run on the client. And so if you're used to just like client side, single page apps, then you have to shift your thinking quite a bit to be like, okay, it's gonna generate this payload and I want things to sync up properly. This part, you know, certain life cycle hooks are not run on the server even. Yeah.

Michael:

And why am I getting this weird bug? Because, oh, it did something on the server, but it's not doing it on the client. And then, you know, there's, I, I find most of the bugs and weird things that I come across for my, like, when I'm writing my own code is, has to do with that. Maybe because I'm like already comfortable with the view specific side of things and I'm still, you know, my brain is still taking a bit to, to get around to the, to the next way of doing things.

Alex:

I think it's very common. And just a a quick mention here, you can even run your own service that running setup with something like Vyke, which was previously Vue plug in no. Sorry. Vite plug in SSR, or even roll it fully on your own, or you can even use Quasar, which also supports it. But in the most common scenarios, yeah, if you use SSR in Vue, then you rather don't want to roll your own because it's painful, and you have to deal with all the issues that, well, NAC is already solving for you, let's say.

Alex:

So so that's that's one thing. And the other issue, yeah, of course, the the complexity, especially with, okay, which data has to go from the server to the client? How can I mark the data so it goes over there? Mhmm. Or, like, what are these weird hydration errors, which are always coming up?

Alex:

Yeah. And I I know it can be it can be tricky because you go for, oh, yeah. I'm doing everything in the client. It's fine. A little bit of window here, a little bit of document, doc query selector here.

Alex:

Please don't. But, oh, I use this chart library here. No problem. Yeah. On the server.

Alex:

It isn't that easy because there's none of that there, no window, no document.

Michael:

Mhmm.

Alex:

And that's something definitely worth dealing with and understanding. Like, not into every tiny detail is fine, But having that idea how the process of server side rendering, what we just talked about, works, that it's only for initial request and that's yeah. The complexity shouldn't be underestimated.

Michael:

So another similar term is SSG. So we've got SSR, we've got SPA, and we also have SSG. And I I have been confused about these terms, especially because they're kind of used interchangeably almost it seems. Yeah. And the and their the acronyms are so, so close together.

Michael:

And I've also seen other people, confused about like, what what is the difference? What do these things mean? Why, you know, if I run NUCs generate, why, why is it doing this and not, not this other thing? And so, yeah, let let's explain what that acronym is and what what it means.

Alex:

Yes. That's a great idea. Maybe maybe let's turn it around this time. Maybe let's yeah. Let me maybe you go for it, explain it.

Alex:

And if I have anything to add, then I'll I'll come after you.

Michael:

Sure. So SSG is, static site generation. Is that what it stands for?

Alex:

Absolutely.

Michael:

Good. I I was gonna say server side generation, which wouldn't be completely wrong. But

Alex:

Well, it's it's close to that, actually. Maybe that would confuse less people. But, yeah, anyway

Michael:

Yeah. And so so there's a difference between a server side rendered application where it's being, it's still being rendered dynamically every time you hit that, that page. Whereas a static site is exactly that it's static. It's not dynamic. This is for things like blogs or other, you know, documentation sites, things like that, where the content doesn't change or need to be dynamically generated based on different requests.

Michael:

And so we can actually generate this ahead of time. Another word that's often used is pre rendered. Maybe that's why there's it adds to the confusion because there's so many different Yep. Terms that describe these very similar concepts. And so, yeah, there's this distinction between, do you need to generate it dynamically?

Michael:

If yes, you have you know, are you generating it on the server or on the client? If it's not dynamic, you can do it statically. And then you're gonna do it on the server in some way. And there's, again, many ways of doing this. You can do it, at build time.

Michael:

You can build all all your pages or render all the pages ahead of time, which is what I do for my blog because

Alex:

Same.

Michael:

That that it's straightforward and it works. But you can also do different kinds of of building where you incrementally build it over time, and, yeah, that it gets complex.

Alex:

Oh, exactly. Exactly. But, yeah, I think that's a very good summary of static's high generation, also known as prerendering, because these these two things are exactly the same. What I like to say about it is always think of, as you said, server side rendering, but not on the fly, not dynamically because it's the static side. So server set's rendering at at build time, like, as you said, ahead of time before it's it goes to the server.

Alex:

The good part is you get out static assets so you can host them everywhere. Very lovely. You don't need any kind of API connection unless you call APIs on the client side. Like, oh, yeah. I you can submit a comment, then that should go into the database.

Alex:

You need that. But if it's just about content that you, for example, grab from a CMS, then you don't need an API connection because what Nuxt will do in this case, it will take all the requests and it will create the payload and save that as well. So some kind of JSON that's a bit compressed and will put in all the data there so you don't need to do the API call, again somewhere. Because it would also be weird, like, okay, you have the data. Actually, it was like that in in Nuxt 2, like, years ago for a while.

Alex:

Like, it was like, okay. You got the data. And then when you do a client side request to another page, it will fetch the API again. And if you refresh the page, the data the content might be different. But, yeah, luckily, we got over that.

Alex:

And there was, like, a full static mode back then, and this is also the default, now when you use Nuxt 3 with with MPX, Nuxt generate.

Michael:

Right.

Alex:

And it's super useful for applications. And even if you say I want to steadily generate a site but turn off server side rendering and you just generate one route, then you have your single page application again because that's just an empty HTML file, maybe for loading spinner, adding your JavaScript and your CSS in there, and you're back to the plain old SPA, which is why you can you can use frameworks like Nox to build all kinds of applications and you can switch that by just a few things in the config.

Michael:

Yeah. And so you you have a lot of flexibility with exactly how things get rendered and run and, and all of that. How would, how would you define like, the the benefits of static versus server side rendering?

Alex:

Yeah. I think, as I mentioned, that you can host it everywhere is a big plus. You don't need the server running all the time, and it's the faster it gets because there's no API call. There's there's nothing. Nothing is faster than just plain HTML.

Michael:

Sending the files.

Alex:

Yes. Exactly. That's a big pro. Just put it in a CDN, cache it, and you're good. It's, of course, tricky if you need new data because then you have to rebuild the whole site usually.

Alex:

So if you have to change things every couple minutes, then static site generation might not be for you, Unless, also, there, there are options to say, hey. Please prerender only these pages, and then it's fine. Fine. So if you have landing pages and they won't necessarily change, you can prerender them, but still have the server running for the rest.

Michael:

For for my own website, I have the blog side of things all prerendered in that way because they don't really change. You know, I occasionally update them, but then I push those changes and then the build happens again and then the whole site's rebuilt. But that doesn't happen that frequently. But then I have the other part, my my course platform side, which is interesting because it's technically just static content. It's like a a blog, but it has authentication around it.

Michael:

So it's harder to do statically and have that authentication. And so then the way that I've I've set it up is the blog side is pre rendered for, for speed and, and all that. And then the other side, the, the core platform side is just SSR, just the default.

Alex:

Oh, so you use hosted rendering with something behind authentication there. Yeah. Interesting. I think you could even say for that part, you turn off SSR. Yeah.

Alex:

Then you you might lose a tiny bit of perceived performance, but then people would just be faster to log in form, I suppose, or a bit slower to log in form. And then you can even use that because that's also one important thing to mention. Even if you do authentication on the server side, everything that's in the front end, like every component, every view page you write is technically visible and human readable. Yeah. Just go through the through the JavaScript files.

Alex:

So if your content I I mean, I assume it does, but for for all the listeners as well, if if your content doesn't come from an API, people can just read it. And it's most important that it comes from an API and is secured if you don't want certain users to see it because then people really need to be logged in, authenticated to get actually access to that.

Michael:

Yeah. I have I have considered, well, yeah, to your point about the the single page app thing, I I want to do some testing with that to to see if that's better or or worse or or what. There's also a way that you could have it pre rendered, but then if you built a custom server to serve those pre rendered files, and then that server has the authentication built in, then instead of just like giving it free access, then you sort of get like the best of both worlds. But I think that's a little more complex and I'm not really interested in going down that route at this point.

Alex:

Yeah. I I also think you don't gain that that much from that because I think the added setup would be a bit more complex for sure. But usually, when it comes to authentication, then you you have to use cookies then. Right? Because if you need authentication during server side rendering on the server side, no local storage.

Alex:

So there's there's that only way going for cookies, which is reasonable. And, of course, it like, you could reduce the complexity by just saying, hey. Okay. It's it's an SPI. It's fine.

Alex:

And if people, let's say, bought access anyway, they probably don't don't bother with, I don't know, half a second more perceived loading time, just like fictional number. Right? I I don't know the numbers for that depending on the site.

Michael:

That's the way that I've thought about it too. Obviously, I don't want it to be slow or terrible performance in UX like that. Like it matters, but at the same time, it's, it's different than a blog post where someone is coming in from Google and they like, you know, if it doesn't load faster, just like, all right back, let's check out the next one. Like if you're, if you're going through a course, you're spending hours on this thing anyway. And so, you know, it's, it's loaded up and you're going through it.

Alex:

I mean, ideally, you bought it already, so that's that's the best part. Like, you're you're not losing customers or potential customers. Yeah. People are more like, okay, nice. I'll get in there.

Alex:

And it will always feel fast and snappy, so that's good. Let's let's pick up one more thing which you already mentioned. You always had the the word incremental. Mhmm. So, of course, that's that's not the end of the service that's rendering, like, sub modes or patterns or however you wanna call it.

Alex:

Yeah. There's, of course, more. Like, I think especially with with Next, the whole, like, incremental static generation or incremental static regeneration, ISG and ISR, or incremental static revalidation, I also heard. Anyway, we can go all down the same road.

Michael:

A lot of different terms.

Alex:

Yeah. It's naming things is hard, but then just stick to one, please. It never works, though. They all are ways to say, okay, I have dynamic server side rendering, but in a way, I don't want to, like, hit the server all the time. I have some cache in between.

Alex:

And depending on how the cache looks like, it's the one or the other. So let let's go back for a second to static site generation. And the problem is, of course, we need if we need recent data or, like, very up to date things, then it's tricky. The other issue is if you have a 100 blog pages, it's fine. But if you have, let's say, 100,000 articles or a 100000 items in the ecommerce store, it's tricky, right, because the bills would take ages, and then you'd have to rebuild and so on and so on.

Alex:

So even if it's not super real time data, but more like, I have a news website and I have 100,000 articles, which is for a bigger news website, not that uncommon. You can't steadily generate all of them ahead of time because that will take ages, hours, maybe even days. So that was one of the big problems also why the whole Jamstack movement was a bit like, Nah, it's tricky. And then someone came up with ISG and ISR saying, Okay, you know what? If we do the same thing as with dynamic server side rendering, so we have a server there and it's rendering stuff, But why don't we cache the whole response?

Alex:

So why don't we just say, like, okay, we take it, stick in the cache, and when someone hits the page again, it would just get that cache response. And that's more or less incremental static generation to say that sites won't be generated initially. The first user who hit the site, yeah, they have to wait a little bit, because that's the initial server side rendering, which might take longer because all API calls on the server and so on and so on. But after that, we just get the cached version.

Michael:

So we're taking the this binary choice between static or server side rendered, and we're turning it into more of a spectrum where you can, like, you could be fully static. You could be fully dynamic server side rendered, or you could be somewhere in the middle and sort of kind of figure out what what balance works for your application and your your site your needs in that way.

Alex:

Exactly. And then you can even say, oh, these are, like, more important. Let's cache them not that long, or these guys can be cached for a day. It's fine. And you can even go once or further and use SWR, which is another acronym for stale via revalidate, basically saying, okay, for for my pages I just set up, let's give them the cached version.

Alex:

So let's say let's say you hit slash about, and slash about was never generated. Then you, as the first user, you get the generated version. So it will take a little bit. It's fine. Now if I hit the page, I get the cached version.

Alex:

But if you enable stale validate, it will check, okay, is that cached version too old? Too old meaning it should be revalidated. But if I say yes, for example, it is too old, it should be revalidated, I still get the stale content while the server in the background will revalidate the page, meaning it will update the cache with the newest entry, and then the user after me hitting the page will get the new website. And the same starts again. That's a wonderful pattern if you say, oh, yeah.

Alex:

I want to reduce the load on my server because if I set it to one second, for example, I have 100 users going on the same page. I don't have 100 requests to the server, but when going to a server, the rest may be also waiting for the cache to populate or just get the things out of the cache. And then the server will, like, repopulate the whole thing once, and you're good.

Michael:

It's a it's an interesting way of balancing performance for the end user and, like, serving them the content as fast as possible, while still updating the content and, and regenerating it as, as needed, it is kind of like tricky to think about because it's like, wait, every as a user, if you hit the endpoint, you're unless you're the very first one, you're never getting, like, the most recently generated one. You're always getting the the cached version, which might be, you know, as you had pointed out, it might be still valid, but it might also be like the old, the old one. And then the next person gets the updated version. And, but it is kinda, it's kinda interesting to think about because then it sort of, it, it means that this, the routes on your app that are the most popular get updated more frequently, and the ones that no one goes to don't really get updated at all. And so it

Alex:

That's true.

Michael:

Makes sense.

Alex:

That that's good and bad as well. Right? And, like, oh, yeah. Somebody might go to a page and get, like, super old content. Though you can even you can you can even fix that by saying, oh, yeah.

Alex:

If if the cache entry is older than an hour a day or whatever, then just do whatever the first user did with, like, do a full service set rendering request. Then the user might have to wait a bit, but gets the most recent thing.

Michael:

Right. And so there's there's ways to catch that so you don't get, like, really old content.

Alex:

Yeah. Yeah. You can you can basically say, okay. When should it be revalidated in background? When should the cache entry be thrown away?

Alex:

Like, these are the 2, like, maximum ages you can define.

Michael:

So there's a lot of stuff with with server side rendering. It's a very complex, in-depth topic, And I think we've covered quite a bit of stuff here. There's certainly a lot of ways to optimize and to configure for your specific needs and for whatever, like literally whatever kind of app you are running, whether it's like a basic marketing page or a giant news site or a SAS app or whatever, whatever else you're you're building.

Alex:

Yeah. What as long as it's public facing, you might need SSR at least for tiny part of application. That's true. And, I mean, there I guess there are a few more things that we could cover but might be good for another episode. Like, Nuxt server components could be could be very interesting to go into that a bit more in-depth.

Alex:

Also, islands architecture in ASTRO is something that's really interesting and getting a lot of traction. It's a lot throughout the whole, like, ecosystem. But, yeah, I also think now, everybody should have a a little bit of a better understanding with regards to server side rendering. And if there are any questions left, then as usual, shoot us a message on some kind of social media

Michael:

Mhmm.

Alex:

Wherever you can find us. Leave a comment or, yeah, tweet at at deja vu fm.

Michael:

We'll see you next time.

Alex:

Exactly. Stay tuned, and next episode, next week as usual. Goodbye.