Server-side rendering & the app shell model

Question

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?

I'm voting to close this question as off-topic because it is about SEO, not programming. SEO questions may be asked on [Webmasters.SE](//webmasters.stackexchange.com/) — Machavity, Mar 24 '17 at 23:45
I believe that your comment is incorrect. The question is about programming - to be specific the app shell model architecture and the principle of progressive enhancement. SEO was mentioned as it is one of the downsides of loading content through JavaScript. I edited the question to rephrase and remove reference to "SEO". — Kevin Farrugia, Mar 27 '17 at 05:51

score 1 · Accepted Answer · answered Apr 25 '17 at 14:48

(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

In the iFixit example, am I correct in saying that if the user agent does not have JavaScript enabled, it will load the server-side data correctly, but if the user agent has JavaScript enabled it will a) Install the service worker and cache the current 'index' page (possibly obsolete) b) Retrieve the latest content from the API and overwrite the content on the 'index' page. — Kevin Farrugia, Apr 25 '17 at 18:52
There are three different behaviors: 1) No JS at all: SSR ensures that there is content for all navigation responses, and links trigger real navigations. 2) JS, but no SW support (e.g. Safari): SSR ensures that there is content for initial navigation response, the SPA-style navigation is used for links, with the DOM updated with the new content. 3) JS, and a registered SW: Initial navigations are fulfilled with the cached App Shell with an immediate DOM update to populate the App Shell, and then SPA-style navigation is used for links. — Jeff Posnick, Apr 25 '17 at 19:17

Server-side rendering & the app shell model

1 Answers1