AMP简介
AMP是如何提升性能？
以下的优化点是AMP页面能被快速加载的原因：
- 只允许异步脚本
- 静态计算资源尺寸大小
- 不让 外部插件阻塞渲染
- 让所有第三方JavaScript离开关键路径
- 所有CSS必须内联
- 字体触发必须高效
- 最小化样式重计算
- 只运行GPU加速动画
- 加载资源的优先级策略
- 瞬间加载页面
下面这个视频是APM引擎的lead ,Malte Ubl对AMP的介绍，内容跟下面的段落差不多。
只允许异步脚本
JavaScript很强大，它能修改页面的所有东西，但是它也会阻塞DOM的构建并延迟页面的渲染（使用 JavaScript 添加交互)。为了防止JavaScript延迟页面渲染，AMP只允许异步的JavaScript。
AMP页面不能包括自己写的JavaScript，相反，页面的交互特性用自定义的AMP元素处理。自定义的AMP元素的背后可能有JavaScript代码，但是它们都是经过精心设计而不会导致性能下降。
虽然在内联框架中运行第三方JS，但是它不能阻塞渲染。比如，如果第三方JS用 性能特别差的document.write API 它也不会阻塞主页面渲染。
静态计算资源尺寸大小
外部资源，比如图片、广告、内联框架<iframe>必须在HTML里声明他们的尺寸，所以在资源下载之前，AMP就能决定元素的大小和位置。AMP可以不用等待资源下载完成就直接加载页面布局。
AMP从资源布局中解耦文档布局。整个文档布局只需要一次HTML请求。因为AMP避免了代价昂贵的重计算样式和布局。所以当资源加载的时候，不会有任何的重布局。
不让 外部插件阻塞渲染
AMP不会让外部插件阻塞页面渲染。AMP支持外部插件包括 lightboxes, instagram embeds, tweets, 等等。然而，这些需要增加额外的HTTP请求，这些请求会阻塞页面布局和渲染。
所有用到自定义脚本的页面必须告诉AMP系统一个自定义的标签。比如， amp-iframe 脚本告诉系统这儿有个 amp-iframe 标签. AMP 在知道里面包含什么前就能生成一个内联页框(iframe box)。
<script async custom-element="amp-iframe" src="https://cdn.ampproject.org/v0/amp-youtube-0.1.js"></script>让所有第三方JavaScript离开关键路径
第三方JS喜欢用同步JS加载，还喜欢用document.write。比如，如果你有5个广告，每个广告有3个同步加载。每次链接有1秒延时，光是JS加载就需要18秒。
AMP页面只在内联框架iframe沙盒中有第三方JavaScript。把第三方JS代码限制在iframe中，它们就不会阻塞主页面的运行。即使它们触发多次样式重计算，但iframes中几乎没有DOM，而样式重计算和布局通常是针对DMO尺寸。所以相比对页面的样式重计算和布局，对iframes的重计算是非常快速的。
使用有限的 inline CSS 样式
CSS阻塞所有的渲染、页面加载，同时它很臃肿。在AMP HTML页面中，只用内联风格的CSS允许使用。比起大多web页面，这个限制会从渲染关键路径去除1个或多个HTTP请求。
同时，内置样式块（sheet）最大可以有50KB大小。但是对大多复杂的页面来说，这些大小已经足够大了，当然这仍然需要页面作者维护良好的CSS风格。
字体触发必须高效
网页字体很大，所以字体优化 对性能来说非常高效。一个有少量同步脚本或外部样式块的传统页面，浏览器也需要等待这些大字体下载。
AMP页面在字体开始下载之前都不会发出HTTP请求。这是因为AMP的JS是异步的，而且允许在线的内置样式块；在下载字体时，没有HTTP请求阻塞浏览器。
最小化样式重计算
当你测量某些元素时，它会触发昂贵的样式重计算，因为浏览器需要布局整个页面。在AMP页面，所有DOM在写之前会先全部读完。这确保了每帧最多只有一次样式重计算。
你可以阅读这篇 渲染性能学习更多关于样式和布局重计算的影响。
只运行GPU加速动画
动画加速的唯一方式是将它们运行在GPU上。GPU知道图层，它知道如何在图层上展示元素，它会移动图层、淡入淡出图层，但是它不会更新页面布局；不过它会把任务抛给浏览器，这并不是很好。
关于动画相关的CSS的规则能保证动画是GPU加速。特别是AMP只允许动画、仿射变换和不透明度，所以不需要布局。可以从使用转换和不透明度的动画修改了解更多知识。
加载资源的优先级策略
AMP控制所有资源下载。它给资源下载分优先级，只在需要时加载，并预取懒加载资源。
当AMP加载资源，它会优化下载策略，当前最重要的资源会最先被下载。图片和广告只会在它们需要可视的时候、在上半版面或者用户快速滚动的时候被下载。
AMP会预取懒加载的资源。资源尽量晚加载，预取尽量早。这种方式，加载会很快，但是只有在资源展示给用户的时候CPU才会被使用。
瞬间加载页面
想确保HTTP请求尽量快速，使用新的 preconnect API 还是比较繁琐。用AMP，在用户显示指明他们想前往的页面前，该页面就被渲染了。在用户选择前往该页面前，它就可能已经准备好了，所以页面就像瞬间被加载一样。
虽然页面内容可以被预渲染，但是预渲染也会消耗大量的CPU资源。AMP会在两者中优化取平衡。预渲染只下载上半版面的资源，而且不会渲染非常消耗CPU资源的元素。
当AMP为瞬间加载页面的效果做预渲染时，只有上半版面的资源会被下载。当AMP文档做预渲染时，一些可能很耗CPU的资源（比如第三方iframes）不会被下载
更多详情： why AMP HTML doesn’t take full advantage of the preload scanner.
帮忙让AMP更快
AMP是个开源项目，我们需要你的帮助来让它更快。 how to contribute.