当我们去面试的时候,很大概率会被面试官问这么一个问题:你有尝试过对项目做性能优化吗?或者你了解哪些性能优化的方法?听到这个问题的你可能是这样的:
似曾相识但又说不清楚,往往只能零散地说出那么几点,难以做到有条理的回答。那么,本文就带你简单了解前端性能优化的几个主要方面,旨在抛砖引玉。
请求过程中一些潜在的性能优化点:
dns
是否可以通过缓存减少dns
查询时间?http
请求的大小和次数?总结: 深入理解http
请求的过程是前端性能优化的核心。
优化核心
http
请求数量;google
首页案例学习
html
压缩;css
压缩;js
的压缩和混乱;gzip
;html
压缩HTML
代码压缩就是压缩一些在文本文件中有意义,但是在HTML
中不显示的字符,包括空格,制表符,换行符等,还有一些其他意义的字符,如HTML
注释也可以被压缩;
一个简单的计算:
google
的流量,占到整个互联网的40%
,预计2016
年全球网络流量将达到1.3ZB(1ZB = 10^9TB)
,那么google
在2016
年的流量就是1.3ZB * 40%
,如果google
每1MB
请求减少一个字节,每年可以节省流量近500TB
流量。
如何进行html
压缩
nodejs
提供的html-minifier
工具;css
代码压缩分为两部分:
css
语义合并;如何进行css
压缩
html-minifier
对html
中的css
进行压缩;clean-css
对css
进行压缩;js
压缩与混乱(丑化)包括:
JS
压缩与混乱(丑化)
html-minifier
对html
中的js
进行压缩;uglify.js2
对js
进行压缩;文件合并的好处:
参考 前端进阶面试题详细解答
不合并请求有下列缺点:
N-1
个网络延迟;keep-alive
本身也存在问题:经过代理服务器时可能会被断开;文件合并存在的问题
js
文件的时候,如果页面渲染只依赖a.js
文件,由于文件合并,需要等待合并后的a-b-c.js
文件请求回来才能继续渲染,这样就会导致页面渲染速度变慢。这种情况大多出现在现代化的前端框架,如Vue
等的使用过程中;a-b-c.js
中只要其中一个文件(比如a.js
)发生变化,那么整个合并文件都将失效,而不采用文件合并就不会出现这种情况;使用建议
js
文件单独合并:比如在单页面应用SPA
中,当路由跳转到具体的页面时才请求该页面需要的js
文件;如何进行文件合并
nodejs
实现文件合并;webpack
等前端构件化工具也可以很好地实现;有损压缩过程: 一张JPG
图片的解析分别要进行:
RGB
的颜色空间转到其他的颜色空间 ;DCT
过程:对高频的颜色采样结果进行压缩,这样压缩的收益会比较大;encoding
);最终得到JPEG-Compressed Image Data
,即真正显示出来的JPG
图片。虽然这是一种有损压缩,但是很多情况下,这些损失的数据并不影响显示;
png8/png24/png32
之间的区别
png8
:256
色 +
支持透明;png24
:2^24
色 +
不支持透明;png32
:2^32
色 +
支持透明;不同格式图片常用的业务场景
jpg
有损压缩,压缩率高,支持透明;应用:大部分不需要透明图片的业务场景;png
支持透明,浏览器兼容好;应用:大部分需要透明图片的业务场景;webp
(2010
年由谷歌推出)压缩程度更好,在ios webview
中有兼容性问题;应用:安卓全部;svg
矢量图,代码内嵌,相对较小,用于图片样式相对简单的场景;应用:比如logo
和iconfont
;针对真实图片情况,舍弃一些相对无关紧要的色彩信息,对图片进行压缩;
css
雪碧图将网站上用到的一些图片整合到一张单独的图片中,从而减少网站HTTP
请求数量。原理为:设定整张雪碧图可示区域,将想要显示的图标定位到该处(左上角);缺点:整合图片比较大时,一次加载比较慢。
如天猫的雪碧图:
很多情况下,并不是所有的小图标都放在一张雪碧图中,而是会适当进行拆分。现在使用雪碧图的场景比较少了。
自动生成雪碧图样式
Image inline
)将图片的内容内嵌到html
当中,减少网站的HTTP
请求数量,常用于处理小图标和背景图片。网页内联图片写法为:
<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAA..." alt="">
缺点:
ie8
以上浏览器;1000kb
的图片,base64
编码会使图片大小增大,导致网页整体下载速度减慢;所以要根据场景使用,不过内联图片减少HTTP
请求的优点还是很显著的。比如,在开发中小于4KB
或8KB
的图片都会通过构建工具自动inline
到HTML
中,这种情况下Image inline
带来的图片大小增长其实是比增加HTTP
请求次数更优的。
SVG
与iconfont
使用iconfont
解决icon
问题
应尽量使用该方式,比如可以采用阿里巴巴矢量图库:
可以选择格式进行下载:
可以看到它们的大小有着明显的差异:
使用SVG
进行矢量图的控制
SVG
意为可缩放矢量图形(Scalable Vector Graphics
)。SVG
使用 XML
格式定义图像。
webp
webp
的优势体现在它具有更优的图像压缩算法,能带来更小的图片体积,而且拥有肉眼识别无差异的图像质量;同时具备了无损和有损的压缩模式、Alpha
透明以及动画的特性。在JPEG
和PNG
上的转化效果都非常优秀、稳定和统一。安卓上不存在兼容性问题,推荐安卓下使用。
以下为淘宝网首页请求的图片:
可以看到,图片中大量地添加了webp
格式的选择。.jpg_.webp
表示当浏览器支持webp
时采用webp
格式,否则采用jpg
格式。
下面为B
站首页的图片,可以看到基本都采用了webp
格式:
同一张图片jpg
格式和webp
格式压缩率有着明显的差异:
可以通过在线网站将图片转换为webp
像图片这样的静态文件可以存放在CDN
服务器上,让CDN
服务器批量地将图片转换成Webp
格式;
版本一:
版本二:
一个渲染引擎主要包括:HTML
解析器,CSS
解析器,javascript
引擎,布局layout
模块,绘图模块:
HTML
解析器:解释HTML
文档的解析器,主要作用是将HTML
文本解释成DOM
树;CSS
解析器:它的作用是为DOM
中的各个元素对象计算出样式信息,为布局提供基础设施;Javascript
引擎:使用Javascript
代码可以修改网页的内容,也能修改css
的信息,javascript
引擎能够解释javascript
代码,并通过DOM
接口和CSS
树接口来修改网页内容和样式信息,从而改变渲染的结果;layout
):在DOM
创建之后,Webkit
需要将其中的元素对象同样式信息结合起来,计算他们的大小位置等布局信息,形成一个能表达这所有信息的内部表示模型;paint
):使用图形库将布局计算后的各个网页的节点绘制成图像结果;浏览器渲染页面的整个过程:浏览器会从上到下解析文档。
HTML
标记,就会调用HTML
解析器解析为对应的 token
(一个token
就是一个标签文本的序列化)并构建 DOM
树(就是一块内存,保存着tokens
,建立它们之间的关系)。在生成DOM
的最开始阶段(应该是Bytes
→ characters
后),并行发起css
、图片、js
的请求,无论他们是否在HEAD
标签中。注意:发起
js
文件的下载请求(request
)并不需要DOM
处理到那个script
节点;
style/link
标记 调用解析器 处理 CSS
标记并构建 CSS
样式树;script
标记 调用 javascript
解析器处理script
标记,绑定事件、修改DOM
树/CSS
树等;DOM
树 与 CSS
树 合并成一棵渲染树(Render Tree
)。Layout
):根据渲染树中各节点的样式和依赖关系,计算出每个节点在屏幕中的位置;Painting
):按照计算出来的结果:要显示的节点、节点的CSS
与位置信息,通过显卡,把内容画到屏幕上;经过第一次Painting
之后DOM
、CSSOM
、Render Tree
都可能会被多次更新,比如JS
修改了DOM
或者CSS
属性时,Layout
和Painting
就会被重复执行。除了DOM
、CSSOM
更新的原因外,图片下载完成后也需要调用Layout
和 Painting
来更新网页。
补充:
HTML
中可能会引入很多的css、js
这样的外部资源,这些外部资源在浏览器端是并发加载的。但是浏览器会对同一域名进行并发数量(度)的限制,即单个域名的并发度是有限的; 所以,经常将大部分的资源托管到CDN
服务器上,并且设置3~4
个CDN
域名。防止只有一个CDN
域名的情况下,达到了浏览器外部资源并发请求数目的上限,导致很多资源无法做到并发请求。所以,应设置多个CDN
域名;
css
阻塞只有通过link
引入的外部css
才会产生阻塞:
style
标签中的样式:html
解析器进行解析;DOM
解析;link
引入的外部css
样式(推荐使用的方式):CSS
解析器进行解析;css
已经加载完毕,所以整个渲染过程是带样式的,所以这种阻塞可以避免“闪屏现象”;js
语句的执行:这个不难理解,js
文件中经常会出现DOM
操作,操作过程中有可能涉及到css
样式的修改。实际上,这些修改往往是依赖于之前引入的css
设定的样式的,所以css
会阻塞js
的执行;css
加载速度:CDN
节点进行外部资源加速;css
进行压缩(利用打包工具,比如webpack
,gulp
等);http
请求数,将多个css
文件合并;js
阻塞 原因:浏览器不知道后续脚本的内容,如果先去解析了下面的DOM
,而随后的js
删除了后面所有的DOM
,那么浏览器就做了无用功,浏览器无法预估脚本里面具体做了什么操作,例如像document.write
这种操作,索性全部停住,等脚本执行完了,浏览器再继续向下解析DOM
;可以通过给script
标签添加defer
和async
属性,异步引入js
文件,以此来解决这一问题。
原因:js
中也可以给DOM
设置样式,浏览器同样等该脚本执行完毕,再继续干活,避免做无用功;
js
的执行: 原因:js
是按顺序执行的,这样可以维护依赖关系,例如:必须先引入jQuery
再引入bootstrap
;
这并不与上面矛盾,因为不可能由于加载一个js
文件就把其他资源的加载都阻塞了。针对这种常见的情况,浏览器会通过预加载的方式加载后续的资源;
css
的解析和js
的执行是互斥的(互相排斥),css
解析的时候js
停止执行,js
执行的时候css
停止解析;css
阻塞,还是js
阻塞,都不会阻塞浏览器加载外部资源(图片、视频、样式、脚本等);因为览器始终处于一种:“先把请求发出去”的工作模式,只要是涉及到网络请求的内容,无论是:图片、样式、脚本,都会先发送请求去获取资源,至于资源到本地之后什么时候用,由浏览器自己协调。显然这种做法效率很高;
WebKit
和Firefox
都进行了【预解析】这项优化。在执行js
脚本时,浏览器的其他线程会解析文档的其余部分,找出并加载需要通过网络加载的其他资源。通过这种方式,资源可以在并行连接上加载,从而提高总体速度。请注意,预解析器不会修改 DOM
树图片进入可视区域之后再请求图片资源的方式称为图片懒加载。适用于图片很多,页面很长的业务场景,比如电商;
懒加载的作用:
比如一个网站有十页图片,用户只查看了第一页的图片,这就没必要将十页图片全都加载出来;
js
的加载,影响网站正常的使用: 由于浏览器对某一个host name
是有并发度上限的,如果图片资源所在的CDN
和静态资源所在的CDN
是同一个的话,过多图片的并发加载就会阻塞后续js
文件的并发加载。
懒加载实现的原理:
监听onscroll
事件,判断可视区域位置:
图片的加载是依赖于src
路径的,首先可以为所有懒加载的静态资源添加自定义属性字段,用于存储真实的url
。比如是图片的话,可以定义data-src
属性存储真实的图片地址,src
指向loading
的图片或占位符。然后当资源进入视口的时候,才将src
属性值替换成data-src
中存放的真实url
。
<img src="" class="image-item" alt="" lazyload = "true" data-src="TB27YQvbm_I8KJjy0FoXXaFnVXa_!!400677031.jpg_180x180xzq90.jpg_.webp">
懒加载实例
可以使用元素的getBoundingRect().top
来判断当前位置是否在视口内,也可以使用元素距离文档顶部的距离offsetTop
和scrollTop
是否小于视口高度来判断:
举例
比如手机淘宝首页:
当快要滚动到需要展示的图片时才进行图片的请求,可以看到图片上有一个lazyload
的属性:
预加载与懒加载正好是相反的过程:懒加载实际上是延迟加载,将我们所需的静态资源加载时间延后;而预加载是将图片等静态资源在使用之前的提前请求,这样资源在使用到时能从缓存中直接加载,从而提升用户体验;
预加载的作用:
WebGL
页面,会依赖一些3D
模型,这些都是页面渲染所必须的资源。如果资源都没有加载完毕就进行页面的渲染,就会造成非常不好的体验。 所以时常使用预加载的方式维护页面渲染的依赖关系,比如将WebGL
页面依赖的3D
模型加载完之后才进行页面渲染。这样渲染的过程就不会有任何阻碍,具有较好的用户体验;
预加载的实例
例如九宫格抽奖业务,每个奖品都有一个选中态和非选中态,实际上这是由两张图片组合而成的。由于每个奖品的选中过程都是一瞬间,这就对图片的选中态和非选中态切换效率要求很高,如果选中态的图片没有预加载的话显然是来不及的。
所以,实际上对于九宫格中所有图片选中态的样式和对应的图片都需要进行预加载,从而让我们在抽奖的过程中,能够瞬间从缓存中读取到选中态的图片,从而不影响抽奖效果的展示。
除此之外还有网站登录或活动时需要用到的动画,这是在动画需要的每帧图片都完全预加载完之后才会进行显示的。
CSS
图层浏览器在渲染一个页面时,会将页面分为很多个图层,图层有大有小,每个图层上有一个或多个节点。在渲染 DOM
的时候,浏览器所做的工作实际上是:
1、获取`DOM`后分割为多个图层;
2、对每个图层的节点计算样式结果(`Recalculate style`--样式重计算);
3、为每个节点生成图形和位置(`Layout`--回流和重布局);
4、将每个节点绘制填充到图层位图中(`Paint Setup`和`Paint`--重绘);
5、图层作为纹理上传至`GUI`;
6、复合多个图层到页面上生成最终屏幕图像(`Composive Layers`--图层重组);
3D
或透视变换的css
属性(prespective transform
);<video>
节点;3D(WebGL)
上下文或加速的2D
上下文的<canvas>
节点;CSS3
动画的插件(如Flash
);css
过滤器的元素;transform
:如translateZ(0)
opacity
filter
will-change
:哪一个属性即将发生变化,进而进行优化。重绘是一个元素外观的改变所触发的浏览器行为,比如background-color
、outline
等属性。这些属性不影响布局,只影响元素的外观,风格,会造成DOM
元素的重新渲染,这个过程称为重绘。
需要注意的是:重绘是以图层为单位,如果图层中某个元素需要重绘,那么整个图层都需要重绘。比如一个图层包含很多节点,其中有个gif
图,gif
图的每一帧,都会重回整个图层的其他节点,然后生成最终的图层位图。
因此,可以通过特殊的方式来强制gif
图单独为一个图层(translateZ(0)
或者translate3d(0,0,0)
;CSS3
的动画也是一样(好在绝大部分情况浏览器自己会为CSS3
动画的节点创建图层);
所以:将频繁重绘回流的DOM
元素作为一个独立图层,那么这个DOM
元素的重绘和回流只会该图层;原则上是要尽量避免新建图层的,因为这会导致图层重组(Composive Layers
)时候的计算量增大。所以,只有当某些DOM
元素频繁重绘回流时,才新建一个独立图层放置它们;
只会触发重绘的属性
//部分属性
color
border-style
border-radius
visibility
text-decoration
background
background-image
background-position
background-repeat
background-size
outline-color
outline
outline-style
outline-width
box-shadow
当render tree
中的一部分(或全部)因为元素的规模尺寸,布局,隐藏等改变而需要重新构建。这就称为回流(reflow
);
触发页面重布局(回流)的属性
盒子模型相关属性 | 定位及浮动属性 | 文字结构属性 |
---|---|---|
width | top | text-align |
height | bottom | overflow-y |
padding | left | font-weight |
margin | right | overflow |
display | position | font-family |
border-width | float | line-height |
border | clear | vertical-align |
min-height | white-space | |
font-size |
频繁触发重绘和回流,会导致UI
频繁渲染。在渲染的过程中由于阻塞了js
线程的执行,最终导致js
执行变慢。
DOM
结点;DOM
的位置;CSS
样式;Resize
窗口;移动端没有这个问题,因为移动端的缩放没有影响布局视口(vw/vh
);DOM
元素的属性(width
,height
等);注:
display:none
会触发Reflow
,而visibility:hidden
只会触发Repaint
,因为没有发生位置变化;
案例一:淘宝轮播图
可以使用Chrome
浏览器调试工具的Performance
来观察淘宝首页一个轮播图引起的重绘回流过程:
Update Layer Tree
回流和重布局:
Paint
重绘:
Composite Layers
图层重组:
案例二:播放器
通过Chrome
调试工具的Layers
选项查看图层,及新增图层的原因:
视频播放的过程中,video
标签的DOM
元素会一直重绘,所以把它限制在一个图层上是非常好的,这样只会涉及到这个图层的重绘,而不会影响其他图层的元素。
图层不能滥用,否则会在图层重组的过程中严重消耗性能!
比如可以将淘宝首页的所有的DOM
元素都变为一个图层:在html
标签中的全局样式(*
)中添加transform:translateZ(0)
来触发新建图层:
还可以通过添加:
will-change: transform
属性新建图层;
再次查看此时的图层情况,可以看到此时首页的图层非常之多,十分地卡:
如果我们需要使得动画或其他节点渲染的性能提高,需要做的就是减少浏览器在运行时所需要做的下列工作:
Recalculate style
--样式重计算);Layout
--回流和重布局);Paint Setup
和Paint
--重绘);Composite Layers
--图层重组);1、使用translate
替代top
等属性来改变位置;
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Document</title>
<style>
#box{ /*方法1*/
position: relative; top: 0; /*方法2*/
/* transform: translateY(0); */
width: 200px; height: 200px; background-color: pink; } </style>
</head>
<body>
<div id="box"></div>
<script>
setTimeout(() => { document.getElementById("box").style.top = '100px'
//document.getElementById("box").style.transform = 'translateY(100px)'
}, 2000); </script>
</body>
</html>
使用top
属性改变正方形位置时,存在重绘和回流Layout
:
而使用translate
属性改变正方形位置时,并不会引起重绘和回流:
比如有的网站会有一些左右飘动的浮窗,由于这些浮窗是采用定时器来实现的,如果每经过100ms
就改变浮窗的位置。这种时候使用transform
来替代top/left
的话1s
内就减少了十次回流,十分有利于网页速度的提升。
2、使用opacity
替代visibility
:
visibility
不触发重排,但是依然重绘;opacity
既触发重绘,又触发重排(GPU
底层设计如此!);opacity
配合图层使用,既不触发重绘也不触发重排; 原因:透明度的改变时,GPU
在绘画时只是简单的降低之前已经画好的纹理的alpha
值来达到效果,并不需要整体的重绘。不过这个前提是这个被修改opacity
本身必须是一个单独的图层。
3、将多次改变DOM
元素样式属性的操作合并成一次操作:
class
,然后通过修改DOM
的className
来添加样式;4、把DOM
离线后再修改:
display
属性为none
的元素不在渲染树中,对隐藏的元素操作不会引发其他元素的重排。如果要对一个元素进行复杂的操作时,可以先隐藏它,操作完成后再显示。这样只在隐藏和显示时触发2
次回流;5、不要把获取某些DOM
节点的属性值放在一个循环里当成循环的变量
当向浏览器请求某些 style
信息的时候,浏览器就会清空(flush
)队列,比如:
ffsetTop
,offsetLeft
,offsetWidth
,offsetHeight
;scrollTop/Left/Width/Height
;clientTop/Left/Width/Height
;width
,height
;浏览器为了获取最精确的值,需要刷新内部队列。因为队列中可能存在影响到这些值的操作,即使没有,浏览器也会强行刷新渲染队列。这样就无法利用渲染队列的缓存来避免回流过于频繁了,所以在使用到DOM
元素这些相关的属性时,可以将获取到的属性值存在一个变量中,而不是每次都去重新获取。
6、不要使用table
布局:
table
的重新布局;所以尽量使用div
布局;7、启用GPU
硬件加速:
原理为:浏览器会检测一些特定的css
属性,当DOM
元素拥有这些css
属性的时候,浏览器就会对该DOM
元素启动GPU
硬件加速;比如:transform: translateZ(0)
和transform: translate3d(0, 0, 0)
这两个属性都可以启动硬件加速;硬件加速同样不能滥用,否则会导致图层过多,导致合并图层时消耗大量性能。
8、动画实现速度的选择:
9、为动画元素新建图层,提高动画元素的z-index
;
10、利用文档碎片(documentFragment
)------vue
使用了该种方式提升性能
如果我们要在一个ul
中添加10000
个li
,如果不使用文档碎片,那么我们就需要使用append
进行10000
次的追加,这会导致页面不停地回流,非常地消耗资源:
var oUl = document.createElement("ul");
for(var i=0;i<10000;i++)
{
var oLi = document.createElement("li");
oUl.appendChild(oLi);
}
document.body.appendChild(oUl);
我们可以引入createDocumentFragment()
方法,它的作用是创建一个文档碎片。先将要插入10000
个li
添加到文档碎片里,然后再一次性添加到document
中。即文档碎片相当于一个临时仓库,这样能够大量减少DOM
操作:
//先创建文档碎片
var oFragment = document.createDocumentFragment();
//再创建ul标签
var oUl = document.createElement("ul");
for(var i=0;i<10000;i++)
{
//创建li标签
var oLi = document.createElement("li");
//先附加在文档碎片中
oFragment.appendChild(oLi);
}
//将文档碎片添加到ul标签中
oUl.appendChild(oFragment);
//将ul标签添加到body标签中
document.body.appendChild(oUl);
11、如果涉及到一些可以使用合成线程来处理 CSS
特效或者动画的情况,就尽量使用 will-change
来提前告诉渲染引擎,让它为该元素准备独立的层。
12、采用虚拟DOM
;
13、使用requestAnimationFrame
制作动画:详细内容如下。
requestAnimationFrame
)window.requestAnimationFrame()
:该方法会告诉浏览器在重绘之前调用指定的函数:
回调函数会被自动传入一个参数:DOMHighResTimeStamp
,标识requestAnimationFrame()
开始触发回调函数的当前时间;
ID
,是回调列表中唯一的标识,没有其他意义;window.cancelAnimationFrame(requestID)
:该方法取消一个先前通过调用window.requestAnimationFrame()
方法添加到计划中的动画帧请求。requestID
是先前调用window.requestAnimationFrame()
方法时返回的ID
。
用途
CSS3
制作动画的情况下,使用这种方法替代定时器制作动画;示例
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Document</title>
<style>
#box{ height: 200px; width: 200px; background-color: pink; } </style>
</head>
<body>
<div id="box"></div>
<script>
let i = 0
//获取请求ID
let id = requestAnimationFrame(move) function move(){ i++ document.getElementById('box').style.transform = `translateX(${i}px)`
//递归调用requestAnimationFrame,更新请求ID,实现动画效果
id = requestAnimationFrame(move) } setTimeout(() => { //2s后停止动画
cancelAnimationFrame(id) }, 2000); </script>
</body>
</html>
代码实现
function debounce(fn,delay){
var timer = null
// 清除上一次延时器
return function(){
clearTimeout(timer)
// 重新设置一个新的延时器
timer = setTimeout(() => {
fn.call(this)
}, delay);
}
}
使用函数防抖可以减少事件触发的次数和频率,在某些情况下可以起到优化的作用。比如:搜索框,对于核心业务非搜索的网站,一般都是等待用户完整输入内容后才发送查询请求,一次来减少服务器的压力。像百度这样的核心业务为搜索的网站,服务器性能足够强大,所以不进行函数防抖处理;
代码实现
*
节流函数:fn:要被节流的函数,delay:规定的时间
*/
function throttle(fn, delay){
// 记录上一次函数出发的时间
var lastTime = 0
return function(){
// 记录当前函数触发的时间
var nowTime = new Date().getTime()
// 当当前时间减去上一次执行时间大于这个指定间隔时间才让他触发这个函数
if(nowTime - lastTime > delay){
// 绑定this指向
fn.call(this)
//同步时间
lastTime = nowTime
}
}
}
Cookie
Cookie
翻译过来是小甜饼的意思,是网景公司的前雇员 Lou Montulli
在1993
年3
月发明的;Cookie
是纯文本格式,不包含任何可执行的代码信息,伴随着用户请求在 Web
服务器和浏览器之间传递;Cookie
本质上属于http
的范畴,因为http
协议本身是无状态的,服务端是没有办法区分请求来自于哪个客户端,即便是来自于同一个客户端的多次请求,服务端也无法进行区分。所以引入了Cookie
去维持客户端的状态(比如每个账号的购物车状态都不一样)。Cookie
的生成方式
在 JavaScript
中通过 document.cookie
属性,你可以创建、维护和删除 Cookie
;设置 document.cookie
属性的值并不会删除存储在页面中的所有 Cookie
,它只简单的创建或修改字符串中指定的 Cookie
。
Web
服务器通过在HTTP
响应头中添加 Set-Cookie
字段来创建一个 Cookie
,可以在该字段中添加HttpOnly
属性禁止JavaScript
脚本访问Cookie
,以此来避免跨域脚本 (XSS
) 攻击。
Cookie
的缺陷
Cookie
在HTTP
中是明文传递的,其中包含的数据都可以被他人访问,出现篡改、盗用等问题;Cookie
的大小限制在4KB
左右,若要做大量存储显然不是理想的选择;Cookie
是绑定域名对应的服务器的,所以对同一个域名的每次请求都会在Request Header
中带上Cookie
。Cookie
信息的场合下流量的浪费;这样浏览器对同一域名的每一次请求都会多出4KB
流量,对于大型网站来说这是很大的损耗。因此要慎用Cookie
,不要在Cookie
中存储重要和敏感的数据。
Cookie
性能优化的方法
将存放静态资源的CDN
服务器域名与主站的域名独立开来。这样每次请求静态文件的时候就不需要携带Cookie
,从而可以节省很多流量。
举例
比如在百度进行登录的时候,请求头里面就会有Set-Cookie
字段,其中的BDUSS
就是标识用户登录状态的字符串:
Set-Cookie
中的httponly
属性表示的是禁止js
脚本访问cookie
,这样能够一定程度防范XSS
攻击;
在Chrome
调试工具的Application
选项中查看Cookies
信息,可以发现该Cookie
已经被网站“种”到Domain:.baidu.com
这个域名下了,并且该Cookie
也设置了HttpOnly
属性:
此后浏览器的每次请求都会在请求头Request Headers
中携带这一Cookie
信息。刷新页面后可以看到,请求头中携带了Cookie
信息BDUSS
:
这样服务器就知道这是已经登录的用户了。
但是不是所有的请求都需要携带Cookie
信息,比如优酷:
可以看到请求index.css
文件时也携带了Cookie
,但是这是不必要的,这就会导致流量的浪费。
解决方法就是上面所说的:将
CDN
域名和主域名独立出来;
百度就是这样解决的:
可以看到请求这个静态资源的url
并不是.baidu.com
,而是静态资源服务器CDN
;并且该请求的请求头中不会携带Cookie
信息:
设置和获取Cookie
设置Cookie
的方式很简单,key
和value
值通过等号连接:
document.cookie = "userName=zhangsan"
打开Application
选项查看当前Cookie
,可以看到Cookie
已被改变:
获取Cookie
:
document.cookie
备注:静态资源是不会携带
Cookie
的;Cookie
一般都是后台种的,很少让前端来直接写;Cookie
分:持久级别、session
级别;Cookie
一般用于存放session ID
与服务器端进行通信;
Web Storage
Web Storage
分为SessionStorage
和LocalStorage
专门用于客户端浏览器的本地存储,同时空间比Cookie
大很多,一般支持5-10M
;Window.sessionStorage
和 Window.localStorage
属性来实现本地存储机制;LocalStorage
LocalStorage
是HTML5
设计出来专门用于存储浏览器信息的:
5~10M
左右;js
进行读写等操作的API
;举例
比如通过Chrome
调试工具的Application
选项可以查看淘宝中LocalStorage
存储的数据:
这些数据只要不手动清除,即使关闭页面也都会存在。当需要使用图片、js/css
文件等资源时就不用重新向服务器发出请求,而是可以直接使用LocalStorage
中的缓存,这就是LocalStorage
缓存的优势;
而Cookie
就不一样了,里面存储的数据都是要带到服务器端的,例如用户登录状态,统计信息等数据:
设置和获取LocalStorage
LocalStorage
提供了相对简单的API
,采用的也是key
和value
的形式。
设置时通过:
localStorage.setItem("key", "value")
查看LocalStorage
,同样设置成功了:
获取时通过:
localStorage.getItem("key")
其他方法
//该方法接受一个键名作为参数,并把该键名从存储中删除。
localStorage.removeItem('key');
//调用该方法会清空存储中的所有键名
localStorage.clear();
SessionStorage
SessionStorage
用于存储浏览器的会话信息,标签页关闭之后它存储的数据就会被清空,而LocalStorage
的数据不会被清空,这是二者的区别:
5~10M
左右;SessionStorage
中,这样即使刷新后数据也不会丢失;还有一种场景:分页的表单在进行前进或后退时,如果将信息保存在SessionStorage
中就不会丢失;设置和获取SessionStorage
设置SessionStorage
的方法与设置LocalStorage
的方法类似:
//设置
sessionStorage.setItem("key", "value")
//获取
sessionStorage.getItem("key")
通过Application
选项查看SessionStorage
,可见已成功修改: 其他方法
//该方法接受一个键名作为参数,并把该键名从存储中删除。
sessionStorage.removeItem('key');
//调用该方法会清空存储中的所有键名
sessionStorage.clear();
IndexedDB
IndexedDB
是浏览器提供的一种API
,用于存储客户端中大量的结构化数据。该API
使用索引来实现对数据的高性能搜索。虽然WebStorage
对于存储较少量的数据时很有用(采用key/value
的方式),但对于存储更大量的结构化数据来说,还是IndexedDB
表现更加优异。
IndexedDB
的应用
可以在浏览器中打印indexedDB
对象:
PWA
PWA
(Progressive Web Apps
)是一种Web App
新模型(标准),并不是具体指某一种前沿的技术或者某一个单一的知识点。从英文缩写就能看出,这是一个渐进式的Web App
,是通过一系列新的Web
特性,配合优秀的UI
交互设计,逐步增强用户的体验;
PWA
的要求
Engaging
):应用可以被增加到手机桌面,并且和普通应用一样有全屏、推送等特性;Service Worker
Service Worker
是一个脚本,可以使浏览器独立于当前网页,在后台运行。为实现一些不依赖页面或者用户交互的特性打开了一扇大门。在未来这些特性将包括推送信息,背景后台同步,geofencing
(地理围栏定位)等它将推出的第一个首要特性,就是拦截和处理网络请求的能力,包括以编程方式来管理被缓存的响应。
即Service Worker
可以帮助浏览器执行大规模的运算而不阻碍主线程的执行。
Service Worker
的应用
Service Worker
在后台运行的同时能和页面通信的能力,去实现大规模后台数据的处理;Service Worker
应用过程
示例
通过Chrome
调试工具的Application
选项可以查看淘宝的Service Workers
信息:
当我们刷新淘宝网页的时候,查看Network
选项,可以从请求文件的size
栏发现大量的文件都是从Service Worker
缓存中请求回来的:
这样的话就可以利用Service Worker
的缓存进行网站的性能优化。
以下列淘宝请求同一js
文件为例,从Service Worker
中加载使用了7ms
:
使用Ctrl + F5
强制刷新后,向服务器请求同一文件花了100ms
:
这就是使用Service Worker
性能上带来的优势。由于是从本地缓存中读取的资源,所以资源读取的速度和整体的性能都会有一个明显的提升。
浏览器在本地磁盘上将用户之前请求的数据存储起来,当访问者再次需要改数据的时候无需再次发送请求,直接从浏览器本地获取数据
可以通过Chrome
浏览器调试工具中的Network
选项查看浏览器请求资源的情况:
注意不要勾选图中方框内的选项,否则有些请求会被过滤;
Cache-Control
字段服务器可通过httpheader
中的Cache-Control
字段控制客户端与服务器端之间的缓存策略,它的属性值有:
max-age
该字段指定了缓存的最大有效时间,以下为淘宝的一张图片:
在max-age
属性指定的时间未到期前,客户端不会向服务器发起请求,而是从缓存中直接读取该图片。上图中可以看到浏览器直接从ServiceWorker
的缓存中读取了该图片资源。
Expires
字段同样可以指定缓存的有效期,不过这是HTTP1.0
中的字段,优先级比HTTP1.1
中的Cache-Control
字段的max-age
属性低;
s-maxage
缓存设备总体来说有两种:浏览器(客户端)和CDN
服务器;
private
类型缓存设备,表示只有浏览器才可以对资源进行缓存;CDN
服务器属于public
类型缓存设备,这种设备可以对源服务器上的资源进行缓存。并且,这种缓存对于任何用户来说都是可以访问的;s-maxage
的优先级在Expires
和max-age
三者之中是最高的,用于指定public
类型缓存设备(比如CDN
)上资源的有效期。如下图所示,该资源设定了该字段后,浏览器既不会使用浏览器缓存,也不会向服务器请求资源,而是向public
类型的缓存设备(如CDN
服务器)请求资源:
private
服务器端可以通过该属性指定某一资源只能被浏览器(客户端)缓存,而不能被代理缓存服务器(CDN
)缓存。
public
服务器端可以通过该属性指定某一资源,既可以被浏览器缓存,也可以被代理缓存服务器缓存;
no-cache
no-cache
属性规定了浏览器要先向服务器端发送请求确认缓存资源的新鲜度,才能决定是否使用缓存;如下图所示:
no-store
该属性指定了浏览器无论缓存资源是否过期直接跳过缓存,重新向服务器请求资源。no-store
属性用的比较少。
Expires
字段这是http1.0
的规范;它的值为一个绝对时间的GMT
(格林威治标准时间)格式时间字符串,如Mon, 10 Jun 2015 21:31:12 GMT
;
该字段指定了浏览器缓存资源的过期时间,在指定的时间到期前,浏览器可以直接从本地缓存中读取数据,而无需再次向服务器发起请求,属于强缓存;相比于max-age
与s-maxage
优先级最低,在这两个属性存在的情况下Expires
字段会失效;
Last-Modified/If-Modified-Since
二者是基于客户端和服务端协商的缓存机制,标识资源最后更新时间的字段。last-modified
字段位于response header
中,If-Modified-Since
字段位于request header
中,二者配合着Cache-Control
字段使用。
当服务器上的资源发生改变时会同步更新last-modified
的字段值,当Expires
字段或max-age
属性指定的时间到期后,客户端会在请求头中携带If-Modified-Since
字段,与服务器端资源的last-modified
字段值进行比较:
last-modified
字段指定的时间以后都没有发生变化,此时服务器返回状态码304
,属于协商缓存;last-modified
字段值,此时的状态码为200
;举例
下图表示状态码为304
的响应:
If-Modified-Since
字段的值为Mon, 23 Mar 2020 18:14:15 GMT
:Last-Modified
字段的值为Mon, 23 Mar 2020 18:14:15 GMT
:二者相等,说明资源没有发生变化,所以服务器返回状态码304
,属于协商缓存,浏览器继续使用本地缓存;
If-Modified-Since
字段的值就是服务器端上一次响应资源中的Last-Modified
字段值;
Last-Modified
的缺点
GET
;1s
内修改了N
次),If-Modified-Since
能检查到的粒度是s
级的,这种修改无法判断(比如淘宝每ms
都会更新数据);所以有了
Etag/If-None-Match
Etag
字段是HTTP1.1
中的标准,是一个唯一标识服务器端资源的hash
值,该字段存在于响应头(reponse header
)中;与请求头(request header
)中的If-None-Match
字段及Cache-Control
字段配合使用。
只要服务器端的资源发生变化Etag
值就会改变,相比于Last-Modified
字段优先级更高且更有效;当Expires
值或者Cache-Control
字段中的max-age
值到期时,客户端会在请求头中携带If-None-Match
字段,该字段值为服务器端上一次响应资源中的Etag
值,并与服务器端上最新资源的Etag
值进行比较:
304
,属于协商缓存;Etag
值,此时状态码为200
;举例
下图表示状态码为304
的响应:
If-None-Match
字段值为2da25d4039...
:Etag
字段值为2da25d4039...
:二者相等,说明资源没有发生变化,所以服务器返回状态码304
,属于协商缓存,浏览器继续使用本地缓存;
总结:利用
Etag
能够更加准确的控制缓存,因为Etag
是服务器自动生成或者由开发者生成的对应资源在服务器端的唯一标识符;Last-Modified
与ETag
是可以一起使用的,由于Etag
的优先度更高,所以服务器会优先比较Etag
和If-None-Match
。一致的情况下,才会继续比对Last-Modified
和If-Modified-Since
,最后才决定是否返回状态码304
。
200 ok(from memory cache)
;304
通知浏览器从缓存中读取资源;缓存 | 获取资源形式 | 状态码 | 发送请求到服务器 |
---|---|---|---|
强缓存 | 从缓存中获取 |
| 否,直接从缓存中获取 |
协商缓存 | 从缓存中获取 |
| 是,根据服务器返回信息判断缓存是否可用 |
最下层的200
状态
Expires/Cache-Control
字段控制:1.Expires
(HTTP1.0
版本有效)是绝对时间;2.Cache-Control
(HTTP1.1
版本有效)是相对时间; 当两者都存在时,Cache-Control
会覆盖Expires
,只要这些字段没有失效,浏览器都会直接使用本地缓存,属于强缓存;
memory cache
和disk cache
:可以看到,从memory cache
中读取缓存不需要时间,从disk cache
中读取缓存则需要一定时间。
相对时间与绝对时间与服务器的设置有关,当服务器设置
Atime
(最后访问时间)时,二者相等;当服务器设置Mtime
(绝对修改时间)时,Expires
从资源的创建开始计算过期时间,Max-age
从请求发起的时间开始计算过期时间;
下图便是淘宝中采用强缓存的例子,状态码为200
,图片资源都是从浏览器缓存memory cache
中读取,所以请求时间为0ms
:
中间的304
状态
last-modified/Etag
控制。当下一层失效时或用户点击refresh/F5
时,浏览器就会向服务器发起请求,如果服务器上的相关资源没有更新,则返回状态码304
,属于协商缓存;下图便为协商缓存的情况,状态码为304
。也可以这样理解:只要状态码是304
都属于协商缓存:
最上层的200
状态
Ctrl + F5
强制刷新时,浏览器会直接向服务器请求最新的资源;如下图所示:
用户操作 |
|
|
---|---|---|
地址栏回车 | 有效 | 有效 |
页面链接跳转 | 有效 | 有效 |
新开窗口 | 有效 | 有效 |
前进后退 | 有效 | 有效 |
| 无效 | 有效 |
| 无效 | 无效 |
如图所示,该流程图表示服务器端在处理资源时采用缓存策略的过程:
Cache-Control
字段中添加no-store
属性;Cache-Control
字段中添加no-cache
属性,这样不管缓存资源是否过期,都要求客户端或缓存代理服务器首先向服务器确认资源的新鲜度,属于协商缓存;Web
代理缓存资源(比如CDN
服务器缓存),如果允许则在Cache-Control
字段中添加public
属性,并指定代理缓存服务器上资源的有效期s-maxage
;不允许则添加private
属性,表示只能由客户端浏览器缓存资源,并设定缓存的有效期max-age
;CDN
服务器网站通常将其所有的服务器都放在同一个地方,当用户群增加时,公司就必须在多个地理位置不同的服务器上部署内容。为了缩短http
请求的时间,我们应该把大量的静态资源放置的离用户近一点。
内容发布网络CDN
(Content Delivery Networks
)就是其中一种方式。CDN
是一组分布在多个不同地理位置或网段的web
服务器,用于更加有效的向用户发布内容。
CDN
系统能够实时地根据网络流量和各节点的连接、负载状况以及到用户的距离和响应时间等综合信息 将用户的请求重新导向离用户最近的服务节点上。最简单的CDN
网络由一个DNS
服务器和几台缓存服务器组成:
URL
时,经过本地DNS
系统解析,DNS
系统最终会将域名的解析权交给CNAME
指向的CDN
专用的DNS
服务器;关于
DNS
解析,不一定由DNS
服务器响应,一般从缓存中读取。比如电脑缓存、浏览器缓存、路由器缓存、运行商缓存等。如果缓存中没有找到,才一级一级地查询:本地DNS
-> 权限DNS
-> 顶级DNS
-> 根DNS
。全球只有13
台根DNS
服务器。
CDN
的DNS
服务器将CDN
的全局负载均衡设备的IP
地址返回给用户;CDN
的全局负载均衡设备发起内容URL
访问请求;CDN
全局负载均衡设备根据用户的IP
地址,以及用户请求的内容URL
,选择一台用户所属区域的区域负载均衡设备,告诉用户向这台设备发起请求;IP
地址,判断哪一台服务器距用户最近;URL
中携带的内容名称,判断哪一台服务器上有用户所需内容; 基于以上这些条件的综合分析之后,CDN
区域负载均衡设备会向CDN
全局负载均衡设备返回一台CDN
缓存服务器的IP
地址。
CDN
全局负载均衡设备把服务器的IP
地址返回给用户;CDN
缓存服务器发起请求,缓存服务器响应用户请求,将用户所需内容传送到用户终端;如果这台CDN
缓存服务器上并没有用户想要的内容,但是区域均衡设备依然将它分配给了用户,那么这台CDN
服务器就要向它的上一级缓存服务器请求内容,直至追溯到网站的源服务器将内容拉到本地; 站点或者应用中大量静态资源的加速分发,建议将站点内容进行动静分离,动态文件可以结合云服务器ECS
,静态资源如各类型图片、html
、css
、js
文件等,使用CDN
服务器存储,可以有效加速内容加载速度,轻松搞定网站图片、短视频等内容分发。
移动APP
更新文件(apk
文件)分发,移动APP
内图片、页面、短视频、UGC
等内容的优化加速分发。提供httpDNS
服务,避免DNS
劫持并获得实时精确的DNS
解析结果,有效缩短用户访问时间,提升用户体验。
简单点说CDN
服务器相当于顺丰快递分布于全国各地的仓库,主仓库将快递运送到这些分仓库,用户可以就近取货,由此加快了速度。
除此之外CDN
服务器还有许多高级功能,比如防止DDOS
攻击等,这里就不展开了;
SSR(Server Side Rendering)
依赖现代框架如Vue
和React
构建的网站,往往会存在一定的问题,比如Vue
框架。
Vue
渲染面临的问题
首屏渲染时,要先下载和解析app.js
(打包过后的Vue.js
)之后,才能开始渲染页面。
优化方案
Prerender
的方式;通常采用服务端渲染(SSR
)的方式进行优化。所谓SSR
就是利用服务器端优秀的计算能力,将一部分的页面渲染任务交由服务器端进行处理。以下为服务端渲染SSR
的流程图:
服务端渲染可以很好地优化首屏渲染的问题;可以根据业务需求,适当地分配客户端和服务器端的渲染部分,综合利用客户端和服务器端的计算能力,从而达到性能优化的目的。
当我们去面试的时候,很大概率会被面试官问这么一个问题:你有尝试过对项目做性能优化吗?或者你了解哪些性能优化的方法?听到这个问题的你可能是这样的:
似曾相识但又说不清楚,往往只能零散地说出那么几点,难以做到有条理的回答。那么,本文就带你简单了解前端性能优化的几个主要方面,旨在抛砖引玉。
请求过程中一些潜在的性能优化点:
dns
是否可以通过缓存减少dns
查询时间?http
请求的大小和次数?总结: 深入理解http
请求的过程是前端性能优化的核心。
优化核心
http
请求数量;google
首页案例学习
html
压缩;css
压缩;js
的压缩和混乱;gzip
;参考 前端进阶面试题详细解答
html
压缩HTML
代码压缩就是压缩一些在文本文件中有意义,但是在HTML
中不显示的字符,包括空格,制表符,换行符等,还有一些其他意义的字符,如HTML
注释也可以被压缩;
一个简单的计算:
google
的流量,占到整个互联网的40%
,预计2016
年全球网络流量将达到1.3ZB(1ZB = 10^9TB)
,那么google
在2016
年的流量就是1.3ZB * 40%
,如果google
每1MB
请求减少一个字节,每年可以节省流量近500TB
流量。
如何进行html
压缩
nodejs
提供的html-minifier
工具;css
代码压缩分为两部分:
css
语义合并;如何进行css
压缩
html-minifier
对html
中的css
进行压缩;clean-css
对css
进行压缩;js
压缩与混乱(丑化)包括:
JS
压缩与混乱(丑化)
html-minifier
对html
中的js
进行压缩;uglify.js2
对js
进行压缩;文件合并的好处:
不合并请求有下列缺点:
N-1
个网络延迟;keep-alive
本身也存在问题:经过代理服务器时可能会被断开;文件合并存在的问题
js
文件的时候,如果页面渲染只依赖a.js
文件,由于文件合并,需要等待合并后的a-b-c.js
文件请求回来才能继续渲染,这样就会导致页面渲染速度变慢。这种情况大多出现在现代化的前端框架,如Vue
等的使用过程中;a-b-c.js
中只要其中一个文件(比如a.js
)发生变化,那么整个合并文件都将失效,而不采用文件合并就不会出现这种情况;使用建议
js
文件单独合并:比如在单页面应用SPA
中,当路由跳转到具体的页面时才请求该页面需要的js
文件;如何进行文件合并
nodejs
实现文件合并;webpack
等前端构件化工具也可以很好地实现;有损压缩过程: 一张JPG
图片的解析分别要进行:
RGB
的颜色空间转到其他的颜色空间 ;DCT
过程:对高频的颜色采样结果进行压缩,这样压缩的收益会比较大;encoding
);最终得到JPEG-Compressed Image Data
,即真正显示出来的JPG
图片。虽然这是一种有损压缩,但是很多情况下,这些损失的数据并不影响显示;
png8/png24/png32
之间的区别
png8
:256
色 +
支持透明;png24
:2^24
色 +
不支持透明;png32
:2^32
色 +
支持透明;不同格式图片常用的业务场景
jpg
有损压缩,压缩率高,支持透明;应用:大部分不需要透明图片的业务场景;png
支持透明,浏览器兼容好;应用:大部分需要透明图片的业务场景;webp
(2010
年由谷歌推出)压缩程度更好,在ios webview
中有兼容性问题;应用:安卓全部;svg
矢量图,代码内嵌,相对较小,用于图片样式相对简单的场景;应用:比如logo
和iconfont
;针对真实图片情况,舍弃一些相对无关紧要的色彩信息,对图片进行压缩;
css
雪碧图将网站上用到的一些图片整合到一张单独的图片中,从而减少网站HTTP
请求数量。原理为:设定整张雪碧图可示区域,将想要显示的图标定位到该处(左上角);缺点:整合图片比较大时,一次加载比较慢。
如天猫的雪碧图:
很多情况下,并不是所有的小图标都放在一张雪碧图中,而是会适当进行拆分。现在使用雪碧图的场景比较少了。
自动生成雪碧图样式
Image inline
)将图片的内容内嵌到html
当中,减少网站的HTTP
请求数量,常用于处理小图标和背景图片。网页内联图片写法为:
<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAA..." alt="">
缺点:
ie8
以上浏览器;1000kb
的图片,base64
编码会使图片大小增大,导致网页整体下载速度减慢;所以要根据场景使用,不过内联图片减少HTTP
请求的优点还是很显著的。比如,在开发中小于4KB
或8KB
的图片都会通过构建工具自动inline
到HTML
中,这种情况下Image inline
带来的图片大小增长其实是比增加HTTP
请求次数更优的。
SVG
与iconfont
使用iconfont
解决icon
问题
应尽量使用该方式,比如可以采用阿里巴巴矢量图库:
可以选择格式进行下载:
可以看到它们的大小有着明显的差异:
使用SVG
进行矢量图的控制
SVG
意为可缩放矢量图形(Scalable Vector Graphics
)。SVG
使用 XML
格式定义图像。
webp
webp
的优势体现在它具有更优的图像压缩算法,能带来更小的图片体积,而且拥有肉眼识别无差异的图像质量;同时具备了无损和有损的压缩模式、Alpha
透明以及动画的特性。在JPEG
和PNG
上的转化效果都非常优秀、稳定和统一。安卓上不存在兼容性问题,推荐安卓下使用。
以下为淘宝网首页请求的图片:
可以看到,图片中大量地添加了webp
格式的选择。.jpg_.webp
表示当浏览器支持webp
时采用webp
格式,否则采用jpg
格式。
下面为B
站首页的图片,可以看到基本都采用了webp
格式:
同一张图片jpg
格式和webp
格式压缩率有着明显的差异:
可以通过在线网站将图片转换为webp
像图片这样的静态文件可以存放在CDN
服务器上,让CDN
服务器批量地将图片转换成Webp
格式;
版本一:
版本二:
一个渲染引擎主要包括:HTML
解析器,CSS
解析器,javascript
引擎,布局layout
模块,绘图模块:
HTML
解析器:解释HTML
文档的解析器,主要作用是将HTML
文本解释成DOM
树;CSS
解析器:它的作用是为DOM
中的各个元素对象计算出样式信息,为布局提供基础设施;Javascript
引擎:使用Javascript
代码可以修改网页的内容,也能修改css
的信息,javascript
引擎能够解释javascript
代码,并通过DOM
接口和CSS
树接口来修改网页内容和样式信息,从而改变渲染的结果;layout
):在DOM
创建之后,Webkit
需要将其中的元素对象同样式信息结合起来,计算他们的大小位置等布局信息,形成一个能表达这所有信息的内部表示模型;paint
):使用图形库将布局计算后的各个网页的节点绘制成图像结果;浏览器渲染页面的整个过程:浏览器会从上到下解析文档。
HTML
标记,就会调用HTML
解析器解析为对应的 token
(一个token
就是一个标签文本的序列化)并构建 DOM
树(就是一块内存,保存着tokens
,建立它们之间的关系)。在生成DOM
的最开始阶段(应该是Bytes
→ characters
后),并行发起css
、图片、js
的请求,无论他们是否在HEAD
标签中。注意:发起
js
文件的下载请求(request
)并不需要DOM
处理到那个script
节点;
style/link
标记 调用解析器 处理 CSS
标记并构建 CSS
样式树;script
标记 调用 javascript
解析器处理script
标记,绑定事件、修改DOM
树/CSS
树等;DOM
树 与 CSS
树 合并成一棵渲染树(Render Tree
)。Layout
):根据渲染树中各节点的样式和依赖关系,计算出每个节点在屏幕中的位置;Painting
):按照计算出来的结果:要显示的节点、节点的CSS
与位置信息,通过显卡,把内容画到屏幕上;经过第一次Painting
之后DOM
、CSSOM
、Render Tree
都可能会被多次更新,比如JS
修改了DOM
或者CSS
属性时,Layout
和Painting
就会被重复执行。除了DOM
、CSSOM
更新的原因外,图片下载完成后也需要调用Layout
和 Painting
来更新网页。
补充:
HTML
中可能会引入很多的css、js
这样的外部资源,这些外部资源在浏览器端是并发加载的。但是浏览器会对同一域名进行并发数量(度)的限制,即单个域名的并发度是有限的; 所以,经常将大部分的资源托管到CDN
服务器上,并且设置3~4
个CDN
域名。防止只有一个CDN
域名的情况下,达到了浏览器外部资源并发请求数目的上限,导致很多资源无法做到并发请求。所以,应设置多个CDN
域名;
css
阻塞只有通过link
引入的外部css
才会产生阻塞:
style
标签中的样式:html
解析器进行解析;DOM
解析;link
引入的外部css
样式(推荐使用的方式):CSS
解析器进行解析;css
已经加载完毕,所以整个渲染过程是带样式的,所以这种阻塞可以避免“闪屏现象”;js
语句的执行:这个不难理解,js
文件中经常会出现DOM
操作,操作过程中有可能涉及到css
样式的修改。实际上,这些修改往往是依赖于之前引入的css
设定的样式的,所以css
会阻塞js
的执行;css
加载速度:CDN
节点进行外部资源加速;css
进行压缩(利用打包工具,比如webpack
,gulp
等);http
请求数,将多个css
文件合并;js
阻塞 原因:浏览器不知道后续脚本的内容,如果先去解析了下面的DOM
,而随后的js
删除了后面所有的DOM
,那么浏览器就做了无用功,浏览器无法预估脚本里面具体做了什么操作,例如像document.write
这种操作,索性全部停住,等脚本执行完了,浏览器再继续向下解析DOM
;可以通过给script
标签添加defer
和async
属性,异步引入js
文件,以此来解决这一问题。
原因:js
中也可以给DOM
设置样式,浏览器同样等该脚本执行完毕,再继续干活,避免做无用功;
js
的执行: 原因:js
是按顺序执行的,这样可以维护依赖关系,例如:必须先引入jQuery
再引入bootstrap
;
这并不与上面矛盾,因为不可能由于加载一个js
文件就把其他资源的加载都阻塞了。针对这种常见的情况,浏览器会通过预加载的方式加载后续的资源;
css
的解析和js
的执行是互斥的(互相排斥),css
解析的时候js
停止执行,js
执行的时候css
停止解析;css
阻塞,还是js
阻塞,都不会阻塞浏览器加载外部资源(图片、视频、样式、脚本等);因为览器始终处于一种:“先把请求发出去”的工作模式,只要是涉及到网络请求的内容,无论是:图片、样式、脚本,都会先发送请求去获取资源,至于资源到本地之后什么时候用,由浏览器自己协调。显然这种做法效率很高;
WebKit
和Firefox
都进行了【预解析】这项优化。在执行js
脚本时,浏览器的其他线程会解析文档的其余部分,找出并加载需要通过网络加载的其他资源。通过这种方式,资源可以在并行连接上加载,从而提高总体速度。请注意,预解析器不会修改 DOM
树图片进入可视区域之后再请求图片资源的方式称为图片懒加载。适用于图片很多,页面很长的业务场景,比如电商;
懒加载的作用:
比如一个网站有十页图片,用户只查看了第一页的图片,这就没必要将十页图片全都加载出来;
js
的加载,影响网站正常的使用: 由于浏览器对某一个host name
是有并发度上限的,如果图片资源所在的CDN
和静态资源所在的CDN
是同一个的话,过多图片的并发加载就会阻塞后续js
文件的并发加载。
懒加载实现的原理:
监听onscroll
事件,判断可视区域位置:
图片的加载是依赖于src
路径的,首先可以为所有懒加载的静态资源添加自定义属性字段,用于存储真实的url
。比如是图片的话,可以定义data-src
属性存储真实的图片地址,src
指向loading
的图片或占位符。然后当资源进入视口的时候,才将src
属性值替换成data-src
中存放的真实url
。
<img src="" class="image-item" alt="" lazyload = "true" data-src="TB27YQvbm_I8KJjy0FoXXaFnVXa_!!400677031.jpg_180x180xzq90.jpg_.webp">
懒加载实例
可以使用元素的getBoundingRect().top
来判断当前位置是否在视口内,也可以使用元素距离文档顶部的距离offsetTop
和scrollTop
是否小于视口高度来判断:
举例
比如手机淘宝首页:
当快要滚动到需要展示的图片时才进行图片的请求,可以看到图片上有一个lazyload
的属性:
预加载与懒加载正好是相反的过程:懒加载实际上是延迟加载,将我们所需的静态资源加载时间延后;而预加载是将图片等静态资源在使用之前的提前请求,这样资源在使用到时能从缓存中直接加载,从而提升用户体验;
预加载的作用:
WebGL
页面,会依赖一些3D
模型,这些都是页面渲染所必须的资源。如果资源都没有加载完毕就进行页面的渲染,就会造成非常不好的体验。 所以时常使用预加载的方式维护页面渲染的依赖关系,比如将WebGL
页面依赖的3D
模型加载完之后才进行页面渲染。这样渲染的过程就不会有任何阻碍,具有较好的用户体验;
预加载的实例
例如九宫格抽奖业务,每个奖品都有一个选中态和非选中态,实际上这是由两张图片组合而成的。由于每个奖品的选中过程都是一瞬间,这就对图片的选中态和非选中态切换效率要求很高,如果选中态的图片没有预加载的话显然是来不及的。
所以,实际上对于九宫格中所有图片选中态的样式和对应的图片都需要进行预加载,从而让我们在抽奖的过程中,能够瞬间从缓存中读取到选中态的图片,从而不影响抽奖效果的展示。
除此之外还有网站登录或活动时需要用到的动画,这是在动画需要的每帧图片都完全预加载完之后才会进行显示的。
CSS
图层浏览器在渲染一个页面时,会将页面分为很多个图层,图层有大有小,每个图层上有一个或多个节点。在渲染 DOM
的时候,浏览器所做的工作实际上是:
1、获取`DOM`后分割为多个图层;
2、对每个图层的节点计算样式结果(`Recalculate style`--样式重计算);
3、为每个节点生成图形和位置(`Layout`--回流和重布局);
4、将每个节点绘制填充到图层位图中(`Paint Setup`和`Paint`--重绘);
5、图层作为纹理上传至`GUI`;
6、复合多个图层到页面上生成最终屏幕图像(`Composive Layers`--图层重组);
3D
或透视变换的css
属性(prespective transform
);<video>
节点;3D(WebGL)
上下文或加速的2D
上下文的<canvas>
节点;CSS3
动画的插件(如Flash
);css
过滤器的元素;transform
:如translateZ(0)
opacity
filter
will-change
:哪一个属性即将发生变化,进而进行优化。重绘是一个元素外观的改变所触发的浏览器行为,比如background-color
、outline
等属性。这些属性不影响布局,只影响元素的外观,风格,会造成DOM
元素的重新渲染,这个过程称为重绘。
需要注意的是:重绘是以图层为单位,如果图层中某个元素需要重绘,那么整个图层都需要重绘。比如一个图层包含很多节点,其中有个gif
图,gif
图的每一帧,都会重回整个图层的其他节点,然后生成最终的图层位图。
因此,可以通过特殊的方式来强制gif
图单独为一个图层(translateZ(0)
或者translate3d(0,0,0)
;CSS3
的动画也是一样(好在绝大部分情况浏览器自己会为CSS3
动画的节点创建图层);
所以:将频繁重绘回流的DOM
元素作为一个独立图层,那么这个DOM
元素的重绘和回流只会该图层;原则上是要尽量避免新建图层的,因为这会导致图层重组(Composive Layers
)时候的计算量增大。所以,只有当某些DOM
元素频繁重绘回流时,才新建一个独立图层放置它们;
只会触发重绘的属性
//部分属性
color
border-style
border-radius
visibility
text-decoration
background
background-image
background-position
background-repeat
background-size
outline-color
outline
outline-style
outline-width
box-shadow
当render tree
中的一部分(或全部)因为元素的规模尺寸,布局,隐藏等改变而需要重新构建。这就称为回流(reflow
);
触发页面重布局(回流)的属性
盒子模型相关属性 | 定位及浮动属性 | 文字结构属性 |
---|---|---|
width | top | text-align |
height | bottom | overflow-y |
padding | left | font-weight |
margin | right | overflow |
display | position | font-family |
border-width | float | line-height |
border | clear | vertical-align |
min-height | white-space | |
font-size |
频繁触发重绘和回流,会导致UI
频繁渲染。在渲染的过程中由于阻塞了js
线程的执行,最终导致js
执行变慢。
DOM
结点;DOM
的位置;CSS
样式;Resize
窗口;移动端没有这个问题,因为移动端的缩放没有影响布局视口(vw/vh
);DOM
元素的属性(width
,height
等);注:
display:none
会触发Reflow
,而visibility:hidden
只会触发Repaint
,因为没有发生位置变化;
案例一:淘宝轮播图
可以使用Chrome
浏览器调试工具的Performance
来观察淘宝首页一个轮播图引起的重绘回流过程:
Update Layer Tree
回流和重布局:
Paint
重绘:
Composite Layers
图层重组:
案例二:播放器
通过Chrome
调试工具的Layers
选项查看图层,及新增图层的原因:
视频播放的过程中,video
标签的DOM
元素会一直重绘,所以把它限制在一个图层上是非常好的,这样只会涉及到这个图层的重绘,而不会影响其他图层的元素。
图层不能滥用,否则会在图层重组的过程中严重消耗性能!
比如可以将淘宝首页的所有的DOM
元素都变为一个图层:在html
标签中的全局样式(*
)中添加transform:translateZ(0)
来触发新建图层:
还可以通过添加:
will-change: transform
属性新建图层;
再次查看此时的图层情况,可以看到此时首页的图层非常之多,十分地卡:
如果我们需要使得动画或其他节点渲染的性能提高,需要做的就是减少浏览器在运行时所需要做的下列工作:
Recalculate style
--样式重计算);Layout
--回流和重布局);Paint Setup
和Paint
--重绘);Composite Layers
--图层重组);1、使用translate
替代top
等属性来改变位置;
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Document</title>
<style>
#box{ /*方法1*/
position: relative; top: 0; /*方法2*/
/* transform: translateY(0); */
width: 200px; height: 200px; background-color: pink; } </style>
</head>
<body>
<div id="box"></div>
<script>
setTimeout(() => { document.getElementById("box").style.top = '100px'
//document.getElementById("box").style.transform = 'translateY(100px)'
}, 2000); </script>
</body>
</html>
使用top
属性改变正方形位置时,存在重绘和回流Layout
:
而使用translate
属性改变正方形位置时,并不会引起重绘和回流:
比如有的网站会有一些左右飘动的浮窗,由于这些浮窗是采用定时器来实现的,如果每经过100ms
就改变浮窗的位置。这种时候使用transform
来替代top/left
的话1s
内就减少了十次回流,十分有利于网页速度的提升。
2、使用opacity
替代visibility
:
visibility
不触发重排,但是依然重绘;opacity
既触发重绘,又触发重排(GPU
底层设计如此!);opacity
配合图层使用,既不触发重绘也不触发重排; 原因:透明度的改变时,GPU
在绘画时只是简单的降低之前已经画好的纹理的alpha
值来达到效果,并不需要整体的重绘。不过这个前提是这个被修改opacity
本身必须是一个单独的图层。
3、将多次改变DOM
元素样式属性的操作合并成一次操作:
class
,然后通过修改DOM
的className
来添加样式;4、把DOM
离线后再修改:
display
属性为none
的元素不在渲染树中,对隐藏的元素操作不会引发其他元素的重排。如果要对一个元素进行复杂的操作时,可以先隐藏它,操作完成后再显示。这样只在隐藏和显示时触发2
次回流;5、不要把获取某些DOM
节点的属性值放在一个循环里当成循环的变量
当向浏览器请求某些 style
信息的时候,浏览器就会清空(flush
)队列,比如:
ffsetTop
,offsetLeft
,offsetWidth
,offsetHeight
;scrollTop/Left/Width/Height
;clientTop/Left/Width/Height
;width
,height
;浏览器为了获取最精确的值,需要刷新内部队列。因为队列中可能存在影响到这些值的操作,即使没有,浏览器也会强行刷新渲染队列。这样就无法利用渲染队列的缓存来避免回流过于频繁了,所以在使用到DOM
元素这些相关的属性时,可以将获取到的属性值存在一个变量中,而不是每次都去重新获取。
6、不要使用table
布局:
table
的重新布局;所以尽量使用div
布局;7、启用GPU
硬件加速:
原理为:浏览器会检测一些特定的css
属性,当DOM
元素拥有这些css
属性的时候,浏览器就会对该DOM
元素启动GPU
硬件加速;比如:transform: translateZ(0)
和transform: translate3d(0, 0, 0)
这两个属性都可以启动硬件加速;硬件加速同样不能滥用,否则会导致图层过多,导致合并图层时消耗大量性能。
8、动画实现速度的选择:
9、为动画元素新建图层,提高动画元素的z-index
;
10、利用文档碎片(documentFragment
)------vue
使用了该种方式提升性能
如果我们要在一个ul
中添加10000
个li
,如果不使用文档碎片,那么我们就需要使用append
进行10000
次的追加,这会导致页面不停地回流,非常地消耗资源:
var oUl = document.createElement("ul");
for(var i=0;i<10000;i++)
{
var oLi = document.createElement("li");
oUl.appendChild(oLi);
}
document.body.appendChild(oUl);
我们可以引入createDocumentFragment()
方法,它的作用是创建一个文档碎片。先将要插入10000
个li
添加到文档碎片里,然后再一次性添加到document
中。即文档碎片相当于一个临时仓库,这样能够大量减少DOM
操作:
//先创建文档碎片
var oFragment = document.createDocumentFragment();
//再创建ul标签
var oUl = document.createElement("ul");
for(var i=0;i<10000;i++)
{
//创建li标签
var oLi = document.createElement("li");
//先附加在文档碎片中
oFragment.appendChild(oLi);
}
//将文档碎片添加到ul标签中
oUl.appendChild(oFragment);
//将ul标签添加到body标签中
document.body.appendChild(oUl);
11、如果涉及到一些可以使用合成线程来处理 CSS
特效或者动画的情况,就尽量使用 will-change
来提前告诉渲染引擎,让它为该元素准备独立的层。
12、采用虚拟DOM
;
13、使用requestAnimationFrame
制作动画:详细内容如下。
requestAnimationFrame
)window.requestAnimationFrame()
:该方法会告诉浏览器在重绘之前调用指定的函数:
回调函数会被自动传入一个参数:DOMHighResTimeStamp
,标识requestAnimationFrame()
开始触发回调函数的当前时间;
ID
,是回调列表中唯一的标识,没有其他意义;window.cancelAnimationFrame(requestID)
:该方法取消一个先前通过调用window.requestAnimationFrame()
方法添加到计划中的动画帧请求。requestID
是先前调用window.requestAnimationFrame()
方法时返回的ID
。
用途
CSS3
制作动画的情况下,使用这种方法替代定时器制作动画;示例
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Document</title>
<style>
#box{ height: 200px; width: 200px; background-color: pink; } </style>
</head>
<body>
<div id="box"></div>
<script>
let i = 0
//获取请求ID
let id = requestAnimationFrame(move) function move(){ i++ document.getElementById('box').style.transform = `translateX(${i}px)`
//递归调用requestAnimationFrame,更新请求ID,实现动画效果
id = requestAnimationFrame(move) } setTimeout(() => { //2s后停止动画
cancelAnimationFrame(id) }, 2000); </script>
</body>
</html>
代码实现
function debounce(fn,delay){
var timer = null
// 清除上一次延时器
return function(){
clearTimeout(timer)
// 重新设置一个新的延时器
timer = setTimeout(() => {
fn.call(this)
}, delay);
}
}
使用函数防抖可以减少事件触发的次数和频率,在某些情况下可以起到优化的作用。比如:搜索框,对于核心业务非搜索的网站,一般都是等待用户完整输入内容后才发送查询请求,一次来减少服务器的压力。像百度这样的核心业务为搜索的网站,服务器性能足够强大,所以不进行函数防抖处理;
代码实现
*
节流函数:fn:要被节流的函数,delay:规定的时间
*/
function throttle(fn, delay){
// 记录上一次函数出发的时间
var lastTime = 0
return function(){
// 记录当前函数触发的时间
var nowTime = new Date().getTime()
// 当当前时间减去上一次执行时间大于这个指定间隔时间才让他触发这个函数
if(nowTime - lastTime > delay){
// 绑定this指向
fn.call(this)
//同步时间
lastTime = nowTime
}
}
}
Cookie
Cookie
翻译过来是小甜饼的意思,是网景公司的前雇员 Lou Montulli
在1993
年3
月发明的;Cookie
是纯文本格式,不包含任何可执行的代码信息,伴随着用户请求在 Web
服务器和浏览器之间传递;Cookie
本质上属于http
的范畴,因为http
协议本身是无状态的,服务端是没有办法区分请求来自于哪个客户端,即便是来自于同一个客户端的多次请求,服务端也无法进行区分。所以引入了Cookie
去维持客户端的状态(比如每个账号的购物车状态都不一样)。Cookie
的生成方式
在 JavaScript
中通过 document.cookie
属性,你可以创建、维护和删除 Cookie
;设置 document.cookie
属性的值并不会删除存储在页面中的所有 Cookie
,它只简单的创建或修改字符串中指定的 Cookie
。
Web
服务器通过在HTTP
响应头中添加 Set-Cookie
字段来创建一个 Cookie
,可以在该字段中添加HttpOnly
属性禁止JavaScript
脚本访问Cookie
,以此来避免跨域脚本 (XSS
) 攻击。
Cookie
的缺陷
Cookie
在HTTP
中是明文传递的,其中包含的数据都可以被他人访问,出现篡改、盗用等问题;Cookie
的大小限制在4KB
左右,若要做大量存储显然不是理想的选择;Cookie
是绑定域名对应的服务器的,所以对同一个域名的每次请求都会在Request Header
中带上Cookie
。Cookie
信息的场合下流量的浪费;这样浏览器对同一域名的每一次请求都会多出4KB
流量,对于大型网站来说这是很大的损耗。因此要慎用Cookie
,不要在Cookie
中存储重要和敏感的数据。
Cookie
性能优化的方法
将存放静态资源的CDN
服务器域名与主站的域名独立开来。这样每次请求静态文件的时候就不需要携带Cookie
,从而可以节省很多流量。
举例
比如在百度进行登录的时候,请求头里面就会有Set-Cookie
字段,其中的BDUSS
就是标识用户登录状态的字符串:
Set-Cookie
中的httponly
属性表示的是禁止js
脚本访问cookie
,这样能够一定程度防范XSS
攻击;
在Chrome
调试工具的Application
选项中查看Cookies
信息,可以发现该Cookie
已经被网站“种”到Domain:.baidu.com
这个域名下了,并且该Cookie
也设置了HttpOnly
属性:
此后浏览器的每次请求都会在请求头Request Headers
中携带这一Cookie
信息。刷新页面后可以看到,请求头中携带了Cookie
信息BDUSS
:
这样服务器就知道这是已经登录的用户了。
但是不是所有的请求都需要携带Cookie
信息,比如优酷:
可以看到请求index.css
文件时也携带了Cookie
,但是这是不必要的,这就会导致流量的浪费。
解决方法就是上面所说的:将
CDN
域名和主域名独立出来;
百度就是这样解决的:
可以看到请求这个静态资源的url
并不是.baidu.com
,而是静态资源服务器CDN
;并且该请求的请求头中不会携带Cookie
信息:
设置和获取Cookie
设置Cookie
的方式很简单,key
和value
值通过等号连接:
document.cookie = "userName=zhangsan"
打开Application
选项查看当前Cookie
,可以看到Cookie
已被改变:
获取Cookie
:
document.cookie
备注:静态资源是不会携带
Cookie
的;Cookie
一般都是后台种的,很少让前端来直接写;Cookie
分:持久级别、session
级别;Cookie
一般用于存放session ID
与服务器端进行通信;
Web Storage
Web Storage
分为SessionStorage
和LocalStorage
专门用于客户端浏览器的本地存储,同时空间比Cookie
大很多,一般支持5-10M
;Window.sessionStorage
和 Window.localStorage
属性来实现本地存储机制;LocalStorage
LocalStorage
是HTML5
设计出来专门用于存储浏览器信息的:
5~10M
左右;js
进行读写等操作的API
;举例
比如通过Chrome
调试工具的Application
选项可以查看淘宝中LocalStorage
存储的数据:
这些数据只要不手动清除,即使关闭页面也都会存在。当需要使用图片、js/css
文件等资源时就不用重新向服务器发出请求,而是可以直接使用LocalStorage
中的缓存,这就是LocalStorage
缓存的优势;
而Cookie
就不一样了,里面存储的数据都是要带到服务器端的,例如用户登录状态,统计信息等数据:
设置和获取LocalStorage
LocalStorage
提供了相对简单的API
,采用的也是key
和value
的形式。
设置时通过:
localStorage.setItem("key", "value")
查看LocalStorage
,同样设置成功了:
获取时通过:
localStorage.getItem("key")
其他方法
//该方法接受一个键名作为参数,并把该键名从存储中删除。
localStorage.removeItem('key');
//调用该方法会清空存储中的所有键名
localStorage.clear();
SessionStorage
SessionStorage
用于存储浏览器的会话信息,标签页关闭之后它存储的数据就会被清空,而LocalStorage
的数据不会被清空,这是二者的区别:
5~10M
左右;SessionStorage
中,这样即使刷新后数据也不会丢失;还有一种场景:分页的表单在进行前进或后退时,如果将信息保存在SessionStorage
中就不会丢失;设置和获取SessionStorage
设置SessionStorage
的方法与设置LocalStorage
的方法类似:
//设置
sessionStorage.setItem("key", "value")
//获取
sessionStorage.getItem("key")
通过Application
选项查看SessionStorage
,可见已成功修改: 其他方法
//该方法接受一个键名作为参数,并把该键名从存储中删除。
sessionStorage.removeItem('key');
//调用该方法会清空存储中的所有键名
sessionStorage.clear();
IndexedDB
IndexedDB
是浏览器提供的一种API
,用于存储客户端中大量的结构化数据。该API
使用索引来实现对数据的高性能搜索。虽然WebStorage
对于存储较少量的数据时很有用(采用key/value
的方式),但对于存储更大量的结构化数据来说,还是IndexedDB
表现更加优异。
IndexedDB
的应用
可以在浏览器中打印indexedDB
对象:
PWA
PWA
(Progressive Web Apps
)是一种Web App
新模型(标准),并不是具体指某一种前沿的技术或者某一个单一的知识点。从英文缩写就能看出,这是一个渐进式的Web App
,是通过一系列新的Web
特性,配合优秀的UI
交互设计,逐步增强用户的体验;
PWA
的要求
Engaging
):应用可以被增加到手机桌面,并且和普通应用一样有全屏、推送等特性;Service Worker
Service Worker
是一个脚本,可以使浏览器独立于当前网页,在后台运行。为实现一些不依赖页面或者用户交互的特性打开了一扇大门。在未来这些特性将包括推送信息,背景后台同步,geofencing
(地理围栏定位)等它将推出的第一个首要特性,就是拦截和处理网络请求的能力,包括以编程方式来管理被缓存的响应。
即Service Worker
可以帮助浏览器执行大规模的运算而不阻碍主线程的执行。
Service Worker
的应用
Service Worker
在后台运行的同时能和页面通信的能力,去实现大规模后台数据的处理;Service Worker
应用过程
示例
通过Chrome
调试工具的Application
选项可以查看淘宝的Service Workers
信息:
当我们刷新淘宝网页的时候,查看Network
选项,可以从请求文件的size
栏发现大量的文件都是从Service Worker
缓存中请求回来的:
这样的话就可以利用Service Worker
的缓存进行网站的性能优化。
以下列淘宝请求同一js
文件为例,从Service Worker
中加载使用了7ms
:
使用Ctrl + F5
强制刷新后,向服务器请求同一文件花了100ms
:
这就是使用Service Worker
性能上带来的优势。由于是从本地缓存中读取的资源,所以资源读取的速度和整体的性能都会有一个明显的提升。
浏览器在本地磁盘上将用户之前请求的数据存储起来,当访问者再次需要改数据的时候无需再次发送请求,直接从浏览器本地获取数据
可以通过Chrome
浏览器调试工具中的Network
选项查看浏览器请求资源的情况:
注意不要勾选图中方框内的选项,否则有些请求会被过滤;
Cache-Control
字段服务器可通过httpheader
中的Cache-Control
字段控制客户端与服务器端之间的缓存策略,它的属性值有:
max-age
该字段指定了缓存的最大有效时间,以下为淘宝的一张图片:
在max-age
属性指定的时间未到期前,客户端不会向服务器发起请求,而是从缓存中直接读取该图片。上图中可以看到浏览器直接从ServiceWorker
的缓存中读取了该图片资源。
Expires
字段同样可以指定缓存的有效期,不过这是HTTP1.0
中的字段,优先级比HTTP1.1
中的Cache-Control
字段的max-age
属性低;
s-maxage
缓存设备总体来说有两种:浏览器(客户端)和CDN
服务器;
private
类型缓存设备,表示只有浏览器才可以对资源进行缓存;CDN
服务器属于public
类型缓存设备,这种设备可以对源服务器上的资源进行缓存。并且,这种缓存对于任何用户来说都是可以访问的;s-maxage
的优先级在Expires
和max-age
三者之中是最高的,用于指定public
类型缓存设备(比如CDN
)上资源的有效期。如下图所示,该资源设定了该字段后,浏览器既不会使用浏览器缓存,也不会向服务器请求资源,而是向public
类型的缓存设备(如CDN
服务器)请求资源:
private
服务器端可以通过该属性指定某一资源只能被浏览器(客户端)缓存,而不能被代理缓存服务器(CDN
)缓存。
public
服务器端可以通过该属性指定某一资源,既可以被浏览器缓存,也可以被代理缓存服务器缓存;
no-cache
no-cache
属性规定了浏览器要先向服务器端发送请求确认缓存资源的新鲜度,才能决定是否使用缓存;如下图所示:
no-store
该属性指定了浏览器无论缓存资源是否过期直接跳过缓存,重新向服务器请求资源。no-store
属性用的比较少。
Expires
字段这是http1.0
的规范;它的值为一个绝对时间的GMT
(格林威治标准时间)格式时间字符串,如Mon, 10 Jun 2015 21:31:12 GMT
;
该字段指定了浏览器缓存资源的过期时间,在指定的时间到期前,浏览器可以直接从本地缓存中读取数据,而无需再次向服务器发起请求,属于强缓存;相比于max-age
与s-maxage
优先级最低,在这两个属性存在的情况下Expires
字段会失效;
Last-Modified/If-Modified-Since
二者是基于客户端和服务端协商的缓存机制,标识资源最后更新时间的字段。last-modified
字段位于response header
中,If-Modified-Since
字段位于request header
中,二者配合着Cache-Control
字段使用。
当服务器上的资源发生改变时会同步更新last-modified
的字段值,当Expires
字段或max-age
属性指定的时间到期后,客户端会在请求头中携带If-Modified-Since
字段,与服务器端资源的last-modified
字段值进行比较:
last-modified
字段指定的时间以后都没有发生变化,此时服务器返回状态码304
,属于协商缓存;last-modified
字段值,此时的状态码为200
;举例
下图表示状态码为304
的响应:
If-Modified-Since
字段的值为Mon, 23 Mar 2020 18:14:15 GMT
:Last-Modified
字段的值为Mon, 23 Mar 2020 18:14:15 GMT
:二者相等,说明资源没有发生变化,所以服务器返回状态码304
,属于协商缓存,浏览器继续使用本地缓存;
If-Modified-Since
字段的值就是服务器端上一次响应资源中的Last-Modified
字段值;
Last-Modified
的缺点
GET
;1s
内修改了N
次),If-Modified-Since
能检查到的粒度是s
级的,这种修改无法判断(比如淘宝每ms
都会更新数据);所以有了
Etag/If-None-Match
Etag
字段是HTTP1.1
中的标准,是一个唯一标识服务器端资源的hash
值,该字段存在于响应头(reponse header
)中;与请求头(request header
)中的If-None-Match
字段及Cache-Control
字段配合使用。
只要服务器端的资源发生变化Etag
值就会改变,相比于Last-Modified
字段优先级更高且更有效;当Expires
值或者Cache-Control
字段中的max-age
值到期时,客户端会在请求头中携带If-None-Match
字段,该字段值为服务器端上一次响应资源中的Etag
值,并与服务器端上最新资源的Etag
值进行比较:
304
,属于协商缓存;Etag
值,此时状态码为200
;举例
下图表示状态码为304
的响应:
If-None-Match
字段值为2da25d4039...
:Etag
字段值为2da25d4039...
:二者相等,说明资源没有发生变化,所以服务器返回状态码304
,属于协商缓存,浏览器继续使用本地缓存;
总结:利用
Etag
能够更加准确的控制缓存,因为Etag
是服务器自动生成或者由开发者生成的对应资源在服务器端的唯一标识符;Last-Modified
与ETag
是可以一起使用的,由于Etag
的优先度更高,所以服务器会优先比较Etag
和If-None-Match
。一致的情况下,才会继续比对Last-Modified
和If-Modified-Since
,最后才决定是否返回状态码304
。
200 ok(from memory cache)
;304
通知浏览器从缓存中读取资源;缓存 | 获取资源形式 | 状态码 | 发送请求到服务器 |
---|---|---|---|
强缓存 | 从缓存中获取 |
| 否,直接从缓存中获取 |
协商缓存 | 从缓存中获取 |
| 是,根据服务器返回信息判断缓存是否可用 |
最下层的200
状态
Expires/Cache-Control
字段控制:1.Expires
(HTTP1.0
版本有效)是绝对时间;2.Cache-Control
(HTTP1.1
版本有效)是相对时间; 当两者都存在时,Cache-Control
会覆盖Expires
,只要这些字段没有失效,浏览器都会直接使用本地缓存,属于强缓存;
memory cache
和disk cache
:可以看到,从memory cache
中读取缓存不需要时间,从disk cache
中读取缓存则需要一定时间。
相对时间与绝对时间与服务器的设置有关,当服务器设置
Atime
(最后访问时间)时,二者相等;当服务器设置Mtime
(绝对修改时间)时,Expires
从资源的创建开始计算过期时间,Max-age
从请求发起的时间开始计算过期时间;
下图便是淘宝中采用强缓存的例子,状态码为200
,图片资源都是从浏览器缓存memory cache
中读取,所以请求时间为0ms
:
中间的304
状态
last-modified/Etag
控制。当下一层失效时或用户点击refresh/F5
时,浏览器就会向服务器发起请求,如果服务器上的相关资源没有更新,则返回状态码304
,属于协商缓存;下图便为协商缓存的情况,状态码为304
。也可以这样理解:只要状态码是304
都属于协商缓存:
最上层的200
状态
Ctrl + F5
强制刷新时,浏览器会直接向服务器请求最新的资源;如下图所示:
用户操作 |
|
|
---|---|---|
地址栏回车 | 有效 | 有效 |
页面链接跳转 | 有效 | 有效 |
新开窗口 | 有效 | 有效 |
前进后退 | 有效 | 有效 |
| 无效 | 有效 |
| 无效 | 无效 |
如图所示,该流程图表示服务器端在处理资源时采用缓存策略的过程:
Cache-Control
字段中添加no-store
属性;Cache-Control
字段中添加no-cache
属性,这样不管缓存资源是否过期,都要求客户端或缓存代理服务器首先向服务器确认资源的新鲜度,属于协商缓存;Web
代理缓存资源(比如CDN
服务器缓存),如果允许则在Cache-Control
字段中添加public
属性,并指定代理缓存服务器上资源的有效期s-maxage
;不允许则添加private
属性,表示只能由客户端浏览器缓存资源,并设定缓存的有效期max-age
;CDN
服务器网站通常将其所有的服务器都放在同一个地方,当用户群增加时,公司就必须在多个地理位置不同的服务器上部署内容。为了缩短http
请求的时间,我们应该把大量的静态资源放置的离用户近一点。
内容发布网络CDN
(Content Delivery Networks
)就是其中一种方式。CDN
是一组分布在多个不同地理位置或网段的web
服务器,用于更加有效的向用户发布内容。
CDN
系统能够实时地根据网络流量和各节点的连接、负载状况以及到用户的距离和响应时间等综合信息 将用户的请求重新导向离用户最近的服务节点上。最简单的CDN
网络由一个DNS
服务器和几台缓存服务器组成:
URL
时,经过本地DNS
系统解析,DNS
系统最终会将域名的解析权交给CNAME
指向的CDN
专用的DNS
服务器;关于
DNS
解析,不一定由DNS
服务器响应,一般从缓存中读取。比如电脑缓存、浏览器缓存、路由器缓存、运行商缓存等。如果缓存中没有找到,才一级一级地查询:本地DNS
-> 权限DNS
-> 顶级DNS
-> 根DNS
。全球只有13
台根DNS
服务器。
CDN
的DNS
服务器将CDN
的全局负载均衡设备的IP
地址返回给用户;CDN
的全局负载均衡设备发起内容URL
访问请求;CDN
全局负载均衡设备根据用户的IP
地址,以及用户请求的内容URL
,选择一台用户所属区域的区域负载均衡设备,告诉用户向这台设备发起请求;IP
地址,判断哪一台服务器距用户最近;URL
中携带的内容名称,判断哪一台服务器上有用户所需内容; 基于以上这些条件的综合分析之后,CDN
区域负载均衡设备会向CDN
全局负载均衡设备返回一台CDN
缓存服务器的IP
地址。
CDN
全局负载均衡设备把服务器的IP
地址返回给用户;CDN
缓存服务器发起请求,缓存服务器响应用户请求,将用户所需内容传送到用户终端;如果这台CDN
缓存服务器上并没有用户想要的内容,但是区域均衡设备依然将它分配给了用户,那么这台CDN
服务器就要向它的上一级缓存服务器请求内容,直至追溯到网站的源服务器将内容拉到本地; 站点或者应用中大量静态资源的加速分发,建议将站点内容进行动静分离,动态文件可以结合云服务器ECS
,静态资源如各类型图片、html
、css
、js
文件等,使用CDN
服务器存储,可以有效加速内容加载速度,轻松搞定网站图片、短视频等内容分发。
移动APP
更新文件(apk
文件)分发,移动APP
内图片、页面、短视频、UGC
等内容的优化加速分发。提供httpDNS
服务,避免DNS
劫持并获得实时精确的DNS
解析结果,有效缩短用户访问时间,提升用户体验。
简单点说CDN
服务器相当于顺丰快递分布于全国各地的仓库,主仓库将快递运送到这些分仓库,用户可以就近取货,由此加快了速度。
除此之外CDN
服务器还有许多高级功能,比如防止DDOS
攻击等,这里就不展开了;
SSR(Server Side Rendering)
依赖现代框架如Vue
和React
构建的网站,往往会存在一定的问题,比如Vue
框架。
Vue
渲染面临的问题
首屏渲染时,要先下载和解析app.js
(打包过后的Vue.js
)之后,才能开始渲染页面。
优化方案
Prerender
的方式;通常采用服务端渲染(SSR
)的方式进行优化。所谓SSR
就是利用服务器端优秀的计算能力,将一部分的页面渲染任务交由服务器端进行处理。以下为服务端渲染SSR
的流程图:
服务端渲染可以很好地优化首屏渲染的问题;可以根据业务需求,适当地分配客户端和服务器端的渲染部分,综合利用客户端和服务器端的计算能力,从而达到性能优化的目的。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。