The Service Worker API is a somewhat new browser feature which gives you a lot more control over how your website behaves while offline or in a bad connection area. The basic premise of a Service Worker is that when someone visits your site for the first time your Service Worker will begin caching the content and assets in the background, in other words installing it on to the device. This means that when they return to your site while offline they are still provided with content. Not every browser supports Service Workers right now, but they are getting increasingly popular.
HTTPS with Github Pages
The Service Worker API requires a valid SSL certificate (HTTPS), and at the time of writing this GitHub only supports HTTPS for pages who don’t utilize their own domain name for their project, which unfortunately excluded me. However after reading several blog posts and issue logs I was able to locate a solution using CloudFlare, a CDN provider I talked about in a previous post of mine. They are able to host DNS for free, and with them you can utilize an SSL certificate to satisfy the browser requirements of HTTPS, allowing you to use the Service Worker API.
As a disclaimer this implementation might not be an appropriate solution depending on the type of site you’re maintaining.
Creating the Service Worker
First things first, I created a
sw.js file in the root directory of my project and added some boilerplate code provided by Google. The following snippet installs the Service Worker and caches the assets provided in the
I then added some fetch events into the mix as outlined in the Offline Cookbook by Jake Archibald. My Service Worker will now check to see if there’s a cache available, and if not it will fall back to the network. In addition, if it finds something on the network that doesn’t match the cache, it will attempt to obtain it and then add it to the cache.
The last part of this puzzle is telling the Service Worker what it should be looking for when it begins caching, and that means filling out the
Then I was able to loop over all of my posts, pages, and assets.
When the page is now built by Jekyll, it pushes all of my pages assets, post and page paths to the
urlsToCache array, meaning my Service Worker is now ready to be deployed.
If your site has a lot of content or assets you might want to limit how much gets cached and instead display an offline fallback. In my case I decided to limit the amount of content that gets cached to my homepage and my three most recent posts. I extended the loops in the previous example to look like the following.
I then added an
offline.html file and populated it with an offline message and provided links to the posts which are available in the cache. Afterwards I updated my
sw.js file to fall back to this if it experiences an error in either fetch events.
Registering the Service Worker
Now that I’ve built my
After testing it locally I was able to go to the Application tab of Chrome developer tools and see the Service Worker was registered and running.
I was able to open the Cache Storage tab and see all of the assets I’ve included inside
urlsToCache array so I was confident that the Service Worker was working properly!
With my Service Worker registering and collecting data, the next thing I did was create a
manifest.json file. The manifest works hand-in-hand with the Service Worker, and depending on the type of device and browser it allows you to change the behavior of your site. There are multiple manifest generators out there, I decided to use this one.
Here’s what my
manifest.json file looks like.
One of the more notable settings in the manifest file is the
display mode. I have mine set to browser, but if set to
fullscreen users will be prompted to add a link to your website to their devices home screen, allowing it to behave like a native app instead of a website, hence the name “Progressive Web App”.
The manifest file needs to be included in your pages header like so.
Amping Up the Service Worker
The last thing I wanted to do was add AMP support for my Service Worker. This allows you to start installing your Service Worker whenever someone starts browsing your page from the Google Cache. This means that if someone visits an AMP article of mine, their subsequent clicks on to other parts of my site both while online and offline will be near instantaneous.
In order to achieve this I created a file called
sw.html. This file will act as a form of endpoint for AMP so it knows where to find my Service Worker. Inside this file I added some standard html with a header script which I got from a Google AMP workshop at AMPConf. Essentially this script looks for
sw.js and registers it.
After testing the AMP page from the Google Cache I was able to determine that the Service Worker was installing properly.
After all is said and done I managed to complete all of the goals I set out to do. I now have a working Gulp setup, Google AMP, and a Service Worker that installs via AMP. I even managed to significantly boost my sites performance and a11y rating so it scores close to top marks on performance rating sites and extensions like Page Speed Insights and Lighthouse. I can’t help but feel rather accomplished right now, cheers!
- Part 1: Utilizing Gulp with Jekyll
- Part 2: Setting up Google AMP with Jekyll
- Part 3: Using a Service Worker with Jekyll