Maximiliano Firtman has a look at PWAs this year, including trying to get a bead on how widespread they are:
At the end of 2020, approximately 1% of websites included a Service Worker, and 2.2% had an installable Web App Manifest file. Remember that some platforms -such as Safari on iOS or Chrome on Android- do not require a Service Worker to have a standalone experience after installation. We can assume that 2.2% of websites are installable, and 1% may pass the PWA criteria on Android, 71% of which offer some offline experience.
That data is from the HTTP Archive, which looked at 7.5 million websites. So 1% might seem like a small number, but that’s lots of sites with PWA tech on them, and 170% year-over-year growth. Those are just the minimum requirements, though. I’m sure fully embracing PWA-ness (e.g. real offline usage) is a tiny fraction of that. Maximiliano has lots of more detailed data, so be sure to dig into the article if you’re interested in the nuance.
Anecdotally, I’d say PWAs fell out of general conversation last year. I don’t think anybody is exactly against the technologies that make them up, but they aren’t embracing them either. My guess? Everyone is scared of Service Workers. I’m scared of Service Workers. They do scary things, like aggressively hold onto cache. I think a whole dev team really needs to understand them and embrace them into their workflow and build process for them to be effective. Generally speaking, we just aren’t there yet.
Although points about Apple are OK I think points against Mozilla were a bit biased: their opinions on proposed APIs are public and many features they’re not willing to support had risks to hurt privacy.
Let me talk about one I’m interested: Local Font Access. It’s amazing! Websites migrating from Flash can use local fonts without issues (like a certain website which uses libass for subtitle rendering and relied on local fonts, so many subtitles broke when they migrated from Flash).
In the other hand, the proposal tried to explain that it will not hurt privacy, but seems it omitted some details: it allows access to font data, take those, hash and you get a super-cookie that persists between browser data cleaning. The spec say browsers don’t need to return real data, but this “solution” reduces a lot the use cases of this API. I know there is canvas fingerprinting, but by allowing direct access to font blobs it would be way more powerful. Oh, there’s a permission prompt? Remember the mess from allowing notification prompts?
New ideas to make Web Apps better is great, but taking ideas made mostly by a group that IMHO don’t take privacy too seriously hurts the web. I like the idea of using local fonts, would help a lot fixing the migration issue, but at the cost of a super-cookie? No. Rethink this proposal before forcing it into Apple or Mozilla. Are there other proposals with hidden caveats? I think so.
What I hope? That people could work together for the interest of the community instead of the usual “let’s take the Cloudflare token idea and make it a Web API so we can improve our ad platform and make it look more secure to publishers”. Even if the crypto looks safe and protects privacy, IMHO the reasoning is weird. Many say Apple hurts the web to protect their store but I would say Google hurts the web by making the new “This website works best with Internet Explorer”, but with Chromium based browsers.
Lack of browser support doesn’t help: https://www.fastcompany.com/90597411/mozilla-firefox-no-ssb-pwa-support
For my part, I am surprised that this approach / technology does not penetrate the market the fastest.
It makes websites much faster, but I didn’t know there were so many downsides.
Good article!
Great article. Thank you for sharing this.
In your newsletter you say “It’s not obvious you can install a website in the browser.” and that it’s a “huge missing piece of the puzzle”. Once people do it a couple of times I don’t think this will be a hurdle. The graphic Google made to guide user’s on how to install a PWA was clear and simple. People didn’t have innate knowledge on how to use touch screens, once someone see’s how to use one… they’re off.
Service workers aren’t intuitive, but Workbox makes them easier to deal with and once they’re set up, they rarely need tweaking.
Unfortunately I’m not surprised by Apple’s bullying tactics, I don’t expect it to change, but the failure of Mozilla’s leadership over the past year or so is gobsmacking. Such a talent filled organisation being led by donkeys.
The Fugu project looks amazing… so many fun, useful and powerful things being put into the hands of web developers! The future is bright.
Great article. Service Workers can make sites faster by prefetching data for next page links. We thought they would be easy to configure but they are a bear, especially when ensuring the caching is in sync with the edge and server caches and all versions and variations. The results are worth it, start browsing a few of these sites: https://www.katespade.com (React), https://universalstandard.com (Nuxt), & https://www.sharperimage.com (Next).
You can read about how these sites were set up here: https://developer.moovweb.com/guides/prefetching