Stuart writes up the process up making a mobile game as a web app—not a native app. The Wordle effect reverberates.
It’s a web app. Works for everyone. And I thought it would be useful to explain why it is, why I think that’s the way to do things, and some of the interesting parts of building an app for everyone to play which is delivered over the web rather than via app stores and downloads.
Much as I appreciate the optimism of this evaluation, I don’t hold out much hope that people’s expectations are going to change any time soon:
Indeed, when given a choice, users will opt for the [native] app version of a platform because it’s been considered the gold standard for reliability. With progressive web apps (PWAs), that assumption is about to change.
Nonetheless, this is a level-headed look at what a progressive web app is, mercifully free of hand-waving:
- App is served through HTTPS.
- App has a web app manifest with at least one icon. (We’ll talk more about the manifest shortly.)
- App has a registered service worker with a fetch event handler. (More on this later too.)
This is a really excellent four-part series on web performance that really dives into the technical details and asks all the right questions:
The headline is a little misleading because if you follow this advice, your multi-page apps will be much much faster than single page apps, especially when you include that initial page load of a single page app.
Here’s a quick high-level summary of what I do…
That’s an excellent recipe for success right there!
Damn, I wish I had thought of giving this answer to the prompt, “What is one thing people can do to make their website better?”
If you do nothing else, this will be a huge boost to your site in 2022.
Chris’s piece is a self-contained tutorial!
The slides from Aaron’s workshop at today’s PWA Summit. I really like the idea of checking navigator.connection.downlink and navigator.connection.saveData inside a service worker to serve different or fewer assets!
This is terrific! Jeremy shows how you can implement a fairly straightforward service worker for performance gains, but then really kicks it up a notch with a recipe for turning a regular website into a speedy single page app without framework bloat.
It’s official. The extremely niche browser behaviour I documented is a bug.
This in an intriguing promise (there’s no code yet):
A PWA typically requires writing a service worker, an app manifest and a ton of custom code. Progressier flattens the learning curve. Just add it to your html template — you’re done.
I worry that this one line of code will pull in many, many, many, many lines of JavaScript.
This is a great way to use a service worker to circumvent censorship:
After the visitor opens the website once over a VPN, the service worker is downloaded and installed. The VPN can then be disabled, and the service worker will take over to request content from non-blocked servers, effectively acting as a proxy.
Chris Ferdinandi blogs every day about the power of vanilla JavaScript. For over a week now, his daily posts have been about service workers. The cumulative result is this excellent collection of resources.
So, why would you want to use a service worker? Here are some cool things you can do with it.
Chris lists some of the ways a service worker can enhance user experience.
A Chrome-only API for adding offline content to an index that can be exposed in Android’s “downloads” list. It just shipped in the lastest version of Chrome.
I’m not a fan of browser-specific non-standards but you can treat this as an enhancement—implementing it doesn’t harm non-supporting browsers and you can use feature detection to test for it.
How do we tell our visitors our sites work offline? How do we tell our visitors that they don’t need an app because it’s no more capable than the URL they’re on right now?
Remy expands on his call for ideas on branding websites that work offline with a universal symbol, along the lines of what we had with RSS.
What I’d personally like to see as an outcome: some simple iconography that I can use on my own site and other projects that can offer ambient badging to reassure my visitor that the URL they’re visiting will work offline.
This is an interesting push by Remy to try to figure out a way we can collectively indicate to users that a site works offline.
Well, seeing as browsers have completely dropped the ball on any kind of ambient badging, it’s fair enough that we take matters into our own hands.
Tantek documents the features he wants his posting interface to have.
This is a great progressive enhancement for performance that uses a service worker to combine reusable bits of a page with fresh content. The numbers are very convincing!
Alas, the code is using the Workbox library, but figuring out the vanilla code to write shouldn’t be too tricky seeing as Philip talks through his logic step by step.
This is a great proposal that would make the Cache API even more powerful by adding metadata to cached items, like when it was cached, how big it is, and how many times it’s been retrieved.
Creating a PWA has saved a lot of kilobytes after the initial load by storing files on the device to reuse on subsequent requests – this in turn lowers the load time and carbon footprint on subsequent page views, making the website better for both people and planet. We’ve also enabled offline access, which significantly improves user experience for people in areas with patchy connections, such as mobile users on their commute.
This is the transcript of a brilliant presentation by Scott—read the whole thing! It starts with a much-needed history lesson that gets to where we are now with the dismal state of performance on the web, and then gives a whole truckload of handy tips and tricks for improving performance when it comes to styles, scripts, images, fonts, and just about everything on the front end.
Essential!