Cancel

Sarah Gooding

WCEU Panel Discusses Progressive WordPress Themes, AMP, and Gutenberg

Progressive themes was a hot topic at WordCamp Europe 2018. During the event I had the opportunity to set up a panel with four experts who are working to integrate progressive web development practices more deeply in WordPress core, plugins, and themes. These practices make it possible for a website (or app) to work offline, load quickly, deliver content on unreliable networks, and use device-specific features to provide a better experience for the user. The PWA (progressive web app) created for WordCamp Europe is a good example of this in action.

Thierry Muller, Alberto Medina, Weston Ruter, and Morten Rand-Hendriksen joined me for an interview, exploring the future of WordPress themes in the era of progressive web development. (see video below)

“At the most abstract level, it’s all about user experience,” Medina said. “How do we maximize the pleasure that our users get when they use our websites? And delightfulness in this context means things like performance, speed, having content that isn’t blocked. If you think about themes built according to those principles, then we are basically seeking an awesome user experience in WordPress.”

It’s not yet clear what this will look like for the WordPress theme landscape, as current solutions are somewhat fragmented. WordPress contributors are working to standardize progressive technologies in core so the ecosystem can collaborate better together.

“There are many progressive themes being built these days,” Medina said. “One of the problems that is happening is that there is a lot of fragmentation. There’s a lot of plugins that are using service workers but in their own ways. What we want is to say, ‘This is the best way to do things,’ this is a uniform API to do it, and then enable progressive theme developers to take advantage of the core functionality.”

Currently, the prospect of setting up a WordPress site that uses progressive web technologies would be a daunting task for regular users, even if they are implementing existing solutions.

“There’s also a user aspect of it, because the people for whom we design WordPress, plugins, and themes, are the people who actually publish their own content onto the web,” Rand-Hendriksen said. “There’s a really valid question in how much should they need to know about how the web works to be able to publish some content. When they spin up a WordPress site, should we impose on them to know that they need to add all these optimization plugins and do all this other stuff just to make the site work properly? How much of that can be offloaded onto the theme itself, or plugins, or even WordPress core?”

The members of the panel are working together to on various projects and core contributions that will standardize the use of progressive enhancement technologies in WordPress.

“The goal is to have a common API for service workers so that plugins and themes can each install their own logic, just like they can enqueue their own scripts today,” Ruter said. “Also to be able to enqueue their own service workers and then core can manage the combination of them, as well as having a common app manifest that plugins and themes can collaborate on and have a single output into the page.”

This is how Rand-Hendriksen’s WP Rig starter theme project came about – to help developers take advantage of these best practices in the meantime, without having to figure out how to put all the pieces together.

“WP Rig gives you the platform to build a progressive theme that uses all the latest performance and WordPress best practices, in a convenient package, and over time it will evolve with these new progressive technologies,” Rand-Hendriksen said.

We also discussed AMP and Gutenberg compatibility, core support for web app manifests, and how the commercial theme industry will react to these new technologies. Check out the full interview in the video below.

Category: ,
Tags: , , ,
21

21 responses to “WCEU Panel Discusses Progressive WordPress Themes, AMP, and Gutenberg”

      • How would you propose to allow plugins to add functionality without compromising the flexibility that srevice workers give you? As I said there are many approaches to caching alone and they all have pros and cons so I am not sure how it could be chieved or even if would be a good thing….

        Create forum topic from comment

      • @Pete: to address the issue you mention, in my website, I have implemented snippets of standard SW functionality (eg: precache assets, store page in SW cache after visiting, etc) that both the theme and other plugins can subscribe to through standard WordPress hooks (eg: any plugin can hook in its resources to precache, etc). Then, from a template coded in PHP, I dynamically generate a single service-worker.js file from the input of several plugins.

        This strategy (which I described in detail here) is a trade-off: plugins don’t get to code their own more specific/customized functionalities, however the general use cases are covered; it is losing a bit of flexibility, but it is still very powerful and makes it very easy for any plugin to benefit from it. So I think that, given a sound strategy, having a streamlined solution for SW can be a very good idea.

        Create forum topic from comment

        • Leo,

          I read your article but I’ve not looked at your code but I doubt a generic solution can provide flexibility required, things like notifications, other caching strategies, and postmessage support to name a few.

          It certainly can’t without having a dynamic service worker which wil double your server load, not ideal and not necessary.better to make the service worker as static as possible

          To that end

          Stay away from spas they are the devils spawn (largely another discussion though)

          Apart from an offline page there is no real need to pre cache anything else as your first page load will probably pull down all required assets, so as long as those assets go not the right cache/caching strategy you are mostly there.

          Tell the service worker about anything else it needs to cache via postmessage

          Create forum topic from comment

      • Pete, yep you’re right about SPAs, but it’s no different than for non-SPAs sites, same strategy will work. The strategy that I describe will dynamically generate an actual .js file that then can be referenced statically (it is not generated each time you request it, but only once before deploying the application), so from that side it is not an issue. Then, the greatest performance gain that can be achieved through SW is precaching assets: it’s very easy to implement through hooks, and it allows sites to be loaded in no time after the 2nd load (loading assets takes a huge chunk of the page loading time… if these can be preloaded, we got a huge performance bump there). And regarding notifications, they can perfectly be implemented through some generic solution that works for the majority of the cases too.

        I have no doubt that that it is possible to create a generic solution that covers most of the cases for which there is an immediate, easy to achieve gain. And for everything else, as long as we generate the service-worker.js file from a PHP template, then customized functionality can also be incorporated, implemented at the theme level. So far, at least, it has worked pretty well on my site.

        I do not doubt that a plugin can provide these easy gains for the WordPress ecosystem too.

        Create forum topic from comment

      • That’s the nature of service workers. You cannot have 2+ operating on the same URL. So I’m not sure what you’re getting at here unless you are thinking about setting up different service workers on different URLs for the same site.

        Create forum topic from comment

      • Rick, no I’m not proposing to have different service workers on different URLs for the same site, that wouldn’t work in my opinion. What I’m suggesting is a way in which the final service-worker.js file, which is unique, is generated dynamically from a PHP process (done only once, just before deploying the site), and that plugins are allowed to output their code into it through standard WordPress hooks. I implemented this approach and it works fine for me. The template to generate the service-worker.js file I implemented is this one, in which the values to replace variables (such as ${cacheItems}) are filled by plugins through hooks.

        In that template there have been coded a few of the general-use functionalities for SW: precache assets, and different strategies for caching pages (taken from Jake Archibald’s offline cookbook.) This same logic can be perfectly put in a plugin, shipping with many of these functionalities, and then at the theme level it can be configured which ones are needed, and only those will be printed on the generated service-worker.js file.

        Create forum topic from comment

      • Rick:
        You can only have one service worker running at a time, and the first service worker to handle a `fetch` event will cause any other handlers to be skipped. So yes, only one service worker can manage the network request for a given URL. But a service worker could/should be conservative in the assets it caches, allowing multiple themes/plugins to control the caching for their own assets. But a service worker can do more than just manage the network. It can also manage notifications and do new things like background sync. So the ability for multiple themes/plugins to introduce their own respective JS code to include in the service worker is useful, and it needs a core API to facilitate it (by concatenating them together) since only one service worker can be installed at a time.

        Create forum topic from comment

    • 2. Service workers are powerful, flexible and there is no right way. So having a service worker api is not a good idea imo.

      This may be true, but there is a workaround to this issue that can work for a majority of plugins out there: a master plugin can implement snippets of standard SW functionality (eg: precache assets, store page in SW cache after visiting, etc) that both the theme and other plugins can subscribe to through standard WordPress hooks (eg: any plugin can hook in its resources to precache, etc). Then, from a template coded in PHP, we can dynamically generate a single service-worker.js file from the input of several plugins. I wrote about this approach in detail here.

      This strategy is a trade-off: while plugins don’t get to code their own more specific/customized functionalities, the general use cases are covered; it is losing a bit of flexibility, but it is still very powerful and makes it very easy for any plugin to benefit from it. So, in a way, you can have a SW API that will benefit most cases out there.

      Create forum topic from comment

      • I think that a core SW API should provide these pre-baked solutions (e.g. for caching strategies) that they can use with minimal configuration (perhaps powered by Workbox), but then also provide a way for themes and plugins to register custom logic to run in the service worker, for example to handle notifications, background sync, and so on. We should encourage the use of the WP abstraction layer when possible, as it could allow us to do conflict detection (such as two plugins requesting different caching strategies for the same route). But by allowing raw access to the generated service worker script, we allow themes and plugins to leverage all of the capabilities that a SW makes available.

        Create forum topic from comment

  3. The WordPress core should be built in mind with the usage of service worker solutions. In such way, the theme and plugin Devs can take advantage of the technology in a more convenient way. Currently there are some plugins using the advantages of SW.js but they all are built very differently.

    Create forum topic from comment

    • Core doesn’t need to know anything about service workers. You can use them on any site, they’re not tied to a technology. They’re simply a way to define, in JS, some features that make a site work well offline and , in some cases, installable like an app. There’s nothing core needs to do to enable this, etc and generic solutions miss the point. I would imagine that a generic solution would end up like those plugins that make a site mobile aware… yes, it works o mobile but it’s nothing like your actual site being adjusted to work well on mobile given your specific needs and design.

      Create forum topic from comment

  4. I don’t see the problem. In fact, I disagree that this is plugin territory. A theme can add service workers tailored to the function of the theme (and that is better practice esp for the fetch section of a service worker). The end user doesn’t need to know anything that way – that’s a red herring issue in any event. End users shouldn’t need to know anything about caching, CSS or serviceworkers in order to have their CSS cached for offline use (to give one small example).

    Create forum topic from comment

    • A service worker can do more than just cache assets for offline. It also is used for notifications and background sync. Plugins and themes may need to introduce their own respective logic for integrating with the service worker to take advantage of these capabilities. Without a central service API in WordPress to coordinate the registration of the service worker scripts, then multiple plugins and themes would not be use service workers at the same time (since only one service worker can be active for a given scope at once).

      Create forum topic from comment

  5. How would you propose to allow plugins to add functionality without compromising the flexibility that srevice workers give you? As I said there are many approaches to caching alone and they all have pros and cons so I am not sure how it could be chieved or even if would be a good thing….

    Create forum topic from comment

You may also like

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.