DEV Community

Guilherme Amaral
Guilherme Amaral

Posted on

The Different Web Navigation and Rendering Techniques Explained

(auto-translated, original post here)

SSG, SSR, SPA, MPA, CSR. If you're a developer and, like me, have tried to venture a bit into frontend web development, you've probably come across some of these terms. One of the biggest confusions I faced while researching the topic was understanding the different types of rendering—not because they are necessarily complex, but because it's somewhat difficult to find clear and precise information about them. A large portion of the available resources and discussions in technical forums end up mixing distinct concepts, especially rendering methods with navigation strategies. When they don't mix these concepts, they focus too much on the advantages and disadvantages of each approach, without adequately explaining what they are and how they work.

Before we begin, it's important to recall the lifecycle of a request and the difference between static and dynamic content. When a user accesses a website, their browser first makes an HTTP request to get the page's HTML. After receiving the HTML, the browser starts to process it and, during this process, identifies and makes new requests to obtain necessary additional resources (like CSS files, JavaScript, and images). This process can take anywhere from a few milliseconds to several seconds, depending on the latency and speed of the connection.

As for the content, it can be classified as static or dynamic. Static content is that which remains the same for all users and rarely changes—for example, a site's logo, institutional texts, or decorative images. Dynamic content, on the other hand, is generated or customized at the time of the request, and can vary based on several factors such as the logged-in user, the time of day, or database data—for example, a social media feed, comments on a blog, or data from an admin dashboard.

To start, it's crucial to establish a clear distinction: these methods can be divided into two main categories—navigation methods (SPA and MPA) and rendering methods (SSR, SSG, and CSR). When you see someone asking, for example, whether SSR or SPA is better, there's already a conceptual error in the question itself, as they are concepts that address different aspects of web development. To make it easier to understand, let's first explore the navigation methods, then the rendering methods, and finally, explain how they can be combined and used together.

Navigation Methods: MPA vs SPA

Navigation methods define how the transition between different pages or sections of a site is handled. Let's use a simple portfolio with two pages as an example: "Who I am" (homepage at portfolio.com) and "My projects" (at portfolio.com/projects). Navigation between these pages can be done through a top navigation bar, where the user clicks to access the desired page.

In the MPA (Multi-Page Application) method, which is the traditional web approach, when a user navigates from the homepage to the projects page, the browser makes a new request to the server. The server, in turn, sends a new HTML page to the browser. This method has been used since the beginning of the internet and continues to be widely employed today, being especially suitable for sites with mostly static content, like blogs and institutional websites. Astro, for example, is a framework that traditionally uses this approach.

In the SPA (Single-Page Application) method, which has gained popularity in the last decade, navigation between pages is actually a simulation. The entire site functions as a single page, and when the user "navigates," what really happens is a dynamic content swap, without the need to reload the entire page. The address in the browser's URL bar changes to give the impression of navigation, but it's all managed by JavaScript. This approach is widely used in modern web applications, like Gmail and Facebook, where the user experience needs to be more fluid and similar to a desktop application. Frameworks like React, Vue, and Angular were initially designed with this type of application in mind. The request cycle here is bifurcated: the browser first receives a minimal static HTML, and then JavaScript takes over, rendering the page dynamically.

It's important to note that a site can use both methods. For example, we can keep the navigation between "home" and "projects" as an SPA, but have a "blog" section that loads as an MPA, leveraging the best of each approach as needed.

Rendering Methods: SSG, SSR, and CSR

Now that we understand how navigation works, let's explore the different rendering methods. These methods determine how and when the HTML content and structure of the page are generated. To facilitate initial understanding, I'll explain the methods in their most classic and isolated forms.

SSG (Static Site Generation) is the method where pages are rendered during the website's build process. In this process, all the source code (whether it's in React, Vue, Svelte, or any other framework) is transformed into optimized HTML, CSS, and JavaScript files. The resulting JavaScript usually focuses on the page's interactive functionalities, not being responsible for the basic content structure, which is handled by the HTML and CSS. Astro, for example, is a framework that uses SSG in combination with MPA. This method is ideal for blogs, documentation sites, and portfolios, where the content doesn't change frequently. In SSG, the page structure is static. During the request cycle, the server simply delivers pre-generated HTML files without any additional processing.

In CSR (Client-Side Rendering), the page structure is rendered in the user's browser. The server typically sends a simplified HTML file, along with the necessary JavaScript to build the interface. Although the basic HTML loads, the page only becomes functional once the JavaScript is executed, making the initial load time longer. This is the method traditionally used by pure React applications and is common in SPAs, being ideal for highly interactive applications where content changes dynamically.

SSR (Server-Side Rendering), similar to SSG, generates complete HTML, but it does so on-demand, when the user makes the request. This allows the content to be personalized for that user or to be up-to-date with the latest information from the database, without the need to access a JSON API. Frameworks like Next.js make extensive use of this approach. SSR also has some disadvantages, such as a higher load on the server compared to other methods, and, in the case of pages using JavaScript frameworks, it also requires a runtime like Node.js running on the server.

Combinations and Nuances of Rendering Methods

The reality of modern web development is that rendering methods rarely exist in their "pure" forms. The combinations between them are not just a matter of using different methods for different pages, but of mixing them in fundamental and intrinsic ways, where it's sometimes difficult to distinguish where one method ends and another begins. These methods also don't need to be used to load an entire page; they can be used to render just parts of it.

For example, consider a page that uses CSR (Client-Side Rendering). In its most basic form, it would start with an almost empty HTML and rely entirely on JavaScript to build the interface. But do we really need to start with a blank page? We can leverage the build process to pre-render the initial content the user will see (known as the "first paint" or "initial render"), creating a hybrid experience between SSG and CSR. In this combination, the initial structure of the page uses SSG, while new changes use CSR, optimizing the request cycle.

Going further, let's suppose that on this same page, we want to add information that changes constantly, like the weather forecast, and we want the user to have access to this information immediately. Using JavaScript requests would only work after the page is loaded, so we can use SSR instead of SSG for our initial HTML, and continue using CSR for future changes on the page.

We can create any combination of the three rendering methods and use them with any mix of the two navigation types; you are not limited to choosing just one.

Conclusion

The choice between different navigation and rendering methods is not a matter of "better or worse," but of suitability for the use case. Many modern applications combine different approaches to optimize the user experience in each context.

The most important thing is to understand how these techniques can be used to improve your application and adapt to your limitations. With the emergence of increasingly sophisticated frameworks, the lines between these approaches become more blurred, allowing for ever more hybrid and optimized solutions.

This is an extensive and complex topic, and there are many nuances that could not be fully addressed in this text. If you have any critiques, questions, or suggestions, I would be very happy to answer them in the comments.

Top comments (1)

Some comments may only be visible to logged-in visitors. Sign in to view all comments.