Sam Richard on web.dev

New Progressive Web App training now available

2021-05-20T00:00:00Z

A lot has changed in the world of Progressive Web Apps since we released our last set of PWA training over four years ago: CSS Grid achieved widespread implementation, PWAs came to desktops, and the capabilities project has launched more than 25 new device-integration focused APIs, opening up brand new app segments that can be built entirely on the web. Today, we're excited to share the first iteration of our newly updated PWA training to teach you how to build reliable, installable, and capable Progressive Web Apps for all devices.

The current version of the training is divided into six slide decks, ready for you to learn from or for you to pick up and teach to others. They are:

To go along with this new material, there are eight new codelabs that will guide you through turning a web app into a Progressive Web App with deep device integration, using the concepts taught throughout the slide decks. You can jump into any codelab and work on it individually, or you can go through them one after another; the choice is yours. They are:

Going Offline - Basics of writing a service worker to cache and serve content offline
Working with Workbox - Using Workbox to write your service worker
IndexedDB - Using IndexedDB to store and retrieve data
Tab to Taskbar - Making your web app installable and providing app shortcuts
Prompting and Measuring Install - Adding in-app install prompts, and where to put success tracking
Empowering your PWA - Adding advanced capabilities, including accessing the local file system and registering as a file handler
Service Worker Includes - Dynamically generating a streaming service worker response
Working with Workers - Using web workers to offload work from the main thread

Over the next few months, we'll be converting the slide deck content into easier-to-consume and update formats. This will make it easier for us to keep the content up-to-date, so no more waiting four years for another push of content. Keep an eye on this space. The future of web apps is exciting, and we're thrilled to teach you how to build it.

What makes a good Progressive Web App?

2020-01-06T00:00:00Z

Progressive Web Apps (PWA) are built and enhanced with modern APIs to deliver enhanced capabilities, reliability, and installability while reaching anyone, anywhere, on any device with a single codebase. To help you create the best possible experience, use the core and optimal checklists and recommendations to guide you.

Core Progressive Web App checklist #

The Progressive Web App Checklist describes what makes an app installable and usable by all users, regardless of size or input type.

Starts fast, stays fast

Performance plays a significant role in the success of any online experience, because high performing sites engage and retain users better than poorly performing ones. Sites should focus on optimizing for user-centric performance metrics.

Why #

Speed is critical for getting users to use your app. In fact, as page load times go from one second to ten seconds, the probability of a user bouncing increases by 123%. Performance doesn't stop with the load event. Users should never wonder whether their interaction—for example, clicking a button—was registered or not. Scrolling and animation should feel smooth. Performance affects your entire experience, from how users perceive your application to how it actually performs.

While all applications have different needs, the performance audits in Lighthouse are based on the Core Web Vitals, and scoring high on those audits will make it more likely that your users have an enjoyable experience. You can also use PageSpeed Insights or the Chrome User Experience Report to get real-world performance data for your web app.

How #

Follow our guide on fast load times to learn how to make your PWA start fast and stay fast.

Works in any browser

Users can use any browser they choose to access your web app before it's installed.

Why #

Progressive Web Apps are web apps first, and that means they need to work across browsers, not just in one of them.

An effective way of doing this is by, in the words of Jeremy Keith in Resilient Web Design, identifying the core functionality, making that functionality available using the simplest possible technology, and then enhancing the experience where possible. In many cases, this means starting with just HTML to create the core functionality, and enhancing the user experience with CSS and JavaScript to create a more engaging experience.

Take form submission for example. The simplest way to implement that is an HTML form that submits a POST request. After building that, you can enhance the experience with JavaScript to do form validation and submit the form via AJAX, improving the experience for users who can support it.

Consider that your users will experience your site across a spectrum of devices and browsers. You cannot simply target the top end of the spectrum. By using feature detection, you'll be able to deliver a usable experience for the widest range of potential users, including those using browsers and devices that may not exist today.

How #

Jeremy Keith's Resilient Web Design is an excellent resource describing how to think about web design in this cross-browser, progressive methodology.

Additional reading #

A List Apart's Understanding Progressive Enhancement is a good introduction to the topic.
Smashing Magazine's Progressive Enhancement: What It Is, And How To Use It? gives a practical introduction and links to more advanced topics.
MDN has an article titled Implementing feature detection that talks about how to detect a feature by directly querying it.

Responsive to any screen size

Users can use your PWA on any screen size and all of the content is available at any viewport size.

Why #

Devices come in a range of sizes, and users may use your application at a range of sizes, even on the same device. Therefore, it's critical to ensure your content not only fits within the viewport, but that all features and content for your site are usable at all viewport sizes.

The tasks users want to complete and the content they want to access do not change with viewport size. The content can be rearranged at different viewport sizes, and it should all be there, one way or another. In fact, as Luke Wroblewski states in his book Mobile First, starting small and going large instead of the other way around can actually improve a site's design:

Mobile devices require software development teams to focus on only the most important data and actions in an application. There simply isn't room in a 320 by 480 pixel screen for extraneous, unnecessary elements. You have to prioritize.

How #

There are many resources on responsive design, including the original article by Ethan Marcotte, a collection of important concepts related to it, as well as books and talks galore. To narrow this discussion down to the content aspects of responsive design, you can dig into content-first design and content-out responsive layouts. Finally, while it's focused on mobile, the lessons in Seven Deadly Mobile Myths by Josh Clark are just as relevant to small-sized views of responsive sites as they are to mobile.

Provides a custom offline page

When users are offline, keeping them in your PWA provides a more seamless experience than dropping back to the default browser offline page.

Why #

Users expect installed apps to work regardless of their connection status. A platform-specific app never shows a blank page when it is offline, and a Progressive Web App should never show the browser default offline page. Providing a custom offline experience, both when a user navigates to a URL that hasn't been cached and when a user tries to use a feature that requires a connection, helps your web experience feel like it's part of the device it's running on.

How #

During a service worker's install event, you can precache a custom offline page for later use. If a user goes offline, you can respond with the precached custom offline page. You can follow our custom offline page sample to see an example of this in action and learn how to implement it yourself.

Is installable

Users who install or add apps to their device tend to engage with those apps more.

Why #

Installing a Progressive Web App allows it to look, feel, and behave like all other installed apps. It's launched from the same place users launch their other apps. It runs in its own app window, separate from the browser, and it appears in the task list, just like other apps.

Why would you want a user to install your PWA? The same reason you'd want a user to install your app from an app store. Users who install your apps are your most engaged audience, and have better engagement metrics than typical visitors, often at parity with app users on mobile devices. These metrics include more repeat visits, longer times on your site and higher conversion rates.

How #

You can follow our installable guide to learn how to make your PWA installable, how to test to see that it's installable, and try doing it yourself.

Optimal Progressive Web App checklist #

To create a truly great Progressive Web App, one that feels like a best-in-class app, you need more than just the core checklist. The optimal Progressive Web App checklist is about making your PWA feel like it's part of the device it's running on while taking advantage of what makes the web powerful.

Provides an offline experience

Where connectivity isn't strictly required, your app works the same offline as it does online.

Why #

In addition to providing a custom offline page, users expect Progressive Web Apps to be usable offline. For example, travel and airline apps should have trip details and boarding passes easily available when offline. Music, video, and podcasting apps should allow for offline playback. Social and news apps should cache recent content so users can read it when offline. Users also expect to stay authenticated when offline, so design for offline authentication. An offline PWA provides a true app-like experience for users.

How #

After determining which features your users expect to work offline, you'll need to make your content available and adaptable to offline contexts. In addition, you can use IndexedDB, an in-browser NoSQL storage system, to store and retrieve data, and background sync to allow users to take actions while offline and defer server communications until the user has a stable connection again. You can also use service workers to store other kinds of content, such as images, video files, and audio files for offline use, as well as use them to implement safe, long-lived sessions to keep users authenticated. From a user experience perspective, you can use skeleton screens that give users a perception of speed and content while loading that can then fall back to cached content or an offline indicator as needed.

Is fully accessible

All user interactions pass WCAG 2.0 accessibility requirements.

Why #

Most people at some point in their life will want to take advantage of your PWA in a way that is covered under the WCAG 2.0 accessibility requirements. Humans' ability to interact with and understand your PWA exist on a spectrum and needs can be temporary or permanent. By making your PWA accessible, you ensure it's usable for everyone.

How #

W3C's Introduction to Web Accessibility is a good place to start. A majority of accessibility testing must be done manually. Tools like the Accessibility audits in Lighthouse, axe, and Accessibility Insights can help you automate some accessibility testing. It's also important to use semantically correct elements instead of recreating those elements on your own, for instance, a and button elements. This ensures that when you do need to build more advanced functionality, accessible expectations are met (such as when to use arrows vs. tabs). A11Y Nutrition Cards has excellent advice on this for some common components.

Can be discovered through search

Your PWA can be easily discovered through search.

Why #

One of the biggest advantages of the web is the ability to discover sites and apps through search. In fact, more than half of all website traffic comes from organic search. Making sure that canonical URLs exist for content and that search engines can index your site is critical for users to be able to find your PWA. This is especially true when adopting client-side rendering.

How #

Start by ensuring that each URL has a unique, descriptive title and meta description. Then you can use the Google Search Console and the Search Engine Optimization audits in Lighthouse to help you debug and fix discoverability issues with your PWA. You can also use Bing's or Yandex's webmaster tools, and consider including structured data via schemas from Schema.org in your PWA.

Works with any input type

Your PWA is equally usable with a mouse, a keyboard, a stylus, or touch.

Why #

Devices offer a variety of input methods, and users should be able to seamlessly switch between them while using your application. Just as important, input methods should not depend on screen size, meaning that large viewports need to support touch and small viewports need to support keyboards and mice. To the best of your ability, ensure that your application and all of its features supports usage of any input method your user may choose to use. Where appropriate, you should also enhance experiences to allow for input-specific controls as well (such as pull-to-refresh).

How #

The Pointer Events API provides a unified interface for working with various input options, and is especially good for adding stylus support. For supporting both touch and keyboard, ensure that you're using the correct semantic elements (anchors, buttons, form controls, etc.) and not rebuilding these with non-semantic HTML (which is good for accessibility). When including interactions that activate on hover, ensure they can activate on click or tap, too.

Provides context for permission requests

When asking permission to use powerful APIs, provide context and ask only when the API is needed.

Why #

APIs that trigger a permission prompt, like notifications, geolocation, and credentials, are intentionally designed to be disruptive to a user because they tend to be related to powerful functionality that requires opt-in. Triggering these prompts without additional context, like on page load, makes users less likely to accept those permissions and more likely to distrust them in the future. Instead, only trigger those prompts after providing an in-context rationale to the user for why you need that permission.

How #

The Permission UX article and UX Planet's The Right Ways to Ask Users for Permissions are good resources to understand how to design permission prompts that, while focused on mobile, apply to all PWAs.

Follows best practices for healthy code

Keeping your codebase healthy makes it easier to meet your goals and deliver new features.

Why #

There's a lot that goes into building a modern web application. Keeping your application up-to-date and your codebase healthy makes it easier for you to deliver new features that meet the other goals laid out in this checklist.

How #

There are a number of high-priority checks to ensure a healthy codebase: avoiding using libraries with known vulnerabilities, ensuring you're not using deprecated APIs, removing web anti-patterns from your codebase (like using document.write() or having non-passive scroll event listeners), and even coding defensively to ensure your PWA doesn't break if analytics or other third party libraries fail to load. Consider requiring static code analysis, like linting, as well as automated testing, in multiple browsers and release channels. These techniques can help catch errors before they make it into production.

What are Progressive Web Apps?

2020-01-06T00:00:00Z

The web is an incredible platform. Its mix of ubiquity across devices and operating systems, its user-centered security model, and the fact that neither its specification nor its implementation are controlled by a single company makes the web a unique platform to develop software on. Combined with its inherent linkability, it's possible to search it and share what you've found with anyone, anywhere. Whenever you go to a website, it's up-to-date, and your experience with that site can be as ephemeral or as permanent as you'd like. Web applications can reach anyone, anywhere, on any device with a single codebase.

Platform-specific applications are known for being incredibly rich and reliable. They're ever-present, on home screens, docks, and taskbars. They work regardless of network connection. They launch in their own standalone experience. They can read and write files from the local file system, access hardware connected via USB, serial port, or bluetooth, and even interact with data stored on your device, such as contacts and calendar events. In these applications, you can do things such as take pictures, see playing songs listed on the home screen, or control song playback while in another app. Platform-specific applications feel like part of the device they run on.

Capabilities vs. reach of platform-specific apps, web apps, and progressive web apps.

If you think about platform-specific apps and web apps in terms of capabilities and reach, platform-specific apps represent the best of capabilities whereas web apps represent the best of reach. So where do Progressive Web Apps fit in?

The three app pillars #

Progressive Web Apps are web applications that have been designed to be capable, reliable, and installable. These three pillars transform them into an experience that feels like a platform-specific application.

Capable #

The web is quite capable in its own right today. For example, you can build a hyper-local video chat app using WebRTC, geolocation, and push notifications. You can make that app installable and take its conversations virtual with WebGL and WebVR. With the introduction of WebAssembly, developers can tap into other ecosystems, such as C, C++, and Rust, and bring decades of work and capabilities to the web. Squoosh.app, for instance, uses this for its advanced image compression.

Until recently, only platform-specific apps could really lay claim to these capabilities. While some capabilities are still out of the web's reach, new and upcoming APIs are looking to change that, expanding what the web can do with features like file system access, media controls, app badging, and full clipboard support. All of these capabilities are built with the web's secure, user-centric permission model, ensuring that going to a website is never scary for users.

Between modern APIs, WebAssembly, and new and upcoming APIs, web applications are more capable than ever, and those capabilities are only growing.

Reliable #

A reliable Progressive Web App feels fast and dependable regardless of the network.

Speed is critical for getting users to use your experience. In fact, as page load times go from 1 second to ten seconds, the probability of a user bouncing increases by 123%. Performance doesn't stop after the onload event. Users should never wonder whether their interaction—for example, clicking a button—was registered or not. Scrolling and animation should feel smooth. Performance affects the entire user experience, from how they perceive your application to how it actually performs.

Finally, reliable applications need to be usable regardless of network connection. Users expect apps to start up on slow or flaky network connections or even when offline. They expect the most recent content they've interacted with, such as media tracks or tickets and itineraries, to be available and usable even if getting a request to your server is hard. When a request isn't possible, they expect to be told there's trouble instead of silently failing or crashing.

Users deserve apps that respond to interaction in the blink of an eye, and an experience they can depend on.

Installable #

Installed Progressive Web Apps run in a standalone window instead of a browser tab. They're launchable from on the user's home screen, dock, taskbar, or shelf. It's possible to search for them on a device and jump between them with the app switcher, making them feel like part of the device they're installed on.

New capabilities open up after a web app is installed. Keyboard shortcuts, usually reserved when running in the browser, become available. Progressive Web Apps can register to accept content from other applications, or to be the default application to handle different types of files.

When a Progressive Web App moves out of a tab and into a standalone app window, it transforms how users think about it and interact with it.

The best of both worlds #

At their heart, Progressive Web Apps are just web applications. Using progressive enhancement, new capabilities are enabled in modern browsers. Using service workers and a web app manifest, your web application becomes reliable and installable. If the new capabilities aren't available, users still get the core experience.

The numbers don't lie! Companies that have launched Progressive Web Apps have seen impressive results. For example, Twitter saw a 65% increase in pages per session, 75% more Tweets, and a 20% decrease in bounce rate, all while reducing the size of their app by over 97%. After switching to a PWA, Nikkei saw 2.3 times more organic traffic, 58% more subscriptions, and 49% more daily active users. Hulu replaced their platform-specific desktop experience with a Progressive Web App and saw a 27% increase in return visits.

Progressive Web Apps provide you with a unique opportunity to deliver a web experience your users will love. Using the latest web features to bring enhanced capabilities and reliability, Progressive Web Apps allow what you build to be installed by anyone, anywhere, on any device with a single codebase.

Integrate PWAs into built-in sharing UIs with Workbox

2019-12-19T00:00:00Z

The Web Share Target API lets you display your Progressive Web App in a user's system-level share sheet after it's been installed. While it works great if you have a server available to receive the request, it's much harder to get working if you don't.

In this article we'll use Workbox, a set of JavaScript libraries for adding offline support to web apps, to create a share target URL that lives entirely inside your service worker. This lets static sites and single-page apps serve as share targets without a dedicated server endpoint.

System-level share target picker with an installed PWA called Share Target Test as an option.

On the same page #

If you're unfamiliar with how Web Share Target Works, Receiving shared data with the Web Share Target API gives you an in-depth introduction. Here's a quick review.

There are two parts to implementing web share target functionality. First, update your web app manifest to indicate that you want your app to be a share target when installed. The following example directs shares to the /share url via a POST request. It is encoded as a multipart form, with title being called name, text being called description, and JPEG images being called photos.

…
"share_target": {
  "action": "/share",
  "method": "POST",
  "enctype": "multipart/form-data",
  "params": {
    "title": "name",
    "text": "description",
    "files": [
      {
        "name": "photos",
        "accept": ["image/jpeg", ".jpg"]
      }
    ]
  }
}
…

While normally handled by a server endpoint, a neat trick you can do for a share target is to register a route directly in your service worker to handle the request. This will let your app be a share target without a backend.

You do this in Workbox by registering a route that's handled by your service worker. Start by importing registerRoute from 'workbox-routing'. Notice that it's registered for the /share route, the same one listed in the example web app manifest. In response it calls shareTargetHandler().

import { registerRoute } from 'workbox-routing';

registerRoute(
  '/share',
  shareTargetHandler,
  'POST'
);

The shareTargetHandler() function is asynchronous and takes the event, awaits the form data, then retrieves the media files from that.

async function shareTargetHandler ({event}) {
  const formData = await event.request.formData();
  const mediaFiles = formData.getAll('media');

  for (const mediaFile of mediaFiles) {
    // Do something with mediaFile
    // Maybe cache it or post it back to a server
  });

  // Do something with the rest of formData as you need
  // Maybe save it to IndexedDB
};

You can then do whatever you'd like with these files. You can cache them. You can send them somewhere with a fetch request. You can even use the other manifest options, maybe serving a page with some query parameters for the other shared items or storing the data and pointers to the media in the Cache Storage API or IndexedDB.

You can try it out on the sample app Fugu Journal and see its service worker implementation in its source code.

One common thing you might do is hold shared resources until better network connections are available. Workbox also supports periodic background sync.

Conclusion #

The Share Target API is a simple way to deeply integrate your Progressive Web App into user's devices, putting them on-par with platform-specific applications for the critical task of sharing content between apps. But doing so usually requires a server available to receive the request. By leveraging Workbox to create a share target route directly in your service worker, your app is free of this constraint, allowing Share Target to work for apps while offline and without backends.

Photo by Elaine Casap on Unsplash

Smarter custom properties with Houdini’s new API

2019-09-19T00:00:00Z

CSS custom properties, also known as CSS variables, let you define your own properties in CSS and use their values throughout your CSS. While incredibly useful today, they have shortcomings that can make them hard to work with: they can take any value so they may be accidentally overridden with something unexpected, they always inherit their values from their parent, and you can't transition them. With Houdini's CSS Properties and Values API Level 1, now available in Chrome 78, these shortcomings are transcended, making CSS custom properties incredibly powerful!

What Is Houdini? #

Before talking about the new API, let's talk about Houdini quickly. The CSS-TAG Houdini Task Force, better known as CSS Houdini or simply Houdini, exists to "develop features that explain the 'magic' of styling and layout on the web". The collection of Houdini specifications are designed to open up the power of the browser's rendering engine, allowing both deeper insight into our styles and the ability to extend our rendering engine. With this, typed CSS values in JavaScript and polyfilling or inventing new CSS without a performance hit are finally possible. Houdini has the potential to superpower creativity on the web.

CSS Properties and Values API Level 1 #

The CSS Properties and Values API Level 1 (Houdini Props and Vals) allows us to give structure to our custom properties. This is the current situation when using custom properties:

.thing {
  --my-color: green;
}

Because custom properties don't have types, they can be overridden in unexpected ways. For example, consider what happens if you define --my-color with a URL.

.thing {
  --my-color: url('not-a-color');
  color: var(--my-color);
}

Here, because --my-color isn't typed, it doesn't know that a URL isn't a valid color value! When we use it, it falls back to default values (black for color, transparent for background). With Houdini Props and Vals, custom properties can be registered so that the browser knows what it should be!

Now, the custom property --my-color is registered as a color! This tells the browser what kinds of values are allowed and how it can type and treat that property!

Anatomy of a registered property #

Registering a property looks like this:

window.CSS.registerProperty({
  name: '--my-color',
  syntax: '<color>',
  inherits: false,
  initialValue: 'black',
});

It supports the following options:

`name: string` #

The name of the custom property.

`syntax: string` #

How to parse the custom property. You can find a complete list of possible values in the CSS Values and Units specification. Defaults to *.

`inherits: boolean` #

Whether it inherits its parent's value. Defaults to true.

`initialValue: string` #

Initial value of the custom property.

Taking a closer look at syntax. There are a number of valid options ranging from numbers to colors to <custom-ident> types. These syntaxes can also be modified by using the following values

Appending + signifies that it accepts a space-separated list of values of that syntax. For example, <length>+ would be a space-separated list of lengths
Appending# signifies that it accepts a comma-separated list of values of that syntax. For example, <color># would be a comma-separated list of colors
Adding | between syntaxes or identifiers signifies that any of the provided options are valid. For example, <color># | <url> | magic would allow either a comma-separated list of colors, a URL, or the word magic.

Gotchas #

There are two gotchas with Houdini Props and Vals. The first is that, once defined, there's no way to update an existing registered property, and trying to re-register a property will throw an error indicating that it's already been defined.

Second, unlike standard properties, registered properties aren't validated when they're parsed. Rather they're validated when they're computed. That means both that invalid values won't appear as invalid when inspecting the element's properties, and including an invalid property after a valid one won't fall back to the valid one; an invalid property will, however, fall back to the registered property's default.

Animating custom properties #

A registered custom property provides a fun bonus beyond type checking: the ability to animate it! A basic animation example looks like this:

<script>
CSS.registerProperty({
  name: '--stop-color',
  syntax: '<color>',
  inherits: false,
  initialValue: 'blue',
});
</script>

<style>
button {
  --stop-color: red;
  transition: --stop-color 1s;
}

button:hover {
  --stop-color: green;
}
</style>

When you hover over the button, it'll animate from red to green! Without registering the property, it'll jump from one color to the other Because, without being registered, the browser doesn't know what to expect between one value and the next and therefore can't guarantee the ability to transition them. This example can be taken a step further, though, to animate CSS gradients! The following CSS can be written with the same registered property:

button {
  --stop-color: red;
  background: linear-gradient(var(--stop-color), black);
  transition: --stop-color 1s;
}

button:hover {
  --stop-color: green;
}

This will animate our custom property that's part of the linear-gradient, thus animating our linear gradient. Check out the Glitch below to see the full code in action and play around with it yourself.

Conclusion #

Houdini is on its way to browsers, and with it, entirely new ways of working with and extending CSS. With the Paint API already shipped and now Custom Props and Vals, our creative toolbox is expanding, allowing us to define typed CSS properties and use them to create and animate new and exciting designs. There's more on the way, too, in the Houdini issue queue where you can give feedback and see what's next for Houdini. Houdini exists to develop features that explain the "magic" of styling and layout on the web, so get out there and put those magical features to good use.

Photo by Maik Jonietz on Unsplash

Sam Richard on web.dev

New Progressive Web App training now available

What makes a good Progressive Web App?

Core Progressive Web App checklist #

Why #

How #

Why #

How #

Additional reading #

Why #

How #

Why #

How #

Why #

How #

Optimal Progressive Web App checklist #

Why #

How #

Why #

How #

Why #

How #

Why #

How #

Why #

How #

Why #

How #

What are Progressive Web Apps?

The three app pillars #

Capable #

Reliable #

Installable #

The best of both worlds #

Integrate PWAs into built-in sharing UIs with Workbox

On the same page #

Service worker share targets with Workbox #

Conclusion #

Smarter custom properties with Houdini’s new API

What Is Houdini? #

CSS Properties and Values API Level 1 #

Anatomy of a registered property #

name: string #

syntax: string #

inherits: boolean #

initialValue: string #

Gotchas #

Animating custom properties #

Conclusion #

`name: string` #

`syntax: string` #

`inherits: boolean` #

`initialValue: string` #