Progressive Web Apps: A Technical Approach
Making your WordPress site mobile friendly doesn’t stop with responsive design. The user is increasingly choosing to view their favorite publications online via apps, and you can accomplish that same feeling for your WordPress site by taking a few steps to turn it into a Progressive Web Application.
In my last post, I offered the business case for making your site into a Progressive Web Application:
- Better Performance — even on the desktop!
- Offline Capability
- No need for complex programming languages
- Increasing Support from the Tech Giants
There seems to be some confusion over what exactly is a progressive web app. I stand with Jeremy Keith, who maintains that any website can become a PWA with just these three characteristics:
- Secure delivery through HTTPS
- A Web Manifest file
- A service worker
In this post, you’ll learn a bit about all these things, and how to test your site against the arbiters of PWAness.
Securing Your Page
Chances are very good that your web host already has or is busy converting your site URL from plain old HTTP to the secure HTTPS protocol. Primary reason: Google is phasing out including insecure sites from search results. Reason #2: If you’re going to have code displaying your site on other devices, the connection between the two should be secure. Finally, it’s a minimal step to protect your website, and your visitors. While there are valid arguments for keeping older sites around and searchable for historical and research purposes, it’s clear going forward that sites need to protect readers from malevolent programmers and other evildoers.
If you need to secure your site ahead of your host, Jenni McKinnon wrote an excellent tutorial on this topic. Meanwhile, ask your host what their plan and timetable is for migrating to HTTPS. If their answer doesn’t satisfy you, it’s easy to find a host that will offer this security.
Writing a Web Manifest
Time to get into the real stuff of creating your app.
A manifest file is a JSON text file that describes metadata associated with your app, and can also offer design elements for your PWA on a device’s home screen. While not required by the standard, it’s a good idea to use the *.webmanifest extension for this file.
All you need to have in a manifest file is an App Name, Description and at least one icon to display. Most likely, you’ll want to add a shortname, some type of color scheme, and the URL of your site to launch the app. This is called the “Start URL.”
The Display options are essential for describing the basic look-and-feel of your app on each device. Choose from these options:
- Fullscreen: When the user clicks the app, it fills up the screen, and doesn’t seem like a browser window.
- Standalone: Your app will look and feel like a native mobile app. In this mode, your app could look different from your site if you wanted. It would have its own icon in the application launcher, instead of a generic Web icon. As a standalone, the user agent (browser) will replace navigation elements to use the native tools for getting around. You can include other standard web UI elements such as a status bar.
- Minimal-ui: The application will look and feel like a standalone application, but the user can scroll around with a minimal set of UI elements for controlling navigation. The elements will vary by browser.
- Browser: The application opens in a conventional browser tab or new window, depending on the browser and platform. This is the default.
Orientation uses the experimental W3C Screen Orientation API to allow the developer to define how this app displays on the screen:
- Portrait: You know this: Always taller than it is wide
- Landscape: You know this too: Always wider than it is tall
- Any: Set this before defining your Primary and Secondary orientations
- Natural: Whatever the device platform defines as “natural.”
- Landscape-primary: Displays this way if the platform defines “natural” as landscape, and if the user holds the device in Portrait and turns it clockwise by 90 degrees.
- Landscape-secondary: If a naturally Landscape app is turned 180 degrees, or a naturally Portrait app is turned 90 degrees counter-clockwise, it displays as Landscape-secondary
- Portrait-primary: If a naturally Portrait app is turned 90 degrees clockwise, it displays the same.
- Portrait-secondary: If a naturally Portrait app is turned 180 degrees, or a natural Landscape app is turned 90 degrees counter-clockwise, it displays as Portrait-secondary
The Mozilla Developer Network offers a complete list of Manifest properties on its Web App Manifest page.
Use the Web App Manifest Generator to type in some basic choices and generate a simple manifest.json file like this:
Once you’ve created the manifest file, link to it in the HEAD of your site. Many themes allow you to place items in the HEAD section without fear of overwrite with each theme update. Check your theme settings, or follow up with your theme developer to confirm that you will be able to do this safely.
Adding a Service Worker
Service workers are the heart of any PWA, because you get the performance improvement over standard pages and web apps, online or offline. Equally important, you also get the ability to run offline on the desktop, or when mobile connections are weak-to-nonexistent (like that ever happens).
These bits are also the hardest piece of a PWA to construct. Whole books have been written about them. So don’t expect much in the way of detail here. I can get you started, though.
Mozilla describes service workers like this:
“Service workers essentially act as proxy servers that sit between web applications, the browser, and the network (when available). They are intended, among other things, to enable the creation of effective offline experiences, intercept network requests and take appropriate action based on whether the network is available, and update assets residing on the server. They will also allow access to push notifications and background sync APIs.”
But where’s WordPress in all this? This half-hour video from the 2017 Google Chrome Developers Conference features Dan Walmsley from Automattic and Google Chrome engineer Das Surma outlines the steps to creating a PWA with WordPress.
Surma’s section on building a service worker for offline access starts around 23 minutes in. He includes the service worker in his theme, but notes that proper service workers need to be on the root page. Until WordPress core can manage to store a service worker throughout the site, this code should work.
With Automattic’s continuing commitment to work with Google on PWA development, you can probably expect better support for service workers and other PWA elements relatively soon. Most likely this will happen after the Gutenberg post editor is stable.
Testing and Learning
Once you have completed converting your site into a PWA, it’s time to test it. These are the critical testing packages:
- Lighthouse: This tool is included in the Google Chrome DevTools, and powers the Audit package.
When you run a test on any of these sites, you might be puzzled that none of them gives you a yes or no answer to the question “Have I made a Progressive Web Application?” You will get a score instead, indicating how far along on the path to PWA Nirvana your application is.
One key to understanding this path is reviewing the Google PWA Checklist.
Until such time as you have reached PWA Nirvana, be safe in the knowledge of having created the three components of a PWA (HTTPS, Web Manifest, Service Worker).
Conclusion and Resources
Now you have the basics of creating a modern Progressive Web Application for your WordPress site. Until such time as you have reached PWA Nirvana, be safe in the knowledge of having created the three components of a PWA (HTTPS, Web Manifest, Service Worker). May you reap the benefits quickly.
Learn more about Progressive Web Apps here. It might be fun to use your Android device to open them: