本文探讨了性能优化的重要性，特别是在移动端。介绍了Google AMP（Accelerated Mobile Pages）项目，旨在提升网页在移动设备上的加载速度和用户体验。通过限制请求、减小体积以及控制CSS和资源加载等方式，AMP确保了在牺牲部分用户界面的同时，实现了更快的加载速度和更好的性能表现。
- 我对性能的一些体会
- google amp和它的理念
Google AMP
当我门谈到性能的时候，谈论的是什么？
卡顿、资源的消耗、流畅、快
性能的理解 —— 速度
加载速度越快，渲染速度越快，IO 文件， http速度
自行车—汽车 —火车–飞机
抛开场景谈性能都是耍流氓！
谈论性能之前都会考虑一些其他的因素？
目标： 想要干什么？
-
提升用户体验
-
提升执行效率
-
减轻服务器压力
花钱 花时间
限制
安全性（常见的优化方式，把图片 从css ， j s静态资源放到cdn上，把我们的文件丢给一个服务商，让他替我们去在全球做分布式的缓存。最大的问题是什么？安全问题 。他们的域名 、服务器 ，他们的挂了我们就挂了，用户信息会被泄露）
一致性
分布式缓存，前后端的缓存， 不同层次的缓存我们怎么保证缓存的数据是一致的。用户刚登录完再刷新丢失了登录状态
可维护性
c语言性能最好， 其他的语言有很好的可维护性
成本
人力 ，时间， 资源。 产出有没有很好的效果 。页面渲染速度慢一秒损失多少。
优化核心的部分，考虑业务特性。
业务特性：读写频率、数据模型特点、用户特点
前端性能优化的场景
web场景下的浏览器和http层性能优化
一般性特点：
- j s执行效率
（j s是脚本语言，没有编译过程,靠浏览器里的js解析器解析和执行）
js性能是有瓶颈的，但是90%以上的场景我们是没有碰到过这种性能优化的场景，
因为浏览器js引擎效率已经很高了
为什么nodej s能在服务上支撑很多业务应用呢？ 有一个点就是v8引擎对j s的执行效率做过非常多的优化
js优化的 一本书 ，讲到了js优化的一些方式，很多优化策略已经不适用了，高级浏览器场景下已经不适用了， 浏览器执行器已经做了。
Google v8有及时编译的一个功能。
Google v8 及时编译这套系统，解决读写的热点。
我们的代码在执行过几次它能感知这个代码是一个性能的热点，它会把这个代码编译成机器码。
比如j s是一个动态类型的语言，不像c语言，c++ ，java ，我声明一个对象这块数据就是这么大变不了，它在内存里占的地方就是这么大。但是j s是动态对象，声明一个对象，这个对象大小是可变的，这个对j s执行引擎的性能优化来讲就非常难。我 给它分配多少内存，分配这块内存上下能放多少东西，原始的强类型语言中它的类型是可知的，所以它存在内存中的大小就是可知的，它在内存里的数据存放可以非常紧凑。
js动态类型语言是我们避免使用的一些特性
比如我们声明一个对象，往这个对象里set 内容，有可能成为性能的热点的，考虑到这个点。
闭包会出现什么问题？变量查找的上下文是怎么样的一个过程，dis指针的查找过程，推荐看j s标准。
传统语言没有闭包场景，一个函数进来我们在栈上声明一些变量，函数执行完毕，栈上的变量全部会被移除
但是js不行。js执行里边可能又会声明一个函数，这个函数生命周期会被延长。
setTimeout,callback里边的函数会被延长，它存在的闭包往上查找能找到根节点，
意味着上面所有的变量都不能释放。现在编译器也会做些优化，只会保留你用到的变量。
但是我们知道在闭包和很多j s的性能会有性能问题。我们对性能敏感的点要注意下。
js是单线程应用的模型，包括我们的浏览器。
遇到页面卡死的情况，比如执行一个非常多的循环 ，页面直接白了什么都干不了为什么？
我们在页面中有两个引擎，一个j s引擎，一个render引擎，这两个引擎间要通讯，我们看到的都是render引擎，j s引擎在背后执行j s脚本。j s对象和dom对象是两个对象，他们之间的沟通是要有成本的。
保证数据一致性 ,牺牲了一些性能。
input 1，2，3 点击按钮callback拿到input值，怎么保证这个值是不变的，因为是单线程的，在这个代码执行完前这个input是不能被用户处理的。callback 任何时间点都是和dom一致的。这就是单线程模型的特点，保证数据的一致性。
浏览器，js在设计时一个重要的权衡，它牺牲了一部分性能 ，用单线程保证一致性。
页面输入很多，如果在脚本执行中无法确定和页面do m值是一致的，代码就会非常复杂。
js不要执行过长，每次执行之后释放出来当前的栈，让UI去响应
- 渲染引擎效率
repaint reflow
越大越多变化越频繁会有级联性的效果，响应式布局性能问题 有大量的计算
UI页面上的盒子怎么摆，大小变了会影响周围盒子变化，c s s效果 放在手机端会出问题，不仅仅是兼容性还有性能问题。支持这个特效但是卡顿。
- http 请求
每个页面发出很多http请求，
返回 html–外部图片 c s s. Js ,这些请求有多少，在常规的p c 端体会不到的，
手机端场景不一样，达不到p c 场景，手机端http请求有限制的，原本pc端执行方式在手机端会造成很大性能问题，框架越来越重
pc端浏览器的性能差异
p c :
- 浏览器性能差异
- 网速相对快
- 处理器性能较好
手机端
- 处理器性能有限
- 网络速度慢
- 流量成本
Google AMP Accelerated Mobile Pages
针对手机页面的一套优化方案，
AMP针对的场景 Mobile. 资讯页 非spa。facebook的instantarticles
场景特点
-
机器性能
-
浏览器性能
-
网速受限
-
非刚性需求
用户粘度低， 挂号 报名等系统没法比。。。
权衡
-
减少请求
-
减小体积
-
牺牲一部分UE
AMP是什么样子的
标记doctype … 隐藏一切。
<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/zh_cn/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>
AMP image
普通图片
<amp-img src="hello.jpg" alt="hello" height="300" width=500></amp-img>
屏幕适配
<amp-img src="hello.jpg" srcset="hello.jpg" 640w, "ni.jpg" 320w
sizes="(min-width:650px) 50vw,100vw">
</amp-img>
一般我们会把css写到 css文件里 ，为什么？
图片占用网络的请求，所以不用默认img从而控制加载时机
图片的大小未知，会触发reflow
所以强制要求图片必须在渲染前指定大小 不会影响外部尺寸
类似的还有
amp-video
Amp-iframe
Amp-audio
.etc
AMP CSS
所有的css
必须是 inline 外部css加载进来会影响当前页面的UI
必须在 head
只能有一个 多个css就会多次渲染
禁止inline style
禁止!import
禁止*selector
禁止filter 依赖显卡
why?
不发额外请求
body渲染前所有样式都已经定义完
避免多次rerender
保证AMP对页面的控制
控制会造成渲染引擎性能问题的属性
http re’flow repait
其他组件： 动态列表、轮播、遮罩、第三方播放器、社交媒体插件
AMP的限制
- 只允许async脚本. 脚本是阻塞的 异步的
- 显示指定Ui尺寸
- css只能有一个inline的
- css只能50k
- 允许有限的css动画 transform 等渲染瓶颈
- 控制资源加载，动画执行
AMP基本原则
- 严格控制值外部资源
- 严格控制整个页面渲染
- 严格控制css动画
性能优化的一般性思考过程
成本 、性能 、可维护性
ICON 图片 拼成雪碧图
Iconfont
NodeJS chat service in action
ways to achieve it
-
Polling (ajax)
-
long polling(comet)
-
flash
-
Web socket
雅虎军规
-
减少http请求次数
页面中引入很多j s 同步加载 很慢 合并
-
减少d n s查找次数
-
避免跳转
301 永久。302 暂时
-
可缓存的a ja x
扫一扫
5148
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
