Go to Articles

Exploring Web Rendering: Static HTML vs. React Application

As web developers, we all start with simple HTML and CSS documents, where we learn that the browser reads each line one after the other. Eventually, we progress to working with JavaScript frameworks, where we master the art of reusing components and providing users with an excellent experience.

But have you ever wondered about the difference between these two ways of rendering a web page? What's the impact of sending a fully loaded HTML document compared to sending an empty one and using JavaScript to populate it?

Web rendering is a topic no frontend developer should overlook, as it's the key to swift loading on users' devices (and a gentle nudge to server cost reduction, just saying).

HTML Files vs. React Applications

Back when we used to write plain HTML documents, the content was already there, statically written. When the server received a resource request to render a page, it luxuriously sent the static file and went back to its nap.

Now, everything changes when we use JavaScript frameworks that don't work the same way (most of them don't, one of them is React).

These frameworks generate all the content via JavaScript. No writing plain content in the HTML document anymore. In fact, the HTML might have an empty body, but with requests to the server for JavaScript files that will manipulate the DOM and fill it with content.

What does this mean? It means the browser takes more steps to render the content. Here's the breakdown:

1. The browser requests an HTML file (which comes empty with external requests).
2. The browser starts reading each line of the HTML. When it reaches the JavaScript request, it calls the same server again to get the required JavaScript file.
3. Upon receiving the JavaScript, it's executed. This JavaScript contains all the components and logic you created with your preferred framework.
4. The DOM is manipulated by JavaScript. This is where users finally see content.

This is known as Client-Side Rendering.

Client-Side Rendering

Client-Side Rendering isn't always optimal. Why make two requests for a page that only displays content, making our dear user wait needlessly? It doesn't make sense, and it shouldn't. This affects user experience and SEO (yes, for a good SEO rank, avoiding Client-Side Rendering is a wise choice).

We could attempt rendering like we did with pure HTML... that would solve several of our issues... but how?

This is where solutions like those offered by frameworks like Next.js, Gatsby.js, Nuxt.js, Astro, and others come into play. Trying to implement non-Client-Side rendering on your own would be complex due to build-server-client configurations. It's better to opt for one of these established options.

Next, I'll explain the rendering types offered by these frameworks. Keep in mind that each framework is different, so you should research what rendering types each one supports.

Server-Side Rendering

Server-Side Rendering executes your framework's JavaScript on the server each time a request comes in, and it sends pre-rendered HTML to the browser. No multiple requests from the browser, and no unnecessary waiting for the user.

The downside of this method is that the server has more workload, which usually translates to more costs 💸. It's cheaper to let the innocent user handle the rendering. Each use case should be studied to choose the most suitable option.

Static Site Generation

Static Site Generation also executes JavaScript on the server, but in a very different way from Server-Side Rendering.

Static Site Generation runs all the JavaScript and performs a single rendering at build time, saving all pages already rendered. When a browser makes a request, the server doesn't need to process anything or delegate work to the browser. It simply sends the previously rendered HTML.

As you might guess, if you're developing a blog or a website that displays unchanging content, static rendering is the way to go. No resources wasted on processing, everything runs at top speed, and everyone's happy.

The downside of Static Site Generation is also its strong point: the content is static. If you need to show real-time updated data, it can get a bit tricky because you'd have to run builds repeatedly. And let's be honest, you're not going to do that. Especially when there's an alternative that addresses this issue.

Another challenge arises when you have numerous pages, like a blog with a hundred or a thousand blog posts, each being a distinct page. The server would need to render all those pages during the build process. This could significantly increase the time it takes for each build, which can be inconvenient.

Incremental Site Regeneration

Incremental Site Regeneration solves the problems of Static Site Generation. It doesn't limit itself to a single rendering.

For each request that reaches the server, it renders the HTML, sends it to the browser, and stores it for future requests within a time range (5 minutes, 30 minutes, 6 hours, etc.). This way, the server doesn't have to render for every request or deliver outdated files. They get updated at intervals you set.

Not only that, but you're not forced to render each of your pages. You can choose to pre-render only a handful, the most important ones, and let the rest be rendered using the technique mentioned above.

This technique is relatively new and might be the best option for many cases. For instance, blogs with many pages or websites that need to be updated, but real-time updates aren't crucial. Like, come on, it's not the end of the world if you don't see a comment posted 3 minutes ago. You can wait until the server renders the site again.