loading...
Cover image for Server Side Rendering vs Static Site Generation

Server Side Rendering vs Static Site Generation

matfrana profile image Matteo Frana Updated on ・3 min read

Server side rendering (SSR) and Static Site Generation (SSG) are two ways to create websites using a modern front-end stack (getting content from a server API) while preserving SEO friendliness and perceived performance.

Here I show the reasons to choose SSR or SSG for you next project, in particular for the React ecosystem.

Server Side Rendering

With SSR, the website pages are generated at runtime on the server.
This means that the server must be able to execute Node.js to generate the pages.
The advantage is that the pages are always up-to-date, but every page view triggers a call to the APIs.

Pros:

  • Content is always up-to-date
  • No need to trigger a rebuild of the website when content changes

Cons:

  • Cannot deploy to a static CDN
  • The Time-To-First-Byte is a bit slower because the content is generated on the server for each request

How to cope with cons:

  • You may always put a caching layer, like a Varnish server with a short TTL, in front of your website to improve the response time
  • Next.js (a framework for SSR with React) understands when your pages don’t need data (no getInitialProps static method) and creates pure static pages that don’t need server processing

Static Site Generation:

With SSG, all the pages are generated at build time as static pages (with some Javascript tricks to load/preload content as fast as possible). The Time-To-First-Byte is the best you can get and you can host your website on a static hosting platform like Netlify.

The problem is that the content becomes stale, so you need to rebuild the website pages to update it. Netlify or Zeit Now provide hooks to trigger a rebuild from a remote app, like a CMS.

Since you call the APIs only at build time, you end up calling them fewer times in a day, so that, if you have a cap on the number of API calls, you don’t risk to exceed it.

The main SSG technologies in the React ecosystem are Gatsby and Next.js (which can do both SSR and SSG).

Pros:

  • Really fast website
  • Can deploy to a static CDN
  • Security: the attack surface of a static website is minimal
  • Fewer API calls

Cons:

  • If content changes frequently, it may become stale
  • Need to trigger a rebuild to update content
  • If you have a really big website, build time may be very long

How to cope with cons:

  • When you have both stable data (for e-commerce: product description, images, etc.) and frequently changing data (stock quantity) you may do an API call on component load to fetch an updated version of just the frequently changing data. Search engines could crawl the stale data, but it’s not a big problem in this case
  • Using this technique, you may also manage authentication and serve a different content to different users

Conclusion

Today I'd choose a static site anytime, unless:

  • the website is very big (for example a 50K products e-commerce)
  • the content changes very frequently and the user needs it up-to-date

NOTE: We'll soon release in beta testing a block-based hybrid CMS called React Bricks, which will work with both SSR (Next.js) and SSG (Gatsby or Next.js), so… stay tuned!

Posted on by:

matfrana profile

Matteo Frana

@matfrana

Front-end developer and speaker. I love React. Husband and father of two. Founder @ F2.net and @ ReactBricks

Discussion

pic
Editor guide
 

With AWS tou can actually use CloudFront caching for dynamic serving content, it has TTL mechanisms to cope with it. So there are ways around the issue.

Look here for some use cases,
aws.amazon.com/cloudfront/dynamic-...

 

In my experience, the major reasons for looking towards SSG rather than any form of active server (SSR, Wordpress, Wiki's, etc.) are: security, static content has nothing to attack outside the base web server, which is typically a very well tested off-the-shelf option; cost saving, typically one can host static files in S3 or Azure storage for 10% of the cost of a hosting a VM.

Personally I'm moving from Wordpress and MoinMoin to static sites with Hugo for these reasons.

 

I totally agree with you.
After a period converting Wordpress sites to Gatsby with Wordpress REST and Admin, we decided to build our "React Bricks" CMS (based on React Components) to avoid Wordpress altogether.
We'll release it in beta soon; we have already used it for 3 sites and we love the new way of working with Gatsby/Next SSG and our CMS.

 

What about the Netlify CMS? Aren't you guys trying to do the same?

 

No, it's different: in NetlifyCMS you edit the content in a form and you have the preview on the side. With React Bricks you edit directly the content through the React components created by you (using React Bricks WYSIWYG components Text, RichText, Image) and the editing page is really the same as what you'll get in the frontend, because the frontend is created by React Bricks's Viewer component.
We have prepared starters for both Gatsby and Next.js.

What's more, you don't have to use components like Gatsby Image, because React Bricks has its own cross-platform Image component (with lazyload, srcSet, etc.).

Migrating from Gatsby to Next or viceversa is just a matter of cloning another starter, copying ApiKey and AppId and the block schema.

BTW, we are launching tomorrow in beta!! :)