对于前端性能优化的理解与实践

先从一道题目说起

从输入 URL 到页面加载完成,发生了什么?

站在性能优化的角度;我们可以分为5个过程;

  • DNS 解析

  • TCP 连接

  • HTTP 请求抛出

  • 服务端处理请求,HTTP 响应返回

  • 浏览器拿到响应数据,解析响应内容,把解析的结果展示给用户

  • 我们从这五个过程个个击破;


    dns解析花时间,tcp连接慢;这些需要我们的服务端解决;
    那么我们的前端工程师在HTTP请求或者浏览器端能做一些什么优化呢?
    http方面前端可以减少请求次数,压缩体积;
    浏览器前端可以做的事情比较多了,例如资源加载优化、服务端渲染、浏览器缓存机制的利用、DOM 树的构建、网页排版和渲染过程、回流与重绘的考量、DOM 操作的合理规避

网络层面(http请求优化and减少网络请求)

webpack打包体积优化
  • webpack-bundle-analyzer 是一款包可视化工具,可以找出体积大的模块;

  • 删除冗余代码 webpack3可以使用UglifyJsPlugin ;webpack4已经自带了,只需要配置下;

  • 按需加载 vue项目可以用require.ensure来实现

  • gzip 本来是服务端的工作,webpack也有gzip可以帮助服务端减轻压力

图片
  • JPEG/JPG:有损压缩、体积小、加载快、不支持透明;庞大的图片用jpg

  • PNG-8 与 PNG-24:无损压缩、质量高、体积大、支持透明 像logo类等比较突出的最好用png

  • SVG (字体图标):文本文件、体积小、不失真、兼容性好

  • Base64 :文本文件、依赖编码、小图标解决方案,Base64 是作为雪碧图的补充而存在的;Base64 编码后,图片大小会膨胀为原文件的 4/3;在传输非常小的图片的时候,Base64 带来的文件体积膨胀、以及浏览器解析 Base64 的时间开销,与它节省掉的 HTTP 请求开销相比,可以忽略不计

  • CSS Sprites(精灵图/雪碧图):小图标解决方案

  • WebP :与 PNG 相比,WebP 无损图像的尺寸缩小了 26%。限制WebP发展的是浏览器兼容问题;

浏览器缓存
  • Memory Cache 内存缓存是快的,也是“短命”的。

  • Service Worker Cache 帮我们实现离线缓存、消息推送和网络代理等功能,但必需以https 协议为前提

  • Push Cache HTTP2存在,Push Cache 是缓存的最后一道防线,会话阶段的缓存;

  • HTTP Cache (主要、最具有代表性的)

HTTP缓存分为强缓存和协商缓存
强缓存:Expires 和 Cache-Control (http1.1新增)两个字段来控制
expires 能做的事情,Cache-Control 都能做;expires 完成不了的事情,Cache-Control 也能做。因此,Cache-Control 可以视作是 expires 的完全替代方案。Cache-Control 相对于 expires 更加准确,它的优先级也更高。当 Cache-Control 与 expires 同时出现时,我们以 Cache-Control 为准。

public 与 private 是针对资源是否能够被代理服务缓存而存在的一组对立概念。

no-cache 绕开了浏览器:我们为资源设置了 no-cache 后,每一次发起请求都不会再去询问浏览器的缓存情况,而是直接向服务端去确认该资源是否过期;no-store 比较绝情,顾名思义就是不使用任何缓存策略。在 no-cache 的基础上,它连服务端的缓存确认也绕开了,只允许你直接向服务端发送请求、并下载完整的响应。

协商缓存:协商缓存机制下,浏览器需要向服务器去询问缓存的相关信息,进而判断是重新发起请求、下载完整的响应,还是从本地获取缓存的资源。资源会被重定向到浏览器缓存,这种情况下网络请求对应的状态码是 304

当我们的资源内容不可复用时,直接为 Cache-Control 设置 no-store,拒绝一切形式的缓存;否则考虑是否每次都需要向服务器进行缓存有效确认,如果需要,那么设 Cache-Control 的值为 no-cache;否则考虑该资源是否可以被代理服务器缓存,根据其结果决定是设置为 private 还是 public;然后考虑该资源的过期时间,设置对应的 max-age 和 s-maxage 值;最后,配置协商缓存需要用到的 Etag、Last-Modified 等参数。

本地存储
  • cookie  只能存储4KB ,紧跟域名的

  • Web  Storage Local Storage和Session Storage 这两个对前端来说很熟悉了;

  • IndexDB 运行在浏览器上的非关系型数据库;IndexDB 是没有存储上限的(一般来说不会小于 250M)

cdn
  • 内容分发网络

  • 缓存和回源。

缓存”就是说我们把资源 copy 一份到 CDN 服务器上这个过程,“回源”就是说 CDN 发现自己没有这个资源(一般是缓存的数据过期了),转头向根服务器(指业务服务器)或者它的上层服务器去要这个资源的过程。

  • CDN 往往被用来存放静态资源

所谓“静态资源”,就是像 JS、CSS、图片等不需要业务服务器进行计算即得的资源。而“动态资源”,顾名思义是需要后端实时动态生成的资源,较为常见的就是 JSP、ASP 或者依赖服务端渲染得到的 HTML 页面。

  • 性能优化方面的应用

同一个域名下的请求会不分青红皂白地携带 Cookie,而静态资源往往并不需要 Cookie 携带什么认证信息。把静态资源和主页面置于不同的域名下,完美地避免了不必要的 Cookie 的出现!

服务端渲染(SSR)
  • 客户端渲染:需要把js文件跑完,生成对应的dom树;

  • 服务端渲染:直接拿到服务端放回的html就可以呈现在用户面前

  • 质上是本该浏览器做的事情,分担给服务器去做。这样当资源抵达浏览器时,它呈现的速度就快了。

CSSOM,JS的优化
浏览器背后的运行机制


CSS 选择符是从右到左进行匹配的

避免使用通配符,只对需要用到的元素进行选择。
关注可以通过继承实现的属性,避免重复匹配重复定义。
少用标签选择器。如果可以,用类选择器替代
不要画蛇添足,id 和 class 选择器不应该被多余的标签选择器拖后腿。
减少嵌套。后代选择器的开销是最高的,因此我们应该尽量将选择器的深度降到最低

JS的加载方式

正常模式 <script src="index.js"></script>
async 模式 <script async src="index.js"></script>
defer 模式 <script defer src="index.js"></script>
defer 模式下,JS 的加载是异步的,执行是被推迟的。等整个文档解析完成、DOMContentLoaded 事件即将被触发时,被标记了 defer 的 JS 文件才会开始依次执行。
从应用的角度来说,一般当我们的脚本与 DOM 元素和其它脚本之间的依赖关系不强时,我们会选用 async;当脚本依赖于 DOM 元素和其它脚本的执行结果时,我们会选用 defer。

DOM的优化
  • 回流和重绘

回流:当我们对 DOM 的修改引发了 DOM 几何尺寸的变化(比如修改元素的宽、高或隐藏元素等)时,浏览器需要重新计算元素的几何属性(其他元素的几何属性和位置也会因此受到影响),然后再将计算的结果绘制出来。这个过程就是回流(也叫重排)。
重绘:当我们对 DOM 的修改导致了样式的变化、却并未影响其几何属性(比如修改了颜色或背景色)时,浏览器不需重新计算元素的几何属性、直接为该元素绘制新的样式(跳过了上图所示的回流环节)。这个过程叫做重绘。
由此我们可以看出,重绘不一定导致回流,回流一定会导致重绘。我们对dom的优化主要在于减少DOM操作;

  • 回流的“导火索”

改变 DOM 元素的几何属性
改变 DOM 树的结构
获取一些特定属性的值:offsetTop、offsetLeft、 offsetWidth、offsetHeight、scrollTop、scrollLeft、scrollWidth、scrollHeight、clientTop、clientLeft、clientWidth、clientHeight...

  • 规避回流与重绘

js先用变量保存好要计算的值,最终再设置dom
避免逐条改变样式,使用类名去合并样式
将 DOM “离线”,先设置display:none;中间操作,后面再设置display:block;

  • 浏览器Flush 队列

  • DOM Fragment 需要了解一下

本质上是作为脱离了真实 DOM 树的容器出现,用于缓存批量化的 DOM 操作

Event Loop 与异步更新策略
  • macro(洪任务):setTimeout、setInterval、 setImmediate、script(整体代码)、 I/O 操作、UI 渲染等。

  • micro-task(微任务): process.nextTick、Promise、MutationObserver

当我们需要在异步任务中实现 DOM 修改时,把它包装成 micro 任务是相对明智的选择。

  • Vue状态更新手法:nextTick

export function nextTick (cb?: Function, ctx?: Object) {  let _resolve
  callbacks.push(() => {
    if (cb) {
      try {
        cb.call(ctx)
      } catch (e) {
        handleError(e, ctx, 'nextTick')
      }
    } else if (_resolve) {
      _resolve(ctx)
    }
  })


  if (!pending) {
    pending = true
     if (useMacroTask) {
      macroTimerFunc()
    } else {
       microTimerFunc()
    }
  }
  // $flow-disable-line
  if (!cb && typeof Promise !== 'undefined') {
    return new Promise(resolve => {
      _resolve = resolve
    })
  }
}

实际上也是运用了promise

lazy-load(懒加载)

在懒加载的实现中,有两个关键的数值:一个是当前可视区域的高度,另一个是元素距离可视区域顶部的高度。

事件的节流(throttle)与防抖(debounce)

像scroll,resize,keyup等事件频繁触发会引发页面的抖动甚至卡顿
节流”与“防抖”是以闭包的形式来实现的;
它们通过对事件对应的回调函数进行包裹、以自由变量的形式缓存时间信息,最后用 setTimeout 来控制事件的触发频率。

  • 节流和防抖结合体

// fn是我们需要包装的事件回调, delay是时间间隔的阈值function throttle(fn, delay) {
  // last为上一次触发回调的时间, timer是定时器
  let last = 0, timer = null
  // 将throttle处理结果当作函数返回
  
  return function () {
    // 保留调用时的this上下文
    let context = this
    // 保留调用时传入的参数
    let args = arguments
    // 记录本次触发回调的时间
    let now = +new Date()
    
    // 判断上次触发的时间和本次触发的时间差是否小于时间间隔的阈值
    if (now - last < delay) {
    // 如果时间间隔小于我们设定的时间间隔阈值,则为本次触发操作设立一个新的定时器
       clearTimeout(timer)
       timer = setTimeout(function () {
          last = now
          fn.apply(context, args)
        }, delay)
    } else {
        // 如果时间间隔超出了我们设定的时间间隔阈值,那就不等了,无论如何要反馈给用户一次响应
        last = now
        fn.apply(context, args)
    }
  }
}


// 用新的throttle包装scroll的回调
document.addEventListener('scroll', throttle(() => console.log('触发了滚动事件'), 1000))


谷歌浏览器自带的Performance以及浏览器插件LightHouse可以监测网站性能;



作者:QRFF
链接:https://www.jianshu.com/p/f326f33ef5cd
来源:简书
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值