高性能网站搭建前端性能优化-附Vue首屏加载时间优化详细方案

前言事实上, 只有10%-20%的最终用户响应时间是发在从Web服务器获取HTML文档并传送到浏览器中的。如果希望能够有效地减少页面的响应时间,就必须关注剩余80%-90%的最终用户体验。--Steve Souders在这篇博客中,我根据工作中的实际项目经验和一些测试的经验中总结出了前端页面在性能上优化方案。其中一些经验吸收自《高性能网站建设指南》Steve Souders 著 电子工业出版社。 一、 代码相关优化1. 将样式表放在首部-使用link标签将样式表放在文档的HEAD中遵循HTML规范,将样式表放在头部,可以有效避免白屏和无样式内容的闪烁。<!DOCTYPE html><html lang="en"><head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <meta http-equiv="X-UA-Compatible" content="ie=edge"> <title></title> <!-- 使用link标签将样式表放在文档的HEAD中 --> <link rel="stylesheet" href="example.css"></head><body></body></html>2. 将脚本放在底部将脚本放在顶部会造成的影响: 脚本阻塞对其后面内容的显示; 脚本会阻塞对其后面组件的下载;将脚本放在底部</body>标签之前, 类似于document.body.appendChild(yourScript), 不会阻塞页面内容的呈现,而且页面中的可视组件可以尽早下载。<!DOCTYPE html><html lang="en"><head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <meta http-equiv="X-UA-Compatible" content="ie=edge"> <title></title> <link rel="stylesheet" href="example.css"></head><body> <!-- 将脚本放在底部 --> <script src="example.js"></script></body></html>3. 减少HTTP请求1) CSS Sprites (雪碧图)将多个图片合成一张图片,通过background-position来定位所需要的图片。每次请求的话只需要请求一张图片减少http请求。(如果使用图标的话建议使用svg,也可以使用iconfont)合成雪碧图的工具有很多本地工具:https://github.com/iwangx/sprite(国人写的)在线工具https://www.toptal.com/develo...本地工具: 在线工具: 2) 内联图片和脚本通过内联图片和脚本无需额外的HTTP请求,图片小于10K的可以设置内联为base64位。<img src="data:image/jpeg;base64,/9j/4AAQSkZJRgABAQEASABIAAD/4SUJRXhpZgAATU>3) 合并脚本和样式表一般来说,使用外部脚本和样式表对性能更有利,然而如果将模块化的代码分开放到多个小文件中,会降低性能,每个文件都会导致一个额外的HTTP请求4. 使用外部Javascript和cssGood <link rel="stylesheet" href="example.css"><script src="example.js"></script>bad <style>// code</style><script>// code</script>使用外部Javascript和Css的主要作用有: 可以配置缓存 有利于组件重用5. 使用CDN (内容分发网络 Content Delivery Network)CDN是构建在网络之上的内容分发网络,依靠部署在各地的边缘服务器,通过中心平台的负载均衡、内容分发、调度等功能模块,使用户就近获取所需内容,降低网络拥塞,提高用户访问响应速度和命中率。CDN的关键技术主要有内容存储和分发技术。--摘自百度百科通过CDN引入的资源目前基本都是使用目前最新的HTTP2协议,所以在性能上可以做到极致优化,感谢CDN。BootCDN - Bootstrap 中文网开源项目免费 CDN 加速服务UNPKG6. 代码压缩1) Gzip 压缩gzip压缩可以节省50%-70%的网络开销浏览器支持的压缩类型可以通过network的Accept-Encoding: gzip, deflate来查看。支持deflate的浏览器也支持gzip,但很多浏览器支持gzip却不支持deflate,因此gzip是最理想的压缩方法node端 使用compression如果是webpack项目可以看下面的Vue首屏加载时间优化方案里的gzip压缩// npm install compression --save-devconst compression = require('compression')2) 代码压缩前端打包压缩的有grunt,gulp,webpack,可以对HTML,CSS,Javascript代码压缩 ...

May 31, 2019 · 2 min · jiezi

前端性能优化02vue性能优化

一、template语义化标签,避免乱嵌套,合理命名属性等等标准推荐的东西就不谈了。 模板部分帮助我们展示结构化数据,vue 通过数据驱动视图,主要注意一下几点 v-show,v-if 用哪个?在我来看要分两个维度去思考问题,第一个维度是权限问题,只要涉及到权限相关的展示无疑要用 v-if ,第二个维度在没有权限限制下根据用户点击的频次选择,频繁切换的使用 v-show ,不频繁切换的使用 v-if ,这里要说的优化点在于减少页面中 dom 总数,我比较倾向于使用 v-if ,因为减少了 dom 数量,加快首屏渲染,至于性能方面我感觉肉眼看不出来切换的渲染过程,也不会影响用户的体验。不要在模板里面写过多的表达式与判断 v-if="isShow && isAdmin && (a || b)" ,这种表达式虽说可以识别,但是不是长久之计,当看着不舒服时,适当的写到 methods 和 computed 里面封装成一个方法,这样的好处是方便我们在多处判断相同的表达式,其他权限相同的元素再判断展示的时候调用同一个方法即可。循环调用子组件时添加 key。 key 可以唯一标识一个循环个体,可以使用例如 item.id 作为 key,假如数组数据是这样的 ['a' , 'b', 'c', 'a'],使用 :key="item" 显然没有意义,更好的办法就是在循环的时候 (item, index) in arr ,然后 :key="index" 来确保 key 的唯一性。在列表数据进行遍历渲染时,给每一项item设置唯一key值,会方便vuejs内部机制精准找到该条列表数据。当state更新时,新的状态值和旧的状态值对比,较快地定位到diff。二、style将样式文件放在 vue 文件内还是外?讨论起来没有意义,重点是按模块划分,我的习惯是放在 vue 文件内部,方便写代码是在同一个文件里跳转上下对照,无论内外建议加上 <style scoped> 将样式文件锁住,目的很简单,再好用的标准也避免不了多人开发的麻烦,约定命名规则也可能会冲突,锁定区域后尽量采用简短的命名规则,不需要 .header-title__text 之类的 class,直接 .title 搞定。为了和上一条作区分,说下全局的样式文件,全局的样式文件,尽量抽象化,既然不在每一个组件里重复写,就尽量通用,这部分抽象做的越好说明你的样式文件体积越小,复用率越高。建议将复写组件库如 Element 样式的代码也放到全局中去。不使用 float 布局,之前看到很多人封装了 .fl -- float: left 到全局文件里去,然后又要 .clear,现在的浏览器还不至于弱到非要用 float 去兼容,完全可以 flex,grid 兼容性一般,功能其实 flex 布局都可以实现,float 会带来布局上的麻烦,用过的都知道。至于其他通用的规范这里不赘述。三、script这部分也是最难优化的点,说下个人意见吧。 ...

April 30, 2019 · 2 min · jiezi

当考虑网页首屏加速的时候我们在考虑什么

写在前面本文首发于公众号:符合预期的CoyPan首先贴一下参考文章的地址:https://developers.google.com... 最近这段时间,我在做h5的首屏加速相关的工作。首先需要搞清楚的问题就是:首屏加速,到底是要加速什么? 答案可能很简单:加快网页的展现过程。不过再细想一下,网页快不快是针对用户而言的,那么什么样的速度会让用户感到快呢?或者说,哪些指标能够衡量用户所感知的"快"呢? 首屏性能指标我首先想到的衡量指标就是网页开始请求,到页面渲染完成展现在用户眼前,这中间的时间差。现代浏览器都提供了window.performance的api,可以通过window.performance.timing.fetchStart来获取网页开始请求时候的时间戳。页面渲染完成的时间点,可以在页面的业务逻辑中判断。我用这种打点方式统计了业务中某页面的首屏加载时长: (上图中,横坐标是加载耗时,单位是毫秒。纵坐标是各个加载耗时对应的pv数) 上图的数据中,pv总数为90316,首屏加载时长60分位值为:1394ms,90分位值为:2715ms。也就是说,60%的用户能在1394毫秒内看到完整的页面,90%的用户能在2715毫秒内看到完整页面。 在测量首屏时长的时候,为了看到长尾数据的影响,一般会采用分位值的方式,平均数会用来作为参考,毕竟平均数在样本量不够大的情况下,受极大、极小值的影响比较大(比如我和马云平均年薪几个亿)。 首屏性能指标细化上面的数据中,我只是简单的统计了页面整体的首屏耗时。但其实页面加载是一个很复杂的过程。在加载过程中,哪些指标可能会影响到用户的体验呢?谷歌给出了以下的指标: FP:首次绘制。用于标记导航之后浏览器在屏幕上渲染像素的时间点。这个不难理解,就是浏览器开始请求网页到网页首帧绘制的时间点。这个指标表明了网页请求是否成功。FCP:首次内容绘制。FCP 标记的是浏览器渲染来自 DOM 第一位内容的时间点,该内容可能是文本、图像、SVG 甚至 <canvas> 元素。FMP:首次有效绘制。这是一个很主观的指标。根据业务的不同,每一个网站的有效内容都是不相同的,有效内容就是网页中"主角元素"。对于视频网站而言,主角元素就是视频。对于搜索引擎而言,主角元素就是搜索框。TTI:可交互时间。用于标记应用已进行视觉渲染并能可靠响应用户输入的时间点。应用可能会因为多种原因而无法响应用户输入:①页面组件运行所需的JavaScript尚未加载完成。②耗时较长的任务阻塞主线程下面是参考文章中的一个例子,来直观表示上述的四种指标。 怎么测量FP、FCP、FMP、TTI的值明确了上述的几个指标的含义后,下面介绍一下如何测量这几个指标的值。 FP和FCP现代浏览器已经为我们提供了性能测试的api。直接上代码: PerformanceObserver在页面html代码顶部加入以下代码,订阅性能事件。 const observer = new PerformanceObserver((list) => { for (const entry of list.getEntries()) { const metricName = entry.name; const time = Math.round(entry.startTime + entry.duration); console.log(entry); console.log(metricName + ' : ' + time); }});observer.observe({entryTypes: ['paint']});上述代码的输出如下: performance下面的代码也是可以的: window.performance.getEntriesByType('paint'); FMPFMP是一个十分主观的指标,需要开发者自己去测量。像文章一开始说的那样,我们可以在业务逻辑中判断页面加载、渲染完成时记录一个时间戳,然后和window.performance.timing.fetchStart相减,来得到FMP。 TTITTI也是一个较为主观的指标。浏览器并没有为这个指标提供api。不过google提供了polyfill。下面是使用方法。 在页面html顶部加入: !function(){if('PerformanceLongTaskTiming' in window){var g=window.__tti={e:[]};g.o=new PerformanceObserver(function(l){g.e=g.e.concat(l.getEntries())});g.o.observe({entryTypes:['longtask']})}}();install这个polyfill, npm install tti-polyfill在业务代码中引用: ...

April 25, 2019 · 1 min · jiezi

你真的了解回流和重绘吗

回流和重绘可以说是每一个web开发者都经常听到的两个词语,我也不例外,可是我之前一直不是很清楚这两步具体做了什么事情。最近由于部门内部要做分享,所以对其进行了一些研究,看了一些博客和书籍,整理了一些内容并且结合一些例子,写了这篇文章,希望可以帮助到大家。浏览器的渲染过程本文先从浏览器的渲染过程来从头到尾的讲解一下回流重绘,如果大家想直接看如何减少回流和重绘,可以跳到后面。(这个渲染过程来自MDN)从上面这个图上,我们可以看到,浏览器渲染过程如下:解析HTML,生成DOM树,解析CSS,生成CSSOM树将DOM树和CSSOM树结合,生成渲染树(Render Tree)Layout(回流):根据生成的渲染树,进行回流(Layout),得到节点的几何信息(位置,大小)Painting(重绘):根据渲染树以及回流得到的几何信息,得到节点的绝对像素Display:将像素发送给GPU,展示在页面上。(这一步其实还有很多内容,比如会在GPU将多个合成层合并为同一个层,并展示在页面中。而css3硬件加速的原理则是新建合成层,这里我们不展开,之后有机会会写一篇博客)渲染过程看起来很简单,让我们来具体了解下每一步具体做了什么。生成渲染树为了构建渲染树,浏览器主要完成了以下工作:从DOM树的根节点开始遍历每个可见节点。对于每个可见的节点,找到CSSOM树中对应的规则,并应用它们。根据每个可见节点以及其对应的样式,组合生成渲染树。第一步中,既然说到了要遍历可见的节点,那么我们得先知道,什么节点是不可见的。不可见的节点包括:一些不会渲染输出的节点,比如script、meta、link等。一些通过css进行隐藏的节点。比如display:none。注意,利用visibility和opacity隐藏的节点,还是会显示在渲染树上的。只有display:none的节点才不会显示在渲染树上。注意:渲染树只包含可见的节点回流前面我们通过构造渲染树,我们将可见DOM节点以及它对应的样式结合起来,可是我们还需要计算它们在设备视口(viewport)内的确切位置和大小,这个计算的阶段就是回流。为了弄清每个对象在网站上的确切大小和位置,浏览器从渲染树的根节点开始遍历,我们可以以下面这个实例来表示:<!DOCTYPE html><html> <head> <meta name=“viewport” content=“width=device-width,initial-scale=1”> <title>Critial Path: Hello world!</title> </head> <body> <div style=“width: 50%"> <div style=“width: 50%">Hello world!</div> </div> </body></html>我们可以看到,第一个div将节点的显示尺寸设置为视口宽度的50%,第二个div将其尺寸设置为父节点的50%。而在回流这个阶段,我们就需要根据视口具体的宽度,将其转为实际的像素值。(如下图)重绘最终,我们通过构造渲染树和回流阶段,我们知道了哪些节点是可见的,以及可见节点的样式和具体的几何信息(位置、大小),那么我们就可以将渲染树的每个节点都转换为屏幕上的实际像素,这个阶段就叫做重绘节点。既然知道了浏览器的渲染过程后,我们就来探讨下,何时会发生回流重绘。何时发生回流重绘我们前面知道了,回流这一阶段主要是计算节点的位置和几何信息,那么当页面布局和几何信息发生变化的时候,就需要回流。比如以下情况:添加或删除可见的DOM元素元素的位置发生变化元素的尺寸发生变化(包括外边距、内边框、边框大小、高度和宽度等)内容发生变化,比如文本变化或图片被另一个不同尺寸的图片所替代。页面一开始渲染的时候(这肯定避免不了)浏览器的窗口尺寸变化(因为回流是根据视口的大小来计算元素的位置和大小的)注意:回流一定会触发重绘,而重绘不一定会回流根据改变的范围和程度,渲染树中或大或小的部分需要重新计算,有些改变会触发整个页面的重排,比如,滚动条出现的时候或者修改了根节点。浏览器的优化机制现代的浏览器都是很聪明的,由于每次重排都会造成额外的计算消耗,因此大多数浏览器都会通过队列化修改并批量执行来优化重排过程。浏览器会将修改操作放入到队列里,直到过了一段时间或者操作达到了一个阈值,才清空队列。但是!当你获取布局信息的操作的时候,会强制队列刷新,比如当你访问以下属性或者使用以下方法:offsetTop、offsetLeft、offsetWidth、offsetHeightscrollTop、scrollLeft、scrollWidth、scrollHeightclientTop、clientLeft、clientWidth、clientHeightgetComputedStyle()getBoundingClientRect具体可以访问这个网站:https://gist.github.com/pauli…以上属性和方法都需要返回最新的布局信息,因此浏览器不得不清空队列,触发回流重绘来返回正确的值。因此,我们在修改样式的时候,最好避免使用上面列出的属性,他们都会刷新渲染队列。如果要使用它们,最好将值缓存起来。减少回流和重绘好了,到了我们今天的重头戏,前面说了这么多背景和理论知识,接下来让我们谈谈如何减少回流和重绘。最小化重绘和重排由于重绘和重排可能代价比较昂贵,因此最好就是可以减少它的发生次数。为了减少发生次数,我们可以合并多次对DOM和样式的修改,然后一次处理掉。考虑这个例子const el = document.getElementById(’test’);el.style.padding = ‘5px’;el.style.borderLeft = ‘1px’;el.style.borderRight = ‘2px’;例子中,有三个样式属性被修改了,每一个都会影响元素的几何结构,引起回流。当然,大部分现代浏览器都对其做了优化,因此,只会触发一次重排。但是如果在旧版的浏览器或者在上面代码执行的时候,有其他代码访问了布局信息(上文中的会触发回流的布局信息),那么就会导致三次重排。因此,我们可以合并所有的改变然后依次处理,比如我们可以采取以下的方式:使用cssTextconst el = document.getElementById(’test’);el.style.cssText += ‘border-left: 1px; border-right: 2px; padding: 5px;’;修改CSS的classconst el = document.getElementById(’test’);el.className += ’ active’;批量修改DOM当我们需要对DOM对一系列修改的时候,可以通过以下步骤减少回流重绘次数:使元素脱离文档流对其进行多次修改将元素带回到文档中。该过程的第一步和第三步可能会引起回流,但是经过第一步之后,对DOM的所有修改都不会引起回流,因为它已经不在渲染树了。有三种方式可以让DOM脱离文档流:隐藏元素,应用修改,重新显示使用文档片段(document fragment)在当前DOM之外构建一个子树,再把它拷贝回文档。将原始元素拷贝到一个脱离文档的节点中,修改节点后,再替换原始的元素。考虑我们要执行一段批量插入节点的代码:function appendDataToElement(appendToElement, data) { let li; for (let i = 0; i < data.length; i++) { li = document.createElement(’li’); li.textContent = ’text’; appendToElement.appendChild(li); }}const ul = document.getElementById(’list’);appendDataToElement(ul, data);如果我们直接这样执行的话,由于每次循环都会插入一个新的节点,会导致浏览器回流一次。我们可以使用这三种方式进行优化:隐藏元素,应用修改,重新显示这个会在展示和隐藏节点的时候,产生两次重绘function appendDataToElement(appendToElement, data) { let li; for (let i = 0; i < data.length; i++) { li = document.createElement(’li’); li.textContent = ’text’; appendToElement.appendChild(li); }}const ul = document.getElementById(’list’);ul.style.display = ’none’;appendDataToElement(ul, data);ul.style.display = ‘block’;使用文档片段(document fragment)在当前DOM之外构建一个子树,再把它拷贝回文档const ul = document.getElementById(’list’);const fragment = document.createDocumentFragment();appendDataToElement(fragment, data);ul.appendChild(fragment);将原始元素拷贝到一个脱离文档的节点中,修改节点后,再替换原始的元素。const ul = document.getElementById(’list’);const clone = ul.cloneNode(true);appendDataToElement(clone, data);ul.parentNode.replaceChild(clone, ul);对于上述那种情况,我写了一个demo来测试修改前和修改后的性能。然而实验结果不是很理想。原因:原因其实上面也说过了,浏览器会使用队列来储存多次修改,进行优化,所以对这个优化方案,我们其实不用优先考虑。避免触发同步布局事件上文我们说过,当我们访问元素的一些属性的时候,会导致浏览器强制清空队列,进行强制同步布局。举个例子,比如说我们想将一个p标签数组的宽度赋值为一个元素的宽度,我们可能写出这样的代码:function initP() { for (let i = 0; i < paragraphs.length; i++) { paragraphs[i].style.width = box.offsetWidth + ‘px’; }}这段代码看上去是没有什么问题,可是其实会造成很大的性能问题。在每次循环的时候,都读取了box的一个offsetWidth属性值,然后利用它来更新p标签的width属性。这就导致了每一次循环的时候,浏览器都必须先使上一次循环中的样式更新操作生效,才能响应本次循环的样式读取操作。每一次循环都会强制浏览器刷新队列。我们可以优化为:const width = box.offsetWidth;function initP() { for (let i = 0; i < paragraphs.length; i++) { paragraphs[i].style.width = width + ‘px’; }}同样,我也写了个demo来比较两者的性能差异。你可以自己点开这个demo体验下。这个对比差距就比较明显。对于复杂动画效果,使用绝对定位让其脱离文档流对于复杂动画效果,由于会经常的引起回流重绘,因此,我们可以使用绝对定位,让它脱离文档流。否则会引起父元素以及后续元素频繁的回流。这个我们就直接上个例子。打开这个例子后,我们可以打开控制台,控制台上会输出当前的帧数(虽然不准)。从上图中,我们可以看到,帧数一直都没到60。这个时候,只要我们点击一下那个按钮,把这个元素设置为绝对定位,帧数就可以稳定60。css3硬件加速(GPU加速)比起考虑如何减少回流重绘,我们更期望的是,根本不要回流重绘。这个时候,css3硬件加速就闪亮登场啦!!划重点:使用css3硬件加速,可以让transform、opacity、filters这些动画不会引起回流重绘 。但是对于动画的其它属性,比如background-color这些,还是会引起回流重绘的,不过它还是可以提升这些动画的性能。本篇文章只讨论如何使用,暂不考虑其原理,之后有空会另外开篇文章说明。如何使用常见的触发硬件加速的css属性:transformopacityfiltersWill-change效果我们可以先看个例子。我通过使用chrome的Performance捕获了一段时间的回流重绘情况,实际结果如下图:从图中我们可以看出,在动画进行的时候,没有发生任何的回流重绘。如果感兴趣你也可以自己做下实验。重点使用css3硬件加速,可以让transform、opacity、filters这些动画不会引起回流重绘对于动画的其它属性,比如background-color这些,还是会引起回流重绘的,不过它还是可以提升这些动画的性能。css3硬件加速的坑如果你为太多元素使用css3硬件加速,会导致内存占用较大,会有性能问题。在GPU渲染字体会导致抗锯齿无效。这是因为GPU和CPU的算法不同。因此如果你不在动画结束的时候关闭硬件加速,会产生字体模糊。总结本文主要讲了浏览器的渲染过程、浏览器的优化机制以及如何减少甚至避免回流和重绘,希望可以帮助大家更好的理解回流重绘。参考文献渲染树构建、布局及绘制高性能Javascript本文地址在->本人博客地址, 欢迎给个 start 或 follow ...

December 11, 2018 · 1 min · jiezi