At the recent AMP Conf (in AM(P)sterdam of course!) there was an interesting talk titled “Progressive Web AMPs” that explored the merging of AMP and PWA technologies. The following is my summary and interpretation of the Carved.com ecommerce use case presented by WompMobile from this session – any errors in the following are my own!
(Note also a previous joint blog post I did with WompMobile for an example Magento 2 AMP module they released publicly.)
Accelerated Mobile Pages (AMP)
One interesting tidbit from the video is just having the AMP lightning bolt on the search result increased the click through rate of users significantly. Mobile users already recognize that the AMP logo means a fast experience, increasing how often they explore the link.
Progressive Web Apps (PWA)
PWAs on the other hand define a set of practices that used together allow a rich app like experience delivered in a web browser. Push notifications, home page links, service worker for background caching and offline operation – PWAs support great flexibility. PWAs frequently preload resources for the predicted next page in the background, allowing fast navigation after the initial application is loaded. (The first page load of a PWA is also optimized, but no preloading occurs until the PWA is launched.)
Progressive Web AMP (PWAMP)
PWAMP is the idea of combining AMP (with their fast first page load) and PWA (with their fast subsequent page refreshes). This was the idea that WompMobile took away from a 2017 presentation, productionized, and reported back on their successes in 2018.
WompMobile identified “content” landing pages (such as product and blog pages) that should be indexed by search and created them using AMP to give a fast first page experience with good SEO. Other pages were then implemented by a PWA with fast subsequent pages (cart management, checkout, payments, order tracking, etc).
A typical user flow may be as follows.
- A user performs a web search, returning a list of results.
- AMP pages linked to from the search results get pre-fetched in the background (e.g. incrementally as the user scrolls around the result list).
- When the user clicks on a match, the AMP page displays near instantly due to the background preload.
- The AMP page includes a “amp-install-serviceworker” component to start downloading the PWA service worker in the background.
- Links from the AMP page navigate the user to the PWA experience, partially pre-loaded by the previous step.
To achieve a consistent user experience, the AMP pages and PWA pages had the same page header (the same top of page branding, menu structure, and navigation controls). Users are not aware that two technologies are being used behind the scenes. They just experience great performance as they navigate throughout the site.
The Clever Parts
But what if the user performs a search within the PWA and wants to navigate to a different product page? This is where the approach WompMobile used gets clever. Rather than leaving the PWA experience, the PWA loads the AMP page for the product and treats it as a cacheable “content block”. The PWA can choose to preload such pages (as well as cache them for later offline usage) To display the AMP product page, the PWA generates the page header and then adds the body of the AMP content block (after removing the header block from the AMP page to avoid two headers being displayed). WompMobile reported success both using iFrames and the Shadow DOM to display the AMP content.
The end result is developers did not have to create product pages in both the PWA and AMP experiences and keep them in sync – the AMP pages are directly used by the PWA application, reducing duplication of effort.
Other PWA Notes
For push notifications, WompMobile deferred asking for permission to send notifications until after some meaningful engagement with the user (e.g. after adding a product to a cart) – not immediately when a user first arrives on the site. The user is more likely to say “no” on first arrival – they need to be given a reason to say “yes” (such as receiving a notification when a product goes on sale).
The “add to home page” offer for the web application similarly is best left until the user has a reason to say yes, such as after the user completes an order. Having submitting an order, the consumer may want to come back and track their order status. That gives them a reason to add the app.
For full details, watch the video! The above is my summary and interpretation of the presentation. But the end result for carved.com is they reported improved conversion rates which now rival desktop rates. They improved ranking in search from use of fast AMP pages (speed is a ranking signal for Google), delivered a fast experience for users when the follow a search link, and a fast experience on subsequent pages. The video shows a full flow from Google search to completing checkout in around 20 seconds.
There are negatives in this approach – combining PWA and AMP together does require more technology to be understood by developers. But what appealed to me about the approach was it resulted in a fast experience from first page throughout the experience, with good SEO behavior. (Indexing a pure PWA is harder and probably less consistent across search engines.)
Note: The Progressive Web AMP presentation is not radically new in concept – articles discussing the approach date back to March 2017 – but it was good to hear about the approaches being live in production with great results.