I’m trying to make a Progressive Web App! Part 4: How I implemented service workers

Wow, that title is almost as long as the time that has passed since I wrote the latest entry in this series.

Let’s recap where we left off before I dove head first into service workers. This is how the Lighthouse report looked:

Does not register a Service Worker

That was my next item on the todo list. I’ve written three blog posts about this adventure, but I still haven’t implemented service workers into the Klickrubrik app.

HTTPS on the local site

This was the first issue i ran into. Service workers require HTTPS in order to be installed. It works if you run your app on http://localhost, but that didn’t work for me since I’m using Laravel Homestead and http://klickrubrik.app as my local URL.
I think that Homestead supports HTTPS, but I never understod how it works actually 🙄.

Valet to the rescue!

Far in the back of my head, I had some memories about Laravel Valet and a secure command.
After a quick check in the documentation, it turned out that I remembered correctly!

$ cd klickrubrik
$ valet link
$ valet secure

Valet is pretty fantastic. These two commands allowed me to browse to https://klickrubrik.dev on my local machine.
With that obstacle finally out of my way, I could implement a service worker!

Service worker precache

In my sub-series of posts about service workers, I showed how to save assets to the cache.

var filesToCache = [
  '/',
  '/build/css/app.css',
  '/build/js/app.js'
];

The problem

Yes, I sure as hell hit another bump in the road! Since I’m using Laravel Elixir for compiling and versioning my assets, the file names can look like this:

/build/css/app-0fsdf2131das.css
/build/js/app-fdss342374892.js

This means that every time I update my CSS or JS, I would have to update my service worker so it stores the correct files.
That’s not very professional!

The solution

I actually found a solution fairly quickly. I had been reading a little bit about a node module called sw-precache. I hadn’t really wrapped my head around why and when I should use it.

Until now!

GoogleChromeLabs/sw-precache

Service Worker Precache is a module for generating a service worker that precaches resources. It integrates with your build process. Once configured, it detects all your static resources (HTML, JavaScript, CSS, images, etc.) and generates a hash of each file’s contents.

In other words, sw-precache generates the service-worker.js file that I’ve written about — automatically.
And since Elixir is built on Gulp and I’m already using it in the Klickrubrik project, it sounded like the perfect solution!

How I did it

Okey, let’s start with the obvious:

$ npm install --save-dev sw-precache

Then I simply copied and pasted the basic example from the documentation into my gulpfile.js
Then I changed the rootDir to public since it’s where my assets is located. I also changed the staticFileGlobs array so it only includes:

• .css and js files from the build directory
• .jpg .png .svg files from the img directory.

This is the full code:

So, when running:

$ gulp generate-service-worker

…this fantastic node module generates a service-worker.js file for me that will cache these assets and making Klickrubrik load instantly.

Finally!

Lighthouse report

So this is where we are now:

Content is not sized correctly for the viewport
The viewport size is 418px, whereas the window size is 412px

Humm, this is a new one since last time. At least I’ve got rid of the horrible Registers a service worker!

See you soon again! (I hope 🙄) 🙃