Tags: Web Design
Google first told us about AMP five years ago, spinning it as a way to - as the name suggests - speed up the web experience on mobile devices. Mobile devices are clearly extremely important, since most people are using such devices to read websites. Since mobile devices have constrained abilities, we should develop websites with technology to match, and AMP was a way to force us to do so. While laudable, the implementation puts Google squarely in control of web technology, and that's not right.
I'm surely more than a little late with starting to complain about AMP. I'd heard about it when Google first unveiled the idea, and felt so leery of it that I refused to even take a look. What had me take a look is an article,
Google Is Tightening Its Grip on Your Website, talking about the dangers of adopting AMP. Bottom line, when you decide to implement AMP, Google imposes a number of requirements that improve web speed but puts Google in control of many things, removes control over your branding and even hides your URL in favor of a Google-owned URL. The tradeoff is a big stream of traffic, enough to be tempting to rework my websites to the AMP specification.
My take is a little different. All the control over branding and URL is a big problem sure, but what I see is a hyper-control attitude that prohibits us from using normal web technologies, and prohibits us from choosing which technology to use on our websites. What business does Google have of dictating technology choices to website publishers?
What follows is one website publisher examining the AMP technology, including the constraints that would be put upon my website, and coming away turned off. I'm curious if others share this opinion, or can convince me that I'm overreacting and should drink the AMP koolaid.
Implementing AMP for a website
At first blush it looks easy. Go to the
AMP getting started guide and start reading, it's clear I could easily implement this in my web publishing workflow.
Namely, I create a plugin for AkashaCMS (the static website generator with which I build several sites including this one). It's task would be rewriting normal HTML to AMP's limited version of HTML. AkashaCMS has powerful features that would make this easy. But as I read about how to do this, I have become more and more alarmed. AMP appears to be a heavy-handed attempt by Google to control technology choices by companies that are supposed to be independent publishers.
The way AMP speeds up websites is by prohibiting several normal everyday HTML tags we've used for decades, and instead requires us to use the AMP version of those tags. Further, we are simply prohibited from loading external CSS and no JavaScript other than AMP-approved JavaScript. Eh?
But let's get on with examining AMP's technology:
<!doctype html>
<html amp lang="en">
<head>
<meta charset="utf-8">
<script async src="https://cdn.ampproject.org/v0.js"></script>
<title>Hello, AMPs</title>
<link rel="canonical" href="https://amp.dev/documentation/guides-and-tutorials/start/create/basic_markup/">
<meta name="viewport" content="width=device-width,minimum-scale=1,initial-scale=1">
<script type="application/ld+json">
{
"@context": "http://schema.org",
"@type": "NewsArticle",
"headline": "Open-source framework for publishing content",
"datePublished": "2015-10-07T12:02:41Z",
"image": [
"logo.jpg"
]
}
</script>
<style amp-boilerplate>body{-webkit-animation:-amp-start 8s steps(1,end) 0s 1 normal both;-moz-animation:-amp-start 8s steps(1,end) 0s 1 normal both;-ms-animation:-amp-start 8s steps(1,end) 0s 1 normal both;animation:-amp-start 8s steps(1,end) 0s 1 normal both}@-webkit-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@-moz-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@-ms-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@-o-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}</style><noscript><style amp-boilerplate>body{-webkit-animation:none;-moz-animation:none;-ms-animation:none;animation:none}</style></noscript>
</head>
<body>
<h1>Welcome to the mobile web</h1>
</body>
</html>
We're shown this as a base template. This looks pretty normal, and most of this I've already implemented on my site.
The application/ld+json thing is a little curious. Why not implement that with <meta> tags? But I'm sure that at schema.org there's some documentation about this which I've missed.
But as we read on, we learn that <img> tags are forbidden, and instead we're supposed to use this:
<amp-img alt="A beautiful sunset"
src="/static/inline-examples/images/sunset.jpg"
width="264"
height="195">
</amp-img>
And if we want responsive images we should do this:
<amp-img alt="A view of the sea"
src="/static/inline-examples/images/sea.jpg"
width="900"
height="675"
layout="responsive">
</amp-img>
Why in the flark is responsiveness implemented using layout=responsive? Why isn't that implemented in CSS? Responsive behavior is best implemented in CSS.
What I understand to be the best practice is a max-width: 100% style on images so that they resize automatically based on viewport size. Who in their right mind uses fixed height and width on <img> tags? That's so 1997.
Since the <amp-img> tag requires the AMP JavaScript library to load, what happens if JavaScript has been disabled? We're told we actually have to do this nonsense:
<amp-img src="/static/inline-examples/images/sunset.jpg"
width="264"
height="195">
<noscript>
<img src="/static/inline-examples/images/sunset.jpg" width="264" height="195" />
</noscript>
</amp-img>
That is, use a <noscript> fallback to using a regular <img> tag.
In order to use an animated GIF one has to use an <amp-anim> tag? An animated GIF is just an image and should be loaded using an <img> tag.
To embed video, you use <amp-video> rather than a normal Video player, and for audio you use <amp-audio> again instead of a normal Audio player.
AMP's hyper-control paradigm
The hyper-control paradigm gets even worse when you start reading the
AMP HTML specification. While there may be a technical reason behind certain limitations - the prohibition on
<script> tag use is extremely egregious.
We are told the <script> tag is:
Prohibited unless the type is
application/ld+jsonortext/plain. (Other non-executable values may be added as needed.) Exception is the mandatory script tag to load the AMP runtime and the script tags to load extended components.
Here's where they lost me. We're not allowed to use JavaScript unless it is JavaScript controlled by the AMP project?
I fully understand where they're coming from. A lot of websites are loading a bunch of heavy weight overly burdensome stuff, most often to intrude noxious advertising into the reading experience. I get that and it is a really bad practice.
But is the solution to ban all JavaScript other than JavaScript loaded from AMP's servers? Oh, and the kicker is that everything on AMP's servers is controlled directly by Google's engineers.
AMP Extended components - more hyper-control paradigm
For an example of what they mean by extended components let's learn how to embed
a Twitter or Instagram or Facebook posting.
Normal practice for certain sites is to allow us to embed content from other sites, like a Tweet or a YouTube Video, by grabbing the embed code to insert on our site. Often the embed code uses some JavaScript that's loaded onto the page.
Since JavaScript is prohibited by AMP, they had to develop a means for 3rd party content like this to be embedded. I suppose we're expected to think "Oh how nice and thoughtful of Google to develop a mechanism for Tweets to be displayed on the web page". But in actuality it is an example of Google exerting a perverse hyper-control paradigm on the technology choices for what we publish on our websites.
In order to enable the <amp-twitter> component we must first load this:
<script async custom-element="amp-twitter"
src="https://cdn.ampproject.org/v0/amp-twitter-0.1.js"></script>
Notice that the URL points to the AMP project server, which is owned and controlled by Google. Surely to get this posted on that server requires working with Google engineers. More importantly it means that random third parties cannot get their code hosted on ampproject.org. Instead, only the organizations Google is willing to work with can get their custom components hosted on that site.
Then to embed the Tweet we do this:
<amp-twitter width="500"
height="583"
layout="responsive"
data-tweetid="638793490521001985">
</amp-twitter>
The result is that the normal mechanism for embedding a Tweet (or Instagram etc) is prohibited, and instead we are forced to use this artificial mechanism that puts the AMP project in control.
AMP's control over stylesheets
We're told that using <link> to load an external stylesheet is prohibited. Instead stylesheets are required to be in-line with the web page.
Clearly the purpose is to speed up page loading by reducing the number of external things that have to be loaded. Any of us who've looked at web page performance know that every loading of an external thing, whether a stylesheet or image or whatever, is another round trip to the server, and it takes more time. By inlining CSS we save some round trips.
But the downside is it increases the total bandwidth consumption. Suppose your stylesheet is 10KB (bootstrap.min.css is 155KB). If it is loaded externally, it'll be loaded once per website then kept in the browser cache. If it's inlined to the HTML page, then every HTML page is suddenly 10KB larger because now the CSS is loaded for every web page on the site irregardless of whether the reader has already loaded a page from that site.
AMP prevents us from using Bootstrap or other front end framework
By prohibiting all JavaScript, and prohibiting all external CSS, AMP prevents us from using normal every day web frameworks.
I use Bootstrap on my sites primarily for some modern niceties. Now that I've paid attention to the size of the CSS file (150KB is excessive) I'm thinking it'd be a good idea to explore alternatives. For example
Shoelace suggests it is an excellent framework For when you don’t need the whole boot.
Why is Google intruding on our decision of what technology to use?
AMP prevents using Vue.js or React or whatever .. e.g. how can we develop inline calculator widgets?
There are a zillion different things we can do with custom JavaScript. The rage now among the cool kids is using libraries like React or Vue.js to implement things. Using libraries of this sort requires creating custom JavaScript and CSS code, loading it in the web page.
But.. we're prevented from doing this because of AMP's hyper-control paradigm.
Instead there is a whole interactivity framework built into AMP. It seems anything we wanted to do with React or whatever is doable with AMP. But... why? Why is Google preventing us from deciding which technology to use?
AMP prevents using non-blessed icon libraries or custom fonts
Some icon libraries and custom fonts are distributed using CSS declarations that get added to the HTML. That results in using a <link> tag to load a stylesheet, which we're prohibited from doing by AMP's hyper-controlling rules.
In another of those Oh how nice and considerate Google is being moments, we learn that we can load
Custom fonts in AMP. But the hyper-control paradigm side of it is we are only allowed to use font and icon services blessed by the AMP project.
They give this example:
<link rel="stylesheet" href="https://fonts.googleapis.com/css?family=Tangerine">
Notice that this is a Google-owned service. Yes the Google Fonts service is an excellent tool, and I am grateful that Google offers this service. But what about Harry's Fonts or George's Fonts?
The AMP documentation kindly lists a set of resources which are whitelisted, and therefore allowed. But while that's nice and considerate, it is another example where Google is intruding on our decision of what technology to use on our sites.
There's a bunch of other examples I could talk about but I've grown tired of complaining, and want to instead talk about what my preferred solution would be.
What should Google have done rather than develop AMP?
Google's laudable goal of speeding up the web experience for mobile users has led Google to asserting hyper-control over technology choices we make to build our web sites.
I believe that Google could have taken a different route. One that does not force prohibitions against this or that piece of web technology. That instead is open to any web technology, but instead objectively measures performance and impact. Such a tool would then enable any technology team or website developer to refine their implementation by using the technology they choose.
For example many years ago Yahoo developed a tool, YSlow that is now hosted at
yslow.org. It's a browser extension providing excellent measurement of web page loading performance. It included a number of metrics related to improving load times.
The YSlow project appears to be dead - so I'm not suggesting this specific project. Instead I'm suggesting it as an example model to follow.
The YSlow project had the same goal, to speed up the web experience. It did this not by heavy handed prohibitions against using normal web technology practices. Instead it did this by objectively measuring the results of your technology choices. And it coached website publishers on improving performance.
That's the model Google should have used.
That's the Don't be evil model Google supposedly lives by.
