We’ve been interested in technologies for making websites work offline for some time now. And we’ve managed to use them - most notably the infamous ApplicationCache – on a number of projects over the last five or so years. However although their promise was great, the technology wasn’t really up to the task, so development was tough-going and involved a lot of compromises and workarounds.
Enter Service Workers
A service worker is a script which can access the lower-level workings of the browser. It can, for example, decide how to handle HTTP requests. It also has access to the Cache API. These two capabilities in combination allow us to develop a cacheing strategy.
The net result is that our website is available even when visitors are offline. And when they’re online, the site is faster than ever... in fact it’s greasy fast.
Our cacheing strategy
Our service worker is configured as follows:
- Before doing anything else, cache a small number of key files including the main CSS and javascript files. Also cache an offline fallback HTML page so it can be displayed when there is no internet connection.
- When a page is requested (i.e. when the user tries to view a page):
- If it’s a Journal (Blog) Entry, we’ll assume that it’s unlikely to change often so we’ll put performance ahead of freshness and get it from the device’s cache. In the background we asynchronously (i.e. not affecting page load time) fetch a fresh version from the network to update the cache for subsequent requests. If our page is not already in the cache we fetch it the old-fashioned way over the internet, show it and put it in the cache. If there’s no internet connection the show still goes on - we display our offline fallback page.
- For an important non-blog page (homepage, section indexes etc), since it is more likely to change regularly we fetch it from the network and store a copy in the cache. If there’s no internet connection, get it from the cache. And if it doesn’t exist in the cache, show our offline fallback page.
- When an image is requested, look in the device’s cache first. Only if it’s not already there do we fetch it from the network. And if there’s no internet connection, show a fallback image.
- For everything else (CSS, Javascript, other media), look for a cached copy first, and only if that doesn’t exist do we go to the network.
The Offline Fallback page
Our website is already more resilient website than it was previously because locally cached pages can be shown even when the reader has no internet connection. However our offline fallback page adds further resilience, by ensuring that when the visitor with no internet connection navigates to a page which has not already been cached, they will see something infinitely more useful than the typical error message. Our fallback page gives them a friendly message telling them that we’ve detected that they are offline, but not to worry – here’s a list of links to (cached) pages that they can browse while offline.
Pieces of a PWA
We’ve written in detail about PWAs elsewhere but to recap, Progressive Web Apps allow us to build enhanced web experiences that previously required a native application. The technical building blocks of a PWA are:
- HTTPS (which we already had);
- a service worker; and
- a manifest.
Our website is now installable
Thanks to our manifest, our website can now be installed to a person’s phone or tablet home screen without any “app store” involvement. Browsers such as Chrome identify www.greenhill.com as a PWA and will prompt the user to install it to their home screen. And achieving this preferential positioning on a person’s phone leads to significant increases in re-engagement, as confirmed by Twitter.
Next Steps
Next up, we plan to implement web push notifications so that visitors can subscribe to be notified when a new blog post is published. We’ll write about that in a future article.
In the meantime, if the performance and resilience gains afforded by a PWA sound interesting to you, why not get in touch and let’s talk it over.
