Comparing SPAs to SSG and SSR

What are the differences between Single Page Apps (SPA), Server Side Rendered Sites (SSR), and Static Site Generator based sites (SSG)? How do they compare in performance, SEO, developer experience, and flexibility? In this article, we give you an in-depth comparison of SPA, SSR, and SSG to help you make an informed decision on which strategies to use for your next front-end project.

The three strategies to JavaScript app development

The three different strategies have unique architectures. Often, if you are using a JavaScript framework, the simplest approach is to make a single-page app (SPA).

A single-page app is a shell of HTML with a script that populates the page with content. Instead of everything coming in the HTML, the browser needs to wait for the JavaScript rendering code, like React or Vue, to load before it can display content. Frameworks like Create React App use this approach, creating a template that just bundles JavaScript with an HTML skeleton, instead of generating full HTML pages. However, because of the delay for JavaScript loading, content often loads slower, making the site load slower on slow networks, which can decrease user experience and cause some people to leave before the site loads.

To overcome this delay, frameworks like Next.js, Nuxt, and SvelteKit offer server-side rendering and static site generation. This approach is more like a traditional website where the server sends HTML to the client pre-built with JavaScript to make it interactive/hydrate it. The biggest difference is that you can write the app more like an SPA, and it functions like an SPA once the JavaScript loads. The primary difference between an SSG site and an SSR site occurs when you generate the HTML. With a statically generated site, it is generated when you compile the project, making you get only static files with no server needed. However, with a server-side rendered approach, the server generates the HTML on each request, allowing you to customize the page based on the user without client-side JavaScript but requiring a server.

When to use each approach

Performance

To ensure a good user experience, your website needs to be fast. Some approaches are faster than others. In general, SSG sites and SSR sites are faster than SPAs in terms of loading content. SPAs, as mentioned earlier, need to download the JavaScript for the app before they can display content. However, in some cases, SSG and SSR can be slower. Because the server sends the HTML along with the JavaScript, there is a certain amount of duplication in the code. This means that the overall downloaded file is bigger, making the Time to Interactive (TTI) slower. Regardless of this file size increase, SSG and SSR will usually get better performance because of the faster content loading time. Another thing to note is that SSR sites can sometimes be slower due to the files needing rendering on every request. However, this can be mitigated by using strategies like edge computing.

SPA	SSG	SSR
Best TTI, but generally not great because all the JavaScript has to download before it can be run, increasing the Largest Contentful and First Contentful Paint (GCP/LCP). Generally not the best for performance.	Overall best for performance. The server response speed is just as fast as an SPA, but you also get the HTML pre-rendered. In certain edge cases, it can be slower than SPAs due to code duplication, but usually, it will be faster.	Good for performance, although it can be slower than SSG. Performance equivalent to SSG, except that SSR can add some latency due to server processing time.

SEO

For your website to be found, search engines need to know what content it has. The practice of helping search engine crawlers do that is called SEO (Search Engine Optimization). There are many ways the approach you take to building a site with a JavaScript framework can help or hurt SEO. This is one place where SPA’s are at an extreme disadvantage. To conserve resources and maximize security, search engines often limit or entirely disable the execution of JavaScript. Googlebot currently supports JavaScript, but some smaller search engines do not. Since SSR and SSG provide the content already rendered as HTML, search engines can crawl the site without as much work. Even with SSG and SSR though, you still need to do things like implementing meta tags to make sure that your app has good SEO.

SPA	SSG	SSR
Not great, especially for smaller search engines. Sometimes can be a toss-up for whether the search engine can understand your content, due to the need for JavaScript execution.	Very good, because the HTML comes pre-rendered, with JavaScript only optional.	Same as SSG.

Flexibility

It is important to start with a base that allows you to do everything you need without having to switch approaches. Flexibility revolves around factors like how much you can do on the server, how easy it is to change stacks, and how much you can extend the tools making up the stack. This is one area where SSG comes up short. SSG requires lots of tooling, which reduces portability. Additionally, unlike SSR, you can’t run secure operations on the server without making a public API. SSR is better in the sense that you can run secure operations on the server to render data. However, it has even more vendor lock-in due to you needing to pick a compute service instead of just a static file host. SPAs perform somewhat well in this area, because they require the least tooling and configuration, and therefore have the least vendor lock-in. The biggest problem with SPA flexibility is that an SPA can’t render anything on the server.

SPA	SSG	SSR
Less vendor lock-in, because it is all static files, and you do not need any tooling beyond the framework itself, but you cannot render things on the server like SSR.	Very limited, due to more vendor lock-in and the inability to render on the server.	The most vendor lock-in out of all the approaches, due to you needing a server and often customized code for that server. However, it does allow you to render things on the server, which means you can dynamically render data securely without client-side JavaScript.

Ease of development

Often you need to ship a product quickly, or you don’t have a lot of resources, so ease of development is important. Overall, it is usually fairly easy to use any of the approaches listed. For example, if you use React, you can quickly make an SPA with Create React App, or make a site using SSG or SSR with Next.js. Nonetheless, there are still differences in ease of use. SPAs are almost always easier because you can design your code to only run in a browser as opposed to running on both a server and a browser. SSG is not as easy as making an SPA, but it is easier than SSR because you do not need to use hosting more advanced than a simple CDN. SSR is the hardest, as said before, because you need to make your code run in two environments and use hosting with the ability to run code (although services like Vercel can make the hosting easier).

SPA	SSG	SSR
Easiest	Harder than an SPA due to your code running in two environments. Additionally, you need more tooling to compile your code.	Hardest out of all approaches for the same reasons as SSG and because it requires running code dynamically on a server

Conclusion

Each approach to building a website with a JavaScript framework has its pros and cons. SPAs are best for heavily interactive apps where JavaScript is essential, and development resources are limited. SSG sites have the best performance and are good for sites with purely static content like marketing sites. SSR is good for more advanced sites that use more dynamic data without using client side JavaScript. I hope you have learned something from this, and thank you for reading.

Frameworks for SPA/SSR/SSG

React/Preact

Next.js: SSR/SSG
Create React App: SPA
Gatsby: SSG
Fresh: SSR Vue
Vue CLI: SPA
Nuxt: SSR/SSG
Vuepress/Vitepress: SSG
Gridsome: SSG Svelte
Svelte Template: SPA
SvelteKit: SSR/SSG
ElderJS: SSG
JungleJS: SSG Framework Agnostic
Astro: SSG

References:

Get started with Fauna

Are you building a project with JavaScript, Jamstack, or serverless? Learn why Fauna is the database of choice for thousands of builders. Fauna is a flexible, developer-friendly, transactional database delivered as a secure and scalable cloud API. Never again worry about database provisioning, scaling, sharding, replication, or correctness. Sign up to explore all the capabilities and start building!