性能优化 Google 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


雅虎军规

  1. 减少http请求次数

    页面中引入很多j s 同步加载 很慢 合并

  2. 减少d n s查找次数

  3. 避免跳转

    301 永久。302 暂时

  4. 可缓存的a ja x

参与评论 您还未登录,请先 登录 后发表或查看评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
©️2022 CSDN 皮肤主题:深蓝海洋 设计师:CSDN官方博客 返回首页

打赏作者

JJWanna

你的鼓励将是我创作的最大动力

¥2 ¥4 ¥6 ¥10 ¥20
输入1-500的整数
余额支付 (余额:-- )
扫码支付
扫码支付:¥2
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值