Yesterday, we looked talked about a common type of harmful complexity I see in many web development projects: using a JS library like React to build a mostly static website.
If your site is mostly content that doesn’t change, or that doesn’t change based on user interactions, it should be served as static HTML files from the server.
Today, I wanted to talk about two different types of tools you can use to do that.
Let’s dig in!
👋 Need help reducing complexity in your project? I have one consulting spot left for 2024. I’d love to work with you!
Server-Side Rendering (SSR)
With server-side rendering (or SSR), users are sent a complete HTML file from the server.
On the backend, you typically have a database with some content in it, and some templates that control how that content is rendered. When the user’s browser requests a URL, the HTML file is dynamically generated on the server and sent back to the user.
This type of setup is great for both same-for-everyone and custom-for-the-user content.
- Because the HTML is generated dynamically, it can be customized based on the user or other factors.
- SSR platforms usually have a nice CMS that makes it easy for non-technical users to author content and generate pages.
- Because HTML is generated dynamically, the server might respond more slowly. This can sometimes be mitigated with good caching strategies.
- Because HTML is generated dynamically, this approach uses more server resources. This can increase cost, environmental impact, and so on.
- The database used to store content is a potential attack vector that can be used to compromise your site.
- If your database fails or your site gets too much traffic, the site can fail to render.
Static Site Generators (SSG)
A static site generator (or SSG) blends the templating benefits of SSR rendering with the performance and resilience of flat HTML files.
You write content in markdown files (typically), and create templates using a backend programming language (it varies by SSG). Then, you run a build step that combines the markdown content and templates into pre-rendered HTML files.
Unlike with SSR, this are not generated dynamically at time of request. They’re rendered ahead of time.
- Because HTML is pre-rendered, there’s almost no lag between URL request and HTML response.
- Because HTML is pre-rendered, the site is incredibly resilient.
- Because HTML is pre-rendered, very few server resources are needed, making it much less expensive to host and run.
- There’s no database to attack or compromise.
- Because content is stored in markdown files, there’s usually not a CMS. There are some third-party options, but they’re not nearly as plentiful or robust as what you get with SSR tools.
- Because the HTML is pre-rendered with a build step, you need to create your own server process to handle things like scheduled posts and time-based updates.
A hybrid approach
I recently built a site that uses a static site generator to build pre-rendered
They’re mostly static HTML, with a sprinkling of custom-for-the-user content.
Like an SSG, it’s much faster than traditional SSR, uses fewer server resources, and has no database to compromise. But like SSR, content can be dynamically customized to the user on the server.
Tools like Astro and SvelteKit attempt to do something similar.
(We’ll be looking at different tool options tomorrow.)
I’m not sure it’s a great fit for every (or even most) projects, but it is an option.
Which approach should you use
As a general guideline…
- Use SSR if you need a CMS for non-technical users or need content dynamically generated and customized for the user.
- Use an SSG if neither of those items is true.
If you need help figuring it out or migrating your existing setup, let me know! I have one consulting spot left, and would love to work with you.