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)

In brief, the goal of AMP is have fast web pages. AMP defines a restricted subset of HTML with additional rules to ensure an efficient web page. Example restrictions include CSS in the page is restricted to 50Kb, and there are special rules around JavaScript. This when combined with the “AMP cache” can result in near instant display of AMP pages from Google searches. (Bing, Pinterest, and others also support 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.

1. A user performs a web search, returning a list of results.
2. 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).
3. When the user clicks on a match, the AMP page displays near instantly due to the background preload.
4. The AMP page includes a “amp-install-serviceworker” component to start downloading the PWA service worker in the background.
5. 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.

Further, WompMobile did not like duplicating the header markup in the PWA and AMP portions of the code base. To overcome this challenge, they used “checkbox hacks” and CSS tricks to implement menus without need for JavaScript. (AMP pages cannot have arbitrary JavaScript added.) This meant the header markup could be directly shared between the PWA and AMP pages. (There may be other ways to achieve the same goal, but this is what WompMobile reported they did.) This avoided code duplication and guarantees the AMP and PWA headers look the same at all times.

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.

Conclusions

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.