速记笔记
markdown工具: https://pandao.github.io/editor.md/
实验服务器:青云服务器

涉及的功能

1. 资源和并与压缩
2. 图片编解码原理和类型选择
3. 浏览器渲染机制
4. 懒加载和预加载
5. 浏览器存储
6. 缓存机制
7. PWA
8. Vue-SSR

前端性能优化原理

前端性能优化原理

资源和并与压缩

优化点:

1. 减少http请求数量

2. 减少请求资源大小两个

   
   CS架构GUI软件的开发与部署过程
   web前端的开发与部署过程.jpg

case:google首页案例学习

1. html压缩
2. css压缩
3. js压缩和混乱
4. 文件合并
5. 开启gzip压缩

html压缩

html压缩就是压缩在文本文件中有意义,但是在html中不显示的字符,包括空格,制表格,换行符等,还有一些其他意义的字符, 比如:注释也可以被压缩.

如何进行html压缩

1. 使用在线网站压缩
2. nodejs提供了html-minifier工具
3. 后端模板引擎渲染压缩

css压缩

1. 无效代码压缩
2. css语义合并

如何进行html压缩

1. 使用在线网站压缩
2. nodejs提供了html-minifier工具对html中的css进行压缩
3. 使用clean-css对css进行压缩

js的压缩与混乱

3. 无效字符的删除
4. 剔除注释
5. 代码语义的缩减和优化
6. 代码保护

如何对js进行压缩和混乱

1. 使用在线网站压缩
2. nodejs提供了html-minifier工具对html中的js进行压缩
3. 使用uglifyjs2 对js进行压缩

文件合并存在问题

1. 首屏渲染问题
2. 缓存失效问题[比如只修改了一部分, 整个代码的缓存就不能使用了]

文件合并存在问题 => 解决方法

1. 公共库合并
2. 不同页面的合并
3. 见机行事, 随机应变

图片编解码原理和类型选择

• jpeg图片是有损压缩
• png8 - 256色 + 支持透明
• png24 - 2^24色 + 不支持透明
• png32 - 2^32色 + 支持透明

不同格式图片常用的业务场景1

• jpeg有损压缩,压缩率高, 不支持透明
• png支持透明, 浏览器兼容性好
• webp压缩程度更好, 在ios webview有兼容性问题
• svg矢量图,代码内嵌, 相对较小, 图片样式相对简单的业务场景

不同格式图片常用的业务场景2

• jpeg - 大部分不需要透明的业务场景
• png - 大部分需要透明的业务场景
• webp - 安卓全部
• svg - 图片样式相对简单的业务场景

css雪碧图

优点: 减少网站的http请求数量
缺点: 整张图片比较大时,加载速度比较慢

css雪碧图 => 替代方法

1. 将图片的内容内嵌到html当中image inline[base64编码]

雪碧图制作工具

spritecow
点选一部分可以选中其中的CSS进行复制

页面加载渲染过程

实验[页面的渲染过程]

1. 设置网络延时加载[上行和下行带宽 && 网络延迟]

   
   第一步
   第二步

2. 网络加载过程

   
   

矢量图

1. 使用svg进行矢量图的绘制
2. 使用iconfont解决icon问题

安卓下使用webp

1. 更优的图像数据压缩算法
2. 能带来更小的图片体积
3. 而且拥有肉眼识别无差异的图像质量
4. 有损和无损的压缩模式
5. alpha透明
6. 动画的特性
7. 在jpeg和png的转化上都非常优秀,稳定和统一

case 手淘国际站

手淘国际站
实现了jpg和webp两种格式的图片兼容

webp格式图片转换工具

智图

问题引出:浏览器的一个请求从发送到返回都经历了什么 => 请求过程中一些潜在的性能优化点

1. dns是否可以通过缓存减少dns查询时间?
2. 网络请求环境走最近的网络环境?
3. 相同的静态资源是否可以缓存?
4. 能否减少http请求大小?
5. 较少http请求?
6. 服务器端渲染?
   注:深入理解请求过程是前端性能优化的核心

html渲染过程的特点

• 顺序执行, 并发加载
• 是否阻塞
• 依赖关系
• 引入方式

顺序执行, 并发加载

加法分析
并发加载
并发上限

css阻塞

• css head中阻塞页面的渲染
• css阻塞js的执行
• css不阻塞外部js的加载

js阻塞

• 直接引入的js会阻塞页面的渲染
• js不阻塞资源的加载
• js顺序执行,阻塞后续逻辑的执行

依赖关系

页面渲染依赖于css的加载
js执行顺序的依赖关系
js逻辑对于dom节点的依赖关系

js的引入方式

• 直接引入
• defer
• async
• 异步动态引入

加载和执行的一些优化点

• css样式表置顶
• 用link代替import
• js脚本置底
• 合理使用js的异步加载能力

懒加载

• 图片进入可视区域之后加载资源
• 对于电商图片很多,页面很长的业务场景
• 减少无效资源的加载
• 并发加载的资源很多会阻塞js的加载,影响网站的正常使用

预加载

• 图片等静态资源使用之前加载
• 资源使用到时能够从缓存中加载,提升用户体验
• 页面展示的依赖关系的维护

预加载模块

PreloadJs模块
要加载的资源放到一个队列当中, 加载完成后有一个回调函数调用预加载的资源

reflow和repaint

css性能让javascript变慢?

频繁触发reflwo和repaint会导致UI频繁渲染, 最终导致JS变慢

reflow

页面布局和几何属性改变时就会触发回流

repaint

只影响元素的外观,风格. 不影响布局就会只触发repaint
注:回流必将引起重绘, 重绘不一定要引起回流

触发页面重布局的属性

盒子模型相关属性会触发重布局
定位属性和重布局也会触发重布局
改变节点内部文字

触发reflow的属性

reflow	reflow	reflow
width	top	text-align
height	right	overflow-y
padding	bottom	font-weight
margin	left	overflow
display	float	font-family
border-width	clear	line-height
border	position	vertical-align
min-height	font-size	white-space

触发repaint的属性

repaint	repaint
border-style	background
border-radius	background-image
visibility	background-position
text-decoration	background-repeat
outline-color	background-size
outline	box-shadow
outline-style	color
outline-width

新建DOM过程

1. 获取DOM后分割为多个图层
2. 对每个图层的节点计算样式结果 - recalculate style - 样式重计算
3. 为每个节点生成图形和位置 - layout -- 回流和重布局
4. 将每个节点绘制填充到图层位置中 - paint setup和paint -- 重绘
5. 图层作为纹理上传GPU
6. 复合多个图层到页面生成最终图像 - composite layers - 图层重组
   注:将 频繁重绘回流 的DOM元素单独作为一个 独立图层, 那么这个 DOM 元素的重绘和回流的影响只会在这个图层中

查看页面的reflow和repaint

第1步:记录一个时间片段
第2步:查看时间片段
第3步:新建dom的过程

查看页面repaint

如何将DOM元素变成新的独立图层[crome浏览器]

1. 3D或透视变换CSS属性(perspective transform)
2. 使用加速视频解码的<video>节点
3. 拥有3D(WebGL)上下文或加速的2D上下文的<canvas>节点
4. 混合插件(如Flash)
5. 对自己的opacity做CSS动画或使用一个动画webkit变换的元素
6. 拥有加速CSS过滤器的元素
7. 元素有一个包含复合层的后代节点(一个元素拥有一个子元素, 该子元素在自己的层里)
8. 元素有一个z-index较低且包含一个复合层的兄弟元素(换句话说就是该元素在复合层上面渲染)
   例如:

transform: translateZ(0);
will-change:transform;

layer不能被滥用

太多了会影响性能, 开启了GPU加速, 会认为存在大量的重绘,大部分时间都花在图层合成上

实战优化点

1. 用translate替代top改变
2. 用opacity替代visibility
3. 不要一条一条地修改DOM的样式, 预先定义好class, 然后修改DOM的className
4. 把DOM离线后修改, 比如: 先把DOM给display:none(有一次reflow), 然后你修改100次, 然后再把它显示出来
5. 不要把DOM节点的属性值放在一个循环里当成循环里的变量
6. 不要使用table布局, 可能很小的一个小改动会造成珍格格table的重新布局
7. 对于动画新建图层
8. 启用GPU硬件加速

reflow和repaint的使用原则

1. 避免使用触发重绘, 回流的CSS属性
2. 将重绘, 回流的影响范围限制在单独的图层之内

多种浏览器存储方式并存, 如何选择?

cookie
注: 因为http请求无状态,所以需要cookie去维持客户端状态

cookie的生成方式:

http response header中的set-cookie

作用

1. 用于浏览器端和服务器端的交互
2. 客户端自身数据的存储

cookie存储的限制

1. 作为浏览器存储, 大小4KB左右
2. 需要设置过期时间expire

问题:cookie中在相关域名下面 - cdn的流量损耗

办法: cdn的域名和主站的域名要分开

cookie安全

httponly只能服务器设置, 前端JS不能修改

LocalStorage

1. html5设计出来专门用于浏览器存储的
2. 大小为5M左右
3. 仅在客户端使用, 不和服务器端进行通信
4. 接口封装较好
5. 浏览器本地缓存方案

SessionStorage

1. 会话级别的浏览器存储
2. 大小为5M左右
3. 仅在客户端使用, 不和服务器端进行通信
4. 接口封装较好
5. 对于表单信息的维护
6. 浏览器的一个tab就是一个会话
7. 刷新页面还有原来的信息
8. 表单在进行多页面切换的时候进行传递也可以使用

IndexedDB

• IndexedDB是一种低级API, 用于客户端存储大量结构化数据. 该API使用索引来实现对该数据的高性能搜索. 虽然Web Storage对于存储较少量的数据很有用, 但对于存储更大量的结构化数据来说, 这种方法不太有用. IndexedDB提供了一个解决方案.
• 为应用创建离线版本
• 现在使用的比较少

PWA

PWA(Progressive Web Apps)是一种Web App新模型, 并不是具体指某一种前沿的技术或者某一个单一的知识点, 这是一个渐进式的Web App, 是通过一系列新的Web特性, 配合优秀的UI交互设计, 逐步的增强Web App的用户体验.

特点

1. 能够在弱网环境下app加载出来
2. 能够在离线状态下app能加载出来
3. 在不同环境下都能有比较好的体验, 并且能够渐进提升.
4. 可靠:在没有网络的环境中也能提供基本的页面访问, 而不会出现"未连接到互联网"的页面.
5. 快速:针对网页渲染及网络数据访问有较好优化.
6. 融入:应用可以被增加到手机桌面, 并且和普通应用一样有全屏, 推送等特性

检测工具[lighthouse]

chrome://extensions/
启动测试工具
测试结果

Service Worker

Service Worker是一个脚本, 浏览器独立于当前网页, 将其在后台运行, 为实现一些不依赖页面或者用户交互的特性打开了一扇大门.

特性

1. 推送信息
2. 背景后台同步
3. geofencing(地理围栏定位)
4. 拦截和处理网络请求的能力, 包括以编程方式来管理被缓存的响应

用处

1. 使用拦截和处理网络请求的能力, 去实现一个离线应用
2. 使用Service Worker在后台运行同时能和页面通信的能力, 去实现大规模后台数据的处理

现状

IOS对PWA支持的不太好

生命周期

Service Worker生命周期

已经被注册的Service Worker情况

chrome://serviceworker-internals/  

被注册的Service Worker

检查当前浏览器上正在运行的Service Workers有哪些

chrome://inspect/#service-workers

正在运行的Service Workers

先把之前的service worker终止一下

先把之前的service worker终止一下
service代码查看
service worker的缓存
缓存内容查看

网络查看

网络查看
demo查看

离线查看

离线查看

缓存

Cache-Control

• max-age

  
  max-age
• s-maxage
  注：s-maxage缓存优先级大于max-age缓存，但是只对public生效。就是从我们的cdn拿缓存
• private
  注：私人浏览器，只有访问这个浏览器的用户才能使用缓存
• public
  注：比如cdn就是public缓存，可以被很多人缓存
• no-cache
• no-store
  例子：

Cache-Control:private, max-age=0, no-cache
1. 都要发送请求询问
2. 如果没有改变返回304
3. 改变了返回200，从新拉取请求

General
    Status Code : 304
Response Headers
    last-modified ：Sun Aug 26 2018 12:14:04 GMT
Request Headers
    if-modified-since :Sun Aug 26 2018 12:14:04 GMT

last-modified有什么缺点

1. 某些服务端不能获取精确的修改时间
2. 文件修改时间改了，但文件内容却没有变

General
    Status Code : 304
Response Headers
    ETag ："ds123456-dsx"
Request Headers
    if-None-Match : "ds123456-dsx"

Etag/If-None-Match

• 文件内容的hash值
• etag - response header
• if-none-match - request header
• 需要与cache-control共同使用

分级缓存策略

1. 200（from cache）

这一层由expires/cache-control控制。

1. expire (http 1.0版本有效)是绝对时间
2. cache-control（http1.1版本有效）相对时间
   两者都存在时，cache-control覆盖expires，只要没有失效，浏览器值访问自己的缓存

2. 304状态

这一层由last-modified/etag控制。当下一层失效时或用户点击refresh，F5时，浏览器就会发送请求给服务器，如果服务器没有变化，则返回304给浏览器

3. 200

当浏览器本地没有缓存或者下一层失效时，或者用户点击了CTL+F5时，浏览器直接去服务器下载最新数据

分级缓存策略
缓存流程图
缓存流程图2

使用缓存的方式

1. 通过新tab输入地址的方式
2. 通过html外联图片的方式
   注：在原tab中刷新会默认添加一个max-age=0的头

其他优化

1. cdn不要使用同域名, 因为会携带cookie增加无谓的带宽消耗
2. react, vue模板代码的渲染会对性能有损耗, 业界的一般做法是做成服务器端渲染的过程