Do you remember how four years ago everything needed to be responsive? Well, in the next two years, the best performing sites are going to be Progressive Web Apps (PWA).
So what makes a site a Progressive Web App?
It’s actually a combination of technologies and approach to implementation that results in a set of qualities. As defined by Google, they are:
- Progressive - Works for everyone, features enable if they’re compatible with device.
- Responsive - Caters to a wide range of device sizes.
- Connectivity independent - Saves content for later to maintain functionality if offline or on poor quality connection
- App-like - Feels like an app to the user with app-style interactions, navigation and shell.
- Fresh - Loads in latest content when it can
- Safe - Everything is over HTTPS for security.
- Discoverable - Provides registration so search engines and browsers can identify it as a progressive web app
- Re-engageable - Makes use of features like push notifications.
- Installable - Users can save to their home screen like they would an app without needing to go to the app store.
- Linkable - It’s the web, so it’s easy to share URLs.
Now that’s a sweet list, now how do I get all of that in your Magento store? Slow down, I’ll get on to that.
What about AMP?
You may also have heard of Accelerated Mobile Pages (AMP), another project pushed by Google that improves page speed on mobile devices. The main reason for the speed gain is the restrictions that are in place, e.g. next to no javascript is allowed, and Google having their own cache servers that cache your pages. In the end though, it’s aimed mainly at publishers. Despite being open-source, it’s a deceptively closed, short term solution. It doesn’t go far towards tackling the priorities listed above and there isn’t any other browsers or standards body involved. That being said, I’m sure there’s some value in implementing AMP because they do result in fast page load times for those articles and because Google are heavily promoting them in search results. I don’t believe that investment in integrating AMP version of your Magento site will be worth the investment though.
Progressive Web Apps on the other hand have been heavily invested in by Google. Both in their own products as well as educating the community. What’s key, though, is that the technology isn’t specific to Google, there are a number of web standards behind them. So there isn’t a competition between vendors that’s going to require you to choose a side to invest in. Google (Chrome) and Firefox are already compatible with many of the technologies needed and Safari is planning implementation in the coming years. Even without safari on board, given that features are added through progressive enhancement, users of this browser are still going to see some benefits and will reap more rewards as they add support.
What makes something app-like?
Moving back to our list of qualities, let’s take a couple of the ones that you might not be familiar with, say “app-like”.
What could we say about apps that aren’t true with our normal web browsing? Apps cope far better with being offline or on a poor connection. They typically will load with navigation and show what you had previously seen. If it can’t load in new content to replace the old content, an app will let you know that it’s offline. The by-product of this is that an app feels much faster because it can load the core components of the interface before it even needs a response from the internet. One last point is about the design of the interface, apps don’t require URLs so can get rid of the URL making more space for the app itself.
Now, let me count the ways that traditional websites aren’t like this. If you’re offline, you get an error page, if you’re on a dodgy connection then pages take forever to load or are broken due to missing javascript. Even in the best of conditions you have to download the entire page and most of the assets before you can actually use the thing. What’s more, even though the header and footer is the same on every page, that’s loaded from scratch every single time.
How do we get there?
Using a combination of new technologies and changing our approach to building websites we can deliver interactive websites even more quickly than before, particularly on repeat viewing.
We avoid massive downloads and bundling all of our CSS and JS into single files that results in pages that take ages to render. Instead, we deliver the “app shell” to customers first. An app shell is the common components of pages, typically the header and navigation. We deliver this as HTML, CSS and JS and this can be re-used on every additional page load. This leaves us only needing to worry about the content that changes between pages. This is very similar to sites and apps like Facebook where you have the header and footer but are waiting for the latest news stories to load in. Not only does this give us great performance because the critical components are loaded in first, it also gives us the foundation to be able to cope better in offline or poor network conditions.
One key technology in facilitating this process is Service Workers, a W3C standard that has already been implemented by Chrome and Firefox on Desktop and Chrome and Android Browser on Android. Service workers allow us to manage the caching of assets: javascript, css and images without having to rely on browsers doing their own thing. What’s more you can cache HTML which is where things start to get really interesting.
You may respond that we already had browser cache for page assets. The problem with this is that browsers always have to send a small request to double check whether they should still use their cached version or fetch a new one. This process delays page load more than it should because of latency involved in making even a small request (numerous times). With managing the cache ourselves, we can cut this process out and take responsibility for expiring the cache.
Even if this request doesn't get made, and the performance of browser cache and service worker are similar, service workers gives the developer the control over the cache which can lead to more intelligent and aggressive caching strategies as well as other new opportunities.
The service worker being able to cache HTML means we can use it to save the “app shell” discussed previously for each page load. It also means that we can support offline viewing. From the second page view onwards, the service worker can cache the entire page. If a customer goes offline in the meantime, we can still show pages they had previously visited. This is the advised approach for ecommerce where stock availability can change quickly, but for pages that are unlikely to change like blog posts and CMS pages, these can be served from cache even if customers are online so that they get a quick response that doesn’t even need to talk to the server again.
In the longer-term, I think that this has interesting applications for high-load periods where we wish to offload some of the server requests. By enabling a more aggressive service worker caching strategy we can dramatically reduce the number of requests made by customers refreshing pages or visiting the same page in quick succession. Finally, on mobile, by registering your PWA with something called a manifest file, Chrome will suggest to the user to save this web app to the home screen to be used again later. When opened this way, you can instruct the browser to not show the URL bar essentially showing your site in full screen, much in the same way than an app would.
Let’s get that merged (into Magento)
We were pushing the boundaries of Magento site by creating a mobile-first responsive design for Ordnance Survey back in 2011 and the commercial results were amazing. Given that this approach to create progressive web apps is not only encouraged by Google but that there are W3C web standards tells us that this is going to be the next step at getting that edge over the competition. In a way, we’re lucky that ecommerce typically lags behind the mainstream so we have an opportunity to get in there early.
Here at Meanbee, we decided that we wanted to invest R&D time to create a progressive web app solution for Magento. The two team members pushing this forward are Darren Belding and Tomas Gerulaitis so the kudos has to go to them. Achieving PWA status is only possible by building this way from the start so we are working on creating a base theme and series of extensions to facilitate this. There’s a lot of rework of Magento 2 to make it compatible with this approach so it’s no mean feat.
While there’s little we can for Magento 1 sites that are already out there, we wanted to back port what functionality we could to bring some of the benefits to people now.
What we have found is that we can provide the improved caching mechanism so that customer page loads are quicker, particularly on poor network conditions. We’ve also been able to enable the offline support so that customers can revisit previous pages they visited even if they’ve gone offline.
Here’s a demo video showing it in practice.
One thing to note is that the stylesheet isn’t being cached on the requests with the service worker disabled which is causing most of the delay on the 3s page load time. This would normally have been cached with the use of expire headers which weren’t in place here. These are the current best practice for production environments for instructing the browser to cache as much as possible. If the stylesheet were cached the improvement in speed with service workers would have been much smaller but the key is that with service workers, we are in control, not the browser which gives us the flexibility to have much more intelligent caching strategies.
It’s now available from Github. To find out more, read the Google Developer guide. Otherwise, in the meantime, watch this space, or get in touch if you’re planning to move to Magento 2 this year.