Anthony McLin

Enabling PWAs on Drupal

Progressive Web Apps are a great way to improve the performance of a website. Besides the functional behaviors that they provide, making a website feel more like a native app, they are predicated on leveraging service workers to improve site caching and offline support so the site can still be viewed even if the visitor has an intermittent (or unavailable) network connection. Follow along as I use Google's Lighthouse audit to enable Progress Web App capabilities on my Drupal-based website.

To start with, I'm going to run the Lighthouse PWA audit on my site. To ensure I'm visiting as a normal user, I open an Incognito tab in Chrome, navigate to my homepage, and start the audit from Chrome's Dev Tools:

The initial score isn't great, only 38/100. This isn't all that surprising however as I last did an overhaul on my site UI well before service workers and Progress Web Apps (PWAs) were defined, let alone commonly used. After my research into the state of PWAs on Drupal, I see that there's work going on to get them into the Drupal 8 core, but it's moslty unfinished. Since I'm currently on Drupal 7, and there's a lot of other steps involved for migrating a site to Drupal 8, I'll leverage the PWA for Drupal 7 module to see how far that can take me:

Enabling the PWA for Drupal module blows up my site. Every public page is returning an HTTP 500 error and trying to get to the module's configuration screen results in a 500 as well. Most likely this is because the module requires PHP 7 and I'm still running a version of PHP 5. It would be nice if the module indiciated this as a requirement, or if Drupal provided a mechanism for flagging this in modules intead of just guessing. Luckily, my hosting provider, Media Temple, makes it easy to switch PHP versions with just a click of a button. So after a quick change in my hosting control panel, I'm back in business and trying again. This time I'm able to get to the module configuration:

Some quick settings of the basic options, a sitewide cache flush, and let's run the Lighthouse audit again:

Installing the module raised the Lighthouse PWA audit score from 38 to 46, which isn't bad but that still leaves a long way to go. Most of the errors are stemming from not registering a service worker (the 2nd error). Registering a service worker requires first having a mnaifest.json, which is present thanks to the module, but won't be leveraged unless the site is HTTPS. So first we need to convert the site from HTTP to HTTPS.

I have a separate article on the details of switching a Drupal site from HTTP to HTTPS. After enabling HTTPS everywhere, let's run the Lighthouse PWA audit again:

What a significant jump, from 46 to 85. As I mentioned, that's because most of the Progressive Web App features are dependent on HTTPS being enabled, so they were ready, just not yet in use. Most of the remaining errors look fairly straightforward to solve. First, let's fix the "short_name will be truncated on the homescreen" error. Open up the PWA for Drupal plugin configuration, and reduce the length of the Short name field:

The next error to adddress is "content is not sized correctly for the viewport". That's caused by header images on my blog posts exceeding both the content column and the page width:

While on some sites this might be considered a design feature (here it's a mistake), we need to remember that offscreen content that the visitor cannot scroll to is wasted pixels being downloaded. That's why this audit item exists. It's telling us of wasted content that the visitor cannot reach on a mobile device. Currently on my site I have the header images in two differeint implementations. One is attached as a field to the article itself (cross-referenced from my photography portfolio) and one as embedded images with the article. This means there are two different class patterns, but both can be targetted with a small piece of CSS. I'll set the max-width of the images to 100% so they cannot exceed the column, and change the height to auto since dimesions are currently goverend by a fixed height and I don't want ratio distortion:

.field-name-body img,
.field-name-field-header-image img {
    max-width: 100%;
    height: auto
} 

The remaining error reported by the Lighthouse PWA audit is "Failures: Service worker does not successfully serve the manifest's start_url, Timed out waiting for fetched start_url". This is essentially a bug in Lighthouse itself. Because the default setting for the audit is to clear local storage for each test, the service worker won't properly cache and serve the page during the audit itself. You can turn off the "Clear Storage" checkbox and the error during the audit will be resolved:

After toggling this setting, let's run the Lighthouse audit again for a perfect score:

While this gets a total score of 100/100, it's important to note a PWA experience shouldn't stop here. The Lighthouse audit only covers a core set of requirements for Google's classification of a PWA site. It can't test for a lot of things like usability, payment request gateways, whether or not the site is getting indexed by Google, and many other features that should matter for a good Progressive Web App experience. Since many of those have subjective implementations, or aren't applicable for site like mine, I'll cover them in other articles in the future. For now, this should be a good introduction on getting a Progressive Web App implementation enabled on a Drupal site.

Add new comment