前端性能优化

  • 2021-12-29
  • 次

目的

  1. 从用户角度而言，优化能够让页面加载得更快、对用户的操作响应得更及时，能够给用户提供更为友好的体验。
  2. 从服务商角度而言，优化能够减少页面请求数、或者减小请求所占带宽，能够节省可观的资源。

总之，恰当的优化不仅能够改善站点的用户体验并且能够节省相当的资源利用。

途径

前端优化的途径有很多，按粒度大致可以分为两类。

  • 页面级别的优化，例如 HTTP请求数、脚本的无阻塞加载、内联脚本的位置优化等 ;
  • 代码级别的优化，例如 Javascript中的DOM 操作优化、CSS选择符优化、图片优化以及 HTML结构优化等等。

实现方案

一、页面级优化

  1. DNS优化
  • 减少DNS请求次数。最理想的方法就是将所有的内容资源（页面、脚本、样式表、图片等）都放在同一个域(Domain)下面，这样访问整个网站就只需要进行一次DNS查找，这样可以提高性能。
  • DNS预获取。DOM还没开始，浏览器预解析地址，把解析好的地址放在本地缓存里面，DOM树生成完，要加载图片类的发现DNS已经解析好了，再发送请求。主要用于图片资源等。
    1
    <link rel='dns-prefetch' href='//dfns.tanx.com'> // 此代码预获取dfns.tanx.com这个域名的IP地址
  • 利用DNS负载均衡技术。一个网站如果只有一个服务器，访问量过大时很容易挂掉。DNS负载均衡技术的实现原理是在DNS服务器中为同一个主机名配置多个IP地址，在应答DNS查询时，DNS服务器会根据每台机器的负载量、与用户的距离等情况返回不同的解析结果，将客户端的访问引导到不同的机器上去，使得不同的客户端访问不同的服务器，从而达到负载均衡的目的。该技术常见的应用是CDN（Content Delivery Network）。
  1. 优化HTTP请求
  • preload和prefetch
  • 合理设置HTTP缓存
    怎样才算合理设置？原则很简单，能缓存越多越好，能缓存越久越好。例如，很少变化的图片资源可以直接通过 HTTP Header中的Expires/max-age设置一个很长的过期头；变化不频繁而又可能会变的资源可以使用Last-Modifed/etag来做请求验证。尽可能的让资源能够在缓存中待得更久。
  • 使用http2
    http2有多路复用、头部压缩等功能，能极大的减少http(s)的请求开销，不过需要在https下使用。
  • 资源合并与压缩
    如果可以的话，尽可能的将外部的脚本、样式进行合并，多个合为一个。另外， CSS、 Javascript、Image 都可以用相应的工具进行压缩，压缩后往往能省下不少空间。
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    #开启和关闭gzip模式
    gzip on;
    #gizp压缩起点，文件大于1k才进行压缩
    gzip_min_length 1k;
    # gzip 压缩级别，1-9，数字越大压缩的越好，也越占用CPU时间
    gzip_comp_level 6;
    # 进行压缩的文件类型。
    gzip_types text/plain application/javascript application/x-javascript text/css application/xml text/javascript ;
    #nginx对于静态文件的处理模块，开启后会寻找以.gz结尾的文件，直接返回，不会占用cpu进行压缩，如果找不到则不进行压缩
    gzip_static on
    # 是否在http header中添加Vary: Accept-Encoding，建议开启
    gzip_vary on;
    # 设置gzip压缩针对的HTTP协议版本
    gzip_http_version 1.1;
  • CSS Sprites
    　　合并 CSS图片，减少请求数的又一个好办法。
  • Inline Images
    　　使用 data: URL scheme的方式将图片嵌入到页面或 CSS中，如果不考虑资源管理上的问题的话，不失为一个好办法。如果是嵌入页面的话换来的是增大了页面的体积，而且无法利用浏览器缓存。使用在 CSS中的图片则更为理想一些。
  • 图片懒加载
    这条策略实际上并不一定能减少 HTTP请求数，但是却能在某些条件下或者页面刚加载时减少 HTTP请求数。对于图片而言，在页面刚加载的时候可以只加载第一屏，当用户继续往后滚屏的时候才加载后续的图片。这样一来，假如用户只对第一屏的内容感兴趣时，那剩余的图片请求就都节省了。

  1. 将外部脚本置底，将css放在HEAD中

    js的下载和执行会阻塞dom解析，也就是会阻塞页面的渲染，css也有可能会阻塞页面的渲染（因为js执行前会下载css）。
    如果把CSS放在文档的最后面加载执行，CSS不会阻塞DOM的生成，但是浏览器在解析完DOM后，要花费额外时间来解析CSS，而不是在解析DOM的时候，并行解析CSS。
    并且浏览器会先渲染出一个没有样式的页面，等CSS加载完后会再渲染成一个有样式的页面，页面会出现明显的闪动的现象。
    所以应该把CSS放在文档的头部，尽可能的提前加载CSS；把JS放在文档的尾部，这样JS也不会阻塞页面的渲染。CSS会和JS并行解析，CSS解析也尽可能的不去阻塞JS的执行，从而使页面尽快的渲染完成。

  2. 异步执行脚本

  • defer和async
  • setTimeout等
  • Web Workers

  1. Lazy Load Javascript

    随着 Javascript框架的流行，越来越多的站点也使用起了框架。不过，一个框架往往包括了很多的功能实现，这些功能并不是每一个页面都需要的，如果下载了不需要的脚本则算得上是一种资源浪费 -既浪费了带宽又浪费了执行花费的时间。目前的做法大概有两种，一种是为那些流量特别大的页面专门定制一个专用的 mini版框架，另一种则是 Lazy Load。YUI 则使用了第二种方式，在 YUI的实现中，最初只加载核心模块，其他模块可以等到需要使用的时候才加载。

  2. 减少不必要的 HTTP跳转

    对于以目录形式访问的HTTP链接，很多人都会忽略链接最后是否带 ‘/‘，假如你的服务器对此是区别对待的话，那么你也需要注意，这其中很可能隐藏了301跳转，增加了多余请求。具体参见下图，其中第一个链接是以无’/‘结尾的方式访问的，于是服务器有了一次跳转。

  3. 避免重复的资源请求

    这种情况主要是由于疏忽或页面由多个模块拼接而成，然后每个模块中请求了同样的资源时，会导致资源的重复请求

二、代码级优化

  1. Javascript

  • DOM

    DOM操作应该是脚本中最耗性能的一类操作，例如增加、修改、删除 DOM元素或者对 DOM集合进行操作。如果脚本中包含了大量的 DOM操作则需要注意以下几点：

    • a. HTML Collection（HTML收集器，返回的是一个数组内容信息）

      　　在脚本中 document.images、document.forms 、getElementsByTagName()返回的都是 HTMLCollection类型的集合，在平时使用的时候大多将它作为数组来使用，因为它有length属性，也可以使用索引访问每一个元素。不过在访问性能上则比数组要差很多，原因是这个集合并不是一个静态的结果，它表示的仅仅是一个特定的查询，每次访问该集合时都会重新执行这个查询从而更新查询结果。所谓的 “访问集合” 包括读取集合的 length属性、访问集合中的元素。因此，当你需要遍历 HTML Collection的时候，尽量将它转为数组后再访问，以提高性能。即使不转换为数组，也请尽可能少的访问它，例如在遍历的时候可以将 length属性、成员保存到局部变量后再使用局部变量。
    • b. Reflow & Repaint

      　　除了上面一点之外， DOM操作还需要考虑浏览器的 Reflow和Repaint ，因为这些都是需要消耗资源的。

  • 慎用 with

    with(obj){ p = 1}; 代码块的行为实际上是修改了代码块中的 执行环境 ，将obj放在了其作用域链的最前端，在 with代码块中访问非局部变量是都是先从 obj上开始查找，如果没有再依次按作用域链向上查找，因此使用 with相当于增加了作用域链长度。而每次查找作用域链都是要消耗时间的，过长的作用域链会导致查找性能下降。
    　　因此，除非你能肯定在 with代码中只访问 obj中的属性，否则慎用 with，替代的可以使用局部变量缓存需要访问的属性。

  • 避免使用 eval和 Function
    　　每次 eval 或 Function 构造函数作用于字符串表示的源代码时，脚本引擎都需要将源代码转换成可执行代码。这是很消耗资源的操作 —— 通常比简单的函数调用慢 100倍以上。
    　　eval 函数效率特别低，由于事先无法知晓传给 eval 的字符串中的内容，eval在其上下文中解释要处理的代码，也就是说编译器无法优化上下文，因此只能有浏览器在运行时解释代码。这对性能影响很大。
    　　Function 构造函数比 eval略好，因为使用此代码不会影响周围代码 ;但其速度仍很慢。
    　　此外，使用 eval和 Function也不利于Javascript 压缩工具执行压缩。

  • 减少作用域链查找（这方面设计到一些内容的相关问题）
    　　前文谈到了作用域链查找问题，这一点在循环中是尤其需要注意的问题。如果在循环中需要访问非本作用域下的变量时请在遍历之前用局部变量缓存该变量，并在遍历结束后再重写那个变量，这一点对全局变量尤其重要，因为全局变量处于作用域链的最顶端，访问时的查找次数是最多的。

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    　　低效率的写法：
    // 全局变量 
    var globalVar = 1; 
    function myCallback(info){ 
        for( var i = 100000; i--;){ 
        //每次访问 globalVar 都需要查找到作用域链最顶端，本例中需要访问 100000 次 
            globalVar += i; 
        }
    } 
    　　更高效的写法：
    // 全局变量 
    var globalVar = 1; 
    function myCallback(info){ 
        // 局部变量缓存全局变量 
        var localVar = globalVar; 
        for( var i = 100000; i--;){ 
        //访问局部变量是最快的 
        localVar += i; 
        } 
        // 本例中只需要访问 2次全局变量
    在函数中只需要将 globalVar中内容的值赋给localVar 中区
        globalVar = localVar; 
    }

    此外，要减少作用域链查找还应该减少闭包的使用。

  • 数据访问

    Javascript中的数据访问包括直接量 (字符串、正则表达式 )、变量、对象属性以及数组，其中对直接量和局部变量的访问是最快的，对对象属性以及数组的访问需要更大的开销。当出现以下情况时，建议将数据放入局部变量：

    • a. 对任何对象属性的访问超过 1次
    • b. 对任何数组成员的访问次数超过 1次
      另外，还应当尽可能的减少对对象以及数组深度查找。

  • 利用防抖和节流函数

    降低事件监听回调频率

  1. CSS

  • css选择符
    在大多数人的观念中，都觉得浏览器对CSS选择符的解析式从左往右进行的，例如#toc A { color: #444; }这样一个选择符，如果是式从左往右解析则效率会很高，因为第一个 ID选择基本上就把查找的范围限定了，但实际上浏览器对选择符的解析是从右往左进行的。如上面的选择符，浏览器必须遍历查找每一个 A标签的祖先节点，效率并不像之前想象的那样高。根据浏览器的这一行为特点，在写选择符的时候需要注意很多事项，有人已经一一列举了， 详情参考此处。

  • 减少重绘和重排
    特别是重排，因为重排一定会触发重绘。具体如:

    • 基于vue/react等框架开发（虚拟dom和diff算法减少了重绘和重排）；
    • 样式集中改变（利用当代浏览器的渲染队列机制将修改样式的代码写在一起，代码中间不要穿插无关样式修改的代码）；样式批量修改（如使用classname改变样式，或者box.style.cssText）；
    • 样式读写分开；利用document.createDocumentFragment生成文档碎片批量插入dom元素或利用document.innerHTML插入多个dom string；
    • 动画效果应用到position属性为absolute/fixed元素上（脱离文档流，减少对其他元素的影响）；
    • 利用css3硬件加速（transform、opacity、filters，触发硬件加速，不触发重绘重排）；尽量避免table布局（不好计算位置和大小）等等

【参考】

前端性能优化方案都有哪些？

我是如何让公司后台管理系统焕然一新的(上) -性能优化

感谢您的阅读，本文由 Astar 版权所有。如若转载，请注明出处：Astar（http://example.com/2021/12/29/%E5%89%8D%E7%AB%AF%E6%80%A7%E8%83%BD%E4%BC%98%E5%8C%96/）
css基础篇（汇总）
自动部署hexo博客