AMP

AMP is a web markup framework developed and heavily promoted by Google through a combination of their Google Chrome browser and their Google Search and Google Adsense products. It is similar to HTML but more limited. AMP pages will supposedly load faster and in some cases they do.

History

AMP was launched with the name "Accelerated Mobile Pages" after discussions with San Francisco-based technology-giants like Twitter, Pinterest and LinkedIn as well as it's "partners" in the "Digital News Initiative" (DNI). DNI been described by Veit Dengler, chairman of the DNI Fund Council, as:

"a PR instrument for Google to win over the European publishing industry"

Veit Dengler, chairman of the DNI Fund Council

The name "Accelerated Mobile Pages" was later dropped in favour of the short-hand AMP

Google immediately begun promoting AMP versions of web pages in their search products mobile results when the first AMP pages appears on the web in February 2016. AMP pages were first promoted as "Top Stories". Google begun pushing AMP stories in the regular search result area too in September 2016. Microsoft added support for AMP pages to it's Bing apps for Android and IOS that same month. Mobile-friendly websites who opt to not adopt Google's AMP framework have been disadvantaged in Google's result since that time.

Twitter started linking users of their mobile app to AMP versions of links shared on that platform in June 2017.

Microsoft announced AMP support and AMP page caching in their Bing search engine in September 2018.

Performance "Advantages"

AMP pages are meant to load faster. Caching is the primary method Google, Bing and Cloudflare use to make third-party AMP pages appear to load faster. AMP pages found in Google and Bing will be served directly from those search-engines bypassing the actual website they are hosted on. AMP pages from websites behind Cloudflare's proxy system get served from Cloudflare's cache. Links pointing directly to an AMP page on a website that is not behind Cloudflare's man-in-the-middle reverse-proxy network will be served directly from that website.

The AMP markup itself is another reason why many AMP pages appear to be faster. It is very limited and it has some strict rules for what you can do compared to normal HTML. A simpler HTML page will load faster than a bloated HTML page with a lot of CSS, JavaScript and other elements. AMP pages have to be simple due to the restrictions that are built into it. A HTML page which is written with the same restrictions and the same simplicity AMP pages have will load just as fast or faster if it is viewed in a web browser which does not have built-in AMP support.

"7 Ways AMP Makes Your Pages Fast"

The AMP website's promotional page "How AMP works" has a embedded YouTube video titled "7 Ways AMP Makes Your Pages Fast".

A in-depth examination of these "7 Ways AMP Makes Your Pages Fast" provides some insights into the AMP framework which are worth considering when looking at the merits of AMP and the aggressive push for it.

"1. Never stop the content".

"Most websites include assets and scripts that are synchronously downloaded in the order specified therefore blocked rendering of the page. This could for instance be a third party app like this red domino here which appears between two blocks on a page. AMP solves this by making all of it's own scripts load in parallel at the same time and by not allowing any custom JavaScript which could break those rules.

Most JavaScript libraries have used async calls since forever so there is no difference between AMP and HTML.

"2. Asset-independent layout".

On a normal HTML page the browser often doesn't know what the layout will be before the assets are loaded. This is demonstrated using a rolled piece of paper, the point being that you don't know what it will look like until the piece of paper is rolled out and you see what's on it. In AMP, all external images, or ads, or iframes, must state their size in the HTML so AMP can determine each element size and position before the extra resource is loaded. So AMP loads the layout of the page without waiting for any resources to download.

A look at a standard image tag in AMP and HTML sheds some light on the above statement. An image tag in AMP can look like:

<amp-img src="welcome.jpg" 
  alt="Welcome" 
  height="400" 
  width="800">
</amp-img>

A HTML equivalent in HTML would look like:

<img src="welcome.jpg"
  alt="Welcome" 
  height="400" 
  width="800" />

However, HTML does not require more than

<img src="welcome.jpg" />

and in that case the browser really does need to load the image to know how it fits into a pages layout. The vast majority of images that are embedded in web pages do have width= and height= defined in the <img /> tag.

One major difference between a HTML image tag and a AMP image tag is not mentioned in the 7 point AMP promotial video: <amp-img> will only work when JavaScript is enabled.. Yes, really - just displaying an image requires JavaScript. Having fall-back tags using <img> and <noscript> is required if you want anyone viewing your AMP page with JavaScript disabled to see images. That's hardly an advantage.

"3. Inline, size-bound CSS"

"On AMP pages we allow only a single stylesheet and that one is inline. Compared to most web pages this removes one or often more http requests from the critical rendering path. The in-line stylesheet has a maximum size of only 50kb".

Regular HTML allows you to place a <style>tag within a pages <head></head> section. It could look like this:

<style type="text/css" title="Default-Style">
  body{
    font-size :1.1em;
     background: "#f0f0f0";
     color: "#000000";
  }
</style>

Most websites do not use in-line stylesheets even though HTML does support it. The vast majority of sites load CSS using one or more <link rel="stylesheet" href="" /> tags in the <head></head> section to load a CSS stylesheet from a separate file. Why would they do this if in-line CSS is so much faster, you may wonder? Because it is, in truth, NOT faster unless you only visit one page on a website.

Consider this simple example: You visit some page on this site and your browser downloads a 8kB HTML blog and a separate 14 kB CSS file which is linked in the head element of the HTML page. The total size is 8+14kB=22kB. That would be the size of the HTML page with CSS embedded in it. Some link on this site is interesting so you click that link and go to another page. The browser fetches a 5 kB HTML file which links to the same CSS file. The browser cached it when you visited the first page so it uses that cached file. The total size of the second page is therefore just the 5 kB the HTML file takes up. The total size of the two pages would be 8+5+14kB=27 kB. Embedding the CSS in the HTML page would make the first download 8+14=22 kB and the second download would be 5+14=19 kB - which adds up to a total of 41 kB.

The same principle applies to JavaScript. You can embed JavaScript in HTML pages. Most websites do not do that since it makes the browsing experience worse for anyone viewing more than one page.

In-line CSS makes a websites pages load marginally the first time you view a page but subsequent pages from the same site will load slower. This is not an advantage unless your entire website consists of just one page.

"4. Efficient font triggering"

Web fonts are super-large. So web font optimization is crucial for performance. On a typical page that has a few synchronous scripts and a few external style-sheets the browser waits and waits to start downloading those huge fonts until everything else is done. The AMP system requires zero HTTP requests until fonts start downloading. This is only possible because all JavaScript in AMP is asynchronous and only in-line stylesheets are allowed.

This is a semi-valid point, pages that do load fonts from the web can be slower if those fonts are loaded from CSS files. A page could have both a in-line stylesheet, like AMP, which loads fonts and a larger external stylesheet which can be caches. That eliminates AMPs "advantage" in those cases where external fonts are used.

The more important point, in my humble opinion, is that font files tend to be large additonal HTTP requests. It is less of an issue today than it was when I first learned that CSS has a @font-face. My reaction then was this is stupid. I've always used font-family with a list of fonts which may or may not be available. font-family:Consolas,"Courier New", Courier, monospace; would make the browser try Consolas then "Courier New" then Courier then monospace. A HTML page which loads no external fonts would be faster than a similar AMP page which loads 10 and vice versa.

"6. Minimize style and layout recalculations"

"Each time you measure or change something on a page the browser has to layout and re-calculate the page. These operations get fairly expensive. So assume that those are two pictures are already on the page. When this picture from earlier is half-loaded the content's over here. But when it's fully loaded the content is pushed further down. The browser doesn't know in advance what will happen to the layout of the page until all assets are loaded. On most pages multiple scripts do various dynamic things at the same time causing lots of re-layouts but because AMP mediates all render-operations that intelligently combines readings and changes to minimize effort. For example, we can get away with only one or two layouts before the page is displayed.

The example of what happens when a picture is loaded with and without AMP is as stupid as it's false since as good as all content management systems generate width= and height= elements as part of the <img /> tag. AMP requires them to be present, HTML does not. That makes little practical difference; close to all the images embedded in web pages do have image tags with width and height specified.

The JavaScript case can be valid. Some pages do load dozens of different JavaScript files from different places. Most of those JS files contain advertisements or trackers or both.

"6. Only GPU-accelerated animations"

"For the longest time all work to display page in a browser was done by a computers processor or CPU. It turns out that the graphics card, specifically your GPU, is much more efficient at pushing pixels around. By off-loading a lot of the visual work to the GPU, a browser can free up CPU cycles and make your page run faster. (..) AMP forces you to remain in the fast lane by only allowing those that can happen on the GPU, namely transform capacity.

This "argument" really shows how Google has tied AMP is with it's Chrome browser product. AMP is, at it's core, a mark-up language. It has no control over what the web browser. Google does have control over it's own browser product. Other web browsers like Firefox will behave differently and both Firefox and Chrome behave differently depending on the device and operating system they are running on.

The essence of this "argument" is that Google's own browser is optimized to display AMP pages faster than regular HTML pages.

"7. Prioritized resource-loading"

"When AMP downloads resources it optimizes downloads so the currently most important resources are downloaded first. Images and ads are only downloaded if they are likely to be seen by the user. Now, above the fold, or if the user is likely to quickly scroll them, and so we make a prediction that they will be seen on screen."

This is, like the last "point", describing a web browser feature.

"When AMP downloads resources" is, like "When HTML downloads resources", a nonsensical statement. A web browser downloads resources from web pages. If this was a commercial for a web browser like Brave and the story was "When Brave downloads resources it optimizes downloads and that makes it faster than Falkon and Midori" then it would make some sense (if that were true).

Conclusion

The 7 "points" describing how AMP "is faster" are all nonsense to the point where it's fair to ask "Why did they bother making that propaganda video?" People who have no idea how a computer works may buy those "arguments" but people who've done any web development will have a hard time swallowing those pro-AMP arguments.

Actual AMP Performance Advantages

AMP's markup and rules places limits on AMP pages which forces developers to make very simple pages. This can be done in HTML too. Consider this very simple HTML example:

<!DOCTYPE html>
<html>
<head>
  <title>Hello World!</title>
        <meta charset="utf-8">
        <meta name="viewport" 
          content="width=device-width, initial-scale=1">
        <style type="text/css" title="Default-Style">
                body{font-size:1.1em;}
                li{padding:0.2em};
        </style>
</head>
<body> 
<h1>Hello, world!!</h2>
<p>This is a simple HTML page.</p>
</body>
</html>

The above HTML page would, due to it's simplicity, load instantly. It would load instantly on very slow mobile connection and Tor connections since it's only 415 bytes. It is not very informative and it would be bigger if it had more text - but it is a simple, working HTML page.

The AMP equivalent of this would, according to the AMP.dev documentation be:

<!doctype html>
<html amp lang="en">
  <head>
    <meta charset="utf-8">
    <script async src="https://cdn.ampproject.org/v0.js"></script>
    <title>Hello World! In AMP</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;
   </style>
  <noscript><style amp-boilerplate>body{
    -webkit-animation:none;
    -moz-animation:none;
    -ms-animation:none;
    animation:none }</style></noscript>
  </head>
  <body>
    <h1>Hello World! For mobile</h2>
    <p>This is a simple AMP page.</p>
  </body>
</html>

First thing which stands out in the above AMP example is the <code><script async src="https://cdn.ampproject.org/v0.js"></script></code> line. That v0.js file is, as of December 2019, 256 kB. The above is 1080b or 1kB which makes the AMP page a 257kB download while the HTML equivalent - which does not need a huge JavaScript blog to say "Hello World - is just 415 bytes. It doesn't take a genius to understand which of those will be a lot faster than the other.

The equation changes if you compare a poorly written gigantic HTML page which loads JavaScript from dozens of different places with a simple AMP page. The same is, of course, true if you compare a simple and tiny HTML page to a very long AMP page.

Googles push towards AMP seems to be more about control and web browser and search-engine tie-ins than it's about performance and end-user experience.

That behind said, there are real-world performance advantages. One article from the British blogg "DailyMail" about some guy using "too much" Botox can serve as a fairly typical example. The amp version of their article is a 152 kB HTML file. The non-AMP desktop version of that same page weighs in at 568kB. The majority of both pages code consists of links to other articles on that site. The mobile version has fewer links and less text in the links - which largely explains a huge part of the reduced size. If a HTML mobile version would be faster or slower than the mobile AMP page is a question worth asking.

Should You Make AMP Versions Of Your Websites Page OR "Is Resistance Futile"?

The short answer: Yes, you should make AMP versions of the pages on your website.

The long answer: AMP has no performance-advantage over regular HTML pages that are clean and optimized the way same AMP pages have to be due to it's more restrictive rules. AMPs other "performance-advantages" are mostly nothing more than web browser optimizations for AMP that are specific to Google's Chrome product. It's easy to dismiss the whole AMP thing as stupid. However, Google controls much of the web. Like it or not; it is a present truth. More people will read articles on your websites or visit your web store if it has a high search engine ranking. Both Google and Microsoft promote AMP pages in their search products results. That competitive advantage is probably why so many mainstream media sites have "AMP optimized" versions of their web pages: It's essentially a question of if you competitor is taking advantage of how search engines favour AMP pages then you've better make your own website AMP optimized or you will loose market-share..

This site doesn't have have any AMP version. Mobile users get regular HTML pages with a mobile-friendly skin which differs from the desktop version and that's the way it will be in the foreseeable future. That doesn't mean you shouldn't make your site AMP friendly. If it's about educating people, free software or things of that nature then you'll do just fine without AMP pages. If you, on the other hand, are trying to maximize profits now so the shareholders of some large multi-national corporation you work for can get dividends then you should absolutely make AMP versions of your site(s).

Footnotes

Sort by date Sort by score

Enable comment auto-refresher

Add your comment

LinuxReviews welcomes all comments. If you do not want to be anonymous, register or log in. It is free.