Two pillars for transforming your website into a
Progressive Web App) are the manifest and having service workers. (Besides that it’s better if your website is responsive, follows
PRPL principles, but I won’t go into these in the current blog post.) Manifest is kind of a no brainer, although requires some work. You need to identify the main theme color and main background color for your website, and generate various sizes of the favicon of your website and reference some of those from the manifest and some of them from the header meta section. There are several websites (Example) which help you to generate series of images and the corresponding manifest and HTML meta tags.
On the other hand the service workers are not as evident since your website could take several shapes and forms (for example
SPA / non
SPA), sub URLs and assets. You first need to decide what caching strategies you prefer and for what part of your website: do you prefer off-line first or on-line first approach. On-line first approach could be a good idea if your website for example displays crypto currency tickers and their current values. In case of a static website with a blog section (like mine) you are good to go with an off-line first approach. Still, you need to configure which files exactly the service worker infrastructure should cache for you for off-line use and what way (expiration, etc.). You can decide the approach per resource basis, so your static website can be off-line first, while only the trade ticker part could be on-line first with an off-line fall-back.
In the past
sw-precache to help with this configuration task and possibly cut down plumbing code related to the service worker configuration and activation mechanisms. The newest generation of
Along that line: in case you are using any static site generator framework then there’s a very good chance that your framework has a package which provides a layer on top of
Workbox and you can deal with it at the level of your generator framework instead of
Workbox must have been done by thousands of engineers before you, and steps probably taken to make this part seamless. This means: always look how your selected framework supports
PWA and look for a layer on top of
At the time of this blogpost this site currently uses Jekyll, and I saw two candidates (BTW, multiple choices are usually a good sign of thriving community): jekyll-pwa-plugin or jekyll-workbox-plugin. Both of them seems nice, but according to this blogpost I decided to go with the latter. Since Jekyll is
RoR (Ruby on Rails) based framework the “package” you need to install is a
Ruby Gem. The configuration is simple, well readable (
yaml format), no fluff inside the expected
_config.yml, and the few plumbing code placeholders. I only needed to add two
default.html7 lines starting at: source
- And a short
sw.jsfile stub (source) with the most important placeholder
And that’s all!