SSR, SPAs and PWAs

13. September 2018 // 15:0015:45
Hörsaal Zugspitze

Outline:

SSR recap – what is it, how does it work?

* send pre-rendered vs. empty document
* improving perceived performance
* Giving non-JS clients something they can work with (e.g. Twitter Cards etc.)

Typical problems

* jQuery obviously not available
* => problems with SSR mostly caused by bad patterns (e.g. jQuery)
* Relying on `localStorage`/`sessionStorage` => move to cookie

Disabling interaction on the pre-rendered document

* Simple case is to disable complete document => result often not great
* Better:
* selectively disable elements that require app to run
* Render them in a loading state (signals the user “this is still setting up”)
* Some elements are functional without a running app already
* Some things can be moved to CSS

Advanced patterns

* Lazy load in the client, bundle everything in SSR as bundle size does not matter much there (e.g. translations)
* Push data in the sandbox (e.g. translations, model data etc.)
* Render differently in SSR/client (e.g. inline SVG in SSR, use image tag in browser)
* Never require SSR to work (fallback to serving non-SSR on SSR errors)

how does this relate to PWAs

* Works well together:
* App frame is fine but app frame + SSR is better
* This can be combined – render app frame first, then put in SSR once available, while app still loads

Whether SSR worth it depends on case though