AMPConf 2019 is just wrapping up but we’re just getting started! In this series of blog posts we celebrate AMPConf by highlighting how the React Storefront framework and Layer0 makes life easier for developers to support AMP in their React apps.
Keeping your AMPs DRY
We’ve been relatively early adopters in eCommerce for both Progressive Web Apps (PWAs) and Accelerated Mobile Pages (AMP). With React powered PWAs, developers can deliver highly engaging experiences on the web that rival native apps. However, when it comes to search-generated traffic, AMP provide the fastest possible option.
In fact, Google’s recommended customer journey is to first deliver an AMP version of your app to search users and transition to the full PWA version of your site on subsequent pages. And since nearly half of retailer website traffic comes from organic search, supporting both AMP and PWA has become a priority.
Writing a great app once is hard enough. No one wants to write the same app twice. Developers hate this kind of thing so much they’ve given it a popular acronym, DRY (Do not Repeat Yourself). As developers ourselves, we invested early in adding automatic AMP support to the React framework we created for eCommerce PWAs. This way developers can write their progressive web app once, in React, and get AMP support with no extra development effort.
And it’s worked very well for our customers. Instead of rebuilding their app, implementing AMP with React Storefront typically takes our customers a day or two, and most of that is simply verifying everything works as expected.
In this post, we will cover how React Storefront does the hard work for you in supporting AMP and PWA from a single codebase. In the next installment, we’ll share some exciting new features of Layer0 that help deliver AMP in a complex, enterprise context.
Why don’t all React frameworks do this?
To overcome this limitation we benefited from an early architectural decision to make React Storefront apps universal (sometimes called isomorphic) by default and support Server-Side Rendering (SSR) in Layer0. With SSR, rendering of the page is done on the server before it is served to users. While our primary goals in adding SSR were to improve performance and SEO, it also enables us to run a React Storefront app on the server and then automatically convert the HTML output to valid AMPHTML in concert with the techniques below.
Notify Google that AMP is supported
In other words, this:
results in something like this on your PWA page:
Now, when Google’s crawler sees a link to /p/1, it will download the AMP content and serve it directly from Google’s AMP CDN.
AMP aware components
Implementing even the most basic interactivity in AMP can be a huge pain. For example, a simple quantity field in AMP might look like:
Imagine writing two versions of code like this FOR EVERY INTERACTIVE CONTROL in your progressive web app. There goes your launch deadline!
The React framework takes care of rendering the AMP version of the component when Google requests an AMP page.
AMP’s declarative way of defining interaction events is completely different from React’s. For example, imagine you want to track clicks on specific product links by sending events to Google Analytics. In AMP, this would be something like:
React Storefront provides an abstraction, the Track component, that implements both of these for you:
Transforming server rendered HTML into AMPHTML
The strategies above get us about 80% of the way towards rendering valid AMP. There are, however, additional changes that need to be made to the document. React Storefront transforms the outgoing HTML before it’s sent making several changes, including:
Adding amp-boilerplate and ⚡
AMP requires some specific elements to be present in the document. These include a “⚡” attribute on the root HTML element, and a standard style element called the AMP boilerplate:
Transforming and consolidating CSS
When added up across all your styles, this automated conversion of CSS takes away another major headache when writing AMP compatible pages from your React app.
Cleaning up markup
There are various other rules that AMP imposes on the markup. For example, the way that ReactDOM renders boolean attributes produces invalid AMPHTML. This JSX:
will result in this HTML:
which results in the AMP validator showing an error like this:
If you use a component library, some of the HTML rendered by the components may run afoul of the AMP validator for various reasons. React Storefront encourages the use of the widely popular Material UI library, and provides specific rules for cleaning up the HTML it produces. This is where using a comprehensive react progressive web app framework that covers everything from state management to components and styling really shows its value in terms of increasing developer velocity.
Infrastructure for AMP and PWA
As a developer implementing AMP and PWA, you could implement two versions of your app and then maintain them through future changes (meaning that every fix becomes a code change in two places), or use automation to derive AMP content from your pages. At Layer0 we chose the latter, and it’s worked very well for our customers. The React Storefront features we’ve described so far are only part of the reason for that success. In the next installment, we’ll explore how the this framework integrates with Layer0 to support AMP in an enterprise environment. Stay tuned.