當前位置：首頁 > 前端技术 > HTML >内容正文

HTML

前端面试超全整理3（webpack性能优化及监控）

發布時間：2023/12/29 HTML 36 豆豆

生活随笔收集整理的這篇文章主要介紹了前端面试超全整理3（webpack性能优化及监控）小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

21、Webpack 性能優化

核心概念

Entry :入口

output:出口

Plugins: 插件，執行范圍更廣的任務。插件的范圍包括，從打包優化和壓縮，一直到重新定義環境中的變量

Loader：翻譯官，把瀏覽器不識別的內容做轉換

研發環境

依賴包：啟動 webpack-dev-server --config webpack.config.dev.jswebpack webpack-cli //基礎依賴 webpack-dev-server -D //熱更新 //將css文件提取為獨立的文件的插件 mini-css-extract-plugin -D html-webpack-plugin -D // 將模板文件和js文件整合到一塊 CopyWebpackPlugin -D //將靜態資源拷貝到dist目錄下 sass-loader node-sass -D //解析scss文件 node-sass --sass_binary_site=https://npm.taobao.org/mirrors/node-sass/ const path = require('path') const htmlWebpackPlugin = require('html-webpack-plugin') const MiniCssExtractPlugin = require('mini-css-extract-plugin')module.exports = {//開發模式：development，代碼調試，生產模式：production ,代碼壓縮，優化//如果mode不配置，會有警告提示信息mode: "development",//開發模式//代碼調試，可以看到源代碼devtool: 'inline-source-map',//入口文件，如果不配置，默然找根目錄下 /src/index.js// entry:"./src/js/index.js",多頁面entry: {'main': "./src/js/index.js",'detail': "./src/js/detai.js"},//打包完成，輸出文件的位置(不能寫相對路徑),可以不配置，默認輸出到dist目錄output: {path: path.resolve(__dirname, './dev'),filename: '[name]-[hash].js'},//支持熱更新devServer: {port: 9099,//打開瀏覽器open: true},//插件plugins: [//它將創建一個html文件，將打包好的各種如js、css模塊引用進去,并通過提供的各種參數完成多種處理new htmlWebpackPlugin({title: 'webpack demo home',//模板文件路徑template: "./src/views/index.html",//自動存儲到output 配置的目錄filename: 'index.html',//這個就表示當前實例僅引入chunk名為main的模塊chunks: ['main']}),//自動更新根據文件名自動更換css文件new MiniCssExtractPlugin({//頁面引用的樣式文件名filename: '[name]-[hash].css',// chunkFilename: 'common.css',}),new CopyWebpackPlugin([{from: './src/static', to: './static' //相對于output 里面配置的path:./}])],//翻譯官，把瀏覽器不識別的內容做轉換module: {//解析規則rules: [//解析scss{test: /\.s[ac]ss$/,//執行順序：從右向左use: [// 將 JS 字符串生成為 style 節點'style-loader',// MiniCssExtractPlugin.loader,//將 CSS 轉化成 CommonJS 模塊'css-loader',//把.scss文件文件轉換為.css文件'sass-loader']},//解析html{test: /\.html$/,use: ['string-loader']}]} }

在這一的章節中，我不會浪費篇幅給大家講如何寫配置文件。如果你想學習這方面的內容，那么完全可以去官網學習。在這部分的內容中，我們會聚焦于以下兩個知識點，并且每一個知識點都屬于高頻考點：

有哪些方式可以減少 Webpack 的打包時間
有哪些方式可以讓 Webpack 打出來的包更小

1、noParse:

該配置是作為 module 的一個屬性值，即不解析某些模塊，所謂不解析，就是不去分析某個模塊中的依賴關系，即不去管某個文件是否 import(依賴)了某個文件，對于一些獨立的庫，比如 jquery，其根本不存在依賴關系，jquery 不會去引入其他的庫(要根據自己對某個模塊的了解去判斷是否要解析該模塊)，所以我們可以讓 webpack 不去解析 jquery 的依賴關系，提高打包速度，如:

module.exports = {module: {noParse:/jquery/,//不去解析jquery中的依賴庫} }

noParse 是 module 配置中的一個屬性，其屬性值為一個正則表達式，填入不被解析的模塊名稱。

為了更清楚的展示 noParse 的作用，假設我們在入口文件 index.js 中引入 bar.js 模塊，同時這個 bar.js 模塊中也引入了 foo.js 模塊，foo.js 不再依賴其他模塊了，那么在不使用 noParse 的情況下，webpack 打包的時候，會先去分析 index.js 模塊，發現其引入了 bar.js 模塊，然后接著分析 bar.js 模塊，發現其引入了 foo.js 模塊，接著分析 foo.js 模塊。

Entrypoint index = index.js [./src/bar.js] 55 bytes {index} [built] [./src/foo.js] 21 bytes {index} [built] [./src/index.js] 81 bytes {index} [built]

而此時如果使用了 noParse: /bar/，那么 webpack 打包的時候，會先去分析 index.js 模塊，發現其引入了 bar.js 模塊，但是由于 noParse 的作用，將不再繼續解析 bar.js 模塊了，即不會去分析 bar.js 中引入的 foo.js 模塊了。

Entrypoint index = index.js [./src/bar.js] 55 bytes {index} [built] [./src/index.js] 81 bytes {index} [built]

2、exclude:

2、exclude: 在 loader 中使用 exclude 排除對某些目錄中的文件處理，即引入指定目錄下的文件時候，不使用對應的 loader 進行處理，exclude 是 loader 配置中的一個屬性，屬性值為正則表達式，如:

module.exports = {module: {rules: [{test: /\.js$/,use: [{loader: "babel-loader",options: {presets: ["@babel/preset-env"],plugins: ["@babel/plugin-transform-runtime"]}}],exclude: /node_modules/}]} }

3、使用 IgnorePlugin

3、使用 IgnorePlugin 來忽略某個模塊中某些目錄中的模塊引用，比如在引入某個模塊的時候，該模塊會引入大量的語言包，而我們不會用到那么多語言包，如果都打包進項目中，那么就會影響打包速度和最終包的大小，然后再引入需要使用的語言包即可，如:

項目根目錄下有一個 time 包，其中有一個 lang 包，lang 包中包含了各種語言輸出對應時間的 js 文件，time 包下的 index.js 會引入 lang 包下所有的 js 文件，那么當我們引入 time 模塊的時候，就會將 lang 包下的所有 js 文件都打包進去，添加如下配置:

const webpack = require("webpack"); module.exports = {plugins: [new webpack.IgnorePlugin(/lang/, /time/)] }

引入 time 模塊的時候，如果 time 模塊中引入了其中的 lang 模塊中的內容，那么就忽略掉，即不引入 lang 模塊中的內容，需要注意的是，這 /time/ 只是匹配文件夾和 time 模塊的具體目錄位置無關，即只要是引入了目錄名為 time 中的內容就會生效。

4、使用 HappyPack：

**4、使用 HappyPack：**由于在打包過程中有大量的文件需要交給 loader 進行處理，包括解析和轉換等操作，而由于 js 是單線程的，所以這些文件只能一個一個地處理，而 HappyPack 的工作原理就是充分發揮 CPU 的多核功能，將任務分解給多個子進程去并發執行，子進程處理完后再將結果發送給主進程，happypack 主要起到一個任務劫持的作用，在創建 HappyPack 實例的時候要傳入對應文件的 loader，即 use 部分，loader 配置中將使用經過 HappyPack 包裝后的 loader 進行處理，如:

module.exports = {plugins: [new HappyPack({ // 這里對處理css文件的loader進行包裝id: "css",// 之前的loader根據具體的id進行引入use: ["style-loader","css-loader"],threads: 5 // 設置開啟的進程數})],module: {rules: [{test: /\.css$/, // 匹配以.css結尾的文件use: ["happypack/loader?id=css"] //根據happypack實例中配置的id引入包裝后的laoder，這里的happyPack的h可以大寫也可以小寫}]} }

webpack 要打包的文件非常多的時候才需要使用 happypack 進行優化，因為開啟多進程也是需要耗時間的，所以文件少的時候，使用 happypack 返回更耗時

5、抽離公共模塊:

5、抽離公共模塊: 對于多入口情況，如果某個或某些模塊，被兩個以上文件所依賴，那么可以將這個模塊單獨抽離出來，不需要將這些公共的代碼都打包進每個輸出文件中，這樣會造成代碼的重復和流量的浪費，即如果有兩個入口文件 index.js 和 other.js，它們都依賴了 foo.js，那么如果不抽離公共模塊，那么 foo.js 中的代碼都會打包進最終輸出的 index.js 和 other.js 中去，即有兩份 foo.js 了。抽離公共模塊也很簡單，直接在 optimization 中配置即可，如:

這樣就會將公共的 foo.js 模塊抽離到 common 目錄下 foo.js 中了，但是如果我們也有多個文件依賴了第三方模塊如 jquery，如果按以上配置，那么 jquery 也會被打包進 foo.js 中，會導致代碼混亂，所以我們希望將 jquery 單獨抽出來，即與 foo.js 分開，我們可以復制一份以上配置，并通過設置抽離代碼權重的方式來實現，即優先抽離出 jquery，如:

module.exports = {splitChunks: { // 分割代碼塊，即抽離公共模塊cacheGroups: { // 緩存組common: { // 組名為common可自定義chunks: "initial",minSize: 0, // 文件大小為0字節以上才抽離minChunks: 2, // 被引用過兩次才抽離name: "common/foo", // 定義抽離出的文件的名稱},verdor: {test: /node_modules/,priority: 1, // 設置打包權重，即優先抽離第三方模塊chunks: "initial",minSize: 0, // 文件大小為0字節以上才抽離minChunks: 2, // 被引用過兩次才抽離name: "common/jquery", // 定義抽離出的文件的名稱}}} }

這樣就會在 common 目錄下同時抽離出 foo.js 和 jquery.js 了，需要注意的是，代碼的抽離必須是該模塊沒有被排除打包，即該模塊會被打包進輸出 bundle 中，如果第三方模塊已經通過 externals 排除打包，則以上 vendor 配置無效。

6、按需加載

**6、按需加載，**即在需要使用的時候才打包輸出，webpack 提供了 import() 方法，傳入要動態加載的模塊，來動態加載指定的模塊，當 webpack 遇到 import()語句的時候，不會立即去加載該模塊，而是在用到該模塊的時候，再去加載，也就是說打包的時候會一起打包出來，但是在瀏覽器中加載的時候并不會立即加載，而是等到用到的時候再去加載，比如，點擊按鈕后才會加載某個模塊，如:

const button = document.createElement("button"); button.innerText = "點我" button.addEventListener("click", () => { // 點擊按鈕后加載foo.jsimport("./foo").then((res) => { // import()返回的是一個Promise對象console.log(res);}); }); document.body.appendChild(button);

從中可以看到，import() 返回的是一個 Promise 對象，其主要就是利用 JSONP 實現動態加載，返回的 res 結果不同的 export 方式會有不同，如果使用的 module.exports 輸出，那么返回的 res 就是 module.exports 輸出的結果；如果使用的是 ES6 模塊輸出，即 export default 輸出，那么返回的 res 結果就是 res.default，如:

// ES6模塊輸出，res結果為

{default: "foo", __esModule: true, Symbol(Symbol.toStringTag): "Module"}

7、開啟模塊熱更新:

7、開啟模塊熱更新: 模塊熱更新可以做到在不刷新網頁的情況下，更新修改的模塊，只編譯變化的模塊，而不用全部模塊重新打包，大大提高開發效率，在未開啟熱更新的情況下，每次修改了模塊，都會重新打包。

要開啟模塊熱更新，那么只需要在 devServer 配置中添加 hot:true 即可。當然僅僅開啟模塊熱更新是不夠的，我們需要做一些類似監聽的操作，當監聽的模塊發生變化的時候，重新加載該模塊并執行，如:

module.exports = {devServer: {hot: true // 開啟熱更新} }----------import foo from "./foo"; console.log(foo); if (module.hot) {module.hot.accept("./foo", () => { // 監聽到foo模塊發生變化的時候const foo = require("./foo"); // 重新引入該模塊并執行console.log(foo);}); }

如果不使用 module.hot.accept 監聽，那么當修改 foo 模塊的時候還是會刷新頁面的

減少 Webpack 打包后的文件體積

注意：該內容也屬于性能優化領域。

按需加載

想必大家在開發 SPA 項目的時候，項目中都會存在十幾甚至更多的路由頁面。如果我們將這些頁面全部打包進一個 JS 文件的話，雖然將多個請求合并了，但是同樣也加載了很多并不需要的代碼，耗費了更長的時間。那么為了首頁能更快地呈現給用戶，我們肯定是希望首頁能加載的文件體積越小越好，這時候我們就可以使用按需加載，將每個路由頁面單獨打包為一個文件。當然不僅僅路由可以按需加載，對于 loadash 這種大型類庫同樣可以使用這個功能。

按需加載的代碼實現這里就不詳細展開了，因為鑒于用的框架不同，實現起來都是不一樣的。當然了，雖然他們的用法可能不同，但是底層的機制都是一樣的。都是當使用的時候再去下載對應文件，返回一個 Promise，當 Promise 成功以后去執行回調。

Scope Hoisting

Scope Hoisting 會分析出模塊之間的依賴關系，盡可能的把打包出來的模塊合并到一個函數中去。

比如我們希望打包兩個文件

// test.js export const a = 1 // index.js import { a } from './test.js'

對于這種情況，我們打包出來的代碼會類似這樣

[/* 0 */function (module, exports, require) {//...},/* 1 */function (module, exports, require) {//...} ]

但是如果我們使用 Scope Hoisting 的話，代碼就會盡可能的合并到一個函數中去，也就變成了這樣的類似代碼

[/* 0 */function (module, exports, require) {//...} ]

這樣的打包方式生成的代碼明顯比之前的少多了。如果在 Webpack4 中你希望開啟這個功能，只需要啟用 optimization.concatenateModules 就可以了。

module.exports = {optimization: {concatenateModules: true} }

Tree Shaking

Tree Shaking 可以實現刪除項目中未被引用的代碼，比如

// test.js export const a = 1 export const b = 2 // index.js import { a } from './test.js'

對于以上情況，test 文件中的變量 b 如果沒有在項目中使用到的話，就不會被打包到文件中。

如果你使用 Webpack 4 的話，開啟生產環境就會自動啟動這個優化功能。

外圍擴展 externals

webpack的配置選項，externals 配置選項提供了「從輸出的 bundle 中排除依賴」的方法。相反，所創建的 bundle 依賴于那些存在于用戶環境(consumer’s environment)中的依賴。此功能通常對 library 開發人員來說是最有用的，然而也會有各種各樣的應用程序用到它。

externals: [{// Stringreact: 'react',// Objectlodash: {commonjs: 'lodash',amd: 'lodash',root: '_' // indicates global variable},// Arraysubtract: ['./math', 'subtract']},// Functionfunction (context, request, callback) {if (/^yourregex$/.test(request)) {return callback(null, 'commonjs ' + request);}callback();},// Regex/^(jquery|\$)$/i],

靜態資源發布CDN后webpack的配置

output: {path: path.resolve(__dirname, 'public/assets'),publicPath: 'https://cdn.example.com/assets/'}

使用 HappyPack：

由于在打包過程中有大量的文件需要交給 loader 進行處理，包括解析和轉換等操作，而由于 js 是單線程的，所以這些文件只能一個一個地處理，而 HappyPack 的工作原理就是充分發揮 CPU 的多核功能，將任務分解給多個子進程去并發執行，子進程處理完后再將結果發送給主進程，happypack 主要起到一個任務劫持的作用，在創建 HappyPack 實例的時候要傳入對應文件的 loader，即 use 部分，loader 配置中將使用經過 HappyPack 包裝后的 loader 進行處理，如:

webpack 要打包的文件非常多的時候才需要使用 happypack 進行優化，因為開啟多進程也是需要耗時間的，所以文件少的時候，使用 happypack 返回更耗時

靜態資源上傳到CDN

/*** 發布靜態文件到CDN上，并且修改HTML引用文件為CDN地址*/const fs = require('fs'); const emitter = require('events'); const Client = require('ftp'); const c = new Client();class MyEmitter extends emitter { } const EventEmitter = new MyEmitter();const bucket = 'source'; const project = 'test'; // 項目名稱 var projectPath = `${bucket}/${project}/`; // static 靜態資源目錄 var staticPath = `${projectPath}static/` //css 文件夾目錄 var cssPath = `${staticPath}css/`; //img 文件夾目錄 var imgPath = `${staticPath}img/`; //js 文件夾目錄 var jsPath = `${staticPath}js/`;const FTP_CONFIG = {host: '192.168.1.170', port: 2121,user: 'username', password: '1qaz2wsx3edc' }; const uploadList = [];function travel(type) {const files = fs.readdirSync(`./dist/static/${type}`);for (let i = 0; i < files.length; i += 1) {uploadList.push({name: `./static/${type}/${files[i]}`,path: `./dist/static/${type}/${files[i]}`});} }function mkdir(path, cb) {c.mkdir(path, function (err) {if (err) {console.log(err.message)} else {console.log(`created path ${path}`)}cb();}) }travel('css'); travel('js'); travel('img');c.on('ready', () => {//create project pathmkdir(projectPath, function () {EventEmitter.emit('PROJECT_PATH_CREATED')})// create project static pathEventEmitter.on('PROJECT_PATH_CREATED', function () {mkdir(staticPath, function () {EventEmitter.emit('STATIC_PATH_CREATED')})})// create css pathEventEmitter.on('STATIC_PATH_CREATED', function () {mkdir(cssPath, function () {EventEmitter.emit('CSS_PATH_CREATED')})})// create image pathEventEmitter.on('CSS_PATH_CREATED', function () {mkdir(imgPath, function () {EventEmitter.emit('IMG_PATH_CREATED')})})// create js pathEventEmitter.on('IMG_PATH_CREATED', function () {mkdir(jsPath, function () {EventEmitter.emit('JS_PATH_CREATED')})})//update static resource fileEventEmitter.on('JS_PATH_CREATED', function () {var count = 0;for (let i = 0; i < uploadList.length; i += 1) {c.put(uploadList[i].path, `${bucket}/${project}/${uploadList[i].name}`, (err) => {count++if (!err) {console.log(`upload success ${uploadList[i].name}`)} else if (err.message.indexOf('Overwrite permission denied')) {console.log(`文件 ${uploadList[i].name}已存在，不給予上傳!`);} else if (err) {console.log(err.message);}if (count == uploadList.length) {console.log('upload complete!')}});}}) }); c.connect(FTP_CONFIG);

DllPlugin + DllReferencePlugin

減少構建時間，進行分離打包。
DllPlugin這個插件是在一個額外的獨立的 webpack 設置中創建一個只有 dll 的 bundle(dll-only-bundle)。這個插件會生成一個名為 manifest.json 的文件，這個文件是用來讓 DLLReferencePlugin 映射到相關的依賴上去的。

webpack.vendor.config.jsnew webpack.DllPlugin({context: __dirname,name: "[name]_[hash]",path: path.join(__dirname, "manifest.json"),})webpack.app.config.jsnew webpack.DllReferencePlugin({context: __dirname,manifest: require("./manifest.json"),name: "./my-dll.js",scope: "xyz",sourceType: "commonjs2"})

CommonsChunkPlugin (<4.0)通過將公共模塊拆出來緩存

通過將公共模塊拆出來，最終合成的文件能夠在最開始的時候加載一次，便存到緩存中供后續使用。這個帶來速度上的提升，因為瀏覽器會迅速將公共的代碼從緩存中取出來，而不是每次訪問一個新頁面時，再去加載一個更大的文件。
如果把公共文件提取出一個文件，那么當用戶訪問了一個網頁，加載了這個公共文件，再訪問其他依賴公共文件的網頁時，就直接使用文件在瀏覽器的緩存，這樣公共文件就只用被傳輸一次。

entry: {vendor: ["jquery", "other-lib"], // 明確第三方庫app: "./entry"},plugins: [new webpack.optimize.CommonsChunkPlugin({name: "vendor",// filename: "vendor.js"// (給 chunk 一個不同的名字)minChunks: Infinity,// (隨著 entry chunk 越來越多，// 這個配置保證沒其它的模塊會打包進 vendor chunk)})]// 打包后的文件<script src="vendor.js" charset="utf-8"></script><script src="app.js" charset="utf-8"></script>

SplitChunkPlugin

起初，chunks(代碼塊)和導入他們中的模塊通過webpack內部的父子關系圖連接.在webpack3中，通過CommonsChunkPlugin來避免他們之間的依賴重復。而在webpack4中CommonsChunkPlugin被移除，取而代之的是 optimization.splitChunks 和 optimization.runtimeChunk 配置項，下面展示它們將如何工作。

在默認情況下，SplitChunksPlugin 僅僅影響按需加載的代碼塊，因為更改初始塊會影響HTML文件應包含的腳本標記以運行項目。

webpack將根據以下條件自動拆分代碼塊：

會被共享的代碼塊或者 node_mudules 文件夾中的代碼塊

體積大于30KB的代碼塊（在gz壓縮前）

按需加載代碼塊時的并行請求數量不超過5個

加載初始頁面時的并行請求數量不超過3個

optimization: {splitChunks: {chunks: 'all', // 只對異步加載的模塊進行拆分，可選值還有all | initialminSize: 0, // 模塊最少大于30KB才拆分maxSize: 0, // 模塊大小無上限，只要大于30KB都拆分minChunks: 1, // 模塊最少引用一次才會被拆分maxAsyncRequests: 5, // 異步加載時同時發送的請求數量最大不能超過5,超過5的部分不拆分maxInitialRequests: 3, // 頁面初始化時同時發送的請求數量最大不能超過3,超過3的部分不拆分automaticNameDelimiter: '-', // 默認的連接符name: true, // 拆分的chunk名,設為true表示根據模塊名和CacheGroup的key來自動生成,使用上面連接符連接cacheGroups: { // 緩存組配置,上面配置讀取完成后進行拆分,如果需要把多個模塊拆分到一個文件,就需要緩存,所以命名為緩存組vendors: { // 自定義緩存組名name: 'venders',test: /[\\/]node_modules[\\/]/, // 檢查node_modules目錄,只要模塊在該目錄下就使用上面配置拆分到這個組priority: -10 // 權重-10,決定了哪個組優先匹配,例如node_modules下有個模塊要拆分,同時滿足vendors和default組,此時就會分到vendors組,因為-10 > -20},commons: { // 默認緩存組名name: 'commons',minChunks: 2, // 最少引用兩次才會被拆分priority: -20, // 權重-5reuseExistingChunk: true, // 如果主入口中引入了兩個模塊,其中一個正好也引用了后一個,就會直接復用,無需引用兩次test: /[\\/]src[\\/]/,minSize: 0,chunks: "all"}}}}

。

UglifyJSPlugin分析JS代碼語法樹\去掉無效代碼

基本上腳手架都包含了該插件,該插件會分析JS代碼語法樹，理解代碼的含義，從而做到去掉無效代碼、去掉日志輸入代碼、縮短變量名等優化。

const UglifyJSPlugin = require('webpack/lib/optimize/UglifyJsPlugin');//...plugins: [new UglifyJSPlugin({compress: {warnings: false, //刪除無用代碼時不輸出警告drop_console: true, //刪除所有console語句，可以兼容IEcollapse_vars: true, //內嵌已定義但只使用一次的變量reduce_vars: true, //提取使用多次但沒定義的靜態值到變量},output: {beautify: false, //最緊湊的輸出，不保留空格和制表符comments: false, //刪除所有注釋}})]

CSS樣式處理

css-loader: 處理 css 文件

style-loader: 把 js 中 import 導入的樣式文件代碼，打包到 js 文件中，運行 js 文件時，將樣式自動插入到

yarn add mini-css-extract-plugin -D yarn add css-loader -D yarn add optimize-css-assets-webpack-plugin -D

ExtractTextPlugin 從 bundle 中提取文本（CSS）到單獨的文件，PurifyCSSPlugin純化CSS（其實用處沒多大）

css-loader 用法：

module.exports = {module: {rules: [{test: /\.css$/i,use: [MiniCssExtractPlugin.loader, 'css-loader'],}]},plugins: [...,new MiniCssExtractPlugin({filename: '[name].css',chunkFilename: '[id].css',}),]};

style-loader用法：

module.exports = {module: {rules: [{test: /\.css$/i,use: [//執行順序，從有向左{ loader: "style-loader" },{ loader: "css-loader" }]},plugins: [...,new MiniCssExtractPlugin({filename: '[name].css',chunkFilename: '[id].css',}),]};

css 壓縮優化：

const OptimizeCSSAssetsPlugin = require('optimize-css-assets-webpack-plugin');。。。optimization: {minimizer: [new OptimizeCSSAssetsPlugin({})],}

DefinePlugin

DefinePlugin能夠自動檢測環境變化，效率高效。
在前端開發中，在不同的應用環境中，需要不同的配置。如：開發環境的API Mocker、測試流程中的數據偽造、打印調試信息。如果使用人工處理這些配置信息，不僅麻煩，而且容易出錯。
使用DefinePlugin配置的全局常量
注意，因為這個插件直接執行文本替換，給定的值必須包含字符串本身內的實際引號。通常，有兩種方式來達到這個效果，使用 ’ “production” ', 或者使用

JSON.stringify('production')。new webpack.DefinePlugin({// 當然，在運行node服務器的時候就應該按環境來配置文件// 下面模擬的測試環境運行配置'process.env':JSON.stringify('dev'),WP_CONF: JSON.stringify('dev'),}),

測試DefinePlugin：編寫

if (WP_CONF === 'dev') {console.log('This is dev');} else {console.log('This is prod');}

打包后WP_CONF === 'dev’會編譯為false

if (false) {console.log('This is dev');} else {console.log('This is prod');}

清除不可達代碼
當使用了DefinePlugin插件后，打包后的代碼會有很多冗余。可以通過UglifyJsPlugin清除不可達代碼。

[new UglifyJsPlugin({uglifyOptions: {compress: {warnings: false, // 去除warning警告dead_code: true, // 去除不可達代碼},warnings: false}})]

最后的打包打包代碼會變成console.log(‘This is prod’)
附Uglify文檔：github.com/mishoo/Ugli…
使用DefinePlugin區分環境 + UglifyJsPlugin清除不可達代碼，以減輕打包代碼體積
HappyPack
HappyPack可以開啟多進程Loader轉換，將任務分解給多個子進程，最后將結果發給主進程。
使用

exports.plugins = [new HappyPack({id: 'jsx',threads: 4,loaders: [ 'babel-loader' ]}),new HappyPack({id: 'styles',threads: 2,loaders: [ 'style-loader', 'css-loader', 'less-loader' ]})];exports.module.rules = [{test: /\.js$/,use: 'happypack/loader?id=jsx'},{test: /\.less$/,use: 'happypack/loader?id=styles'},]

ParallelUglifyPlugin

ParallelUglifyPlugin可以開啟多進程壓縮JS文件import ParallelUglifyPlugin from 'webpack-parallel-uglify-plugin';module.exports = {plugins: [new ParallelUglifyPlugin({test,include,exclude,cacheDir,workerCount,sourceMap,uglifyJS: {},uglifyES: {}}),],};

壓縮圖片資源

圖像占了頁面大小的一半以上。雖然它們不像JavaScript那樣重要(例如，它們不會阻塞呈現)，但它們仍然占用了很大一部分帶寬。在 webpack 中可以使用 url-loader、svg-url-loader 和 image-webpack-loader 來優化它們。

url-loader

參見：項目 webpack-css

url-loader 可以將小型靜態文件內聯到應用程序中。如果不進行配置，它將把接受一個傳遞的文件，將其放在已編譯的包旁邊，并返回該文件的url。但是，如果指定 limit 選項，它將把小于這個限制的文件編碼為Base64 數據的 url 并返回這個url，這會將圖像內聯到 JavaScript 代碼中，從而可以減少一個HTTP請求。

// webpack.config.js module.exports = {module: {rules: [{test: /\.(jpe?g|png|gif)$/,loader: 'url-loader',options: {// Inline files smaller than 10 kB (10240 bytes)limit: 10 * 1024,},},],} }; // Home.js import logo from '../assets/images/logo.png';

注意：需要在增大代碼體積和減少 HTTP 請求數之前進行權衡。

svg-url-loader

svg-url-loader 的工作原理與 url-loader 類似 — 只是它使用的是URL編碼而不是Base64編碼來編碼文件。這對SVG圖像很有用 — 因為SVG文件只是純文本，這種編碼更高效。

// webpack.config.js module.exports = {module: {rules: [{test: /\.svg$/,loader: 'svg-url-loader',options: {// Inline files smaller than 10 kB (10240 bytes)limit: 10 * 1024,// Remove the quotes from the url// (they’re unnecessary in most cases)noquotes: true,},},],}, };

注意: svg-url-loader 有一些選項可以改進Internet Explorer的支持，但會使其他瀏覽器的內聯更加糟糕。如果需要支持此瀏覽器，請應用 iesafe: true 選項。

image-webpack-loader

image-webpack-loader 可支持JPG、PNG、GIF和SVG圖像的壓縮。
這個加載器不嵌入圖像到應用程序，所以它必須與 url-loader 和 svg-url-loader 成對工作。為了避免將其復制粘貼到兩個規則中(一個用于JPG/PNG/GIF圖像，另一個用于SVG圖像)，我們通過 enforce: ‘pre’ 將這個加載器設為一個單獨的規則：

// webpack.config.js module.exports = {module: {rules: [{test: /\.(jpe?g|png|gif|svg)$/,loader: 'image-webpack-loader',// This will apply the loader before the other onesenforce: 'pre',},],}, };

壓縮圖片

參考：https://www.npmjs.com/package/image-webpack-loader

yarn add image-webpack-loader --dev //添加loader module: {rules: [{test: /\.(png|jpg|gif)$/i,use: [{loader: 'url-loader',options: {limit: 100,},},{loader: 'image-webpack-loader',options: {pngquant: {quality: [0.25, 0.60],speed: 4},},},],}]... }

使用 Tree Shaking:描述移除 JavaScript 上下文中的未引用代碼

參考:https://webpack.js.org/guides/tree-shaking/

tree shaking 是一個術語，通常用于描述移除 JavaScript 上下文中的未引用代碼(dead-code)。它依賴于 ES2015 模塊語法的靜態結構特性，例如 import 和 export。這個術語和概念實際上是由 ES2015 模塊打包工具 rollup 普及起來的。

+ mode: 'development', + optimization: { + usedExports: true, + }, };

webpack 2 正式版本內置支持 ES2015 模塊（也叫做 harmony modules）和未使用模塊檢測能力。新的 webpack 4 正式版本擴展了此檢測能力，通過 package.json 的 “sideEffects” 屬性作為標記，向 compiler 提供提示，表明項目中的哪些文件是 “pure(純的 ES2015 模塊)”，由此可以安全地刪除文件中未使用的部分。

test & include & exclude

減小文件搜索范圍，從而提升速度
示例

{test: /\.css$/,include: [path.resolve(__dirname, "app/styles"),path.resolve(__dirname, "vendor/styles")]}

小結

在這一章節中，我們學習了如何使用 Webpack 去進行性能優化以及如何減少打包時間。

Webpack 的版本更新很快，各個版本之間實現優化的方式可能都會有區別，所以我沒有使用過多的代碼去展示如何實現一個功能。這一章節的重點是學習到我們可以通過什么方式去優化，具體的代碼實現可以查找具體版本對應的代碼即可。

22、監控

前端監控一般分為三種，分別為頁面埋點、性能監控以及異常監控。

這一章節我們將來學習這些監控相關的內容，但是基本不會涉及到代碼，只是讓大家了解下前端監控該用什么方式實現。畢竟大部分公司都只是使用到了第三方的監控工具，而不是選擇自己造輪子。

PV是網站分析的一個術語，用以衡量網站用戶訪問的網頁的數量。對于廣告主，PV值可預期它可以帶來多少廣告收入。一般來說，PV與來訪者的數量成正比，但是PV并不直接決定頁面的真實來訪者數量，如同一個來訪者通過不斷的刷新頁面，也可以制造出非常高的PV。

1、什么是PV值

PV（page view）即頁面瀏覽量或點擊量，是衡量一個網站或網頁用戶訪問量。具體的說，PV值就是所有訪問者在24小時（0點到24點）內看了某個網站多少個頁面或某個網頁多少次。PV是指頁面刷新的次數，每一次頁面刷新，就算做一次PV流量。

度量方法就是從瀏覽器發出一個對網絡服務器的請求（Request），網絡服務器接到這個請求后，會將該請求對應的一個網頁（Page）發送給瀏覽器，從而產生了一個PV。那么在這里只要是這個請求發送給了瀏覽器，無論這個頁面是否完全打開（下載完成），那么都是應當計為1個PV。

2、什么是UV值

UV（unique visitor）即獨立訪客數，指訪問某個站點或點擊某個網頁的不同IP地址的人數。在同一天內，UV只記錄第一次進入網站的具有獨立IP的訪問者，在同一天內再次訪問該網站則不計數。UV提供了一定時間內不同觀眾數量的統計指標，而沒有反應出網站的全面活動。通過IP和cookie是判斷UV值的兩種方式：

用Cookie分析UV值

當客戶端第一次訪問某個網站服務器的時候，網站服務器會給這個客戶端的電腦發出一個Cookie，通常放在這個客戶端電腦的C盤當中。在這個Cookie中會分配一個獨一無二的編號，這其中會記錄一些訪問服務器的信息，如訪問時間，訪問了哪些頁面等等。當你下次再訪問這個服務器的時候，服務器就可以直接從你的電腦中找到上一次放進去的Cookie文件，并且對其進行一些更新，但那個獨一無二的編號是不會變的。

3、IP即獨立IP數

IP可以理解為獨立IP的訪問用戶，指1天內使用不同IP地址的用戶訪問網站的數量，同一IP無論訪問了幾個頁面，獨立IP數均為1。但是假如說兩臺機器訪問而使用的是同一個IP，那么只能算是一個IP的訪問。

IP和UV之間的數據不會有太大的差異，通常UV量和比IP量高出一點，每個UV相對于每個IP更準確地對應一個實際的瀏覽者。

①UV大于IP

這種情況就是在網吧、學校、公司等，公用相同IP的場所中不同的用戶，或者多種不同瀏覽器訪問您網站，那么UV數會大于IP數。

②UV小于IP

在家庭中大多數電腦使用ADSL撥號上網，所以同一個用戶在家里不同時間訪問您網站時，IP可能會不同，因為它會根據時間變動IP，即動態的IP地址，但是實際訪客數唯一，便會出現UV數小于IP數。

頁面埋點

頁面埋點應該是大家最常寫的監控了，一般起碼會監控以下幾個數據：

PV / UV
停留時長
流量來源
用戶交互

對于這幾類統計，一般的實現思路大致可以分為兩種，分別為手寫埋點和無埋點的方式。

相信第一種方式也是大家最常用的方式，可以自主選擇需要監控的數據然后在相應的地方寫入代碼。這種方式的靈活性很大，但是唯一的缺點就是工作量較大，每個需要監控的地方都得插入代碼。

另一種無埋點的方式基本不需要開發者手寫埋點了，而是統計所有的事件并且定時上報。這種方式雖然沒有前一種方式繁瑣了，但是因為統計的是所有事件，所以還需要后期過濾出需要的數據。

異常監控

對于異常監控來說，以下兩種監控是必不可少的，分別是代碼報錯以及接口異常上報。

腳本錯誤一般分為兩種：語法錯誤，運行時錯誤。

語法錯誤一般在編碼時就有觀測

Uncaught SyntaxError: Invalid or unexpected token xxx

運行時錯誤：

window.onerror-除跨域腳本、網絡異常、瀏覽器兼容

缺陷

對于跨域的代碼錯誤會顯示 Script error. 對于這種情況我們需要給 script 標簽添加 crossorigin 屬性
對于某些瀏覽器可能不會顯示調用棧信息，這種情況可以通過 arguments.callee.caller 來做棧遞歸
對于 onerror 這種全局捕獲，最好寫在所有 JS 腳本的前面，因為你無法保證你寫的代碼是否出錯，如果寫在后面，一旦發生錯誤的話是不會被 onerror 捕獲到的。
onerror 是無法捕獲到網絡異常的錯誤。

當我們遇到用戶訪問網站，圖片 CDN 無法服務，圖片加載不出來

報 404 網絡請求異常的時候，onerror 是無法幫助我們捕獲到異常的。

由于網絡請求異常不會事件冒泡，因此必須在捕獲階段將其捕捉到才行，
<script> window.addEventListener( 'error', (msg, rl, row, col, error) => {console.log('我知道 404 錯誤了');console.log(msg, url, row, col, error);return true;} , true);//捕獲 </script><img src="./404.png" alt="">
但是這種方式雖然可以捕捉到網絡請求的異常，但是無法判斷 HTTP 的狀態是 404 還是其他比如 500 等等，

所以還需要配合服務端日志才進行排查分析才可以。

catch：捕獲異步代碼、promise

try catch：捕獲 async await

缺陷：只能捕獲捉到運行時非異步錯誤，對于語法錯誤和異步錯誤就顯得無能為力，捕捉不到。

語法錯誤：一般不會帶上線

**異步錯誤：**如果錯誤發生在setTimeout中；除非你在異步代碼 setTimeout 函數中再套上一層 try-catch，否則就無法感知到其錯誤，但這樣代碼寫起來比較啰嗦。

Promise 全局異常捕獲事件 unhandledrejection

所以如果你的應用用到很多的 Promise 實例的話，特別是你在一些基于 promise 的異步庫比如 axios 等一定要小心，因為你不知道什么時候這些異步請求會拋出異常而你并沒有處理它，所以你最好添加一個

`window.addEventListener("unhandledrejection", function(e){e.preventDefault()console.log('我知道 promise 的錯誤了');console.log(e.reason);return true;});Promise.reject('promise error');new Promise((resolve, reject) => {reject('promise error');});new Promise((resolve) => {resolve();}).then(() => {throw 'promise error'});`

接口異常：列舉狀態碼的類型可以立即上報出錯

另外接口異常就相對來說簡單了，可以列舉出出錯的狀態碼。一旦出現此類的狀態碼就可以立即上報出錯。接口異常上報可以讓開發人員迅速知道有哪些接口出現了大面積的報錯，以便迅速修復問題。

異常上報方式

但是要注意線上運行的代碼都是壓縮過的，需要在打包時生成 sourceMap 文件便于 debug。

/***

@param {String} msg 錯誤信息

* @param {String} url 出錯文件

* @param {Number} row 行號

* @param {Number} col 列號

* @param {Object} error 錯誤詳細信息

*/window.onerror = function (msg, url, row, col, error) {

console.log('我知道錯誤了');

console.log({msg, url, row, col, error})

return true;};//window.onerror 函數只有在返回 true 的時候，異常才不會向上拋出

error;//否則控制臺顯示：Uncaught Error: xxxxx

對于捕獲的錯誤需要上傳給服務器，通常可以通過 img 標簽的 src 發起一個請求。

監控拿到報錯信息之后，接下來就需要將捕捉到的錯誤信息發送到信息收集平臺上，常用的發送形式主要有兩種:

通過 Ajax 發送數據

動態創建 img 標簽的形式

實例 - 動態創建 img 標簽進行上報

function report(error) {var reportUrl = 'http://xxxx/report';new Image().src = reportUrl + 'error=' + error;}

vue項目的異常處理

vue提供了一個全局配置 errorHandle,，用于收集Vue運行時發生的錯誤。

Vue.config.errorHandler = function (err, vm, info) { // handle error // `info` 是 Vue 特定的錯誤信息，比如錯誤所在的生命周期鉤子 // 只在 2.2.0+ 可用 let componentName = formatComponentName(vm);} // 獲取組件的名稱 function formatComponentName(vm) { if (vm.$root === vm) return 'root'; let name = vm._isVue ? (vm.$options && vm.$options.name) || (vm.$options && vm.$options._componentTag): vm.name; return ( (name ? 'component <' + name + '>' : 'anonymous component') +(vm._isVue && vm.$options && vm.$options.__file ? ' at ' + (vm.$options && vm.$options.__file): '') );}

拿到vue對應的實例之后，就可以獲取vue對應的組件名稱，定位到是哪一個組件報錯；

性能監控

性能監控可以很好的幫助開發者了解在各種真實環境下，頁面的性能情況是如何的。

對于性能監控來說，我們可以直接使用瀏覽器自帶的 Performance API 來實現這個功能。

對于性能監控來說，其實我們只需要調用 performance.getEntriesByType('navigation') 這行代碼就行了。對，你沒看錯，一行代碼我們就可以獲得頁面中各種詳細的性能相關信息

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-rJ6Ntgjf-1597843082634)(file:///C:/Users/29150/Desktop/%E5%89%8D%E7%AB%AF%E9%9D%A2%E8%AF%95%E4%B9%8B%E9%81%93/24-%E7%9B%91%E6%8E%A7_files/168c82d1976cc115)][外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-O1GB6OZf-1597843082636)(C:\Users\29150\AppData\Roaming\Typora\typora-user-images\image-20200602084157858.png)]

我們可以發現這行代碼返回了一個數組，內部包含了相當多的信息，從數據開始在網絡中傳輸到頁面加載完成都提供了相應的數據。

[PerformanceNavigationTiming]

0: PerformanceNavigationTiming

unloadEventStart: 0

unloadEventEnd: 0

domInteractive: 3514.37999999996

domContentLoadedEventStart: 3514.4899999999666

domContentLoadedEventEnd: 3514.499999999998

domComplete: 5213.5649999999605

loadEventStart: 5213.635000000011

loadEventEnd: 5213.774999999998

type: “navigate”

redirectCount: 0

initiatorType: “navigation”

nextHopProtocol: “http/1.1”

workerStart: 0

redirectStart: 0

redirectEnd: 0

fetchStart: 12.564999999995052

domainLookupStart: 12.564999999995052

domainLookupEnd: 12.564999999995052

connectStart: 12.564999999995052

connectEnd: 12.564999999995052

secureConnectionStart: 0

requestStart: 16.705000000001746

responseStart: 398.3299999999872

responseEnd: 399.4449999999574

transferSize: 0

encodedBodySize: 710

decodedBodySize: 1256

serverTiming: Array(0)

length: 0

proto: Array(0)

name: “https://www.gaosiedu.com/”

entryType: “navigation”

startTime: 0

duration: 5213.774999999998

proto: PerformanceNavigationTiming

length: 1

proto: Array(0)

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-uCG6YrB9-1597843082637)(file:///C:/Users/29150/Desktop/%E5%89%8D%E7%AB%AF%E9%9D%A2%E8%AF%95%E4%B9%8B%E9%81%93/24-%E7%9B%91%E6%8E%A7_files/168c82e5cc721387)]

1、為什么要監控性能？

性能收益

Google 延遲 400ms	搜索量下降 0.59%
Bing 延遲 2s	收入下降 4.3%
Yahoo 延遲 400ms	流量下降 5-9%
Mozilla 頁面打開減少 2.2s	下載量提升 15.4%
Netflix 開啟 Gzip	性能提升 13.25% 帶寬減少50%

根本原因還是在于性能影響了用戶體驗。加載的延遲、操作的卡頓等都會影響用戶的使用體驗。尤其是移動端，用戶對頁面響應延遲和連接中斷的容忍度很低。我們需要一套性能監控系統持續監控、評估、預警頁面性能狀況、發現瓶頸，指導優化工作的進行。

2、有什么可用的工具？

Page Speed、webpagetest,是谷歌開發的分析和優化網頁的工具，

為了持續監控不同網絡環境下用戶訪問情況與頁面各功能可用狀況，我們選擇在頁面中植入 JS 來監控線上真實用戶訪問性能，同時利用已有的分析工具作為輔助，形成一套完整多元的數據監控體系，為產品線的評估與優化提供可靠的數據。

3、真實用戶性能監控

關于不同監控方式的簡單對比可以查看下表：

類型優點缺點示例

非侵入式	指標齊全、客戶端主動監測、競品監控	無法知道性能影響用戶數、采樣少容易失真、無法監控復雜應用與細分功能	Pagespeed、PhantomJS、UAQ
侵入式	真實海量用戶數據、能監控復雜應用與業務功能、用戶點擊與區域渲染	需插入腳本統計、網絡指標不全、無法監控競品	DP 、Google 統計

4、如何采集性能數據？

線上監控哪些指標呢？如何更好地反映用戶感知？

對于用戶來說他感覺到的為什么頁面打不開、為什么按鈕點擊不了、為什么圖片顯示這么慢。

而對于工程師來說，可能關注的是 DNS 查詢、TCP 連接、服務響應等瀏覽器加載過程指標。

我們根據用戶的痛點，

將瀏覽器加載過程抽取出四個關鍵指標，即白屏時間、首屏時間、用戶可操作、總下載時間

這些指標是如何統計的呢？

確定統計起點

我們需要在用戶輸入 URL 或者點擊鏈接的時候就開始統計，因為這樣才能衡量用戶的等待時間。如果你的用戶高端瀏覽器占比很高，那么可以直接使用Navigation Timing接口來獲取統計起點以及加載過程中的各個階段耗時。另外也可以通過 cookie 記錄時間戳的方式來統計，需要注意的是 Cookie 方式只能統計到站內跳轉的數據。

統計白屏時間

白屏時間是用戶首次看到內容的時間，也叫做首次渲染時間，chrome 高版本有 firstPaintTime 接口來獲取這個耗時，但大部分瀏覽器并不支持，必須想其他辦法來監測。仔細觀察 WebPagetest 視圖分析發現，白屏時間出現在頭部外鏈資源加載完附近，因為瀏覽器只有加載并解析完頭部資源才會真正渲染頁面。基于此我們可以通過獲取頭部資源加載完的時刻來近似統計白屏時間。盡管并不精確，但卻考慮了影響白屏的主要因素：首字節時間和頭部資源加載時間。

如何統計頭部資源加載呢？我們發現頭部內嵌的 JS 通常需等待前面的 JS\CSS 加載完才會執行，是不是可以在瀏覽器 head 內底部加一句 JS 統計頭部資源加載結束點呢？可以通過一個簡單的示例進行測試：

<!DOCTYPE HTML> <html><head><meta charset="UTF-8"/><script>var start_time = +new Date; //測試時間起點，實際統計起點為 DNS 查詢</script><script src="script.php"></script> <script>var end_time = +new Date; //時間終點var headtime = end_time - start_time; //頭部資源加載時間 console.log(headtime);</script></head> <body> <p>在頭部資源加載完之前頁面將是白屏</p><p>script.php 被模擬設置 3s 后返回，head 底部內嵌 JS 等待前面 js 返回后才執行</p><p>script.php 替換成一個執行長時間循環的 js 效果也一樣</p> </body> </html>

經測試發現，統計的頭部加載時間正好跟頭部資源下載時間相近，而且換成一個執行時間很長的 JS 也會等到 JS 執行完才統計。說明此方法是可行的(具體原因可查看瀏覽器渲染原理及 JS 單線程相關介紹)。

統計首屏時間

首屏時間的統計比較復雜，因為涉及圖片等多種元素及異步渲染等方式。觀察加載視圖可發現，影響首屏的主要因素的圖片的加載。通過統計首屏內圖片的加載時間便可以獲取首屏渲染完成的時間。統計流程如下：

首屏位置調用 API 開始統計 -> 綁定首屏內所有圖片的 load 事件 -> 頁面加載完后判斷圖片是否在首屏內，找出加載最慢的一張 -> 首屏時間

這是同步加載情況下的簡單統計邏輯，另外需要注意的幾點：

頁面存在 iframe 的情況下也需要判斷加載時間
gif 圖片在 IE 上可能重復觸發 load 事件需排除
異步渲染的情況下應在異步獲取數據插入之后再計算首屏
css 重要背景圖片可以通過 JS 請求圖片 url 來統計(瀏覽器不會重復加載)
沒有圖片則以統計 JS 執行時間為首屏，即認為文字出現時間

統計用戶可操作和總下載

用戶可操作默認可以統計domready時間，因為通常會在這時候綁定事件操作。對于使用了模塊化異步加載的 JS 可以在代碼中去主動標記重要 JS 的加載時間，這也是產品指標的統計方式。

總下載時間默認可以統計onload時間，這樣可以統計同步加載的資源全部加載完的耗時。如果頁面中存在很多異步渲染，可以將異步渲染全部完成的時間作為總下載時間。

網絡指標

網絡類型判斷

對于移動端來說，網絡是頁面加載速度最大的影響因素，需要根據不同的網絡來采取相應的優化措施，例如對于 2G 用戶采用簡版等。但 web 上沒有接口獲取用戶的網絡類型。為了獲取用戶網絡類型，可以通過測速的方式來判斷不同 IP 段對應的網絡。測速例如比較經典的有 facebook 的方案。經過測速后的分析，用戶的加載速率有明顯的分布區間，如下圖所示：

各個分布區間正好對應不同的網絡類型，經過與客戶端的輔助測試，成功率可以在 95%以上。有了這個 IP 庫對應的速率數據，就可以在分析用戶數據時根據 IP 來判斷用戶網絡類型。

網絡耗時統計

網絡耗時數據可以借助前面提到 Navigation Timing 接口獲取，與之類似的還有Resource Timing,可以獲取頁面所有靜態資源的加載耗時。通過此接口可以輕松獲取 DNS、TCP、首字節、html 傳輸等耗時，Navigation Timing 的接口示意圖如下所示：

以上重點介紹了數據采集部分，這也是系統中最關鍵的一部分，只有保證數據能真實反映用戶感知，才能對癥下藥提升用戶體驗。數據采集完之后我們可以在頁面加載完之后統一上報，如示例：

http://xxx.baidu.com/tj.gif?dns=100&ct=210&st=300&tt=703&c_dnslookup=0&c_connecting=0&c_waiting=296&c_receiving=403&c_fetch_dns=0&c_nav_dns=75&c_nav_fetch=75&drt=1423&drt_end=1436&lt=3410&c_nfpt=619&nav_type=0&redirect_count=0&_screen=1366*768|1366*728&product_id=10&page_id=200&_t=1399822334414

### Day 5 如何分析性能數據？

讓數據會說話

而數據分析過程，如前一篇文章所述，可以從多個維度去分析數據。大數據處理需要借助 hadoop、Hive 等方式，而對于普通站點則任意一種后端語言處理即可。

均值與分布

均值與分布是數據處理中最常見的兩種方式。因為它能直觀的表示指標的趨勢與分布狀況，方便進行評估、瓶頸發現與告警。處理過程中應去除異常值，例如明顯超過閾值的臟數據等。

耗時的評估中，有很多這方面的研究數據。例如有人提出三個基本的時間范圍：

0.1秒 : 0.1 秒是用戶感知的最小粒度，在這個時間范圍內完成的操作被認為是流暢沒有延遲的
1.0秒 : 1.0 秒內完成的響應認為不會干擾用戶的思維流。盡管用戶能感覺到延遲，但 0.1 秒 -1.0 秒內完成的操作并不需要給出明顯 loading 提示
10秒 : 達到 10 秒用戶將無法保持注意力，很可能選擇離開做其他事情

我們根據業界的一些調研，結合不同指標的特點，制定了指標的分布評估區間。如下圖所示：

評估區間的制定方便我們了解當前性能狀況，同時對性能趨勢波動做出反應。

多維分析

為了方便挖掘性能可能的瓶頸，需要從多維的角度對數據進行分析。例如移動端最重要的維度就是網絡，數據處理上除了總體數據，還需要根據網絡類型對數據進行分析。常見的維度還有系統、瀏覽器、地域運營商等。我們還可以根據自身產品的特點來確定一些維度，例如頁面長度分布、簡版炫版等。

需要注意的是維度并不是越多越好，需要根據產品的特點及終端來確定。維度是為了方便查找性能瓶頸。

小插曲 ：之前從微博中看到有人評價說想做監控但是公司沒有日志服務器。并不需要單獨的日志服務器,只要能把統計的這個請求訪問日志保存下來即可。如果網站自己的獨立服務器都沒有還有解決辦法，在百度開發者中心新建一個應用，寫一個簡單的 Web 服務將接收到的統計數據解析存到百度云免費的數據庫中，然后每天再用 Mysql 處理下當天的數據即可，對于普通站點的抽樣性能數據應該沒問題。請叫我雷鋒。

5、如何利用監控數據解決問題？

發現瓶頸，對癥下藥

對于圖表制作，比較出名的有Highcharts，百度開發的Echarts也很不錯。不管使用什么工具，最關鍵的一點就是讓報表能突出重點，直觀明了。

制作報表前多問幾個如何讓人直觀看到目前狀況和可能存在的問題，哪些地方可以加強，哪些可以去掉，使用是否習慣等。

有了能反映用戶感知的真實世界、并且細分到各個業務功能，有詳細的網絡等輔助數據，我們在解決前端性能上便更加得心應手。監控系統已經對線上訪問狀況有了連續的反饋，根據現有評估與瓶頸選擇對應方案進行優化，最后根據反饋進行調整，相信性能優化不再是個難題。

如何選擇優化方案呢？這又是一個比較大的話題了，好在已經有很多經驗可以借鑒。附錄中就整理了部分性能的學習資料，可以根據需要閱讀學習。

6、總結

通過以上“幾天”的努力，我們可以搭建一個小而美的前端性能監控系統。但這僅僅是開始，前端數據有很多挖掘的價值。性能優化也是一門需要認真學習的課程，為了打造流暢的使用體驗，為了讓用戶更加滿意，趕緊搭建起自己的前端數據平臺吧!

總結

以上是生活随笔為你收集整理的前端面试超全整理3（webpack性能优化及监控）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。

上一篇： MyChrome制作Chrome浏览器便
下一篇：移动web前端框架一、jQuery Mo