其他分享
首页 > 其他分享> > Web优化躬行记（6）——优化闭环实践

Web优化躬行记（6）——优化闭环实践

作者：互联网

　　在遇到一个页面性能问题时，我理解的优化闭环是：分析、策略、验证和沉淀。

　　这其中非常关键的一步是需要采集到性能数据，并且得有个可视化后台查看数据变化。

　　在之前已经自制了一个性能优化平台，采集前端性能参数的 SDK 叫 shin.js。

一、优化的三部分

　　在文章开头，我想先聊聊网页优化的三部分：网络，渲染和容器。

　　第一部分的网络就是提升传输速度，可优化的手段包括 gzipped压缩、CDN、HTTP 缓存、HTTP 2.0协议、并发请求等。

　　像 HTTP 缓存分为强缓存和协商缓存，请求首部和浏览器配合完成资源的缓存机制，下图摘自《前端程序员面试笔试宝典》。

　　

　　第二部分的渲染就是 CRP 优化（关键渲染路径），CRP 是指浏览器从接收资源到渲染像素的过程。

　　优化的点包括资源数、字节数和加载时序。现代化的 webpack 构建工具就会对资源做前两项的优化处理，包括压缩文件、合并文件、优化包的引入等。

　　加载时序就包括日常都会用的图片懒加载和预加载、脚本的延迟（defer）、异步（async）和预加载（preload）等。

　　对于比较庞大的首页，可以先将那些能阻塞网页首次渲染的关键资源载入，其余资源都延迟载入，以此提升页面打开速度。

　　第三部分的容器（WebView）就是借用端的能力，让 APP 配合优化网页。

　　例如预请求，将请求接口的时机前置到容器打开之时，下面是一张实现流程图。

　　

　　还有一种静态资源缓存至客户端本地，当时与公司客户端讨论此方案时，他们觉得每次拦截请求会损伤性能，后面就采用了折中的办法。

　　就是他们去主动请求特定地址的静态资源，然后开放接口让我可以去读取本地资源，也就是说由 Web 来控制是否读取缓存资源。

二、问题引出　　

　　现在言归正传，回到本次的优化中来。

　　为了提升页面产出率，联合 UI 设计构建了一套可配置的通用活动模板。

　　活动上线后，就查看了性能数据，情况很不理想，如下图所示。

　　

　　FP（白屏）时间大部分都在 2 秒以上，取平均值更是在 3 秒左右。Google的报告指出：

三、数据排查

　　在数据库中，将指定的性能数据记录导出到 Excel 中。

　　翻了一条后发现，性能问题集中在 DOM 中。

{
    "unloadEventTime": 0,
    "loadEventTime": 1,
    "interactiveTime": 1255,
    "parseDomTime": 1075,
    "initDomTreeTime": 721,
    "readyStart": 5,
    "redirectCount": 0,
    "compression": 0,
    "redirectTime": 0,
    "appcacheTime": 0,
    "lookupDomainTime": 0,
    "connectSslTime": 0,
    "connectTime": 0,
    "requestTime": 119,
    "requestDocumentTime": 119,
    "responseDocumentTime": 0,
    "TTFB": 534,
}

　　JSON 中的 interactiveTime、parseDomTime 和 initDomTreeTime 消耗的时间都不短，计算规则如下所示。

    /**
     * 解析 DOM 树结构的时间
     * 期间要加载内嵌资源
     * 反省下你的 DOM 树嵌套是不是太多了
     */
    api.parseDomTime = timing.domComplete - timing.domInteractive;
    /**
     * 请求完毕至DOM加载耗时
     */
    api.initDomTreeTime = timing.domInteractive - timing.responseEnd;
    /**
     * 首次可交互时间
     */
    api.interactiveTime = timing.domInteractive - timing.fetchStart;

　　参考 W3C 第二版性能参数图可知，慢的地方集中在 Processing 阶段。

　　

四、Chrome DevTools

　　打开 Chrome DevTools 中的 Performance 一栏，录制后，可在火焰图中看到长任务。

　　点击 Long task 链接，会跳转到使用 RAIL 模型衡量性能一文。

　　

　　在 PC 浏览器中打开肯定会比在手机中快，但即使如此，还是出现了性能瓶颈，说明这里是真的慢。

　　蓝底的 DCL 是 DOMContentLoaded 事件，在 HTML 文档被完全加载和解析后触发，绿底的 FP 就是白屏时间。

　　黄底的 Evaluate Script 表示加载 JavaScript 脚本，Compile Script 表示执行 JavaScript 脚本。

　　再来看看网络请求瀑布图，下图中的蓝线就是 DCL，可以清晰的看到，蓝线之前在加载的基本都是 JavaScript 脚本。

　　

　　由此可知，加载的脚本有点多，并且有一个 chunk-vendors.js 脚本还比较大，下载时间有点长（依据蓝色块）。

五、代码分析

　　定位到了问题根源，那就直接查看基于 Vue 的代码是怎么写的了。

1）HTML

　　下面是编译后的页面 HTML 结构，只列出了关键部分。

<!DOCTYPE html>
<html lang=en>
<head>
  <script src=https://res.wx.qq.com/open/js/jweixin-1.6.0.js></script>
  <script src=//www.xxxx.com/flexible/flexible.js></script>
  <script src=//www.xxxx.co/files/js/baidu.js></script>
  <script src=//www.xxxx.co/files/js/shin.js></script>
  <link href=//www.xxxx.me/game/css/operation37.cba04f10.css rel=preload as=style>
  <link href=//www.xxxx.me/game/js/chunk-lodash.152ef24b.js rel=preload as=script>
  <link href=//www.xxxx.me/game/js/chunk-lottie.23b9982e.js rel=preload as=script>
  <link href=//www.xxxx.me/game/js/operation37.fa5f5378.js rel=preload as=script>
  <link href=//www.xxxx.me/game/css/chunk-vendors.779f7d1d.css rel=stylesheet>
  <link href=//www.xxxx.me/game/css/operation37.cba04f10.css rel=stylesheet>
</head>

<body>
  <div id=app></div>
  <script src=//www.xxxx.me/game/js/chunk-vendors.ca022e99.js></script>
  <script src=//www.xxxx.me/game/js/operation37.fa5f5378.js></script>
</body>
</html>

　　首先在 head 中，引入了大量的 JavaScript 脚本，flexible.js 其实在构建时可以内联，不需要网络访问。

　　然后 jweixin-1.6.0.js 和 baidu.js 这两个脚本完全可以延迟加载，后者就是增加百度统计的脚本。

　　接着就是 shin.js 需要做压缩处理，可以减少 50% 以上的尺寸。

　　在 link 元素中，使用了 preload，表示可并行的预加载，并且不会执行，这是提升页面性能的一种手段。

　　虽然第三方的库（chunk-vendors.ca022e99.js）和业务主逻辑（operation37.fa5f5378.js）两个脚本声明在 body 中。

　　但是主结构就是个空的 div，因此在加载和运行时就会延长 DOM 的解析，影响白屏时间。

2）vendors 优化

　　Vue 内置了一条命令，可以查看每个脚本的尺寸以及内部依赖包的尺寸。

　　在下图中，vendors.js 的原始尺寸是 3.76M，gzipped 压缩后的尺寸是 442.02KB，比较大的包是 lottie、swiper、moment、lodash 等。

　　

　　这类比较大的包可以再单独剥离，不用全部聚合在 vendors.js 中。

　　在 vue.config.js 中，配置 config.optimization.splitChunks()，如下所示，参数含义可参考官网。

config.optimization.splitChunks(
      {
        cacheGroups: {
          vendors: {
            name: 'chunk-vendors',
            test: /[\\/]node_modules[\\/]/,
            priority: -10,
            chunks: 'initial'
          },
          lottie: {
            name: 'chunk-lottie',
            test: /[\\/]node_modules[\\/]lottie-web[\\/]/,
            chunks: 'all',
            priority: 3,
            reuseExistingChunk: true,
            enforce: true
          },
          swiper: {
            name: 'chunk-swiper',
            test: /[\\/]node_modules[\\/]_swiper@3.4.2@swiper[\\/]/,
            chunks: 'all',
            priority: 3,
            reuseExistingChunk: true,
            enforce: true
          },
          lodash: {
            name: 'chunk-lodash',
            test: /[\\/]node_modules[\\/]lodash[\\/]/,
            chunks: 'all',
            priority: 3,
            reuseExistingChunk: true,
            enforce: true
          }
        }
      }
    )

　　在经过一顿初步操作后，原始尺寸降到 2.4M，gzipped 压缩后的尺寸是 308.64KB，比之前少了 100 多 KB。

　　

　　现在在入口处需要单独声明依赖的包，否则不会自动引入。

pages: {
   operation37: {
      entry: 'src/pages/operation37/index.js',
      template: 'src/pages/operation37/index.html',
      filename: 'operation37.html',
      title: '榜单配置页面',
      chunks: ['chunk-lottie', 'operation37', 'chunk-vendors']
   },
}

　　其实大部分的 H5 页面都比较简单，可能就使用了包的一个小功能，那完全可以自己用代码实现，这样就不必依赖那个大包了。

　　后面就是在代码逻辑层面的优化，核心就是减少脚本尺寸。优化后，再去观察数据的变化。

3）CDN加速

　　之前部分静态资源采取了 CDN 加速，现在需要将 game 下面中的静态资源全部走 CDN。

　　在云端配置些参数，就能走 CDN。不过，第一次没有配置好，没有配置转发路径，造成了严重的线上问题。

　　第二次就比较谨慎，在测试环境将之前碰到的问题都验证后，才最终在线上配置。

　　白屏时间占比变化：

 

参考资料：

长的 JavaScript 任务是否会延迟您的交互时间？

狙杀页面卡顿 —— Performance 工具指北

chrome performance看浏览器渲染过程

深入理解浏览器解析渲染 HTML

Vue CLI 项目页面打开时间优化：从16秒到2秒内

preload 让加载和解析解耦

标签：Web,躬行,js,vendors,页面,优化,chunk,加载
来源： https://www.cnblogs.com/strick/p/16331794.html