• Client Side Rendered (CSR) — Browser loads a static html page which fetches data
  • Server Side Rendered (SSR) — Server returns html on the fly from templates/views/components to the Browser (no follow up data fetch)


With a server side rendered site, you’ll probably have some context variables in your http handlers, with things like the current user, their organization/team, feature flags, etc. to make returning user specific content easier.

With a client side rendered app, you don’t have the same luxury, instead you return a static html file with Javascript and fetch any user specific data on load. This isn’t great for initial loads because you have to wait for the HTML & JS to load before you can even start fetching data from the server.

You could server side render your client side app, but that can be a tall order as you have to deal with the split between client only APIs and server APIs.

Another option is to inject the static index.html page with the user specific data, usually via a json blob parsed on page load.

This gives you a few benefits:

  • web app code stays the same – don’t have to worry about server only APIs vs client only APIs
  • avoids the delay with fetching after initial load
  • support metadata for search engines/scrapers (iMessage, Discord, Slack, Facebook, Twitter, etc.) without having to use user agent specific hacks (see Trello)

Preload Examples


Client side rendered apps are easy to deploy, but server side rendering helps with initial load times and supporting search engines/scrapers.