Intermediate React, v3 Server Side Rendering Q&A

Transcript from the "Server Side Rendering Q&A" Lesson

[00:00:00]
>> So without going too deep, what would you recommend to measure performance something like lighthouse, or other tools.
>> So what would I recommend for measuring performance lighthouse is definitely a good starter. It's going to give you a lot of performance metrics just kind of all up then you should be instrumenting your code in your server side code.

[00:00:20]
>> With how long it's taking to respond to things, because you'll see when you add server side rendering to it, it's going to take longer to respond to users, so basically time to response, I think is TTR or no, it's time to first byte. That's the thing that you actually want to watch.

[00:00:40] There's a server called, or a service called caliber that will actually run lighthouse as a service for you, which is kind of interesting. And then having things like New Relic or Azure monitor or whatever the rest of those are, having those instrumented on your services will help a lot as well.

[00:00:59]
>> If I want only let's say div homepage to be server side rendered and the other pages, I just want to keep them just regular way of react. I just doing it thing. Is that possible?
>> That's definitely. So what you would do here instead of just this is right now is acting on every single request coming in that doesn't match this one.

[00:01:19] So basically you would have something like this, which would only respond to the homepage request. Actually, that might even work out of the box. Now, you'd have to do a little bit more to make sure that you're serving the index.HTML and everything else. So this one quite work we have to go in here and basically say like if I don't match anything else send them indexed at HTML.

[00:01:48] So I guess that might be this Express static dist/index.html Let's see if this works. It might work. This is kind of off the top my head. I've been teaching for a few hours. Did I break it? No it worked okay. So let's say on details. So now details would not be server side rendered.

[00:02:25] This would only come in as a react application. And it looks like I broke something, but that's kind of the gist here. I don't really know what I broke here. Yeah, so somewhere along the pathway here I broke this particular something, but that's you just make sure that you're always serving in index.HTML to everything else that matches your routes.

[00:02:53]
>> What should we consider if we want to, let's say, decide to use server side rendering for specific pages or like for the entire website? I know SEO depends on it and react is not the best when it comes to SEO because of how long it takes to load sometimes.

[00:03:08] So, is there any other stuff that you would take into consideration when deciding to use server side rendering or not?
>> Yeah I mean SEO is gonna be a big one. Because you want to serve rendered markup to web crawlers. In theory, Google will execute your react app, but it's going to mark that down as being a bit slower than other applications.

[00:03:32] So if you can serve rendered markup on the top is a positive thing. And then other crawlers, like Yandex and some of those don't run JavaScript. So things where SEO is absolutely critical. Yeah rendering out to a static HTML file is probably smart. Just in general things that are going to have high interactivity, you're going to need reactant but everything else that like there like static blog posts, you might just server side render and then write that to like a CDN cache, and then just serve it from cache.

[00:04:02] And you don't even need to execute JavaScript on those pages. So it's all going to be the trade off of interactivity which react is going to offer you to how fast can I serve it? Do I have static needs, things like that. Is it kind of a spectrum there