资讯专栏INFORMATION COLUMN

前端性能优化—js代码打包

Rango / 883人阅读

摘要:注意使用的版本不同,可能会导致打包出的结果不一样。完整的优化代码见有用的文章分离第三方库及公用文件

现在的 web 应用,内容一般都很丰富,站点需要加载的资源也特别多,尤其要加载很多 js 文件。js 文件从服务端获取,体积大小决定了传输的快慢;浏览器端拿到 js 文件之后,还需要经过解压缩、解析、编译、执行操作,所以,控制 js 代码的体积以及按需加载对前端性能以及用户体验是十分的重要。

本文从 Tree Shaking代码分割 两部分介绍 js 打包优化,有兴趣的可以跟着一起实践。
clone 以下项目 https://github.com/jasonintju...,就是个简单的 React SPA,一看就懂。

Tree Shaking

Tree Shaking 简单理解就是:打包时把一些没有用到的代码删除掉,保证打包后的代码体积最小化。其详细的介绍可以参考 Tree-Shaking性能优化实践 - 原理篇。

项目 clone、安装依赖后,先 npm run build 打包初始代码,大小及分布如下(其中 src/utils/utils.js 这个文件打包后大小为11.72Kb):

src/containers/About/test.js只引用但是没有使用到,src/utils/utils.js 这个文件是个工具函数集,有很多很多函数,而我们只用到了其中的一个。默认情况下,整个文件都被打包进 main.js 了,显然,这是很大的冗余,正好可以使用 Tree Shaking 优化。

修改 .babelrc
{
  "presets": [["env", { "modules": false }], "react", "stage-0"]
}
修改 package.json
{
  "name": "optimizing-js",
  "version": "1.0.0",
  "sideEffects": false
}

这样设置之后,表示所有的 module 都是无副作用的,没有使用到的 module 都可以删掉,此时打包结果如下:

import React from "react";
// 只引入了 arraySum, utils.js 中的其他方法不会被打包
import { arraySum } from "@utils/utils";
import "./test"; // 引用,“未使用”,不会被打包
import "./About.scss"; // 引用,“未使用”,不会被打包

class About extends React.Component {
  render() {
    const sum = arraySum([12, 3]);
    return (
      

About Page

12 plus 3 equals {sum}
); } } export default About;

如上面注释所说,Tree Shaking 认为这些是没有被使用的代码,所以可以删掉。但事实上我们知道不是这样的,test.js 可以删掉,但是 css、scss 是有用的代码,我们只需引入即可。因此,需要修改一下 sideEffects 的值:

{
  "sideEffects": [
    "*.css", "*.scss", "*.sass"
  ]
}

表示,除了[]中的文件(类型),其他文件都是无副作用的,可以放心删掉。此时打包结果:

可以看到,css 等样式文件现在如期打包进去了。如果有其他类型的文件有副作用,但是也希望打包进去,在 sideEffects: [] 中添加即可,可以是具体的某个文件或者某种文件类型。

关于为什么修改这两个地方就可以实现 Tree Shaking 的效果了,可以参考一下https://developers.google.com... 或者其他文章,这里不做详细解释了。

代码分割

单页应用,如果所有的资源都打包在一个 js 里面,毫无疑问,体积会非常庞大,首屏加载会有很长时间白屏,用户体验极差。所以,要代码分割,分成一个一个小的 js,优化加载时间。

分离第三方库代码

第三方库代码多带带提取出来,和业务代码分离,减少 js 文件体积。在 webpack.base.conf.js 中增加:

module: {...},
optimization: {
  splitChunks: {
    cacheGroups: {
      venders: {
        test: /node_modules/,
        name: "vendors",
        chunks: "all"
      }
    }
  }
},
plugins: ...

动态导入

使用 ECMAScript 提案 的 dynamic import 语法可以异步加载业务中的组件。使用方法如下:

// src/containers/App/App.js

// 注释掉此行代码
// import About from "@containers/About/About";

// 修改模块为动态导入形式
 import(/* webpackChunkName: "about" */ "@containers/About/About").then(module => module.default)}/>

此时打包结果:

能看到, 组件已经被 webpack 多带带打包出对应的 js 文件了。同时,结合 react-router,分离 组件的同时也做到了按需加载:当访问 About 页面时,about.js 才会被浏览器加载。

注意,我们现在只是简单地使用了 dynamic import,很多边界情况没考虑进去,比如:加载进度、加载失败、超时等处理。可以开发一个高阶组件,把这些异常处理都包含进去。社区有个很棒的 react-loadable,大树底下好乘凉~

npm i react-loadable

// src/containers/App/App.js
import Loadable from "react-loadable";

// 代码分割 & 异步加载
const LoadableAbout = Loadable({
  loader: () => import(/* webpackChunkName: "about" */ "@containers/About/About"),
  loading() {
    return 
Loading...
; } }); class App extends React.Component { render() { return (
); } }

react-loadable 还提供了 preload 功能。假如有统计数据显示,用户在进入首页之后大概率会进入 About 页面,那我们就在首页加载完成的时候去加载 about.js,这样等用户跳到 About 页面的时候,js 资源都已经加载好了,用户体验会更好。

// src/containers/App/App.js
componentDidMount() {
  LoadableAbout.preload();
}

如果有同学对Network面板不是很熟悉,可以看一下 Chrome DevTools — Network。

提取复用的业务代码

第三方库代码已经多带带提取出来了,但是业务代码中也会有一些复用的代码,典型的比如一些工具函数库 utils.js。现在,About 组件Docs 组件都引用了 utils.js,webpack 只打包了一份 utils.jsmain.js 里面,main.js 在首页就被加载了,其他页面有使用到 utils.js 自然可以正常引用到,符合我们的预期。但是目前我们只是把 About 页面异步加载了,如果把 Docs 页面也异步加载了会怎么样呢?

// src/containers/App/App.js
// 注释掉此行代码
// import Docs from "@containers/Docs/Docs";

const LoadableDocs = Loadable({
  loader: () => import(/* webpackChunkName: "docs" */ "@containers/Docs/Docs"),
  loading() {
    return 
Loading...
; } }); class App extends React.Component { render() { return (
); } }

此时打包结果:

能够看到,about.js 和 docs.js 里面都打包了 utils.js,重复了!
webpack.base.conf.js 中增加:

module: {...},
optimization: {
  splitChunks: {
    cacheGroups: {
      venders: {
        test: /node_modules/,
        name: "vendors",
        chunks: "all"
      },
      default: {
        minSize: 0,
        minChunks: 2,
        reuseExistingChunk: true,
        name: "utils"
      }
    }
  }
},
plugins: ...

再打包看结果:

utils.js 也被多带带打包出来了,达到了预期。

分离非首页使用且复用程度小的第三方库

假如,现在 Docs.js 引用了 lodash 这个三方库:

import React from "react";
import _ from "lodash";
import { arraySum } from "@utils/utils";
import "./Docs.scss";

class Docs extends React.Component {
  render() {
    const sum = arraySum([1, 3]);
    const b = _.sum([1, 3]);
    return (
      

Docs Page

1 plus 3 equals {sum}

use _.sum, 1 plus 3 equals {b} too.
); } } export default Docs;

打包结果:

lodash.js 只在 Docs 页面使用,而且可能 Docs 页面访问量很少,把 lodash.js 打包在首页就会加载的 venders.js 里面,实在不是明智之举。

修改 webpack.base.conf.js

...
venders: {
  test: /node_modules/(?!(lodash)/)/, // 去除 lodash,剩余的第三方库打成一个包,命名为 vendors-common
  name: "vendors-common",
  chunks: "all"
},
lodash: {
  test: /node_modules/lodash//, // lodash 库多带带打包,并命名为 vender-lodash
  name: "vender-lodash"
},
default: {
  minSize: 0,
  minChunks: 2,
  reuseExistingChunk: true,
  name: "utils"
}
...

此时把 lodash 多带带打成了一个包,且配合 Docs 页面的按需加载,达到了理想的加载效果。

缓存

项目打包后,资源部署在服务器端,客户端需要向服务器请求下载这些资源,用户才能看到内容。使用缓存,客户端可以大大减少不必要的请求和时间耽搁,只有当资源有更新时,再去下载。区分一个文件是否有更新,使用 文件名 + hash 可以达到目的。本案例中,已经使用了 "[name].[contenthash:8].js"

然而,在打包的时候,webpack的运行时代码有时候会导致某些情况出现,如:什么内容都没改,两次 build 代码的 hash 不一样;或者是,修改了 a 文件的代码,却导致了某些未修改代码文件的 hash 也发生了变化。This is caused by the injection of the runtime and manifest which changes every build.

注意:使用的 webpack 版本不同,可能会导致打包出的结果不一样。较新的版本或许没有这种 hash 问题,但为了安全起见,还是建议按照下面的步骤处理一下。
分离 webpack runtimeChunk code
// webpack.base.conf.js
optimization: {
  runtimeChunk: {
    name: "manifest"
  },
  splitChunks: {...}
}

此时,能达到:修改某个文件,只有这个文件和 manifest.js 文件的 hash 会发生变化,其他文件的 hash 不变。
打包前:

// About.scss
.page-about {
  padding-left: 30px;
  color: #545880; // 修改字体颜色
}

修改后:

HashedModuleIdsPlugin

增加、删除一些模块,可能会导致不相关文件的 hash 发生变化,这是因为 webpack 打包时,按照导入模块的顺序,module.id 自增,会导致某些模块的 module.id 发生变化,进而导致文件的 hash 变化。

解决方式: 使用 webpack 内置的 HashedModuleIdsPlugin,该插件基于导入模块的相对路径生成相应的 module.id,这样如果内容没有变化加上 module.id 也没变化,则生成的 hash 也就不会变化了。

// webpack.prod.conf.js
const webpack = require("webpack");
...
plugins: [new webpack.HashedModuleIdsPlugin(), new BundleAnalyzerPlugin()]

完整的优化代码见 https://github.com/jasonintju...

有用的文章:
webpack分离第三方库及公用文件
https://developers.google.com...

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/97611.html

相关文章

  • 前端进阶(14) - 如何提升前端性能和响应速度

    摘要:一般建议文件最大不超过。按需加载可以减小首屏加载文件的体积,达到提高响应速度的目的。如果你的项目不需要处理静态资源如图片,也不需要按需加载,并追求前端高性能的话,可以尝试。 如何提升前端性能和响应速度 下面大多是从前端工程化的角度给出的优化建议,如果需要了解语法上的优化,可以参考: 如何提高页面加载速度 编写高效的JavaScript Web前端性能优化进阶 - 完结篇 1. 原生...

    lylwyy2016 评论0 收藏0
  • 前端进阶(14) - 如何提升前端性能和响应速度

    摘要:一般建议文件最大不超过。按需加载可以减小首屏加载文件的体积,达到提高响应速度的目的。如果你的项目不需要处理静态资源如图片,也不需要按需加载,并追求前端高性能的话,可以尝试。 如何提升前端性能和响应速度 下面大多是从前端工程化的角度给出的优化建议,如果需要了解语法上的优化,可以参考: 如何提高页面加载速度 编写高效的JavaScript Web前端性能优化进阶 - 完结篇 1. 原生...

    Airy 评论0 收藏0
  • 如何构建前端代码

    摘要:首先散文件是有害处的,第一是,散文件可能没有版本号的区分,这样因为缓存导致第二是散文件会严重拖慢性能,因为很多散文件不仅消耗请求资源,而且是在串行消耗。 基本认识 开发环境和线上环境的区别 在很久以前,前端的部署其实比较简单,开发环境下,静态资源往服务器上面一扔就ok了,如果考虑下优化或者代码保护,也只是加一个代码压缩和混淆。没错,刚入行的时候我就是这么干的。。。 但是随着前...

    jhhfft 评论0 收藏0
  • 前端进阶(9) - js 性能优化利器:prepack

    摘要:性能优化利器性能优化性能优化不外乎从三个角度入手开发者在编写程序时,尽量避免不必要的冗余代码,包括冗余的第三方库首先要避免不必要的冗余代码,包括不必要的闭包不必要的变量与函数声明不必要的模块分割等。 js 性能优化利器:prepack 1. js 性能优化 js 性能优化不外乎从三个角度入手: 1.1 开发者在编写程序时,尽量避免不必要的冗余代码,包括冗余的第三方库 首先要避免不必要的...

    JouyPub 评论0 收藏0
  • 前端构建】WebPack实例与前端性能优化

    摘要:感受构建工具给前端优化工作带来的便利。多多益处逻辑清晰,程序注重数据与表现分离,可读性强,利于规避和排查问题构建工具层出不穷。其实工具都能满足需求,关键是看怎么用,工具的使用背后是对前端性能优化的理解程度。 这篇主要介绍一下我在玩Webpack过程中的心得。通过实例介绍WebPack的安装,插件使用及加载策略。感受构建工具给前端优化工作带来的便利。 showImg(https://se...

    QiShare 评论0 收藏0

发表评论

0条评论

最新活动
阅读需要支付1元查看
<