AMP and PWA with Michael Gaud • Surfacing.RR

This is the second post in a series called Surfacing.RR. In this series, we uncover nuggets of knowledge buried deep within the projects and teams at Retro Rabbit, and bring them to the surface.

In the second instalment of the Surfacing.RR series, we talk to Michael Gaud about accelerated mobile pages (AMP) and progressive web applications (PWA). Michael and his team work on the frontends for a variety of local insurance companies. They had previously created a couple of web-based products for these companies, and have recently undertaken a conversion of those web pages to both AMP and PWA.

Phlippie: Why did you use AMP?

Michael: The benefit of using AMP is that, when a web page is validated as being AMP-compliant, then Google will cache that entire page and serve it from their own domain. It is equivalent to using Google as a free content delivery network (CDN). With Google’s servers being situated everywhere, this means that our pages load very, very quickly from anywhere in the world.

Phlippie: How does it work?

Michael: AMP is like a set of constraints, together with built-in functionality, that forces and enables us to use best practices when making a web page.

Some of the constraints that are enforced are:

• We cannot include any custom JavaScript files
• We cannot use any external scripts
• The total CSS must be less than 50kB in size
• All CSS must be inline, so no external CSS files
• CSS cannot include the !important tag
• Only certain tags may be used with the Google Tag Manager

It sounds very restrictive. And in a sense, it is — it took us a while to adjust and to be able to produce the same fully-featured pages that we were used to making. But it is totally possible to do that. In the end, we didn’t have to compromise any functionality to make our pages AMP-compliant.

This is partly because AMP also includes a bunch of tools that let us implement our functionality in a way that is still AMP-compliant. For example, if you have your data available somewhere in a JSON list format, you can use the amp-list tag to fetch that data when the page loads, and amp-mustache to display that data on the page. Likewise, if you want to have state changes on the web page, you can use amp-bind to change variables on click events, and edit the hidden or class properties.

With enough patience and endurance to learn this new way of creating web pages, you can make a website that is ultra fast, without compromising on functionality.

Phlippie: And what about PWAs? Why did you use that?

Michael: The main benefit here is also caching, which gives us very quick page loads. We used AMP to boost the page load speed for mobile users, and PWA to pre-cache pages for desktop users.

With a PWA, you create a service worker to handle your caching. This means that caching is not left up to the browser, and we have a hook to make our pages load faster. What we do is we pre-cache the top 5 most visited pages on the website, which means that when someone navigates to these pages, it is served from cache and provides a near instant page load. Then, as you visit other pages that are not pre-cached, we also cache those, so that future visits to these pages will provide the same near-instant feedback.

Caching gives us another benefit in that, if the user if offline, cached pages are still available. Obviously any external calls won’t work, but anything that is already cached can be always be viewed.

And because we have this service worker, we can add further functionality. One thing that we would like to add in the near future is a simple offline indicator — when the user is offline, we show them a banner. This is the type of thing that the service worker can be used for in a PWA site. In fact, there are many, many things that we can do, that we’d like to do; another example is to enable push notifications from a web browser.

Phlippie: Were you able to write your sites using AMP and PWA from the start?

Michael: No, this was a conversion done to an existing site. And we only converted our pages that were previously served by our content management system, and left out the JS-heavy ones. So we did not add any functional requirements — i.e. any features — as part of our recent work. This was done completely to reach our non-functional requirements regarding a better user experience. It just feels better when a page loads faster. And Google also prioritises AMP-compliant sites in its search results, so it’s good for SEO.

But the conversion was not without its problems. There were many of those.

Phlippie: Tell me about the problems. What problems did you have with AMP?

Michael: When Google caches your AMP page, the page is not served from your domain; it is served under a Google domain name. This domain name is dynamic, and it caused us a lot of grief when we did form posts. We ran into CORS errors on production until we figured out a solution.

For the same type of reason, we had issues with Google analytics. When a user starts at a cached, Google-served page, and then navigates to a page that we did not set up with AMP, the cookies don’t carry over. The user gets a new session. This created problems with our advertising campaigns and gave the impression of fewer conversions and a higher bounce rate. We had to get the Google devs to assist us in fixing this problem.

Then another problem was that not everyone on the team was originally involved in the conversion to AMP. At some point, someone who was not familiar with AMP made some modifications to the code and broke it, in terms of AMP-compliance. We got various AMP validation errors, and then Google stopped serving our pages. This caused our conversion rate to drop to 0% for about a week before we realised what had happened. To our clients, this made it seem like their investment wasn’t worth it.

Phlippie: So if you’re making an AMP page, I suppose it’s a good idea to put CI in place to prevent this from happening. Any problems on the PWA side?

Michael: The cache, which is the very reason we use PWA, also caused a lot of problems. Most of our site is built with a CMS. So to update a page, we would update the contents of that page at the CMS. Normally, this would update the page at the user’s end. But now the user has their own cache of the site, so they always see the old version of the page. We have a fix which is probably not ideal, but it seems to work: our build scripts dynamically change the name of the cache when we do a new release. We deploy weekly, so the users’ cache is invalidated every seven days, so it works out.

Another major problem was with some of our Javascript being cached weirdly. For example in a callback request, you specify when you’d like to be called, and you cannot be called in the past, of course. However if you did a callback request 3 days ago, and again today, the variable that we used to store the min and max for the date picker would have been cached, so you can request a callback for yesterday, which is wrong.

We also disabled the PWA in development environments, as it made making changes annoying, requiring us to load each page twice.

The problems that we experienced were new to us, even as seasoned web developers. But none of them were deal-breakers. Despite the issues, we have gone live with our converted sites that offer the same fully-featured content that we previously had, only now they load lightning fast and rank at the top of Google’s search results. That really adds a lot of value for our clients.