⚡AMPing up? A few things to consider.

A few weeks ago, I attended AMPConf 2018 in Amsterdam. It’s been a few years since the first AMP (Accelerated Mobile Pages) library was released, and yet it’s not a very known concept to most people. Google is a very big player in the development of this project. Of course, we wanted to take this thing for a spin at Greenhouse Group and transform one of our clients’ landing pages into an AMP. So it’s time for a short post on what AMP is, what it can (not) do and to share my experiences so far. I’ve only built very small projects with AMP, so I’m not an expert on it. But here’s my very opinionated review of my adventure.

So, what is AMP?

Well, according to Google it is this:

AMP HTML is a subset of HTML for authoring content pages such as news articles in a way that guarantees certain baseline performance characteristics.

In my understanding, it means that they have taken the basic building blocks of HTML and added a ‘little’ ruleset on it that allows and disallows certain usages. In specific, it focusses on using the highly performant parts and disabling the slow parts. For example, loading external resources like JS and CSS generally slows down a webpage (or at least it’s rendering) and therefore it is not allowed in the AMP spec. Assets like images have to be optimized and loaded with a custom tag. Stuff like that.

Styling

This was the first part that baffled me. ‘What?… No external CSS? But… web packaging?’. Of course, CSS is allowed, but not by supplying external stylesheets. Instead, you have to pack all your CSS in a style tag in the head of the page. And a special one at that:

<head>
      ...
      <style amp-custom>
        /* any custom styles go here. */
      </style>

So all the styling that is needed to style the current page you are serving to the user should be included internally. Also, to make things a lot harder, it should be under 50kb.

From a technical point of view, this might seem like an unnecessary hassle. We’ve been able to make pages fast for a while now, even on mobile. However, when you look at it from a user experience point of view, it can never be fast enough.

If it’s not instant, it’s not fast enough

And that seems to be the entire point of AMP. Do things that can be made blazingly fast, or don’t do them at all. So putting a physical limit to CSS seems like a logical decision. Especially considering that even very large sites have been able to meet this requirement.

JavaScript

Another very counterintuitive measure in my opinion. We’ve been so used to using JavaScript in websites that it’s impossible to imagine them without it. Same trick as CSS and inline it?

Nope, the restrictions here are much heavier than with styling. You can not use custom JS at all. In fact, the use of the script tag is prohibited unless the type is application/ld+json’. This has quite far going technical implications, but again when you think about it, a lot of JS that we use does not directly contribute to a better user experience. Extra load times, distracting animations, CPU/memory usage etc. In short, it consumes user resources for reasons that don’t always benefit the user.

Of course, JavaScript is not entirely unavailable. In this case, the AMP library contains a lot of premade components for building the most common things, like accordions, carousels, sliders and many others. This library has been growing quite fast, but all components are built in a way that ensures speed and prefers user experience above all else.

Build process trouble

Naturally, I ran into some issues. Our pages are mostly built in ReactJS, and we love to reuse our React components across projects. Sadly, React and especially JSX is not very compatible with AMP components. And since JS is not allowed, serving an SPA with React is definitely not valid as AMP.

I tried compiling the JSX components and turning them into static AMP afterward, but this proved to be a very troublesome process for a relatively simple page. In this case, I had to opt for building the AMP manually, which was not that much work, but I really missed my nice webpack build processes. The next step for me will be to try and automate this process. For now, it seems we have to stick to building the site from AMP components instead.

You noticed me saying ‘… definitely not valid AMP’? For a page to be fully compatible with AMP it has to be compliant with the spec. The easiest way to check this is by using the AMP validator.

Deciding on what to ‘AMP’

In this story so far we have seen some measures that feel quite crippling to web developers. Especially for websites with a lot of interactivity like in e-commerce. While the component library has been growing quite fast, it is not yet ready to replace all the features of a website.

Depending on your website, it might be a good idea to replace your entry points with an AMP. For example, we took one of our clients’ existing landing pages and made an AMP variant of that, while the rest of the web site remained the same.

However, there have been examples of people turning large parts of their websites into AMP, like CNN and The Washington Post. This can work really well for news websites, blogs, and other websites that are very content driven. There are even WordPress plugins that turn your page into AMP automatically. You may also have noticed that our own ‘The Marketing Technologist’ blog runs AMP, since Ghost has built-in support.

This could also mean that it’s no longer necessary for these websites to maintain and serve a regular version and an AMP next to each other. Why would we only serve ‘Accelerated Pages’ on ‘Mobile’? It works fine on a desktop as well.

Conclusion

Actually, to me, the AMP project is very two-sided. On the one hand, making the web better, faster and more user-friendly is a very nice goal. Technical difficulties should never be the defining boundary, we just have to think differently about the way we build stuff. Sure, it’d be great to stick to the build tools we all know and love, but there is always a next phase where we have to break all the old stuff down to make way for a better web. I’m all in favor of that.

On the other hand, I see one very large ‘but’ in this story. But… even though the AMP library is open source, this whole project is mainly backed by Google. Therefore whatever fork of the library is preferable by Google will be the de facto standard. This means that the decision of what’s good and bad is effectively in the hands of one company and this might lead to centralization of the web. Google is providing services like the ‘AMP cache’ to make your pages even faster, which is playing right into this wheelhouse.

Will AMP be the next big thing? I don’t know, but their story is very good and there is a clear value to companies of all sorts. Meanwhile, the AMP spec is expanding from content driven sites to e-commerce, multimedia stories, and even ad-tech. This last bit is obviously very interesting to a media company like Greenhouse Group, so there will definitely be more blogs on that soon.