鈴木さんの記事を読みましてAMPの仕組みについて読んでみました。以下抜粋して日本語メモを。
モバイルウェブが爆速に！ GoogleがAMP (Accelerated Mobile Pages) を立ち上げ | 海外SEO情報ブログ
追記：ざっくり言うと、主にニュースとか静的コンテンツを想定し、HTML+CSSでJSは原則禁止、広告とかで使いたい場合iframeを用意するのでその中だけ。iframeや画像は事前にサイズを固定し変更不可にすることでlazyloadしてもレンダリング時にガタガタしないよね。というAMP HTMLフレームワークを策定したお話です。
原文：https://www.ampproject.org/how-it-works/
モバイルのための仕組み
（※見出しは筆者による）
Web performance is not unexplored territory for the tech community: books have been written about it, many talks have been given – there is even an entire conference series dedicated to the topic. However, users still frequently see poor web performance in the wild, particularly on mobile devices.
Consumption of news articles, and similar relatively static content, is often painfully slow, with pages taking a long time to load. Even after text becomes visible, pages continue to build up over many seconds, as ads and images come into display. The result is an often jarring experience of janky scrolling and users needlessly losing their reading position.
中略
To make the web fast at scale, we want to make it easier to create documents that are fast-by-default.
ウェブパフォーマンスは、技術コミュニティにとって未知の領域ではなくなったものの、ことモバイルウェブにおいてはまだまだ荒削りの状態です。ニュース記事を読むにしても、テキストが表示されてなお画像や広告を読み込むためにページの構築は何秒間も続きます。その結果ユーザは読むために不毛なスクロールと耳障りな経験をします。
そこで我々はWebを高速にスケールさせるために、デフォルトで高速なドキュメントを作りやすくしたいと考えました。
対象は静的コンテンツのみ
The web today is many things: an application platform, an e-commerce platform, a content platform, a gaming platform, and so much more. We decided to focus entirely on static content
いまウェブはEC、プラットフォーム、ゲームなど様々なものでできているので、その中で容易に適用できる静的コンテンツに集中することに決めました。
We began to experiment with an idea: could we develop a restricted subset of the things we’d use from HTML, that's both fast and expressive, so that documents would always load and render with reliable performance? That experiment has culminated in a promising proof of concept we call Accelerated Mobile Pages (AMP). AMP HTML is built on existing web technologies, and the documents written in it render in all modern web browsers and web views.
我々はHTMLのサブセットを開発し高速で表現力豊かな、そして信頼できるパフォーマンスを実現できるか検証し、AMPと呼ばれるコンセプトを実証しました。
AMP HTMLは既存のWeb技術で作られているため、すべてのモダンブラウザやWebViewで適切にレンダリングされます。（※翻訳元のページ自体がAMP HTMLで記述されています）
We think AMP HTML is promising, but we know it's not complete. We are sharing our proof-of-concept on GitHub to start a conversation about how to make static content on the web fast.
AMP HTMLは有望だと思いますが完全ではありません。ぜひgithubページをみて静的コンテンツを（モバイル）ウェブ上で高速にする方法について議論しましょう。
One thing we realized early on is that many performance issues are caused by the integration of multiple JavaScript libraries, tools, embeds, etc. into a page. This isn’t saying that JavaScript immediately leads to bad performance, but once arbitrary JavaScript is in play, most bets are off because anything could happen at any time and it is hard to make any type of performance guarantee. With this in mind we made the tough decision that AMP HTML documents would not include any author-written JavaScript, nor any third-party scripts.
私達が早くから認識していたパフォーマンス問題の一つに、ページ内に埋め込まれる多数のJavaScript（ライブラリやツール等）があります。
JavaScript＝パフォーマンス低下というわけではありません。しかし任意のJavascriptを実行させるとパフォーマンスの保証を行うことが非常に難しいため、難しい決断でしたがAMP HTMLは一切のJavaScript（自信が書いたものもサードパーティ製のものも）を含めないことにしました。
JavaScript is the core building block for advanced web apps, but for static content it may not always be required
中略
But the web platform has a great solution: custom elements and web components. AMP components may have JavaScript under the hood, but it is coordinated with other AMP components, so its composition into the page doesn’t cause performance degradation.
JavaScriptは先進的なWebアプリにとって中心をなすものですが、必ずしも静的コンテンツに必要ではありません。（投票などの機能を用いている記事はあるものの）ウェブプラットフォームにはカスタム要素とweb componentがあります。AMPコンポーネントの中にJavaScriptを用意しています、他のAMPコンポーネントと協調して動作するためパフォーマンスの低下を引き起こしません。
So, AMP HTML comes with strong limitations on JS. What about CSS? AMP HTML loves CSS! We do add some best practice enforcement, but we do want AMP HTML documents to look like their authors intended them to, and so allowing extensive styling is core to the platform.
AMP HTMLがJSに強い制限を加える一方、CSSはどうでしょうか。AMP HTMLはCSSが大好きです！いくつかのベストプラクティスを用意しましたが、AMPページで制作者の表現をぜひして欲しいので、スタイルの許可をプラットフォームのコアとして据えています。
Ads and analytics – while critical for publishers – are a big part of the performance problem and so they must be a big part of the solution.
中略
AMP HTML does not allow this. We realize that both ads and analytics are an important element of monetization on the web, and so we need to support them: our goal is to realign monetization with great user experience.
パブリッシャーにとって、広告と解析がとても重要であることは理解しています。（広告や解析は様々なタイミングでJSを実行しますが）AMP HTMLではそれらを許可しません。解析や広告がウェブでの重要なマネタイズ手段だと認識しているので、我々はそれをサポートする必要があります。私達のゴールは素晴らしいユーザ体験とともにマネタイズを再編成することです。
AMP HTML is taking the following approach to analytics: so-called “tracking pixels” can be embedded into AMP documents as long as they don’t use JavaScript. They typically come with a noscript version that makes this easy. More advanced analytics are currently not supported. Our vision is to deploy a single, unified, auditable, high performance, open source analytics library with AMP HTML that can report to various existing analytics provider backends, so it is possible to use the existing ecosystem without overloading a page with analytics software.
AMP HTMLでは、従来noscriptタグとともに用いられていたような解析ピクセルを使用して下さい。それ以上の高度な解析は現在サポートしていませんが、AMP HTMLが従来と同様の解析を出来るようなオープンソースライブラリを提供したいと構想しています。
instead they live in sandboxed iframes with no access to the primary document. 中略
We also prioritize ads lower during loading than other content and optimize load timing to avoid jank. Ads in AMP files can still be heavyweight, so there is still a lot of work to do for us.
（AMP HTMLはJSが利用できませんが）代わりにサンドボックスiframeに広告を表示できます。iframeは優先度低くロードされることでページロードを阻害しません。iframe内の広告自体に関しては、まだまだ高速ではないため私たちは多くのことをする必要があります。
速度について
So, how fast is AMP HTML? Pretty fast. In a sample of pages our early partners created we are seeing performance improvements measured through Speed Index between 15% and 85%. This was measured with a simulated 3G connection and a simulated Nexus 5 device.
それで、どれくらい速いのでしょう？めっちゃ速いで。SpeedIndexを使用してNexus 5の３G回線で計測したら、15%～85%位早くなりました。
But how do we get from good to, let’s say, instant? We’ll cheat :) AMP documents are from the ground up designed to be efficiently pre-renderable. Browsers have long supported pre-rendering through the <link rel=prerender> tag, but they need to be conservative about this mechanism because prerendering can be expensive. With AMP HTML we added the ability to tell a document: render yourself, but only as far as what is visible above the fold and only elements which are not CPU intensive to minimize the cost of pre-rendering. With this mechanism in place, referrers of AMP document can initiate rendering of docs before the user acts much more aggressively, so that in many cases the document will be done rendering by the time the user clicks.
でも、どのように実現しているのでしょうか。私たちはズルをしました。AMPは事前にレンダリングしやすいようにデザインされています。各ブラウザは<link rel=prerender>タグを実装していましたが、処理が重くあまり利用されてきませんでした。AMP HTMLは、ブラウザ自身がレンダリングするもののファーストビューができるだけ早く、かつCPU負荷の高くないものという条件でプレレンダリングするようブラウザに伝えます。このため、多くの場合でユーザがクリックする前にドキュメントのレンダリングが完了しているのです。
With all of these techniques in place, AMP HTML documents can be loaded with a small set of HTTP requests: the document itself, custom fonts (if used) and what we call the AMP JavaScript library that implements the AMP custom elements and resource loading.
これらのテクニックを適切にするため、AMP HTMLは少数のHTTPリクエストでロードできます。ドキュメント自体、カスタムフォント（使う場合）そしてカスタム要素やリソースをロードするためのAMPライブラリと呼んでいるものです。
Our goal with AMP HTML is reliable performance, so we designed it to be easily cacheable by content delivery networks (CDNs). Google is offering a service that delivers AMP HTML documents given their URL through its CDN. Others can use this service or make their own or serve AMP HTML pages from a plain-old-web-server.
信頼できるパフォーマンスを達成するため、CDN経由でキャッシュ可能な配信できるようにしました。AMP HTMLはGoogleが提供するCDN経由で配信することができます。もちろん自身のサーバからでも、普通の古いサーバからでも配信することが可能です。
レイアウトを事前に定義
This brings us to the final topic that makes AMP HTML unique: all resource loading is controlled by the AMP library and, more importantly, resources must declare their sizing up-front.
This doesn’t mean that resources can’t be responsive – they can be, but their aspect ratio or dimensions needs to be inferable from the HTML alone. This means that after initial layout, an AMP document does not change until user action.
中略
This gets us lazy loading with zero visual jank.
最後に、AMP HTMLを特徴づけている点について。すべてのリソースは、事前に自分のサイズを定義しておかなければなりません。
これは、レスポンシブデザインに対応していないという意味ではありませんが、縦横比やサイズを初期ロードのタイミングでHTMLから読み取れるようにしておく必要があります。AMPページは初期レイアウトされてから、ユーザがアクションするまでレイアウトが変化しません。（広告であっても固定の枠からサイズ変更を許可しないので）非同期でリソースを読み込んでもページがガタガタとレンダリングされることがありません。
To summarize: AMP HTML is a specialized subset of HTML with custom elements that provides reliable performance and instant loading of static content. Nothing about the project is set in stone.
中略
See you over on GitHub!
まとめ：AMP HTMLはHTMLのサブセットとカスタム要素で出来ていますが、まだなにも確定はしていません。See you over on GitHub!
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
ということで、HTML+CSSでシンプルなページを用意し、JSを禁止し、画像や広告の表示サイズを事前に固定することで、高速ロード、高速レンダリングかつ読みやすくなるよね！ということのようでした。Googleが参加するということでWeb界隈の人は抑えておいたほうが良いと思います。
