Google published a very interesting article ๐ฐ about service workers : Instant Loading Web Apps With An Application Shell Architecture. It promotes using service workers for caching the main UI of the appsite, so it gets out of the way when it's time to load the content.
Progressive Web Apps (PWAs) describe how a web app can progressively change with use and user consent to give the user a more native-app-like experience with offline support, push notifications and being installable to the home-screen. They can gain substantial performance benefits thanks to intelligent service worker caching of your UI shell for repeat visits.
They define what they mean:
When we talk about an appโs shell, we mean the minimal HTML, CSS and JavaScript powering the user interface. This should load fast, be cached and once loaded, dynamic content can populate your view.
Indeed this seems an interesting option when the appsite is being used multiple times a day. It becomes less so for a site that you go every once in a while. The cache will have been destroyed by the browsing of other sites. Maybe what is missing is the possibility for users to somehow keep a local version of the full UI, the same way that when you install an app on your computer ๐ป, you are not necessary forced to update to the next version, but still can access content with it.
Progressive Enhancement
They mentionned progressive enhancement:
While service worker isnโt currently supported by all browsers, the application content shell architecture uses progressive enhancement to ensure everyone can access the content. For example, take our sample project.
but this is progressive enhancement in the context of the support or not of service workers. It is not in the context of a Web site where you separate the notion of UI and content.
I guess it helped me to understand what bugs me in system like our own webcompat website we are creating. When we deactivate JavaScript, there is no way the site keeps working. We currently load the shell ๐ through a "normal HTTP" request and then the content through XHR. No JavaScript, No XHR, No content. Sad panda ๐ผ. I can see how service workers ๐ท could provide a better way of thinking ๐ค about it, but if and only if content comes first.
Content First
As a user, when I'm being given a URI to something, I want to get access first to the content. This is the thing I'm interested by. The UI and features come second. The content is the first class citizen. I don't mind at all having a non styled text as long as I can read it right away, and then if the UI ๐ starts appearing after (at least on first load), it's all jolly good๐. And given the fact that service workers will come to help for caching the UI elements, when going to the second URI, there should not be any delay anymore.
To think more about it.
PS: no emojis have been abused during the writing of this blog post.
Otsukare!