The app shell model suggests that the app shell containing the minimum required HTML, CSS & JavaScript is loaded first and then content is loaded dynamically afterwards. This seems to imply the lazy loading of content using JavaScript and APIs.
For example the PWA mentioned in the article above Google I/O 2016.
However such an approach means that your content is only available for JavaScript-enabled browsers.
This could also impact search engine indexing, for example when testing the Google I/O 2016 website, the content is not available if you disable JavaScript.
What is the recommended approach, as this seems to go against the principle of progressive enhancement?
(Caveat: there are lots of different ways to implement server-side rendering.)
If you make "proper" use of server-side rendering, then your server should respond to any navigation requests that are sent to it with a complete HTML document, with content specific to the URL. In this model, JavaScript is not necessary for getting content onto the screen, though it might be needed for "interactive" features, or for doing single-page app style navigations.
The wrinkle is that once you have a service worker installed, and if you're taking advantage of the App Shell model, your browser will no longer have to send a navigation request to the server in order to obtain a response. It can use the previously cached App Shell HTML to fulfill the request, bypassing the network completely.
Browsers or other theoretical user agents that don't support service workers will continue to send navigation requests to your server, and your server will continue to respond to them with full HTML documents.
There's a video of a talk I gave a few years back that explains this in further detail: https://youtu.be/jCKZDTtUA2A?t=1428, and a sample application that takes advantage of this technique at https://github.com/GoogleChrome/sw-precache/tree/master/app-shell-demo