Progressive Web Apps and Accelerated Mobile Pages – What is Holding WordPress Back?

Progressive Web Apps and Accelerated Mobile Pages – What is Holding WordPress Back?

Having been involved in building Progressive Web Apps from before they were even called Progressive Web Apps, we believe that everyone should use JavaScript to build amazing user experiences on the web. This has been our mantra in the last few years and we’re sticking to it :).

However, using Content Management Systems (and in particular WordPress) as backend / APIs has proven a challenge. This is mostly due to the clash between technologies (client vs. backend rendering) and the large ecosystem of plugins / themes that surround WordPress. The value of WordPress is not only its powerful core, but all those widgets that you can install and enhance the functionality of your WordPress site. Most of these are plug & play. At the same time, I have yet to see a plug & play PWA with a 100% score on Lighthouse. Wherever you see success stories (ex. Twitter app), they also involve a lot of custom work.

So, where does that leave us? We don’t pretend to have all the answers or a magic, silver bullet that can remodel your WordPress website into a 100% PWA. However, we believe that by taking a more detailed look at the technology behind WordPress, PWAs and AMP, we can come up with ideas on how to close the gap between them. Below, you’ll find a list of 5 key points that we believe should be addressed to get us moving in the right direction.

1. Server-side rendering vs. client-side rendering

WordPress themes & plugins use server-side rendering. If you’re not familiar with the differences between server-side and client-side rendering, you can read about it here. In short, WordPress themes / plugins need a server to run the code and produce an output (HTML & CSS code).

In contrast, the PWA standard doesn’t impose a particular use of technology for implementing such an application. Most PWAs are built on JavaScript libraries / frameworks and are thus Single Page Applications (SPAs). It’s also possible to build Multiple Page Applications as PWAs, however the architecture is heavily customized. Here you can find a presentation from Google I/O 2018, describing the architecture of such a PWA implemented using a NodeJS / Express.js server and service workers. This can be even more intimidating compared to SPAs and it still requires writing JavaScript code, at least for the service worker.

So, what happens when we combine WordPress’ server-side rendering with a SPA? Well, we don’t – we have to make the choice between generating the HTML & CSS code on the server (server-side rendering) or letting the browser render that code (client-side rendering). In WordPress Mobile Pack, we use a special WordPress theme that loads only on mobile browsers. It strips down any WordPress code besides the bare minimum required to load the PWA assets (bundled JavaScript and CSS). It then becomes the responsibility of the browser to fetch the content (posts, pages, categories and so on) from WordPress’ REST API.

2. Limitations of the REST API

We strongly believe that the inclusion of the REST API in the core has opened the door for building amazing apps on top of WordPress. However, as it stands today, the functionality of the REST API is limited compared to all other things that you can do from the WordPress admin area. Just think for example about customizing the menu for your WordPress site. You can go to Appearances > Menus and do just that, your responsive theme will easily adapt to the changes.

Yet, there is no endpoint that can help export those settings to a PWA. The REST API functionality is limited to retrieving posts, pages, categories, etc. and some basic settings. So, a trivial task that is available to all responsive themes is cumbersome for a PWA. One solution is to extend the functionality of the REST API and create new endpoints (there is some work being done in that direction here). This doesn’t change the fact that we’ll have to jump through some hoops to integrate our PWAs with basic WordPress features.

3. Page Builders & Widgets

Who doesn’t love an easy-to-use page builder? These plugins promise to make our lives easier and just by using drag-and-drop we can make our website look the way we want. It’s no wonder their popularity is increasing.

The majority of these plugins rely on server-side rendering. They also insert additional JavaScript & CSS code and heavily depend on the page’s context to properly render a layout. Well, adding JavaScript code (like a widget) inside other JavaScript code (PWA) is a recipe for disaster. The embedded JavaScript code will not be executed because it’s not loaded directly in the browser.

Not to mention that the REST API doesn’t even export some of the shortcode used by page builders – which is normal because that shortcode doesn’t make sense outside of a responsive theme’s context.

4. Service workers support

Service workers are a big part of implementing a PWA. They help provide all that fancy stuff – like caching / offline mode, add to homescreen and web push notifications.

One caveat? They must reside on the root domain of your website – even if your WordPress install exists at, the service worker must be hosted directly on And they are JavaScript files. You might think “what’s the big deal, I’ll just copy the service worker file to my theme folder”. Well, as I already mentioned, WordPress uses server-side rendering, which makes it possible to load content from a theme folder even when in the browser you’re accessing the home page. But JavaScript files are different – their path is not changed when they are loaded by the browser. And, for very good reasons (think security!), a theme or plugin doesn’t have access to write files in the root folder of your WordPress installation.

So, what we can do? Well, we can manually copy the service worker file using FTP. But I do hope that WordPress comes up with a better solution in the future. I don’t want to be stuck forever copying my service worker whenever WordPress code is updated.

5. Lack of transparency on how SEO works for SPAs

The lack of transparency when it comes to search engine optimization is one of the main reasons for the slow adoption of SPAs. Even though Google announced that its bots can crawl JavaScript code a few years back, this doesn’t change the fact that many people still look at their Google Webmasters Search Console and see all kinds of problems in there.

Some details surfaced last year, mainly the fact that the Googlebot uses Chrome 41 for rendering. Also, at this year’s Google I/O, we could take a sneak peak on how Google Search works and why SPAs are not as efficient as basic HTML/CSS websites when it comes to SEO. There was one very important insight that was shared:

“The rendering of JavaScript powered websites in Google Search is deferred until Googlebot has resources available to process to content.”

The recommended solution is to do server-side rendering only for bots, which if you ask me, sounds like a hassle because we end up maintaining two different versions of the same content. I do hope there’s a better solution in the making, because this one doesn’t sound good at all.


The good part about all of this is that Google is definitely making steps into closing the gap between its technologies and WordPress. There was another interesting presentation at Google I/O that you should definitely watch: “Make your WordPress site progressive“. The approach is very interesting – using AMP and the Gutenberg editor to build WordPress websites. It looks like the WP AMP plugin is getting a lot of love recently and there are some very cool use cases that can be built on top of it.

Even though there is no silver bullet for solving the issues I have mentioned in this article, I do hope we’ll see many more cool PWAs being built on top of WordPress, taking advantage of the CMS’s popularity and versatility.

Co-founder and CTO at Likes to get involved in various activities to help women get into programming/coding, but also found their own businesses.

Leave a Reply