There’s been a lot of discussion lately about Progressive Web Apps, and with good reason. Google pushed the idea fairly hard at their Dev Summits, and also released their first official guidance for PWAs for indexation recently.
What’s a Progressive Web App?
Watch Alex Russell talk about Progressive Web Apps from the 2015 Chrome Dev Summit:
Video Source Progressive Web Apps (Chrome Dev Summit 2015)
In Summary progressive Web Apps are:
- Progressive – Work for every user, regardless of browser choice because they’re built with progressive enhancement as a core tenet.
- Responsive – Fit any form factor: desktop, mobile, tablet, or whatever is next.
- Connectivity independent – Enhanced with service workers to work offline or on low quality networks.
- App-like – Feel like an app to the user with app-style interactions and navigation because they’re built on the app shell model.
- Fresh – Always up-to-date thanks to the service worker update process.
- Safe – Served via HTTPS to prevent snooping and ensure content hasn’t been tampered with.
- Discoverable – Are identifiable as “applications” thanks to W3C manifests and service worker registration scope allowing search engines to find them.
- Re-engageable – Make re-engagement easy through features like push notifications.
- Installable – Allow users to “keep” apps they find most useful on their home screen without the hassle of an app store.
- Linkable – Easily share via URL and not require complex installation.
Source: Your First Progressive Web App (Google)
For brevity, from here on out I’ll be referring to Progressive Web Apps as PWAs.
So what marks the distinction between a website and a PWA in the first place? Well the two defining characteristics would be that a PWA employs both Application Shell Architecture and Service Workers. To wit: the pages served contain all the HTML, CSS and JS required to load the page entirely and correctly, all held inline without requiring the download of further assets. Service workers enable features like push notifications and background sync for when a user has been offline and reconnects.
Google’s spec for a PWA also requires HTTPS for connection, the ability to add a site to the home screen of a device, and require the browser to run in a full-screen mode, hiding the URL bar. The last point there is a bone of contention and may change in the future, however for the moment it means you need to engineer a way to have a user be able to get access to the URL of a page, without having them be able to get to the URL bar.
Main Indexation Pointers
Firstly, you’re going to want to be using some form of universally rendering JS application. Personally, I’d throw my weight behind either React or Angular 2. Because these allow you to render server-side, you can send an initial payload with all the data to display the page, as well as all the CSS to load that specific page. That CSS gets inlined, to make sure the paint will work even if the client is offline. CSS modules make that part easier, as you can grab exactly what you need and inline it.
Second, service workers act as a proxy between your site and your server, which means we can build our system to assume they don’t exist and still work. That way if they do, you get the benefits, but if they don’t you still have a working system. This matters, as for the moment service workers are not well supported. For now, build everything to work normally using normal best practice, then add PWA parts progressively for when it exists in the browser.
Thirdly, make sure you’re using clean URLs for your site, and providing canonical URLs so Google knows what’s a PWA, what’s AMP content, what’s your site etc. Understanding the canonical version of your architecture is only going to become more important over time, especially if you’re dealing with internationalisation on top of all this.
Finally, it seems like Google may be crawling and understanding what’s a PWA and not today, but I can’t say for definite that that’s the case. We know that they do have the capability to detect what is and isn’t one, but we don’t know if that’s part of the normal crawling architecture yet. However, if it isn’t, it certainly will be soon.
Using with WordPress
Helpfully, WordPress support for PWAs can be added pretty quickly nowadays, thanks to a suite of plugins provided by Mozilla. These only need the app shell, which will require customisation to support them.
As with anything else, the best way to ensure things are working properly with regards to Googlebot are to watch your access logs for requests from it, watch what it does, and if anything is hinkey, fix it. However, provided you’re rendering from the server so there’s content to be indexed, linking between pages using links and not events, and using a sensible URL architecture, that’ll take care of most issues.