14
Quick Tip - JavaScript Rendering
Originally Posted - https://aidangee.dev/blog/quick-tip-javascript-rendering
Popular JavaScript frameworks like Next.js, Nuxt.js and SvelteKit come with a number of rendering options included. But what does SSR, ISR, SSG and all the other fancy acronyms mean?
Minimal static HTML is served back to the user, this will most likely only contain links to scripts and CSS files. The JavaScript is in charge of generating the HTML in the browser.
Because there are no servers needed you will often see platforms that host static websites for free with a generous amount of network bandwidth e.g. Render, Firebase Hosting, Vercel, Netlify. Or you could run this yourself in AWS storing the files in S3 and backing with a CloudFront CDN for a very low cost (often a few cents a month).
Pros
- Simple deployments, just an index.html file and built JavaScript
- Easy to scale with static files, that requires no server side compute to serve to the user.
Cons
- SEO requirements can be more complicated (good video series about that on Google search YouTube channel)
- Some performance metrics can be affected, for example CLS & FCP
- All JavaScript is shipped to the client, so it must not contain any secrets / private data
Ideal for
- Applications that require authentication to use
- Applications without SEO requirements
- Applications that receive spikes in traffic (static HTML does not need compute that has to scale)
HTML is generated at build time and the full static HTML will be served over the network to the user.
This generates static HTML files, which means much of the same low cost hosting solutions as the client side rendering example can be used. The difference being that with Static Generation you will have a HTML file per page generated, rather than just an index.html.
Pros
- Easy to scale with static files, no servers needed
- Faster response times than if the file was generated on the fly
- Full HTML content served to the user which benefits SEO, FCP, CLS over client side rendering
Cons
- Longer build times, that can increase as content on an app increases
- Will often have to be rebuilt to update page content
- Cannot contain personalised content, the same generated page is served to all users
Ideal for
- Applications where content / data is not required to be updated frequently
- Applications with high performance requirements
- Applications that receive spikes in traffic (static HTML does not need compute that has to scale)
HTML is generated on request and the full static HTML will be served over the network to the user.
As it implies in the name, this requires a server side component. Each request will need to use some compute to generate the HTML (if you are not using a cache). You could use a serverless platform here like Begin, Vercel or Netlify to mitigate having to manage any servers.
Pros
- Full HTML content served to the user which benefits SEO, FCP, CLS over client side rendering
- Data can be dynamic on each request
Cons
- Each request to the origin requires some server side compute resource
- Slower response time than static generation
Ideal for
- Applications where content / data is updated often
- Applications with personalised content
- Applications with strict SEO requirements
This can be considered a mixture of the above approaches. Frameworks like Next.js, Nuxt.js & SvelteKit (to name a few) have excellent APIs to achieve this.
To demonstrate this let us look at a simple example scenario with SvelteKit. Imagine we are building a blog with the following specification -
- A static welcome homepage
- A blog page that lists posts with content from a CMS
We could split these pages into different categories:
- The homepage is static and won't change, so we can generate this at build time
- The blog listing page, well that depends. We could generate the list page at build time with static generation but if the data source for blogs is often being updated then it might make sense to use SSR which would allow the page to update as the content updates.
This sounds like it might be complicated to mix and match, but the frameworks make this easy.
Homepage (pages/index.svelte)
<script context="module">
// exporting this variable is all you need to do
export const prerender = true;
</script>
<svelte:head>
<title>Homepage</title>
<meta name="description" content="My homepage">
</svelte:head>
<main>
<!-- content goes here -->
</main>Blog List (pages/blog/index.svelte)
<script context="module">
// export a load function to grab data server side
export async function load({ page, fetch, session, context }) {
const blogs = await fetch('https://mycms.io').then((response) => response.json());
return {
props: {
blogs
}
}
})
// we have static generation disabled
export const prerender = false;
</script>
<script>
export let blogs;
</script>
<main>
<BlogPosts blogs={blogs}/>
</main>If you wanted to switch this to being statically generated like discussed above, you could just set prerender to true. (be aware, in svelte the load function is run on the client and server)
One more I wanted to include under the hybrid list is a feature of Nuxt.js and Next.js they call Incremental Static Regeneration (ISR). This can be viewed as a middle ground between SSR and SSG, if you use ISR then the page will be generated at build time like it would if you use static generation. But with ISR you specify a duration, and after this duration passed the page will be regenerated.
With this, you get the benefits of static generation but the increased frequency of updates that you get from SSR. This would actually be a good solution to our blogs list page from above. ISR can allow us to have a pre-rendered page but will update frequently enough to support any new blogs being added to the CMS.
Unfortunately, there is not one answer to how you should render your application. It is highly specific to what you are building. The good news is that hybrid rendering makes this specificity possible to allow best mix in your application.
For the best performance and low cost, static generation is recommended. I find myself saying 'can I pre-render this?' more and more, and often when I have something on the page that is dynamic like comments on a blog post. I'll mix in a component that grabs and renders that data client side before reaching for SSR. Why? This allows the initial content for the user to be pre-rendered with the dynamic part sprinkled on top in the client.
14