Practical Guide to Web Rendering
Server-Side Rendering. Client-Side Rendering. CSR with Prerendering, etc. The differences, trade-offs, and similarities between most common web rendering solutions and why you should care about them as a dev.
6 minutes
After a few attempts at writing about Gatsby vs Next.js, I always ended up with 50% of the article trying to explain concepts around rendering on the web. So, I figured the topic deserves its own post.
Before we get started, first, a bit of background and definition. What is rendering on the web? In order to answer that question, we'll take a bit of a stroll down history lane.
More than 30 years ago, the web started as a collection of static documents, built for scientists to share their findings and ideas. Over the following decades, the web had become more dynamic, technologies like PHP, MySQL, and the likes enabled developers to build more dynamic functionalities.
Since then, JS frameworks were introduced along with a class of static site generators, rendering has become complex with different models suitable for different use cases. This article is my attempt at making sense of all this complexity. If I am to succeed at my job, you (the readers) will be able to decide which methodologies will be most applicable to your next web project.
When choosing a technology for a project, here are some considerations (familiarity and preferences aside):
- SEO: depending on whether SEO is important for your project, you can choose the right technologies accordingly
- Performance: performance is always a consideration when choosing technologies
- Hosting: different rendering method also affects what kind of hosting platform you can use and how expensive your hosting cost may be,
There are other technical considerations that you should consider such as TTFB, TTI, FCP, etc. However, these are beyond the scope of this article.
Server-Side Rendering is when the server generates the full HTML document in response to the browser's navigation request. This usually involves a template engine with data fetched from the database. Here's what happens from start to end:
Because there are many steps between the request and response, SSR may be slower than other methods. On the other hand, because the server fetches data from the data source at every request, the content is highly dynamic.
Although the document content can be dynamic, the drawback of SSR is it doesn't employ any front-end JS frameworks, making it harder to build complex and interactive web applications.
Examples of SSR are frameworks like Ruby on Rails, PHP Laravel, Elixir Phoenix, or Python Django, and the like.
Static Rendering is when the server builds all pages into HTML documents. This is called a "build step". The end result of the build step is a set of HTML documents that can be deployed to a server or CDN, ready to "serve".
The main characteristic of this method is "static". That's both the pros and cons of this method.
Because all pages are static, this produces a super-fast load time as the page is readily available and easily scaled globally.
And because all pages are static, they're very inflexible and non-dynamic.
Because of this, the SSG approach is mostly popular for blogs, simple landing pages, and brochure websites.
Client-Side Rendering is when the server (ideally the CDN) delivers a static application shell to the browser and allows the JavaScript code to take care of the rendering part on the client. The application that uses CSR is typically referred to as Single Page Application (SPA) as the whole application is just 1 page where routes are managed by the application instead of the server.
This is usually the default rendering method when you use client-side JavaScript frameworks. A framework is the default case. It's usually simpler to get started as you don't need to use a meta-framework (framework on top of a framework) or further optimization. However, it comes with some significant drawbacks.
The first issue is around load time. While the document size may be smaller because it's only the application shell, the browser may take a while to parse the JavaScript code before your users can view and interact with the content. That's why techniques like lazy loading and code splitting are important when using CSR.
The second issue is around SEO. As the server only delivers an application shell, the browser has to rely on JavaScript for the page to be fully loaded and functional. Although Google crawlers are able to parse JavaScript and render your web pages, this topic is still quite controversial. There are many experiments as well as lessons learned from switching between CSR and SSR that indicate that SSR is superior when it comes to SEO.
With these drawbacks, CSR only makes sense if your web projects don't require SEO. Its most popular use case is for web applications (typically back-office applications or desktop applications and the likes), SaaS dashboards, etc.
The three solutions mentioned above are the foundations of rendering on the web. Of course, they each have their own pros and cons. To combat the cons, developers have attempted to mesh those techniques together.
SSR with Hydration is a mesh of SSR and CSR. The idea is to build dynamic pages that are good with SEO while being highly interactive with a JS framework.
This technique is great if you can take advantage of the good things of SSR and CSR with SSR being good for SEO and CSR being good for interactivity. To achieve that, you do have to pay both the cost of SSR and CSR.
CSR with Prerendering is a mesh of CSR and static generation. The idea is to pre-build all HTML pages with a static site generator so the site is fast and SEO-friendly while being highly interactive after JS kicks in.
This technique is one of the best ways to deliver a blazing-fast and interactive website. Its main drawback is the same as the static rendering technique, Since you have to build all pages at build time, it's more challenging to deal with highly dynamic content. It may not be suitable for projects with user-generated SEO requirements (blogging platform, forum, etc).
Most client-side JS frameworks such as Angular, React, Svelte, Vue default to CSR as its rendering method. There are meta-frameworks on top that enable further rendering options.
Some example meta-frameworks:
- Angular: Angular Universal
- React: Next.js, Gatsby, Remix
- Svelte: SvelteKit
- Vue: Nuxt, Vuepress
Using Next.js, developers can use SSG, SSR with Hydration, and CSR with Prerendering depending on the use case. Next.js is like the swiss army knife of a web framework, and that's why it's a useful tool to have in every developer's toolbelt. That must be one of the reasons Next.js has exploded in popularity over the past few years (as you can see in the latest Web Almanac By HTTP Archive 2021 research).
Hopefully, this article has explained the difference between using different web technologies. I won’t be saying anything new when I say that in general, it boils down to your project at hand and its needs.
Lastly, I'd love to mention that edge computing has grown and changed the game over the last few years. It plays a huge role in front-end architecture and hopefully, we can discuss more on the topic on another day.
Thinking of switching to an eCommerce platform + frontend framework that helps rather than hinders your website's performance but not sure of the approach you should take?
Don’t worry, we got your back!
Set up a personal 1-on-1 demo today and let’s see what solution best fits your use case. Or, why not, SIGN UP for FREE and start building.
Here are some additional great reads if you're choosing a front end technology for your web projects:
https://developers.google.com/web/updates/2019/02/rendering-on-the-web
https://jasonformat.com/application-holotypes/
https://www.swyx.io/svelte-sites-react-apps/
Follow the Rabbit🐰
What Is a Static Site Today?
There are numerous approaches to developing a web application that is performant. Going the static site way is just one of them. Pause here. What do we/I mean when we/I say static sites?