The Progressive Web App term is now five years old, and it’s time to sit down and understand where we are at 2021 within the platform, what has changed during 2020 and what we are expecting for the upcoming months.
It shouldn’t surprise you while reading that iOS is the bottleneck here …
Very nice video by Sam Selikoff in which he sets up a web manifest to make his site feel more app-like. Great production quality.
There are some tweaks I’d suggest though:
Fixate the header using position: sticky; instead of position: fixed;. No need for that extra margin on the content then. Update: See note below
Don’t set the header height to a fixed number, as not all devices have (equally sized) notches. Use the User Agent Variable safe-area-inset-top instead, and apply it as the top padding:
header {
padding-top: env(safe-area-inset-top);
}
Don’t disable scaling in case your app does not follow the system font sizing — which it does not by default. To make it do follow the system font sizing, use this snippet:
@supports (font: -apple-system-body) {
html {
font: -apple-system-body;
}
}
💡 You can still override the font-family after that. That way you can have your custom font and also follow the preferred system Text Size
As an extra: to prevent that long-press behavior when the app is not added to the home screen, set -webkit-touch-callout: none; on the links.
On Twitter Sam pointed me out that when using position: sticky; there’s an issue with overscroll/bounce: The header will shift down along with the body as you do so.
We return to take a closer look at Progressive Web Apps (PWAs) and how they combine the reach of the web with the device integrations of installed software. In this ebook, Volume 2 in the series, you will learn:
The capabilities of Progressive Web Apps
Product strategies for deploying PWAs
Promotional patterns for driving installs of PWAs
UX best practices for designing installed experiences that work reliably offline
How to implement analytics to measure business impact.
While testing a progressive web app for one of our clients, I bumped into a suspicious error in the browser console: DOMException: Quota exceeded.
After browsing the app a few more times, it became clear the error would occur after a small number of images were added to the cache storage by the service worker. Looking in the Chrome DevTools Application tab, the cache storage was indeed over capacity.
How could this be? There were only ~15 images in the cache storage. Something was off.
If you’ve totally missed out on PWAs, then this summarising video by Pete LePage is a good start. If you know what PWAs are then you might want to skip forward to the 8:30 mark, where details on the Twitter PWA (which might come to macOS soon?) are shared.
In the first part of the Progressive Web App video series, you’ll find out how others have successfully used PWAs to improve their user experience and learn some of the key concepts behind PWAs.
Recently it was announced that iOS 11.3 and macOS 10.13.4 will include Service Workers, opening up the way for PWAs on iOS (and potentially macOS too, following lead of Microsoft here).
☝️ If you don’t want to download the macOS 10.13.4 beta you can alternatively download Safari Technology Preview (> 48) for use with your current macOS install.
Great news indeed, yet as Maximiliano Firtman documented there are quite a few caveats right now. Some might get fixed, yet some others won’t. One of the bigger issues I find worrying is the fact that you can end up with different versions of one and the same PWA, depending on the context you are running it in:
On Safari, on each app’s Web view, and home screen web apps, the engine doesn’t share Service Workers nor the Cache Storage, which means the user might end with several copies of all the files for the PWA on the same device.
Tinder recently swiped right on the web. Their new responsive Progressive Web App — Tinder Online — is available to 100% of users on desktop and mobile, employing techniques for JavaScript performance optimization, Service Workers for network resilience and Push Notifications for chat engagement. Today we’ll walk through some of their web perf learnings.
Service Worker Toolbox provides some simple helpers for use in creating your own service workers. Specifically, it provides common caching strategies for dynamic content, such as API calls, third-party resources, and large or infrequently used local resources that you don’t want precached.
A bit more advanced is to precache a “you’re offline” page first, and return that in case a user is offline (src):
importScripts('sw-toolbox.js');
toolbox.precache([
'/offline',
'/img/offline.png',
// …
]);
// …
toolbox.router.get('/(.*)', function(request, values, options) {
// networkFirst will attempt to return a response from the network,
// then attempt to return a response from the cache.
return toolbox.networkFirst(request, values, options).catch(function(error) {
// If both the network and the cache fail, then `.catch()` will be triggered,
// and we get a chance to respond with our cached fallback page.
if (request.method === 'GET' && request.headers.get('accept').includes('text/html')) {
return toolbox.cacheOnly(new Request('/offline'), values, options);
}
throw error;
});
});
In this series of posts I’ll share my experience turning React-based web apps into PWAs. We’ll also cover why shipping just what users need for a route & throwing out all other scripts are good ideas for fast perf.
As with all articles by Addy: well-written, accurate, and complete.