New WordPress Feature Plugin Adds Support for Progressive Web Apps

WordPress contributors are working on getting support for Progressive Web Apps (PWA) into core. A new PWA feature plugin is now available on WordPress.org, spearheaded by the teams at XWP, Google, and Automattic.

Progressive Web Apps are applications that run on the web but provide a speedy app-like experience inside a mobile browser. Google describes them as having the following three qualities:

  • Reliable – Load instantly and never show the downasaur, even in uncertain network conditions
  • Fast – Respond quickly to user interactions with silky smooth animations and no janky scrolling
  • Engaging – Feel like a natural app on the device, with an immersive user experience

The plugin adds support for technologies that PWAs require, including Service Workers, a Web App Manifest, and HTTPS. These technologies support functions like background syncing, offline content, push notifications, mobile home screen icon, and other PWA features.

XWP CTO Weston Ruter said the purpose of the feature plugin is to curate PWA capabilities for proposed merging into core. The idea is to merge them piece by piece. Core tickets are already in process for adding support for web app manifests and support for service workers, as well as bringing improvements to HTTPS.

“This PWA feature plugin is intended to equip and facilitate other plugins which implement PWA features,” Ruter said. “It’s not intended to negate any existing plugins with these features, but rather to allow such plugins (and themes) to work together seamlessly and expand upon them.”

The first release of the plugin on WordPress.org (v0.1.0) adds support for web app manifests and initial support for allowing theme and plugin developers to register scripts for service workers via wp_register_service_worker(). It also includes an API for detecting whether HTTPS is available.

“A next step for service workers in the PWA feature plugin is to integrate Workbox to provide a declarative WordPress PHP abstraction for managing the caching strategies for routes, with support for detecting conflicts,” Ruter said. Anyone who is interested to contribute to PWA support for WordPress can check out the discussions and plugin on GitHub.

In the past, app-like experiences were only available for sites and services that had their own native mobile apps, but native apps can be costly to develop and maintain. Progressive web apps use the greater web as their platform and are quick to spin up. They make content easier to access on mobile even without an internet connection. It’s also far easier to tap a home screen icon than to enter a URL on mobile, and this makes users more likely to engage with their favorite sites.

PWA Stats is a site that features case studies of progressive web apps that have significantly increased performance, engagement, and conversion. A few compelling examples include:

PWA support in WordPress will enable the plugin and theme ecosystems to work together in providing site owners with more engaging ways to connect with their visitors. Once the market starts building on core support, site owners should soon be able to offer better experiences for mobile users without having to become experts in the technologies that power progressive web apps.

10 Comments


  1. I switched my manually coded implementation with this plugin. Chrome’s Lighthouse says it’s poorer than my implementation and it’s missing the “Add to home screen” feature. But I’d rather have it as a plugin than hardcoded in my theme and I hope they’ll update it more frequently.

    Report


    1. @Ciprian This plugin is not intended to be a full-featured plugin to turn your site into a PWA. It’s intended to provide a foundation for core that other themes and plugins can use to create PWAs.

      @Peter This plugin is not intended to supersede your plugin. Rather, as the article notes it is intended to facilitate and empower your plugin. It looks like your plugin is LH Web Application? We’ve been collaborating with the authors of the SuperPWA as well as the Progressive WordPress plugin to work on a common API for core that can power them. We’d be happy to work with you as well. See https://github.com/xwp/pwa-wp/issues/8

      Report


  2. This gets an article and the 5 existing plugins, including mine, which are far better than this get no publicity whatsoever.

    Report


  3. “This PWA feature plugin is intended to equip and facilitate other plugins which implement PWA features,” Ruter said. “It’s not intended to negate any existing plugins with these features, but rather to allow such plugins (and themes) to work together seamlessly and expand upon them.”

    Interesting that core developers are suddenly so interested in having different plugins work seamlessly together. After all, the Gutenberg architecture rejects that approach entirely. See https://github.com/WordPress/gutenberg/issues/4116

    It’s almost as if what is getting proposed for core is determined not by its substantive value but according to the whims of those with the power to commit it.

    Report


    1. Gutenberg is absolutely being designed to let plugins work together seamlessly. The issue you’re linking to is regarding backwards-compatibility with existing plugins that manipulate content. In this case, Gutenberg needs to provide a common API for plugins to interact with the blocks. It’s the exact same thing for PWA features: core needs to provide a common API for plugins seamlessly to extend the web app manifest and the service worker. In the case of the PWA plugin, however, there isn’t really a concern for backwards-compatibility since it is a new technology.

      Report


      1. Weston,

        You are the person who told me on this site a couple of years ago that the Customizer was still a work in progress, and shouldn’t be criticized too much. And yet it remains clumsy, brittle, and the width of a cellphone screen.

        So let’s look at what is actually said in the thread to which I linked. John Blackbourne comments that Gutenberg works in such a way that “almost completely eliminates the ability to interact with blocks beyond the block editor.” While Andrew Duthie concedes the point and reminds everyone that “for better and worse, we settled on HTML as the ultimate source of truth.”

        It is, of course, for worse. If Gutenberg were really being designed to make things work seamlessly together, it wouldn’t be relying on HTML comments.

        Report


      2. The Gutenberg issue is not closed yet. Work is still underway.

        Anyway, this is about PWA not Gutenberg. The purpose of the PWA plugin is to allow themes and plugins to have a common API so that they can work seamlessly together in how they need to make their respective changes to the web app manifest and the service worker.

        Report


      3. Whilst a canonical manifest is almost certainly beneficial I’m not convinced that it is needed or a good thing to handle the service worker side.

        Service workers are just so powerful and flexible and people’s needs are so different. The permutations are practically infinite.

        Report

Comments are closed.