This is a good walkthrough of the flow you’d need to implement if you want to notify users of an updated service worker.
Friday, May 18th, 2018
Wednesday, May 16th, 2018
HTTPS + service worker + web app manifest = progressive web app
I gave a quick talk at the Delta V conference in London last week called Any Site can be a Progressive Web App. I had ten minutes, but frankly I only needed enough time to say the title of the talk because, well, that was also the message.
There’s a common misconception that making a Progressive Web App means creating a Single Page App with an app-shell architecture. But the truth is that literally any website can benefit from the performance boost that results from the combination of HTTPS + Service Worker + Web App Manifest.
See how I define a progressive web app as being HTTPS + service worker + web app manifest? I’ve been doing that for a while. Here’s a post from last year called Progressing the web:
Literally any website can be a progressive web app:
Later I wrote a post called What is a Progressive Web App? where I compared the definition to responsive web design.
Regardless of the specifics of the name, what I like about Progressive Web Apps is that they have a clear definition. It reminds me of Responsive Web Design. Whatever you think of that name, it comes with a clear list of requirements:
- A fluid layout,
- Fluid images, and
- Media queries.
Likewise, Progressive Web Apps consist of:
- A service worker, and
- A Web App Manifest.
There’s more you can do in addition to that (just as there’s plenty more you can do on a responsive site), but the core definition is nice and clear.
But here’s the thing. Outside of the confines of my own website, it’s hard to find that definition anywhere.
On Google’s developer site, their definition uses adjectives like “reliable”, “fast”, and “engaging”. Those are all great adjectives, but more useful to a salesperson than a developer.
Over on the Mozilla Developer Network, their section on progressive web apps states:
Progressive web apps use modern web APIs along with traditional progressive enhancement strategy to create cross-platform web applications. These apps work everywhere and provide several features that give them the same user experience advantages as native apps.
Hmm …I’m not so sure about that comparison to native apps (and I’m a little disturbed that the URL structure is
/Apps/Progressive). So let’s click through to the introduction:
PWAs are web apps developed using a number of specific technologies and standard patterns to allow them to take advantage of both web and native app features.
Okay. Specific technologies. That’s good to hear. But instead of then listing those specific technologies, we’re given another list of adjectives (discoverable, installable, linkable, etc.). Again, like Google’s chosen adjectives, they’re very nice and desirable, but not exactly useful to someone who wants to get started making a progressive web app. That’s why I like to cut to the chase and say:
- You need to be running on HTTPS,
- Then you can add a service worker,
- And don’t forget to add a web app manifest file.
If you do that, you’ve got a progressive web app. Now, to be fair, there’a lot that I’m leaving out. Your site should be fast. Your site should be responsive (it is, after all, on the web). There’s not much point mucking about with service workers if you haven’t sorted out the basics first. But those three things—HTTPS + service worker + web app manifest—are specifically what distinguishes a progressive web app. You can—and should—have a reliable, fast, engaging website before turning it into a progressive web app.
I agree with you on the three things that comprise a PWA, but as far as I can tell, you’re the first to declare it as such.
I was quite surprised by that. I always assumed that I was repeating the three ingredients of a progressive web app, not defining them. But looking through all the docs out there, Jason might be right. It’s surprising because I assumed it was obvious why those three things comprise a progressive web app—it’s because they’re testable.
Lighthouse, PWA Builder, Sonarwhal and other tools that evaluate your site will measure its progressive web app score based on the three defining factors (HTTPS, service worker, web app manifest). Then there’s Android’s Add to Home Screen prompt. Here finally we get a concrete description of what your site needs to do to pass muster:
- Includes a web app manifest…
- Served over HTTPS (required for service workers)
- Has registered a service worker with a fetch event handler
Anyway, if you’re looking to turn your website into a progressive web app, here’s what you need to do (assuming it’s already performant and responsive):
- Switch over to HTTPS. Certbot can help you here.
- Add a web app manifest.
- Add a service worker to your site so that it responds even when there’s no network connection.
That last step might sound like an intimidating prospect, but help is at hand: I wrote Going Offline for exactly this situation.
Friday, May 11th, 2018
Here are the slides and links from the talk I just gave at the Delta V conference. I had ten minutes, but to be honest, just saying the name of the talk tells you everything.
Thursday, May 10th, 2018
My publishers asked me some questions. My answers turned out to be more revealing of my inner demons than I was expecting. I hope this isn’t too much oversharing, but I found it quite cathartic.
My greatest fear for the web is that it becomes the domain of an elite priesthood of developers. I firmly believe that, as Tim Berners-Lee put it, “this is for everyone.” And I don’t just mean it’s for everyone to use—I believe it’s for everyone to make as well. That’s why I get very worried by anything that raises the barrier to entry to web design and web development.
Thursday, May 3rd, 2018
It is very disheartening to read misinformation like this:
A progressive web app is an enhanced version of a Single Page App (SPA) with a native app feel.
To quote from The Last Jedi, “Impressive. Everything you just said in that sentence is wrong.”
But once you get over that bit of misinformation at the start, the rest of this article is a good run-down of planning and building a progressive web app using one possible architectural choice—the app shell model. Other choices are available.
Wednesday, May 2nd, 2018
I really enjoyed chatting with Mark and Ben on the Relative Paths podcast. We talked about service workers and Going Offline, but we also had a good musical discussion.
Service worker resources
At the end of my new book, Going Offline, I have a little collection of resources relating to service workers. Here’s how I introduce them:
If this book were a podcast, then this would be the point at which I would be imploring you to rate me on iTunes (or I’d be telling you about a really good mattress). Instead, I’d like to give you some hyperlinks so that you can explore some of the topics in this brief book in more detail.
It always feels a little strange to publish a list of hyperlinks in a physical book, so I figured I’d republish them here for easy access…
- Mariko Kosaka wrote and illustrated an explanation of service workers in a post on her site called “Service Worker, what are you?” (https://kosamari.com/notes/Service-Worker-what-are-you).
- Mariko also wrote and illustrated an explanation of promises called “The Promise of a Burger Party” (https://kosamari.com/notes/the-promise-of-a-burger-party).
- Ire Aderinokun wrote a clear guide to “The Service Worker Lifecycle” (https://bitsofco.de/the-service-worker-lifecycle/).
- Yoav Weiss has an explanation of different kinds of caching in “A Tale of Four Caches” (https://blog.yoav.ws/tale-of-four-caches/).
- Lyza Gardner wrote a step-by-step guide for Smashing Magazine on “Making A Service Worker: A Case Study” (https://www.smashingmagazine.com/2016/02/making-a-service-worker/).
- Jake Archibald has collected a series of service worker strategies into an “offline cookbook” (https://jakearchibald.com/2014/offline-cookbook/).
- Jake also recorded an excellent online video series that you can enjoy for free (https://www.udacity.com/course/offline-web-applications—ud899).
- Mike Riethmuller has on offline page on his site that shows articles you’ve previously visited (https://madebymike.com.au/writing/service-workers/).
- Ethan Marcotte has a similar offline page, but he also shows metadata for each article (https://ethanmarcotte.com/wrote/going-offline/).
- Una Kravets allows you to choose which pages on her site you want to save for reading offline (https://una.im/save-offline/).
Progressive web apps
- Alex Russell answers the question “What, Exactly, Makes Something A Progressive Web App?” (https://infrequently.org/2016/09/what-exactly-makes-something-a-progressive-web-app/).
- Ada Rose Cannon goes into the details of “The Building Blocks Of Progressive Web Apps” (https://www.smashingmagazine.com/2016/09/the-building-blocks-of-progressive-web-apps/).
- Aaron Gustafson quite rightly points out that “Yes, That Web Project Should Be a PWA” (https://alistapart.com/article/yes-that-web-project-should-be-a-pwa).
- Jason Grigsby outlines “The Business Case for Progressive Web Apps” (https://cloudfour.com/thinks/the-business-case-for-progressive-web-apps/).
- Google released a collection of scripts and tools for going offline called Workbox (https://developers.google.com/web/tools/workbox/).
- To get started with your manifest and service worker, you can paste your website’s URL into PWA Builder (http://preview.pwabuilder.com/).
- Lighthouse is a great testing tool for progressive web apps that’s now bundled into Chrome’s Developer Tools under the Audits panel (https://developers.google.com/web/tools/lighthouse/).
Tuesday, May 1st, 2018
Here’s an article from last year that gives a really good introduction to service workers and provides a plug-in for the Craft CMS.
Monday, April 30th, 2018
Here’s a great even-handed in-depth review of Going Offline:
Saturday, April 28th, 2018
A short’n’sweet review of Going Offline:
Jeremy nails it again with this beginner-friendly introduction to Service Workers and Progressive Web Apps. The foreword to the book says “you’ll gain a solid understanding of how to put this new technology to work for you right away” and I’d say that is very accurate.
Friday, April 27th, 2018
This is the first chapter of Going Offline, a brief book about service workers for web designers, published by A Book Apart.
Businesses are built on the web. Without the web, Twitter couldn’t exist. Facebook couldn’t exist. And not just businesses—Wikipedia couldn’t exist. Your favorite blog couldn’t exist without the web. The web doesn’t favor any one kind of use. It’s been deliberately designed to accommodate many and varied activities.
Just as many wonderful things are built upon the web, the web itself is built upon the internet. Though we often use the terms web and internet interchangeably, the World Wide Web is just one application that uses the internet as its plumbing. Email, for instance, is another.
Like the web, the internet was designed to allow all kinds of services to be built on top of it. The internet is a network of networks, all of them agreeing to use the same protocols to shuttle packets of data around. Those packets are transmitted down fiber-optic cables across the ocean floor, bounced around with Wi-Fi or radio signals, or beamed from satellites in freakin’ space.
As long as these networks are working, the web is working. But sometimes networks go bad. Mobile networks have a tendency to get flaky once you’re on a train or in other situations where you’re, y’know, mobile. Wi-Fi networks work fine until you try to use one in a hotel room (their natural enemy).
When the network fails, the web fails. That’s just the way it is, and there’s nothing we can do about it. Until now.
Weaving the Web
For as long as I can remember, the World Wide Web has had an inferiority complex. Back in the ’90s, it was outshone by CD-ROMs (ask your parents). They had video, audio, and a richness that the web couldn’t match. But they lacked links—you couldn’t link from something in one CD-ROM to something in another CD-ROM. They faded away. The web grew.
These days it’s native apps that make the web look like an underachiever. Like Flash, they’re under the control of individual companies instead of being a shared resource like the web. Like Flash, they demonstrate all sorts of capabilities that the web lacks, such as access to device APIs and, crucially, the ability to work even when there’s no network connection.
The history of the web starts to sound like an endless retelling of the fable of the tortoise and the hare. CD-ROMs, Flash, and native apps outshine the web in the short term, but the web always seems to win the day somehow.
A service worker is like a web worker with extra powers. It still can’t access the DOM, but it does have access to the fundamental inner workings of the browser.
Browsers and Servers
Let’s take a step back and think about how the World Wide Web works. It’s a beautiful ballet of client and server. The client is usually a web browser—or, to use the parlance of web standards, a user agent: a piece of software that acts on behalf of the user.
The user wants to accomplish a task or find some information. The URL is the key technology that will empower the user in their quest. They will either type a URL into their web browser or follow a link to get there. This is the point at which the web browser—or client—makes a request to a web server. Before the request can reach the server, it must traverse the internet of undersea cables, radio towers, and even the occasional satellite (Fig 1.1).
Imagine if you could leave instructions for the web browser that would be executed before the request is even sent. That’s exactly what service workers allow you to do (Fig 1.2).
Getting Your Head Around Service Workers
A service worker is like a cookie. Cookies are downloaded from a web server and installed in a browser. You can go to your browser’s preferences and see all the cookies that have been installed by sites you’ve visited. Cookies are very small and very simple little text files. A website can set a cookie, read a cookie, and update a cookie. A service worker script is much more powerful. It contains a set of instructions that the browser will consult before making any requests to the site that originally installed the service worker.
A service worker is like a virus. When you visit a website, a service worker is surreptitiously installed in the background. Afterwards, whenever you make a request to that website, your request will be intercepted by the service worker first. Your computer or phone becomes the home for service workers lurking in wait, ready to perform man-in-the-middle attacks. Don’t panic. A service worker can only handle requests for the site that originally installed that service worker. When you write a service worker, you can only use it to perform man-in-the-middle attacks on your own website.
A service worker is like a toolbox. By itself, a service worker can’t do much. But it allows you to access some very powerful browser features, like the Fetch API, the Cache API, and even notifications. API stands for Application Programming Interface, which sounds very fancy but really just means a tool that you can program however you want. You can write a set of instructions in your service worker to take advantage of these tools. Most of your instructions will be written as “when this happens, reach for this tool.” If, for instance, the network connection fails, you can instruct the service worker to retrieve a backup file using the Cache API.
A service worker is like a duck-billed platypus. The platypus not only lactates, but also lays eggs. It’s the only mammal capable of making its own custard. A service worker can also…Actually, hang on, a service worker is nothing like a duck-billed platypus! Sorry about that. But a service worker is somewhat like a cookie, and somewhat like a virus, and somewhat like a toolbox.
Service workers are powerful. Once a service worker has been installed on your machine, it lies in wait, like a patient spider waiting to feel the vibrations of a particular thread.
Imagine if a malicious ne’er-do-well wanted to wreak havoc by impersonating a website in order to install a service worker. They could write instructions in the service worker to prevent the website ever appearing in that browser again. Or they could write instructions to swap out the content displayed under that site’s domain. That’s why it’s so important to make sure that a service worker really belongs to the site it claims to come from. As the specification for service workers puts it, they “create the opportunity for a bad actor to turn a bad day into a bad eternity.”
To prevent this calamity, service workers require you to adhere to two policies:
- Same origin.
- HTTPS only.
The same-origin policy means that a website at example.com can only install a service worker script that lives at example.com. That means you can’t put your service worker script on a different domain. You can use a domain like for hosting your images and other assets, but not your service worker script. That domain wouldn’t match the domain of the site installing the service worker.
The HTTPS-only policy means that https://example.com can install a service worker, but http://example.com can’t. A site running under HTTPS (the S stands for Secure) instead of HTTP is much harder to spoof. Without HTTPS, the communication between a browser and a server could be intercepted and altered. If you’re sitting in a coffee shop with an open Wi-Fi network, there’s no guarantee that anything you’re reading in browser from http://newswebsite.com hasn’t been tampered with. But if you’re reading something from https://newswebsite.com, you can be pretty sure you’re getting what you asked for.
Securing Your Site
There’s one exception. You can use a service worker on a site being served from localhost, a web server on your own computer, not part of the web. That means you can play around with service workers without having to deploy your code to a live site every time you want to test something.
If you’re using a Mac, you can spin up a local server from the command line. Let’s say your website is in a folder called
mysite. Drag that folder to the Terminal app, or open up the Terminal app and navigate to that folder using the
cd command to change directory. Then type:
python -m SimpleHTTPServer 8000
This starts a web server from the
mysite folder, served over port 8000. Now you can visit localhost:8000 in a web browser on the same computer, which means you can add a service worker to the website you’ve got inside the
mysite folder: http://localhost:8000.
But if you then put the site live at, say, http://mysite.com, the service worker won’t run. You’ll need to serve the site from https://mysite.com instead. To do that, you need a secure certificate for your server.
There was a time when certificates cost money and were difficult to install. Now, thanks to a service called Certbot, certificates are free. But I’m not going to lie: it still feels a bit intimidating to install the certificate. There’s something about logging on to a server and typing commands that makes me simultaneously feel like a l33t hacker, and also like I’m going to break everything. Fortunately, the process of using Certbot is relatively jargon-free (Fig 1.3).
On the Certbot website, you choose which kind of web server and operating system your site is running on. From there you’ll be guided step-by-step through the commands you need to type in the command line of your web server’s computer, which means you’ll need to have SSH access to that machine. If you’re on shared hosting, that might not be possible. In that case, check to see if your hosting provider offers secure certificates. If not, please pester them to do so, or switch to a hosting provider that can serve your site over HTTPS.
Another option is to stay with your current hosting provider, but use a service like Cloudflare to act as a “front” for your website. These services can serve your website’s files from data centers around the world, making sure that the physical distance between your site’s visitors and your site’s files is nice and short. And while they’re at it, these services can make sure all of those files are served over HTTPS.
Once you’re set up with HTTPS, you’re ready to write a service worker script. It’s time to open up your favorite text editor. You’re about to turbocharge your website!
Wednesday, April 25th, 2018
Jeremy’s technical writing is as superb as always. Similar to his first book for A Book Apart, which cleared up all my confusions about HTML5, Going Offline helps me put the pieces of the service workers’ puzzle together.
It feels a little strange to refer to Going Offline as “my” book. I may have written most of the words in it, but it was only thanks to the work of others that they ended up being the right words in the right order in the right format.
I’ve included acknowledgements in the book, but I thought it would be good to reproduce them here in the form of hypertext…
Everyone should experience the joy of working with Katel LeDû and Lisa Maria Martin. From the first discussions right up until the final last-minute tweaks, they were unflaggingly fun to collaborate with. Thank you, Katel, for turning my idea into reality. Thank you, Lisa Maria, for turning my initial mush of words into a far more coherent mush of words.
Jake Archibald and Amber Wilson were the best of technical editors. Jake literally wrote the spec on service workers so I knew I could rely on him to let me know whenever I made any factual missteps. Meanwhile Amber kept me on the straight and narrow, letting me know whenever the writing was becoming unclear. Thank you both for being so generous with your time.
Thanks to my fellow Clearlefty Danielle Huntrods for giving me feedback as the book developed.
Finally, I want to express my heartfelt thanks to everyone who has ever taken the time to write on their website about their experiences with service workers. Lyza Gardner, Ire Aderinokun, Una Kravets, Mariko Kosaka, Jason Grigsby, Ethan Marcotte, Mike Riethmuller, and others inspired me with their generosity. Thank you to everyone who’s making the web better through such kind acts of openness. To quote the original motto of the World Wide Web project, let’s share what we know.
Tuesday, April 24th, 2018
Going Offline, available now!
The day is upon us! The hour is at hand! The book is well and truly apart!
If you pre-ordered the book, thank you. An email is winging its way to you with download details for the digital edition. If you ordered the paperback, the Elves Apart are shipping your lovingly crafted book to you right now.
If you didn’t pre-order the book, I grudgingly admire your cautiousness, but don’t you think it’s time to throw caution to the wind and treat yourself?
Seriously though, I think you’ll like this book. And I’m not the only one. Here’s what people are saying:
I know you have a pile of professional books to read, but this one should skip the line.
It is so good. So, so good. I cannot recommend it enough.
Super approachable and super easy to follow regardless of your level of knowledge.
—also Sara Soueidan
You’re gonna want to preorder a copy, believe me.
Beautifully explained without being patronising.
I very much look forward to hearing what you think of Going Offline. Get your copy today and let me know what you think of it. Like I said, I think you’ll like this book. Apart.
Monday, April 23rd, 2018
Sara describes the process of turning her site into a progressive web app, and has some very kind words to say about my new book:
Jeremy covers literally everything you need to know to write and install your first Service Worker, tweak it to your site’s needs, and then write the Web App Manifest file to complete the offline experience, all in a ridiculously easy to follow style. It doesn’t matter if you’re a designer, a junior developer or an experienced engineer — this book is perfect for anyone who wants to learn about Service Workers and take their Web application to a whole new level.
Too, too kind!
I highly recommend it. I read the book over the course of two days, but it can easily be read in half a day. And as someone who rarely ever reads a book cover to cover (I tend to quit halfway through most books), this says a lot about how good it is.
Thursday, April 19th, 2018
That new-book smell
The first copies of Going Offline showed up today! This is my own personal stash, sent just a few days before the official shipping date of next Monday.
To say I was excited when I opened the box of books would be an understatement. I was positively squealing with joy!
Others in the Clearleft office shared in my excitement. Everyone did that inevitable thing, where you take a fresh-out-of-the-box book, open it up and press it against your nose. It’s like the bookworm equivalent of sniffing glue.
Actually, it basically is sniffing glue. I mean, that’s what’s in the book binding. But let’s pretend that we’re breathing in the intoxicating aroma of freshly-minted words.
If you’d like to bury your nose in a collection of my words glued together in a beautifully-designed package, you can pre-order the book now and await delivery of the paperback next week.
Tuesday, April 17th, 2018
Two technical editors worked with me on Going Offline.
Jake was one of the tech editors. He literally (co-)wrote the spec on service workers. There ain’t nuthin’ he don’t know about the code involved. His job was to catch any technical inaccuracies in my writing.
I deliberately didn’t wait until I was an expert in this topic before writing Going Offline. I knew that the more familiar I became with the ins-and-outs of getting a service worker up and running, the harder it would be for me to remember what it was like not to know that stuff. I figured the best way to avoid the curse of knowledge would be not to accrue too much of it. But then once I started researching and writing, I inevitably became more au fait with the topic. I had to try to battle against that, trying to keep a beginner’s mind.
My watchword was this great piece of advice from Codebar:
Assume that anyone you’re teaching has no knowledge but infinite intelligence.
It was tricky. I’m still not sure if I managed to pull off the balancing act, although early reports are very, very encouraging. You’ll be able to judge for yourself soon enough. The book is shipping at the start of next week. Get your order in now.
Sunday, April 15th, 2018
The audience for Going Offline
I didn’t want to overwhelm the reader with lots of code up front, so I’ve tried to dole it out in manageable chunks. The amount of code ramps up a little bit in each chapter until it peaks in chapter five. After that, it ramps down a bit with each subsequent chapter.
This tweet perfectly encapsulates the audience I had in mind for the book:
I pre-ordered it, and I’m excited about it. I’ve been curious about service workers for a long time, but have been nervous about actually writing one.— Matthew J Derocher (@mjamesderocher) April 13, 2018
Some people have received advance copies of the PDF, and I’m very happy with the feedback I’m getting.
Seriously applauding the author for explaining how to run a local server in passing, in like 3 lines.— Lívia De Paula Labate (@livlab) April 5, 2018
People do not understand how this is a massive barrier to designers who are interested but don’t know how/are new to coding.
Here I am all self-congratulatory “yes, yes, I am understanding service workers much now…”— Lívia De Paula Labate (@livlab) April 6, 2018
How is this happening: it did not tell me upfront I needed to learn it, it did not even tell me it was going to teach me.— Lívia De Paula Labate (@livlab) April 6, 2018
Ok, I’m done reading @adactio’s Going Offline book and as my wife would say, it’s the bomb dot com.— Lívia De Paula Labate (@livlab) April 15, 2018
You can check the thread above for some impressions, but definitely read it. It is a _very_ gentle introduction to technology we are going to use A LOT.
Honestly, that is so, so gratifying to hear!
Words cannot express how delighted I am with Sara’s reaction:
Today I finished reading @adactio ’s new book: Going Offline. As someone who rarely ever reads a book cover to cover, this alone says a lot about how good the book is.— Sara Soueidan (@SaraSoueidan) April 13, 2018
It is *so* good. So, so good. I cannot recommend it enough: abookapart.com/products/going-offline
I’ll tweet about this in time, but for now: THANK YOU for a WONDERFUL book. I can’t believe how approachable you made SWs with your writing style. I’d recommend it to everyone in a heart beat.— Sara Soueidan (@SaraSoueidan) April 12, 2018
She’s walking the walk too:
I’m expecting weird or inconsistent behavior / bugs at this point (still need to test!) BUT I can finally say that sarasoueidan.com is now officially a Progressive Web App. 🎉— Sara Soueidan (@SaraSoueidan) April 13, 2018
✅ HTTPS (long ago)
✅ Service Worker (since yesterday)
✅ Manifest (added today)
That gives me a warm fuzzy glow!
If you’ve been nervous about service workers, but you’ve always wanted to turn your site into a progressive web app, you should get a copy of this book.