Google AMP

[MrZWH]

当我们谈论性能的时候我们在谈论什么？

• 速度，加载速度渲染速度

考虑性能之前需要考虑什么？

• 目标
  • 提升用户体验
  • 提升执行效率
  • 减轻服务器压力
• 限制
  • 安全性
  • 一致性
  • 可维护性
  • 成本
• 业务特性：读写频率、数据模型特点、用户特点 etc
  需要在目标和限制之间做平衡

前端性能优化场景

或者说 Web场景下的浏览器和HTTP 层性能优化

一般性特点

• JS 执行效率
  • 有很多优化策略在现在的一些高级浏览器下已经不适用了，写的优化执行器已经替你做了，比如 V8 即时编译的功能
• 渲染引擎效率
• HTTP 请求

PC 端：

• 浏览器性能差异
• 网速相对较快
• 处理器性能较好

移动端：

• 处理器性能有限
• 网络速度慢
• 浏览成本

for 循环和 forEach：微软的 Chakra 引擎对 forEach 有优化性能比原生的 for 还好。

Google AMP

Accelerated Mobile Pages

AMP 针对的场景

• Mobile
• 咨询页面（非 SPA）
• facebook 的 instant articles 商业性布局

场景的特点

• 机器性能低
• 浏览器性能低
• 网速受限
• 非刚性需求

权衡

• 减少请求数
• 减小体积
• 牺牲一部分 UE
• 牺牲一部分开发效率

AMP 是什么样子的

• 图片占用网络请求，所以不用默认 img 标签从而控制加载时机
• 图片大小未知，会触发 reflow，所以强制要求图片必须在渲染前指定大小
• amp-video
• amp-iframe
• amp-audio

AMP CSS

• 所有的 css 必须 inline
• 必须在 head
• 只能有一个
• 禁止 inline style
• 禁止 !important
• 禁止 * selector
• 禁止 filter，filter 非常依赖与显卡这个硬件优化

为什么这么做？

• 不发额外请求
• body 渲染前所有样式都已经定义玩
• 避免多次 rerender
• 保证 AMP 对页面的控制
• 控制会造成渲染引擎性能问题的属性

AMP 的限制

• 只允许 async 脚本
• 显示指定 UI 尺寸
• CSS 只能有一个 inline 的
• CSS 只能 50k
• 允许有限的 CSS 动画
• 控制资源加载，动画执行

AMP 的原则

• 严格控制外部资源
• 严格控制整个页面渲染
• 严格控制 CSS 动画

自由即奴役，https://zhuanlan.zhihu.com/p/21741712

性能优化的一般性思考过程

当你的「性能」性能越高时↑，你的「成本」会越高↑，同时对性能的优化会造成「可维护性」降低↓

Icon

普通图片 、Sprite、icon-font、inline base64、inline svg

人月神话，No Silver Bullet 没有银弹，All About Trade-off 都是权衡，对于中高级工程师来说，你要对你不同的实现方案之间要有思索，你要知道什么时候你该用什么，或者你用的这个方案有什么缺陷有什么坑，学会只是第一步，学会在什么时候用才是更重要的一步。