7 min read

Rendering On the Web

Rendering On the Web

Hello friends 👋,

This is the weekly edition of our newsletter.  The Pallet Post features conversations with awesomely insightful professionals, jobs from companies they recommend, and some of our own takeaways from building a startup.

Today's post will be a little different than our usual thought piece on the world of recruiting and what Pallet is doing to fix it. Recently, we had an interesting technical challenge, and I'm tapping one of our engineers, Zach, to explain how technical approaches will evolve alongside your growing business. Specifically, he'll explain our decision to switch from Client-Side Rendering to Server-Side Rendering.

As Zach mentions above, we started with link previews that looked like this:

Anytime someone shared a Pallet link they would all render the same– not ideal. We needed to give Creators/Communities the ability to share unique previews of their boards and individual jobs. We wanted link previews to render like this:

So what were we to do? Development speed was our initial focus– but now we needed a more robust, dynamic web rendering solution. Fortunately for us, Zach broke down the various rendering techniques and why we should move forward with Next.js.  

There are a million ways to build a website. As a developer, I find that we usually don't build them right the first time. Requirements change, the business evolves, new technologies emerge, and developers have to make decisions in the moment that sometimes affect the entire architecture of our applications. If you ever build a website, one of these core questions you'll ask yourself is, how is my application rendered, and is that the best for the business?

At Pallet, we recently took on the task of rebuilding our website– as we evaluated the different benefits and tradeoffs of various rending techniques, I thought it would be helpful to explain my findings, and how we decided to use static rendering.

But first, I want to take you through each of the different rendering techniques, so you'll be able to talk to your team, (who will be very impressed with your newly developed knowledge) about which web rending technique best serves your business.

The 3 Main Rendering Techniques

There are 3 main types of rendering on the web. There is no single best approach for all situations, so understanding the pros and cons and when to use one technique over another is very important.

1. Server-Side Rendering (SSR)

In simpler times, before web applications and databases were mainstream, most web pages were just plain static HTML pages. You could click around a bit, but they weren't very interactive. As websites became more complex and needed to access data securely, server-side rendering frameworks like PHP and WordPress dominated the market. Server-Side Rendering, or SSR, means that every time a user visits a page, an HTTP request is made to the server that does all of the work for you — making a connection to a database, running a query, handling business logic — all with the ultimate goal of returning formatted markdown (or HTML) back to the browser so that it can be rendered. Every time you navigate to another route, the server has to do the work all over again. For each page request, the server retrieves the corresponding PHP file (or whatever language), compiles/interprets it, and delivers back the HTML. Because all the requests to your server return as fully rendered HTML, you don't need a bunch of fancy JavaScript to load the page.


  • Faster times for rendering the initial page
  • Fully crawlable HTML pages (which means better SEO)
  • Ability to customize the <head> of every page (i.e. for social sharing previews and SEO)


  • Frequent server requests
  • Full page reloads
  • Having to manage a server in general can be a headache
  • Can be expensive to host

2. Client-Side Rendering (CSR)

Client-Side Rendering simply means rendering content in the browser entirely through JavaScript. Another name for sites that use Client-Side Rendering is Single Page Applications (SPAs). SPAs are still considered pretty new since they didn’t become popularized until JavaScript libraries like React and Angular came along. Create React App (CRA) is one of the most popular tools for quickly spinning up a new SPA. Instead of getting all of the content from the HTML document itself, CRA has a single barebones index.html that includes a JavaScript file that is responsible for loading the rest of the site entirely in the browser. All "routes" are not separate network requests as with SSR. Routing is typically handled purely through JavaScript.

As an exercise, navigate to this calculator app built with CRA, right-click anywhere on the page, and select “View Page Source”. You will see that there are no <h1> tags or HTML at all; only a link to the main JS bundle. In fact, you need to have JavaScript enabled in your browser for the site to work!

This is the main downside of Client-Side Rendering; web crawlers and bots are not smart enough to know what is being displayed on each page because everything is rendered dynamically through JavaScript. Arguably the user experience is smoother in CSR apps (versus SSR) because there are no hard page transitions. However, CSR suffers in terms of performance on the initial site visit since the entire site is often bundled together in the same JavaScript file. For this reason, CSR does not scale up well for very large sites. After the initial page load, performance isn't as big of an issue because assets can be cached by the browser. However, the initial page load time is something SEO bots care a lot about.

SPAs are typically used anywhere that exists behind a login page because you generally don't have to worry as much about SEO. In fact, many companies choose to have completely separate apps for their marketing and product sites. It's common to see a marketing site use a server-side rendering framework and CMS like WordPress, with the rest of the"user" app being a SPA. Although there's nothing wrong with this, be careful that this then does not eventually lead to a fragmented user experience!


  • Rich site interactions
  • Fast website rendering after the initial load
  • Quick to spin up a site as there are many frameworks to help like Create React App
  • Lots of awesome JavaScript libraries to choose from (React, Angular, Vue, etc)


  • Low SEO value
  • Slow initial load
  • Cannot customize the initial <head> of each page (for social sharing and SEO)

3. Static Rendering

Static site generation has become very popular recently and can be very efficient if used correctly. It can be considered a variant of SSR as the benefits are similar, but not all SSR apps can be static apps.

Instead of waiting until a page is requested and then generating its view on demand each time, a static site generator does this in advance so that all of the HTML assets are ready to serve ahead of time. And it does so for every possible view of a site at build time. Think of a static site generator as a script that takes in data, content and templates, processes them, and outputs a folder full of all the final pages and assets. Most important is that it shifts the work away from run-time to build-time, which makes this by far the "fastest" of all 3 approaches (especially because you can put all of the content behind a CDN).

In addition, you can still use JavaScript and CSR within a page to make pages more interactive. However, updating dynamic content requires rebuilding the entire app (or else you have to fetch the data on the client-side which loses SEO value). Because static sites are so fast and each request delivers a separate HTML file, they are very SEO friendly. Among pure static site generators, Gatsby.js is one of the most popular and easy-to-use React frameworks. If you have a small blog or marketing site that needs to be SEO friendly and doesn’t have a lot of dynamic content, Gatsby is a great choice.


  • Super fast (easy to cache everything behind a CDN)
  • Secure (no server required)
  • Simple (it’s just static content)
  • Cheap to host (Netlify is a very popular host for static and JAMstack sites)


  • Increased build times
  • Cannot truly render dynamic content (without rebuilding the entire app every time)
  • Large apps with thousands of pages will be slow to develop and build


One of the most popular JavaScript frameworks that support SSR is Next.js. Although Next.js is often thought of as an SSR tool, it is really a hybrid framework capable of all 3 rendering techniques. The fact that you can choose whether to fetch data via client, server, or statically makes it so powerful. If you are a web developer new to Next.js, I would highly recommend going through their brief tutorial that covers all the basics.


One of the most powerful features of Next.js is its ability to pre-render pages, or generating the HTML in advance either by server-side rendering or statically. You can create a "hybrid" Next.js app by using server-side rendering for most pages and Static Generation for others. As the developer, you get to choose! Finally, you should be using the Next.js Link component for all internal site links. This allows users to experience client-side navigation when visiting the site, but web crawlers will still see the pre-rendered markup - offering the best of both worlds. This strategy of blending a server-rendered web app with a single-page application is also known as building isomorphic or universal apps. One other perk with pre-rendering is you should be able to disable JS in your browser completely and still be able to see the site! In contrast, you cannot do that with a single-page application.

So which rendering technique should I use?

Again, the answer to this question involves analyzing the tradeoffs of each approach and seeing what makes sense in your specific scenario. At Pallet, we started off building our website as a single-page application using Create React App because it was the quickest thing to get up and running. However as we started to delve into SEO, URLs with custom share previews, and increasing page performance, we needed a flexible tool to handle all of these different aspects. This is why we ultimately chose to rebuild our site using Next.js.

If you are still unsure what technique is best for your site, I highly recommend Next.js as it is a safe option that allows you to change your mind later. Note that there are some additional costs when using something like Next.js as the increased development complexity means it can take longer to ship a new feature. However, in our case, we found that the added SEO, performance, and feature benefits were definitely worth the initial learning curve.