Progressive web sites and service workers

Awake early I read this interesting blog post about making a very fast modern website. Lots of good stuff in there, like React alternatives that are lighter weight, avoiding polyfill overhead for modern browsers, the value of server side rendering, etc. Also two things that were entirely new to me: “Progressive web apps” and “Service Workers”. Also new-to-me: Google’s web fundamentals instructional material.

Progressive web app is the buzzword for a web page that works like a little application. Like Gmail in the days of yore, or Google Docs, or any modern / complex site like Twitter or Facebook or whatever. Or my own single page apps like WindHistory and LogsOfLag. Web apps are nothing new, but the “progressive” is meant to suggest a site that works fast even on mobile devices with slow and unreliable networking. Key ideas are rendering quickly and handling unreliable networks intelligently. They also have a neat tool called Lighthouse that audits a web app for progressiveness. A lot of what it checks for is mom-and-apple-pie, deferring script loads etc.

But Service Workers are the key magic. They are “a programmable network proxy, allowing you to control how network requests from your page are handled”. Basically it’s a background Javascript thread running asynchronously doing all the network for your web app. The web app page installs a service worker once the first time the site is loaded. Then it lives in the background doing things for your app like loading resources, receiving push notifications, synchronizing data to the server, etc. It communicates asynchronously via messages to the Javascript in the browser page.

It sounds pretty powerful. Basically it gives the developer control over the browser’s network, how stuff is cached and when it is loaded, etc. It also sounds pretty complicated, and I imagine 95% of developers won’t code to this API themselves and instead use a framework that takes advantage of it to optimize performance.

The big problem is service workers aren’t fully supported: on desktop Chrome and Firefox support it, but not MSIE/Edge nor Apple Safari. Mobile support is not good either. And this feature is so complex I don’t think you can polyfill support in, certainly not in a meaningfully performant way. I don’t have enough perspective to see whether service workers have momentum. Chrome has supported it for two years, which in a way is a bad sign that it’s been that long and there’s no clear consensus for implementing it everywhere. OTOH it solves a real problem and Apple and Microsoft are certainly not known for leading the way in web development.


Bonus links from reading that blog post. The fetch API is a modern alternative to XMLHttpRequest, etc which is nicer to use. Polyfills exist. And speaking of polyfills, is a nice CDN service that delivers optimized polyfills to browsers based on their User-Agent. Finally does free geolocation of IP addresses and powers a polyfill for the HTML5 location API. It runs as a free service with usage limits, or you can download the IP database and code and run your own.