Server-Side Rendering Overview

[00:00:00]
>> Brian Holt: Let's talk about server-side rendering, this is like, you wouldn't probably do both of these at the same time. I don't know, honestly, I could fathom ways that you could do these together, but it's way outside the scope of this class, maybe it's not. So, I could see you statically generating like the shell of your app, like a larger React app like generating the HTML tag, the body tag, the head tag with static site generation, and then only server-side rendering the actual interior app.

[00:00:26]
Actually, I could see that being a really valid use case, I think that's actually technically what Next does for you because Next controls the entire app, not just the interior app. So it is like a combination of techniques being put together here, but let's talk about server-side rendering.

[00:00:46]
So first thing I'm gonna say is V5 of this course goes pretty in depth on, look at that handsome gentleman down there, in terms of just covering how to take an entire React app and move it to server-side rendering. So if that brownfield migration is interesting to you, I got questions of, why you find brownfield migrations interesting, but this, this would be helpful for those activities, right?

[00:01:14]
But this one's gonna focus on a much more shallow focus of, here's how you would set up server-side rendering just for a new app that you were doing, generally speaking. And again, we're gonna try and keep this as just minimal as possible, so we can focus on just the server-side rendering portion of that.

[00:01:29]
And if you wanna get again, more into the weeds of that, check out V5 nothing has changed, it's totally 100% valid. Yeah, we spent a bunch of time on it last time, because that used to be like the state of the art when it came to the server component of React.

[00:01:47]
So I have this open image, a new tab, lovely, beautiful diagram, it's perfect, [LAUGH] right? No, I made this with excalidraw, just trying to help you visualize, like the React request cycle, so the user requests the app here on the left, they get the index.html. The server receives a request, it doesn't just sends back the entire React bundle and the entire HTML shell, it does nothing, right?

[00:02:17]
The browser then receives it parses the JavaScript, it then executes the JavaScript, and at the end, when all of that entire React cycle has happened, the user finally sees an interactive app, right? It's all like it goes from zero to done, and there's no intermediary steps at the end, time to interactive and time to first meaningful paint.

[00:02:40]
If you're into those performance metrics, end up being within a millisecond of each other, if not being literally the same thing. It's like the normal browser request cycle, you could say the same thing about Angular or Vue or any of those if they're in the same client-side rendering thing.

[00:02:59]
What if we could make it a little bit better in terms of perceived performance that the user sees something before it's interactive? Well, just think about it for a second, let's actually just pull up the diagram, so that's probably helpful. Open image, a new tab, so what if we could separate these two motions here, where, when the user sees the app and when the app is actually useful.

[00:03:16]
That tends to be better perceived performance of actually, technically, time to interactive will be a bit slower, almost without exception, that that will be true, but that's good, because the user will see the app. It takes, like, 100, 200 milliseconds for the human brain to just process that, I'm quoting someone that I read online said, I'm not a psychologist.

[00:03:45]
Don't trust my metrics, but that's what I remember reading, that it takes a human about that long to decide what they wanna do, and by the time that they actually go to click on something, the app will probably have bootstrapped and then be interactive by that point. So the user is gonna perceive that the app has gone faster, does that make sense?

[00:04:03]
So it's faster perceived performance, even if, though the actual performance is unchanged, even if a little bit worse. So the key here is this little step here where you pre render the page before you send that. So you're actually sending them complete markup of the first render of the page, and then you're sending the React bundle with it as well.

[00:04:23]
So that the user sees inert, normal HTML that the browser is parsed and then displays, and then later, the React app panics and takes over, right? And then makes everything interactive, that is the entire premise of what server-side rendering is for reactors, how can we show them something sooner, so they start thinking about their decision sooner.

[00:04:45]
This has a variety of impacts, imagine that I'm on a iPhone, what is it, 16 Pro is that the latest one? iPhone 19 Pro, right? And I'm just standing next to the Wi-Fi access point, to the point that I'm getting sick from all the radiation, right? This probably doesn't really help me that much, because my device is so fast and my internet connection is so fast, right?

[00:05:12]
If anything, it's actually probably slowing me down, because now my server requests are taking longer, my device could have received it and rendered it faster. Now perceive that you're camping outside of Yellowstone, where notoriously has crappy reception, and you're on some old Android, crappy device, right? This could actually be a massive difference, right?

[00:05:31]
In terms of just perceived performance, that you can actually start seeing things and be like, okay, what do I want to do about this, or I can see all the information, right? And it's gonna take my device forever to render, and the internet connection can be quite flaky or finicky or something like that.

[00:05:50]
So I hope you're seeing that the persona and what your app does is extremely important contextually about why this could not be useful. If you're making Uber for helicopters in San Francisco, this is probably not that helpful, because they probably all have nice devices, right? And they're probably all in San Francisco, where there's pretty decent Wi-Fi throughout the city, actually, surprisingly, in parts of the city, terrible reception.

[00:06:12]
But that's not anything to do with this course, that's just me complaining. But if you're building like, I don't know, a cropped tracker for rural Montana or rural Wyoming or rural India or something like that, yeah, this make a big difference, right? But know your user, that's a big thing here and measure, right?

[00:06:34]
Make sure that you're actually making a difference because this tool can actually make things worse. Again, a lot of these things are not slam dunks, they're just different techniques that can apply in certain situations. So yeah, SSR, server-side rendering carries complexity, so a good example is, if everything's browser based, you can just assume the browser APIs always exist.

[00:06:53]
So for example, if you want to fire off like a Google Analytic event on when a component does something. If you're not server-side rendering, you can go willy-nilly and do it anywhere that you want to. It doesn't really matter if you're doing server-side rendering that can't be in the hot path of what runs on the server, because the browser APIs don't exist on the server, and you will crash right?

[00:07:15]
So that complexity ends up being important, we talked about that, and please measure. I harp on this quite a bit specifically because at Netflix, we did this, and we found in places this didn't actually help, it actually made things worse in places, and that's at Netflix scale, right?

[00:07:31]
So that's like the entire gamut, we took it out in places.
>> Speaker 2: Do you recommend measuring?
>> Brian Holt: Just eyeball it, no, I'm kidding [LAUGH] Google Analytics will give you a really good, portrait of, this is when your first paint was. Actually the Chrome DevTools are really good for this, the Firefox ones are improving as well, where you can see time to first meaningful paint, time to interactive.

[00:08:00]
Those are the three metrics that you want to really first meaningful paint and time to interactive. Lighthouse will give you these metrics as well, and I'm sure there's other tools that will. But any front end focused performance analytics give you pretty good metrics on that.
>> Speaker 2: You need to instrument the server as well to catch both sides of Otter.

[00:08:19]
>> Brian Holt: Probably, yeah, the time to response, depending on how heavy your component is and what kinda server you're running and all that stuff. If you're running your home server on Raspberry Pi, one good for you, but it's gonna meaningfully suffer even on small components. But if you're running an extra large on AWS, you're probably not gonna see too much of a difference.

[00:08:42]
But yeah, to get the full picture, you would have to do that, for example, we're gonna do Fastify. I think there's a Fastify library to actually include your server-side metrics in your Chrome Dev Tools, so you can actually see the entire life cycle. Including all your database query and all that stuff, so instrumenting your node server would help as well.