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).
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.
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.
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
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 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.