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.
When to use each approach
- SSG: 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.
- SSR: 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.
- SSR: Same as SSG.
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: 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.
- SSG: Very limited, due to more vendor lock-in and the inability to render on the server.
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: Easiest
- SSG: Harder than an SPA due to your code running in two environments. Additionally, you need more tooling to compile your code.
- SSR: Hardest out of all approaches for the same reasons as SSG and because it requires running code dynamically on a server.
Originally published at https://fauna.com.