web前端服务器性能,web前端性能优化

涉及的功能

资源和并与压缩

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

浏览器渲染机制

懒加载和预加载

浏览器存储

缓存机制

PWA

Vue-SSR

前端性能优化原理

前端性能优化原理

资源和并与压缩

优化点:

减少http请求数量

减少请求资源大小两个

CS架构GUI软件的开发与部署过程

web前端的开发与部署过程.jpg

case:google首页案例学习

html压缩

css压缩

js压缩和混乱

文件合并

开启gzip压缩

html压缩

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

如何进行html压缩

使用在线网站压缩

nodejs提供了html-minifier工具

后端模板引擎渲染压缩

css压缩

无效代码压缩

css语义合并

如何进行html压缩

使用在线网站压缩

nodejs提供了html-minifier工具对html中的css进行压缩

使用clean-css对css进行压缩

js的压缩与混乱

无效字符的删除

剔除注释

代码语义的缩减和优化

代码保护

如何对js进行压缩和混乱

使用在线网站压缩

nodejs提供了html-minifier工具对html中的js进行压缩

使用uglifyjs2 对js进行压缩

文件合并存在问题

首屏渲染问题

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

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

公共库合并

不同页面的合并

见机行事, 随机应变

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

jpeg图片是有损压缩

png8 - 256色 + 支持透明

png24 - 2^24色 + 不支持透明

png32 - 2^32色 + 支持透明

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

jpeg有损压缩,压缩率高, 不支持透明

png支持透明, 浏览器兼容性好

webp压缩程度更好, 在ios webview有兼容性问题

svg矢量图,代码内嵌, 相对较小, 图片样式相对简单的业务场景

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

jpeg - 大部分不需要透明的业务场景

png - 大部分需要透明的业务场景

webp - 安卓全部

svg - 图片样式相对简单的业务场景

css雪碧图

优点: 减少网站的http请求数量

缺点: 整张图片比较大时,加载速度比较慢

css雪碧图 => 替代方法

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

雪碧图制作工具

spritecow

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

页面加载渲染过程

实验[页面的渲染过程]

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

第一步

第二步

网络加载过程

矢量图

使用svg进行矢量图的绘制

使用iconfont解决icon问题

安卓下使用webp

更优的图像数据压缩算法

能带来更小的图片体积

而且拥有肉眼识别无差异的图像质量

有损和无损的压缩模式

alpha透明

动画的特性

在jpeg和png的转化上都非常优秀,稳定和统一

case 手淘国际站

手淘国际站

实现了jpg和webp两种格式的图片兼容

webp格式图片转换工具

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

dns是否可以通过缓存减少dns查询时间?

网络请求环境走最近的网络环境?

相同的静态资源是否可以缓存?

能否减少http请求大小?

较少http请求?

服务器端渲染?

注:深入理解请求过程是前端性能优化的核心

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过程

获取DOM后分割为多个图层

对每个图层的节点计算样式结果 - recalculate style - 样式重计算

为每个节点生成图形和位置 - layout -- 回流和重布局

将每个节点绘制填充到图层位置中 - paint setup和paint -- 重绘

图层作为纹理上传GPU

复合多个图层到页面生成最终图像 - composite layers - 图层重组

注:将 频繁重绘回流 的DOM元素单独作为一个 独立图层, 那么这个 DOM 元素的重绘和回流的影响只会在这个图层中

查看页面的reflow和repaint

第1步:记录一个时间片段

第2步:查看时间片段

第3步:新建dom的过程

查看页面repaint

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

3D或透视变换CSS属性(perspective transform)

使用加速视频解码的节点

拥有3D(WebGL)上下文或加速的2D上下文的节点

混合插件(如Flash)

对自己的opacity做CSS动画或使用一个动画webkit变换的元素

拥有加速CSS过滤器的元素

元素有一个包含复合层的后代节点(一个元素拥有一个子元素, 该子元素在自己的层里)

元素有一个z-index较低且包含一个复合层的兄弟元素(换句话说就是该元素在复合层上面渲染)

例如:

transform: translateZ(0);

will-change:transform;

layer不能被滥用

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

实战优化点

用translate替代top改变

用opacity替代visibility

不要一条一条地修改DOM的样式, 预先定义好class, 然后修改DOM的className

把DOM离线后修改, 比如: 先把DOM给display:none(有一次reflow), 然后你修改100次, 然后再把它显示出来

不要把DOM节点的属性值放在一个循环里当成循环里的变量

不要使用table布局, 可能很小的一个小改动会造成珍格格table的重新布局

对于动画新建图层

启用GPU硬件加速

reflow和repaint的使用原则

避免使用触发重绘, 回流的CSS属性

将重绘, 回流的影响范围限制在单独的图层之内

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

cookie

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

cookie的生成方式:

http response header中的set-cookie

作用

用于浏览器端和服务器端的交互

客户端自身数据的存储

cookie存储的限制

作为浏览器存储, 大小4KB左右

需要设置过期时间expire

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

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

cookie安全

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

LocalStorage

html5设计出来专门用于浏览器存储的

大小为5M左右

仅在客户端使用, 不和服务器端进行通信

接口封装较好

浏览器本地缓存方案

SessionStorage

会话级别的浏览器存储

大小为5M左右

仅在客户端使用, 不和服务器端进行通信

接口封装较好

对于表单信息的维护

浏览器的一个tab就是一个会话

刷新页面还有原来的信息

表单在进行多页面切换的时候进行传递也可以使用

IndexedDB

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

为应用创建离线版本

现在使用的比较少

PWA

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

特点

能够在弱网环境下app加载出来

能够在离线状态下app能加载出来

在不同环境下都能有比较好的体验, 并且能够渐进提升.

可靠:在没有网络的环境中也能提供基本的页面访问, 而不会出现"未连接到互联网"的页面.

快速:针对网页渲染及网络数据访问有较好优化.

融入:应用可以被增加到手机桌面, 并且和普通应用一样有全屏, 推送等特性

检测工具[lighthouse]

chrome://extensions/

启动测试工具

测试结果

Service Worker

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

特性

推送信息

背景后台同步

geofencing(地理围栏定位)

拦截和处理网络请求的能力, 包括以编程方式来管理被缓存的响应

用处

使用拦截和处理网络请求的能力, 去实现一个离线应用

使用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有什么缺点

某些服务端不能获取精确的修改时间

文件修改时间改了，但文件内容却没有变

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控制。

expire (http 1.0版本有效)是绝对时间

cache-control(http1.1版本有效)相对时间

两者都存在时，cache-control覆盖expires，只要没有失效，浏览器值访问自己的缓存

2. 304状态

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

3. 200

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

分级缓存策略

缓存流程图

缓存流程图2

使用缓存的方式

通过新tab输入地址的方式

通过html外联图片的方式

注：在原tab中刷新会默认添加一个max-age=0的头

其他优化

cdn不要使用同域名, 因为会携带cookie增加无谓的带宽消耗

react, vue模板代码的渲染会对性能有损耗, 业界的一般做法是做成服务器端渲染的过程