If you’ve learned about Progressive Web Apps, you might know that the core of it is a technology called service worker, a client-side proxy that sits between your server and web app to provide things like faster loads and offline functionality.
But what if you built the most amazing Progressive Web App, and nobody discovers it? The problem with service workers is that they won’t make your first page load fast. On a cold start, your service worker will only activate on the second page load.
Even though the service worker API allows you to cache away all of your site’s assets for an almost instant subsequent load, like when meeting someone new, it’s the first impression that counts. If the first load takes more than three seconds, our latest DoubleClick study shows that more than 53% of all users will drop off. Don’t feel too bad though. The overall landscape of today’s web looks a lot grimmer.
The average mobile page loads in about 19 seconds, with 77% of it taking longer than 10, doing 214 survey requests, 50% of which are ad-related. Yeah.
Take a moment to wipe away your tears. Turns out we found a solution for the first page load. And surprise, surprise, we call it AMP. AMP, short for Accelerated Mobile Pages, is an ecosystem consisting of web components library that allows you to declaratively write HTML we call AMP HTML, because it’s both a superset and a subset. And AMP caches, basically CDN’s, or more technically correct, reverse proxies that accelerate the delivery.
Now, if you’ve already read about the individual advantages and disadvantages of Progressive Web Apps versus AMP, you have surely struggled with this question before.
AMP or Progressive Web App? Instant delivery and optimized delivery, or the latest advanced platform features and super flexible application code?
In the end, what matters is the user journey. The first hop to your site should feel almost instant. And the browsing experience should get more and more engaging afterwards.
AMP and Progressive Web App are both critical components to make this happen AMP pages for the first navigation, and your Progressive Web App for the onward journey.
There are two ways of combining the two– steps I personally call AMP up and AMP down. Now, AMP up is the background bootstrapping of your Progressive Web App shell.
While the user is enjoying your AMP page. And then number two, AMP down, describes reusing AMP pages as a data source for your Progressive Web App.
So the basics with AMP up are that the first click will be an AMP page, usually served from the AMP cache. But any links on that page will navigate to your Progressive Web App Now normally, that second click would still be considerably slower than the instant-feeling, preloaded, first click to your AMP page.
But there’s a powerful component baked into AMP– the tag. It allows you to install your service worker for your origin– yes, even when your AMP page is served from the AMP cache.
That means while the user is reading the article, the service worker can warm up and precache the entire Progressive Web App app shell and some initial data.
When the user now clicks on any link on the page, or call to action at the bottom, your Progressive Web App shows up instantly.
Start fast, stay fast. This is what I call AMP up. But now you’re in the Progressive Web App, and chances are most of you are using some Ajax-driven navigation that fetches content via JSON.
Now, you can certainly do that, but now you have these crazy infrastructure needs for two completely different content backends. One generating AMP pages, and one offering a JSON-based API for your Progressive Web App.
The AMP team has asked themselves the logical next question– what if we could dramatically simplify backend complexity by ditching the additional JSON API and instead reusing AMP as a data format for our Progressive Web App?
We started with a proof of concept many months ago and iterated on it for a while, rewriting many parts of AMP to make it a reality.
So how do we do it? The process looks like this. The Progressive Web App hijacks navigation clicks, then does an Ajax request to fetch the requested AMP page. Third, puts the content into a new Shadow Root. And fourth, tells the main AMP library, hey, I have a new document for you.
Check it out. Which, in other terms, means calls attachShadow Doc on the runtime. And then you have things like Shadows Slots and advanced CSS classes to insert advanced widgets and functionality into your AMP pages from the Progressive Web App.
Now of course, you can do that last step manually by regexing the source of the AMP page, but the key is that the above is easy for everyone.
OK, finally, time for an even more advanced pattern I call AMP Konami Code, because it’s up, down, left, right– all the things.
So we have a pretty good experience now, but if you are in the Progressive Web App, copy a link, and share it on Twitter, that link will open the Progressive Web App directly.
And for a new user who doesn’t have a warmed up service worker cache, it won’t feel instant. That, too, is a problem we can solve in the final step of our development journey.
Instead of creating a separate URL space for the Progressive Web App– for instance, pwa.yourdomain.com/article– like we did before, we reuse existing AMP URLs to load the Progressive Web App on the site’s origin.
All we need to do for this is to listen for navigation requests in the service worker. Then, instead of serving a cached AMP page, we serve the cached PWA shell, which then does an XHR to fetch the requested AMP doc. This means that in just one request, your Progressive Web App would show up along with the requested content.
Best of all, we now progressively enhance our AMP pages with our Progressive Web App. And showing that no matter what, your users will get a super fast experience. For browsers that do not support service worker, they’ll simply see AMP pages.
So now, one additional thing we build is called fallback URL rewriting. And this means that even for browsers that do not support AMP caches, we’re giving to you the ability to rewrite links to another URL space that is a fallback URL for your Progressive Web App.
And there you got it. We’ve successfully combined AMP with a Progressive Web App. Now the user always gets it fast experience, no matter what. Your site is progressively enhanced. You have less backend complexity because you have just one data source, and profit from the built-in performance of AMP everywhere, even in your Progressive Web App.
Before I leave you, keep in mind this is just one pattern to build sites, and it won’t work for everyone. You probably shouldn’t build the next Air Horn or Gmail with it, but focus on sites that have lots of leaf nodes– individual sites with static content.
By all means, find out if the pattern is the right one for you, and feel free to get in touch to discuss. Check out our React-based demo and learn more about AMP and Progressive Web Apps individually on ampproject.org and developers.google.com/web. I can’t wait to see what you will build.