Google AMP in 2020 - better, but still not good

Recently, in one of my previous blog posts, I covered how I redesigned and optimized my blog. There, I mentioned my numerous unsuccessful past attempts of redesigning it. However, I skipped the part that I wasn’t too proud of - my Google AMP journey.

Accelerated Mobile Pages (AMP for short) is a technology introduced by Google in late 2015. If you’re a web developer, you’ve probably already heard of it. Ever since its introduction, the technology promised to make creating performant mobile-friendly web pages easier and more enjoyable. But, with a major backlash for the developer community, it hasn’t reached the level of approval that I think it was intended to - at least not without a whole lot of controversy.

So, after all these years and with my latest experience, I’d like to give you a brief overview of AMP’s current state and if it got any better than it was. Spoiler warning - it did, but still not enough.

What’s AMP?

Let’s start with a more in-depth explanation of what AMP really is and how it works.

Generally speaking, AMP is an open-source Web Component framework. Web Components itself is a set of different technologies enabling developers to create native, reusable components, inspired by but not bound to any JS framework.

Limitations

AMP builds upon this technology to provide you with a set of optimized components for easier development of performant websites. However, it’s not your typical component library you might be accustomed to. That’s because, while providing you with these components, AMP also restricts the use of custom JavaScript code and limits your usual CSS and HTML capabilities.

And so, your HTML must have a proper structure, and you can’t use certain tags like <img> and <iframe>, rather than their AMP component equivalents (<amp-img>, and <amp-iframe>). Your CSS also needs to be inlined inside the <head>’s <style> tag, and is limited to a total of 75KB, and 1KB per style attribute, if you decide to include your CSS this way.

However, it’s JavaScript that’s the most limited in AMP. Only recently it became possible to use a limited set of JS functionalities inside AMP pages. But still, the go-to way of using any moderately-advanced custom JS code remains to be an <iframe>, or should I say <amp-iframe> which also comes with its own set of limitations.

Because of all that, AMP is best suited for fairly simple, text-heavy publications like blogs or media outlets and that’s where it’s seen the most adoption.

AMP Cache

Thanks to all these limitations, AMP websites can be quite fast. But there’s still one more secret to their performance. After all, AMP or not - a website is a website and there’s no special in-browser optimization that could make them any faster. No, the secret is AMP Cache.

AMP Cache is a proxy-like Content Delivery Network (CDN) that’s designed to serve only valid AMP pages. Most notable AMP Cache providers are Google and Bing, whose servers thanks to their sheer size and computing power, can deliver AMP pages to users around the world blazingly fast. However, if your AMP page isn’t fully compliant with AMP strict rules, or doesn’t get cached for any other reason, it won’t experience this potentially huge performance bump.

AMP experiences

Although in this post I talk mostly about AMP websites which are the main part of the AMP ecosystem, there are other kinds of experiences that AMP supports. These are AMP stories (quick slideshow-like experiences), AMP ads (for creating AMP-compatible “user-focused” ads), and AMP email (for rich AMP-based emails).

Developers’ issues

Now, with this brief overview of AMP and possibly your personal experiences with the technology, I think you can already see at least some of the reasons why so many developers are against AMP.

Lack of customizability

Because of all the limitations that AMP puts on your design, it can be rather hard to use it to create the website you’d truly want. Although AMP components can often speed up the development of certain features and CSS is all you need to customize most of the website’s elements, many AMP pages (especially those generated automatically by e.g. a WordPress plugin) can lack the feeling that’s so special to a given website or brand.

Unclear performance benefits

Even though AMP is clearly focused on mobile and speed, the performance benefits it provides aren’t guaranteed. It’s no mystery that a lot of AMP’s performance edge comes from the use of AMP Cache. If your AMP website isn’t eligible for caching or is accessed directly from your own servers instead of the cache, you might experience no performance gains at all!

In reality, it’s really hard if not impossible for an AMP page with all its somewhat-bulky Web Components and without AMP Cache or Google’s clever pre-connect tricks to come anywhere close to hand-tuned website.

Google’s dominance

The last and probably the biggest concern developers had against AMP is Google’s influence.

Even though AMP is an open-source initiative, it was started by Google and it’s Google who stands to gain the most from it. It’s clearly visible in Google’s push towards AMP and the way they treat the technology.

AMP holds a very special place in many Google services, which, as we know, are one of the major sources of traffic for many websites. Google often favors AMP pages on its primary search results page, in Google Discover, and various other services. AMP stories - the same ones I’ve talked about earlier - also get special treatment in form of a placement at the top news carousel that’s often seen in search results.

Technically, Google says that they prioritize pages in search results by performance(among content and other factors) and that a well-optimized website can get similar results. And because AMP pages are “fast by default” they get this special treatment pretty much out-of-the-box. But I’ve already told you that it’s only the case when AMP gets cached - and I assure you all pages that Google shows are cached. Funnily though, that’s yet another case to be made against AMP.

AMP Cache is no magic - it’s just a very fast caching mechanism - and that’s it. But such a cache doesn’t work fully transparently. Whenever the user accesses your AMP page cached e.g. by Google, instead of your domain and proper URL, they’ll see Google’s in their URL bar. Your domain may only be visible in an additional grey bar below the proper URL one.

Many people agree that this limits brand recognition. It’s also a source of many issues related to what URL to use when sharing (although it now uses the original URL in most browsers) and so on.

Recent improvements

All of these issues might make AMP seem bad, but in truth… yeah it kind-of is. Sure, maybe its public goal of better and faster Web experiences for the users is good, but the implementation is currently “meh” at best.

However, AMP has come a pretty long way since its introduction and many changes have been made to make it better for developers and users alike. It’s still not enough for sure - but these are steps in the right direction.

Governance changes

I won’t be going too much into details here. Generally, the main take away is that AMP ever since late 2018 is under a new, more open governance model. It’s certainly part of an effort to steer AMP away from negative “Google stigma”, and more into a true open-source philosophy.

Because of the change development of AMP is now in control of the Technical Steering Committee (TSC) composed of various publishers who use AMP.

JavaScript allowance

Like I’ve mentioned earlier, JavaScript has only fairly recently been allowed to run on AMP pages (outside of the <amp-iframe> that is). It’s possible thanks to <amp-script> Web Component that executes the provided JavaScript in a special Web Worker-based environment with virtual DOM, without blocking the main thread.

Although this approach sounds promising, it’s important to remember that Web Workers don’t have access to DOM, and thus, such implementation requires custom handling for all of the JS DOM API methods. Due to this requirement, only a handful of most basic and common methods is implemented. And in classic AMP style, the size of the JS code is limited to 10 KB per <amp-script> with a total of 150 KB allowed.

The lack of custom JavaScript in AMP pages, although really limiting has been one of the key ingredients responsible for making AMP fast. However now, with the introduction of <amp-script> some started to doubt if it’s the right way. In theory, the Web Worker implementation is aligned with AMP’s goals, but from one hand - it’s still custom JS - and from the other - it’s still too limiting for advanced use.

URL changes

Outside of the AMP itself, Google has also made some steps to make the project more appealing. Arguably the biggest change here is the introduction of Signed HTTP Exchanges (SXGs). It’s a feature that allows correctly set up and verified domains to display their original domain in the URL bar, even if it’s accessed through AMP Cache.

Truly, it’s a step in the right direction. However, currently, it’s quite flawed. Setting up SXGs yourself can be cumbersome, and the only other way is to use a service provider, which - at least for now - means Cloudflare AMP Real URL only.

Also, to work correctly, SXGs must be supported on the browser side as well. Thus, low cross-browser support is yet another problem as only the latest Chromium-based browsers support it. Probably the most notable exclusion is all the iOS-based mobile devices.

Personal experience

To tell you something about my personal experience with AMP, I did try it. In fact, I originally wanted to redesign this whole blog with AMP support built-in.

To be honest, the development experience wasn’t really that bad - especially with Ghost’s support for AMP. Many features were really easy to implement with AMP components. However, the lack of feature-full JavaScript support was a deal-breaker.

The two most important pieces of custom JavaScript on my blog are the comment section and the ad that keeps it all running. While the comment section was somewhat easy to put into <amp-iframe> (although it felt unnecessarily complicated and hacky), the ad was not. Sure, I could put it inside the <amp-iframe>, but the problem is that AMP prohibits such practice. Only a handful of compatible ad networks are supported through the dedicated <amp-ad> component. And sadly, Carbon Ads which serve developer-friendly ads here on my blog - is not one of them.

Thus, I ended up hand-tuning my website, achieving better performance than AMP - with or without AMP Cache.

Summary

So, to summarize it all, AMP is a pretty interesting idea with some great goals in mind for making the Web a better place. However, it’s the execution that complicates everything so badly.

Sure, if you’re running a big news outlet, or say an unmonetized blog or one monetized with big, well-known ad networks (e.g. Google AdSense), then AMP might be a good choice for you. But not really because of its speed (unless you don’t have time to properly optimize your website that is), but rather because of all the Google perks that you get with it.

That’s it for this post. What do you think about AMP? Do you like it or not? Do you think it’s just another piece to the puzzle of Google’s total domination? Feel free to share your thoughts in the comment section below. And follow me on Twitter, Facebook, or through my weekly newsletter for more up-to-date content! Thanks for reading!