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:
- switch over to HTTPS,
- add a JSON manifest file with your metacrap, and
- add a service worker.
That last step can be tricky if you’re new to service workers, but it’s not unsurmountable. It’s certainly a lot easier than completely rearchitecting your existing website to be a JavaScript-driven single page 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:
- HTTPS,
- 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.
Jason has been thinking about progressive web apps a lot lately (he should write a book or something), and he said to me:
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
(Although, as of this month, Chrome will no longer show the prompt automatically — you also have to write some JavaScript to handle the beforeinstallprompt event).
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.
This was originally posted on my own site.
