前端面试超全整理3（webpack性能优化及监控）
21、Webpack 性能優(yōu)化
核心概念
Entry :入口
output:出口
Plugins: 插件，執(zhí)行范圍更廣的任務(wù)。插件的范圍包括，從打包優(yōu)化和壓縮，一直到重新定義環(huán)境中的變量
Loader：翻譯官，把瀏覽器不識別的內(nèi)容做轉(zhuǎn)換
研發(fā)環(huán)境
依賴包：啟動 webpack-dev-server --config webpack.config.dev.jswebpack webpack-cli //基礎(chǔ)依賴 webpack-dev-server -D //熱更新 //將css文件提取為獨立的文件的插件 mini-css-extract-plugin -D html-webpack-plugin -D // 將模板文件和js文件整合到一塊 CopyWebpackPlugin -D //將靜態(tài)資源拷貝到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 = {//開發(fā)模式：development，代碼調(diào)試， 生產(chǎn)模式：production ,代碼壓縮，優(yōu)化//如果mode不配置，會有警告提示信息mode: "development",//開發(fā)模式//代碼調(diào)試，可以看到源代碼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: [//它將創(chuàng)建一個html文件，將打包好的各種如js、css模塊引用進去,并通過提供的各種參數(shù)完成多種處理new htmlWebpackPlugin({title: 'webpack demo home',//模板文件路徑template: "./src/views/index.html",//自動存儲到output 配置的目錄filename: 'index.html',//這個就表示當前實例僅引入chunk名為main的模塊chunks: ['main']}),//自動更新根據(jù)文件名自動更換css文件new MiniCssExtractPlugin({//頁面引用的樣式文件名filename: '[name]-[hash].css',// chunkFilename: 'common.css',}),new CopyWebpackPlugin([{from: './src/static', to: './static' //相對于output 里面配置的path:./}])],//翻譯官，把瀏覽器不識別的內(nèi)容做轉(zhuǎn)換module: {//解析規(guī)則rules: [//解析scss{test: /\.s[ac]ss$/,//執(zhí)行順序：從右向左use: [// 將 JS 字符串生成為 style 節(jié)點'style-loader',// MiniCssExtractPlugin.loader,//將 CSS 轉(zhuǎn)化成 CommonJS 模塊'css-loader',//把.scss文件文件轉(zhuǎn)換為.css文件'sass-loader']},//解析html{test: /\.html$/,use: ['string-loader']}]} }在這一的章節(jié)中，我不會浪費篇幅給大家講如何寫配置文件。如果你想學(xué)習(xí)這方面的內(nèi)容，那么完全可以去官網(wǎng)學(xué)習(xí)。在這部分的內(nèi)容中，我們會聚焦于以下兩個知識點，并且每一個知識點都屬于高頻考點：
- 有哪些方式可以減少 Webpack 的打包時間
- 有哪些方式可以讓 Webpack 打出來的包更小
1、noParse:
該配置是作為 module 的一個屬性值，即不解析某些模塊，所謂不解析，就是不去分析某個模塊中的依賴關(guān)系，即不去管某個文件是否 import(依賴)了某個文件，對于一些獨立的庫，比如 jquery，其根本不存在依賴關(guān)系，jquery 不會去引入其他的庫(要根據(jù)自己對某個模塊的了解去判斷是否要解析該模塊)，所以我們可以讓 webpack 不去解析 jquery 的依賴關(guān)系，提高打包速度，如:
module.exports = {module: {noParse:/jquery/,//不去解析jquery中的依賴庫} }noParse 是 module 配置中的一個屬性，其屬性值為一個正則表達式，填入不被解析的模塊名稱。
為了更清楚的展示 noParse 的作用，假設(shè)我們在入口文件 index.js 中引入 bar.js 模塊，同時這個 bar.js 模塊中也引入了 foo.js 模塊，foo.js 不再依賴其他模塊了，那么在不使用 noParse 的情況下，webpack 打包的時候，會先去分析 index.js 模塊，發(fā)現(xiàn)其引入了 bar.js 模塊，然后接著分析 bar.js 模塊，發(fā)現(xiàn)其引入了 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 模塊，發(fā)現(xiàn)其引入了 bar.js 模塊，但是由于 noParse 的作用，將不再繼續(xù)解析 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 排除對某些目錄中的文件處理，即引入指定目錄下的文件時候，不使用對應(yīng)的 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 包中包含了各種語言輸出對應(yīng)時間的 js 文件，time 包下的 index.js 會引入 lang 包下所有的 js 文件，那么當我們引入 time 模塊的時候，就會將 lang 包下的所有 js 文件都打包進去，添加如下配置:
const webpack = require("webpack"); module.exports = {plugins: [new webpack.IgnorePlugin(/lang/, /time/)] }引入 time 模塊的時候，如果 time 模塊中引入了其中的 lang 模塊中的內(nèi)容，那么就忽略掉，即不引入 lang 模塊中的內(nèi)容，需要注意的是，這 /time/ 只是匹配文件夾和 time 模塊的具體目錄位置無關(guān)，即只要是引入了目錄名為 time 中的內(nèi)容就會生效。
4、使用 HappyPack：
**4、使用 HappyPack：**由于在打包過程中有大量的文件需要交給 loader 進行處理，包括解析和轉(zhuǎn)換等操作，而由于 js 是單線程的，所以這些文件只能一個一個地處理，而 HappyPack 的工作原理就是充分發(fā)揮 CPU 的多核功能，將任務(wù)分解給多個子進程去并發(fā)執(zhí)行，子進程處理完后再將結(jié)果發(fā)送給主進程，happypack 主要起到一個任務(wù)劫持的作用，在創(chuàng)建 HappyPack 實例的時候要傳入對應(yīng)文件的 loader，即 use 部分，loader 配置中將使用經(jīng)過 HappyPack 包裝后的 loader 進行處理，如:
module.exports = {plugins: [new HappyPack({ // 這里對處理css文件的loader進行包裝id: "css",// 之前的loader根據(jù)具體的id進行引入use: ["style-loader","css-loader"],threads: 5 // 設(shè)置開啟的進程數(shù)})],module: {rules: [{test: /\.css$/, // 匹配以.css結(jié)尾的文件use: ["happypack/loader?id=css"] //根據(jù)happypack實例中配置的id引入包裝后的laoder，這里的happyPack的h可以大寫也可以小寫}]} }webpack 要打包的文件非常多的時候才需要使用 happypack 進行優(yōu)化，因為開啟多進程也是需要耗時間的，所以文件少的時候，使用 happypack 返回更耗時
5、抽離公共模塊:
5、抽離公共模塊: 對于多入口情況，如果某個或某些模塊，被兩個以上文件所依賴，那么可以將這個模塊單獨抽離出來，不需要將這些公共的代碼都打包進每個輸出文件中，這樣會造成代碼的重復(fù)和流量的浪費，即如果有兩個入口文件 index.js 和 other.js，它們都依賴了 foo.js，那么如果不抽離公共模塊，那么 foo.js 中的代碼都會打包進最終輸出的 index.js 和 other.js 中去，即有兩份 foo.js 了。抽離公共模塊也很簡單，直接在 optimization 中配置即可，如:
module.exports = {splitChunks: { // 分割代碼塊，即抽離公共模塊cacheGroups: { // 緩存組common: { // 組名為common可自定義chunks: "initial",minSize: 0, // 文件大小為0字節(jié)以上才抽離minChunks: 2, // 被引用過兩次才抽離name: "common/foo", // 定義抽離出的文件的名稱}}} }這樣就會將公共的 foo.js 模塊抽離到 common 目錄下 foo.js 中了，但是如果我們也有多個文件依賴了第三方模塊如 jquery，如果按以上配置，那么 jquery 也會被打包進 foo.js 中，會導(dǎo)致代碼混亂，所以我們希望將 jquery 單獨抽出來，即與 foo.js 分開，我們可以復(fù)制一份以上配置，并通過設(shè)置抽離代碼權(quán)重的方式來實現(xiàn)，即優(yōu)先抽離出 jquery，如:
module.exports = {splitChunks: { // 分割代碼塊，即抽離公共模塊cacheGroups: { // 緩存組common: { // 組名為common可自定義chunks: "initial",minSize: 0, // 文件大小為0字節(jié)以上才抽離minChunks: 2, // 被引用過兩次才抽離name: "common/foo", // 定義抽離出的文件的名稱},verdor: {test: /node_modules/,priority: 1, // 設(shè)置打包權(quán)重，即優(yōu)先抽離第三方模塊chunks: "initial",minSize: 0, // 文件大小為0字節(jié)以上才抽離minChunks: 2, // 被引用過兩次才抽離name: "common/jquery", // 定義抽離出的文件的名稱}}} }這樣就會在 common 目錄下同時抽離出 foo.js 和 jquery.js 了，需要注意的是，代碼的抽離必須是該模塊沒有被排除打包，即該模塊會被打包進輸出 bundle 中，如果第三方模塊已經(jīng)通過 externals 排除打包，則以上 vendor 配置無效。
6、按需加載
**6、按需加載，**即在需要使用的時候才打包輸出，webpack 提供了 import() 方法，傳入要動態(tài)加載的模塊，來動態(tài)加載指定的模塊，當 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 實現(xiàn)動態(tài)加載，返回的 res 結(jié)果不同的 export 方式會有不同，如果使用的 module.exports 輸出，那么返回的 res 就是 module.exports 輸出的結(jié)果；如果使用的是 ES6 模塊輸出，即 export default 輸出，那么返回的 res 結(jié)果就是 res.default，如:
// ES6模塊輸出，res結(jié)果為
{default: "foo", __esModule: true, Symbol(Symbol.toStringTag): "Module"}7、開啟模塊熱更新:
7、開啟模塊熱更新: 模塊熱更新可以做到在不刷新網(wǎng)頁的情況下，更新修改的模塊，只編譯變化的模塊，而不用全部模塊重新打包，大大提高開發(fā)效率，在未開啟熱更新的情況下，每次修改了模塊，都會重新打包。
要開啟模塊熱更新，那么只需要在 devServer 配置中添加 hot:true 即可。當然僅僅開啟模塊熱更新是不夠的，我們需要做一些類似監(jiān)聽的操作，當監(jiān)聽的模塊發(fā)生變化的時候，重新加載該模塊并執(zhí)行，如:
module.exports = {devServer: {hot: true // 開啟熱更新} }----------import foo from "./foo"; console.log(foo); if (module.hot) {module.hot.accept("./foo", () => { // 監(jiān)聽到foo模塊發(fā)生變化的時候const foo = require("./foo"); // 重新引入該模塊并執(zhí)行console.log(foo);}); }如果不使用 module.hot.accept 監(jiān)聽，那么當修改 foo 模塊的時候還是會刷新頁面的
減少 Webpack 打包后的文件體積
注意：該內(nèi)容也屬于性能優(yōu)化領(lǐng)域。
按需加載
想必大家在開發(fā) SPA 項目的時候，項目中都會存在十幾甚至更多的路由頁面。如果我們將這些頁面全部打包進一個 JS 文件的話，雖然將多個請求合并了，但是同樣也加載了很多并不需要的代碼，耗費了更長的時間。那么為了首頁能更快地呈現(xiàn)給用戶，我們肯定是希望首頁能加載的文件體積越小越好，這時候我們就可以使用按需加載，將每個路由頁面單獨打包為一個文件。當然不僅僅路由可以按需加載，對于 loadash 這種大型類庫同樣可以使用這個功能。
按需加載的代碼實現(xiàn)這里就不詳細展開了，因為鑒于用的框架不同，實現(xiàn)起來都是不一樣的。當然了，雖然他們的用法可能不同，但是底層的機制都是一樣的。都是當使用的時候再去下載對應(yīng)文件，返回一個 Promise，當 Promise 成功以后去執(zhí)行回調(diào)。
Scope Hoisting
Scope Hoisting 會分析出模塊之間的依賴關(guān)系，盡可能的把打包出來的模塊合并到一個函數(shù)中去。
比如我們希望打包兩個文件
// 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 的話，代碼就會盡可能的合并到一個函數(shù)中去，也就變成了這樣的類似代碼
[/* 0 */function (module, exports, require) {//...} ]這樣的打包方式生成的代碼明顯比之前的少多了。如果在 Webpack4 中你希望開啟這個功能，只需要啟用 optimization.concatenateModules 就可以了。
module.exports = {optimization: {concatenateModules: true} }Tree Shaking
Tree Shaking 可以實現(xiàn)刪除項目中未被引用的代碼，比如
// test.js export const a = 1 export const b = 2 // index.js import { a } from './test.js'對于以上情況，test 文件中的變量 b 如果沒有在項目中使用到的話，就不會被打包到文件中。
如果你使用 Webpack 4 的話，開啟生產(chǎn)環(huán)境就會自動啟動這個優(yōu)化功能。
外圍擴展 externals
webpack的配置選項，externals 配置選項提供了「從輸出的 bundle 中排除依賴」的方法。相反，所創(chuàng)建的 bundle 依賴于那些存在于用戶環(huán)境(consumer’s environment)中的依賴。此功能通常對 library 開發(fā)人員來說是最有用的，然而也會有各種各樣的應(yīng)用程序用到它。
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],靜態(tài)資源發(fā)布CDN后webpack的配置
output: {path: path.resolve(__dirname, 'public/assets'),publicPath: 'https://cdn.example.com/assets/'}使用 HappyPack：
由于在打包過程中有大量的文件需要交給 loader 進行處理，包括解析和轉(zhuǎn)換等操作，而由于 js 是單線程的，所以這些文件只能一個一個地處理，而 HappyPack 的工作原理就是充分發(fā)揮 CPU 的多核功能，將任務(wù)分解給多個子進程去并發(fā)執(zhí)行，子進程處理完后再將結(jié)果發(fā)送給主進程，happypack 主要起到一個任務(wù)劫持的作用，在創(chuàng)建 HappyPack 實例的時候要傳入對應(yīng)文件的 loader，即 use 部分，loader 配置中將使用經(jīng)過 HappyPack 包裝后的 loader 進行處理，如:
module.exports = {plugins: [new HappyPack({ // 這里對處理css文件的loader進行包裝id: "css",// 之前的loader根據(jù)具體的id進行引入use: ["style-loader","css-loader"],threads: 5 // 設(shè)置開啟的進程數(shù)})],module: {rules: [{test: /\.css$/, // 匹配以.css結(jié)尾的文件use: ["happypack/loader?id=css"] //根據(jù)happypack實例中配置的id引入包裝后的laoder，這里的happyPack的h可以大寫也可以小寫}]} }webpack 要打包的文件非常多的時候才需要使用 happypack 進行優(yōu)化，因為開啟多進程也是需要耗時間的，所以文件少的時候，使用 happypack 返回更耗時
靜態(tài)資源上傳到CDN
/*** 發(fā)布靜態(tài)文件到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 靜態(tài)資源目錄 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
減少構(gòu)建時間，進行分離打包。
DllPlugin這個插件是在一個額外的獨立的 webpack 設(shè)置中創(chuàng)建一個只有 dll 的 bundle(dll-only-bundle)。 這個插件會生成一個名為 manifest.json 的文件，這個文件是用來讓 DLLReferencePlugin 映射到相關(guān)的依賴上去的。
CommonsChunkPlugin (<4.0)通過將公共模塊拆出來緩存
通過將公共模塊拆出來，最終合成的文件能夠在最開始的時候加載一次，便存到緩存中供后續(xù)使用。這個帶來速度上的提升，因為瀏覽器會迅速將公共的代碼從緩存中取出來，而不是每次訪問一個新頁面時，再去加載一個更大的文件。
如果把公共文件提取出一個文件，那么當用戶訪問了一個網(wǎng)頁，加載了這個公共文件，再訪問其他依賴公共文件的網(wǎng)頁時，就直接使用文件在瀏覽器的緩存，這樣公共文件就只用被傳輸一次。
SplitChunkPlugin
起初，chunks(代碼塊)和導(dǎo)入他們中的模塊通過webpack內(nèi)部的父子關(guān)系圖連接.在webpack3中，通過CommonsChunkPlugin來避免他們之間的依賴重復(fù)。而在webpack4中CommonsChunkPlugin被移除，取而代之的是 optimization.splitChunks 和 optimization.runtimeChunk 配置項，下面展示它們將如何工作。
在默認情況下，SplitChunksPlugin 僅僅影響按需加載的代碼塊，因為更改初始塊會影響HTML文件應(yīng)包含的腳本標記以運行項目。
webpack將根據(jù)以下條件自動拆分代碼塊：
。
UglifyJSPlugin分析JS代碼語法樹\去掉無效代碼
基本上腳手架都包含了該插件,該插件會分析JS代碼語法樹，理解代碼的含義，從而做到去掉無效代碼、去掉日志輸入代碼、縮短變量名等優(yōu)化。
const UglifyJSPlugin = require('webpack/lib/optimize/UglifyJsPlugin');//...plugins: [new UglifyJSPlugin({compress: {warnings: false, //刪除無用代碼時不輸出警告drop_console: true, //刪除所有console語句，可以兼容IEcollapse_vars: true, //內(nèi)嵌已定義但只使用一次的變量reduce_vars: true, //提取使用多次但沒定義的靜態(tài)值到變量},output: {beautify: false, //最緊湊的輸出，不保留空格和制表符comments: false, //刪除所有注釋}})]CSS樣式處理
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: [//執(zhí)行順序，從有向左{ loader: "style-loader" },{ loader: "css-loader" }]},plugins: [...,new MiniCssExtractPlugin({filename: '[name].css',chunkFilename: '[id].css',}),]};css 壓縮優(yōu)化：
const OptimizeCSSAssetsPlugin = require('optimize-css-assets-webpack-plugin');。。。optimization: {minimizer: [new OptimizeCSSAssetsPlugin({})],}DefinePlugin
DefinePlugin能夠自動檢測環(huán)境變化，效率高效。
在前端開發(fā)中，在不同的應(yīng)用環(huán)境中，需要不同的配置。如：開發(fā)環(huán)境的API Mocker、測試流程中的數(shù)據(jù)偽造、打印調(diào)試信息。如果使用人工處理這些配置信息，不僅麻煩，而且容易出錯。
使用DefinePlugin配置的全局常量
注意，因為這個插件直接執(zhí)行文本替換，給定的值必須包含字符串本身內(nèi)的實際引號。通常，有兩種方式來達到這個效果，使用 ’ “production” ', 或者使用
測試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清除不可達代碼。
最后的打包打包代碼會變成console.log(‘This is prod’)
附Uglify文檔：github.com/mishoo/Ugli…
使用DefinePlugin區(qū)分環(huán)境 + UglifyJsPlugin清除不可達代碼，以減輕打包代碼體積
HappyPack
HappyPack可以開啟多進程Loader轉(zhuǎn)換，將任務(wù)分解給多個子進程，最后將結(jié)果發(fā)給主進程。
使用
ParallelUglifyPlugin
ParallelUglifyPlugin可以開啟多進程壓縮JS文件import ParallelUglifyPlugin from 'webpack-parallel-uglify-plugin';module.exports = {plugins: [new ParallelUglifyPlugin({test,include,exclude,cacheDir,workerCount,sourceMap,uglifyJS: {},uglifyES: {}}),],};壓縮圖片資源
圖像占了頁面大小的一半以上。雖然它們不像JavaScript那樣重要(例如，它們不會阻塞呈現(xiàn))，但它們?nèi)匀徽加昧撕艽笠徊糠謳挕Ｔ?webpack 中可以使用 url-loader、svg-url-loader 和 image-webpack-loader 來優(yōu)化它們。
url-loader
參見：項目 webpack-css
url-loader 可以將小型靜態(tài)文件內(nèi)聯(lián)到應(yīng)用程序中。如果不進行配置，它將把接受一個傳遞的文件，將其放在已編譯的包旁邊，并返回該文件的url。但是，如果指定 limit 選項，它將把小于這個限制的文件編碼為Base64 數(shù)據(jù)的 url 并返回這個url，這會將圖像內(nèi)聯(lián)到 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 請求數(shù)之前進行權(quán)衡。
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的支持，但會使其他瀏覽器的內(nèi)聯(lián)更加糟糕。如果需要支持此瀏覽器，請應(yīng)用 iesafe: true 選項。
image-webpack-loader
image-webpack-loader 可支持JPG、PNG、GIF和SVG圖像的壓縮。
這個加載器不嵌入圖像到應(yīng)用程序，所以它必須與 url-loader 和 svg-url-loader 成對工作。為了避免將其復(fù)制粘貼到兩個規(guī)則中(一個用于JPG/PNG/GIF圖像，另一個用于SVG圖像)，我們通過 enforce: ‘pre’ 將這個加載器設(shè)為一個單獨的規(guī)則：
壓縮圖片
參考：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 是一個術(shù)語，通常用于描述移除 JavaScript 上下文中的未引用代碼(dead-code)。它依賴于 ES2015 模塊語法的 靜態(tài)結(jié)構(gòu) 特性，例如 import 和 export。這個術(shù)語和概念實際上是由 ES2015 模塊打包工具 rollup 普及起來的。
+ mode: 'development', + optimization: { + usedExports: true, + }, };webpack 2 正式版本內(nèi)置支持 ES2015 模塊（也叫做 harmony modules）和未使用模塊檢測能力。新的 webpack 4 正式版本擴展了此檢測能力，通過 package.json 的 “sideEffects” 屬性作為標記，向 compiler 提供提示，表明項目中的哪些文件是 “pure(純的 ES2015 模塊)”，由此可以安全地刪除文件中未使用的部分。
test & include & exclude
減小文件搜索范圍，從而提升速度
示例
小結(jié)
在這一章節(jié)中，我們學(xué)習(xí)了如何使用 Webpack 去進行性能優(yōu)化以及如何減少打包時間。
Webpack 的版本更新很快，各個版本之間實現(xiàn)優(yōu)化的方式可能都會有區(qū)別，所以我沒有使用過多的代碼去展示如何實現(xiàn)一個功能。這一章節(jié)的重點是學(xué)習(xí)到我們可以通過什么方式去優(yōu)化，具體的代碼實現(xiàn)可以查找具體版本對應(yīng)的代碼即可。
22、監(jiān)控
前端監(jiān)控一般分為三種，分別為頁面埋點、性能監(jiān)控以及異常監(jiān)控。
這一章節(jié)我們將來學(xué)習(xí)這些監(jiān)控相關(guān)的內(nèi)容，但是基本不會涉及到代碼，只是讓大家了解下前端監(jiān)控該用什么方式實現(xiàn)。畢竟大部分公司都只是使用到了第三方的監(jiān)控工具，而不是選擇自己造輪子。
PV是網(wǎng)站分析的一個術(shù)語，用以衡量網(wǎng)站用戶訪問的網(wǎng)頁的數(shù)量。對于廣告主，PV值可預(yù)期它可以帶來多少廣告收入。一般來說，PV與來訪者的數(shù)量成正比，但是PV并不直接決定頁面的真實來訪者數(shù)量，如同一個來訪者通過不斷的刷新頁面，也可以制造出非常高的PV。
1、什么是PV值
PV（page view）即頁面瀏覽量或點擊量，是衡量一個網(wǎng)站或網(wǎng)頁用戶訪問量。具體的說，PV值就是所有訪問者在24小時（0點到24點）內(nèi)看了某個網(wǎng)站多少個頁面或某個網(wǎng)頁多少次。PV是指頁面刷新的次數(shù)，每一次頁面刷新，就算做一次PV流量。
度量方法就是從瀏覽器發(fā)出一個對網(wǎng)絡(luò)服務(wù)器的請求（Request），網(wǎng)絡(luò)服務(wù)器接到這個請求后，會將該請求對應(yīng)的一個網(wǎng)頁（Page）發(fā)送給瀏覽器，從而產(chǎn)生了一個PV。那么在這里只要是這個請求發(fā)送給了瀏覽器，無論這個頁面是否完全打開（下載完成），那么都是應(yīng)當計為1個PV。
2、什么是UV值
UV（unique visitor）即獨立訪客數(shù)，指訪問某個站點或點擊某個網(wǎng)頁的不同IP地址的人數(shù)。在同一天內(nèi)，UV只記錄第一次進入網(wǎng)站的具有獨立IP的訪問者，在同一天內(nèi)再次訪問該網(wǎng)站則不計數(shù)。UV提供了一定時間內(nèi)不同觀眾數(shù)量的統(tǒng)計指標，而沒有反應(yīng)出網(wǎng)站的全面活動。通過IP和cookie是判斷UV值的兩種方式：
用Cookie分析UV值
當客戶端第一次訪問某個網(wǎng)站服務(wù)器的時候，網(wǎng)站服務(wù)器會給這個客戶端的電腦發(fā)出一個Cookie，通常放在這個客戶端電腦的C盤當中。在這個Cookie中會分配一個獨一無二的編號，這其中會記錄一些訪問服務(wù)器的信息，如訪問時間，訪問了哪些頁面等等。當你下次再訪問這個服務(wù)器的時候，服務(wù)器就可以直接從你的電腦中找到上一次放進去的Cookie文件，并且對其進行一些更新，但那個獨一無二的編號是不會變的。
3、IP即獨立IP數(shù)
IP可以理解為獨立IP的訪問用戶，指1天內(nèi)使用不同IP地址的用戶訪問網(wǎng)站的數(shù)量，同一IP無論訪問了幾個頁面，獨立IP數(shù)均為1。但是假如說兩臺機器訪問而使用的是同一個IP，那么只能算是一個IP的訪問。
IP和UV之間的數(shù)據(jù)不會有太大的差異，通常UV量和比IP量高出一點，每個UV相對于每個IP更準確地對應(yīng)一個實際的瀏覽者。
①UV大于IP
這種情況就是在網(wǎng)吧、學(xué)校、公司等，公用相同IP的場所中不同的用戶，或者多種不同瀏覽器訪問您網(wǎng)站，那么UV數(shù)會大于IP數(shù)。
②UV小于IP
在家庭中大多數(shù)電腦使用ADSL撥號上網(wǎng)，所以同一個用戶在家里不同時間訪問您網(wǎng)站時，IP可能會不同，因為它會根據(jù)時間變動IP，即動態(tài)的IP地址，但是實際訪客數(shù)唯一，便會出現(xiàn)UV數(shù)小于IP數(shù)。
頁面埋點
頁面埋點應(yīng)該是大家最常寫的監(jiān)控了，一般起碼會監(jiān)控以下幾個數(shù)據(jù)：
- PV / UV
- 停留時長
- 流量來源
- 用戶交互
對于這幾類統(tǒng)計，一般的實現(xiàn)思路大致可以分為兩種，分別為手寫埋點和無埋點的方式。
相信第一種方式也是大家最常用的方式，可以自主選擇需要監(jiān)控的數(shù)據(jù)然后在相應(yīng)的地方寫入代碼。這種方式的靈活性很大，但是唯一的缺點就是工作量較大，每個需要監(jiān)控的地方都得插入代碼。
另一種無埋點的方式基本不需要開發(fā)者手寫埋點了，而是統(tǒng)計所有的事件并且定時上報。這種方式雖然沒有前一種方式繁瑣了，但是因為統(tǒng)計的是所有事件，所以還需要后期過濾出需要的數(shù)據(jù)。
異常監(jiān)控
對于異常監(jiān)控來說，以下兩種監(jiān)控是必不可少的，分別是代碼報錯以及接口異常上報。
腳本錯誤一般分為兩種：語法錯誤，運行時錯誤。
語法錯誤一般在編碼時就有觀測
Uncaught SyntaxError: Invalid or unexpected token xxx
運行時錯誤：
window.onerror-除跨域腳本、網(wǎng)絡(luò)異常、瀏覽器兼容
缺陷
-
對于跨域的代碼錯誤會顯示 Script error. 對于這種情況我們需要給 script 標簽添加 crossorigin 屬性
-
對于某些瀏覽器可能不會顯示調(diào)用棧信息，這種情況可以通過 arguments.callee.caller 來做棧遞歸
-
對于 onerror 這種全局捕獲，最好寫在所有 JS 腳本的前面，因為你無法保證你寫的代碼是否出錯，如果寫在后面，一旦發(fā)生錯誤的話是不會被 onerror 捕獲到的。
-
onerror 是無法捕獲到網(wǎng)絡(luò)異常的錯誤。
當我們遇到用戶訪問網(wǎng)站，圖片 CDN 無法服務(wù)，圖片加載不出來
報 404 網(wǎng)絡(luò)請求異常的時候，onerror 是無法幫助我們捕獲到異常的。
由于網(wǎng)絡(luò)請求異常不會事件冒泡，因此必須在捕獲階段將其捕捉到才行，
<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="">但是這種方式雖然可以捕捉到網(wǎng)絡(luò)請求的異常，但是無法判斷 HTTP 的狀態(tài)是 404 還是其他比如 500 等等，
所以還需要配合服務(wù)端日志才進行排查分析才可以。
catch：捕獲異步代碼、promise
try catch：捕獲 async await
缺陷：只能捕獲捉到運行時非異步錯誤，對于語法錯誤和異步錯誤就顯得無能為力，捕捉不到。
語法錯誤：一般不會帶上線
**異步錯誤：**如果錯誤發(fā)生在setTimeout中；除非你在異步代碼 setTimeout 函數(shù)中再套上一層 try-catch，否則就無法感知到其錯誤，但這樣代碼寫起來比較啰嗦。
Promise 全局異常捕獲事件 unhandledrejection
所以如果你的應(yīng)用用到很多的 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'});`接口異常：列舉狀態(tài)碼的類型可以立即上報出錯
另外接口異常就相對來說簡單了，可以列舉出出錯的狀態(tài)碼。一旦出現(xiàn)此類的狀態(tài)碼就可以立即上報出錯。接口異常上報可以讓開發(fā)人員迅速知道有哪些接口出現(xiàn)了大面積的報錯，以便迅速修復(fù)問題。
異常上報方式
但是要注意線上運行的代碼都是壓縮過的，需要在打包時生成 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 函數(shù)只有在返回 true 的時候，異常才不會向上拋出
error;//否則控制臺顯示：Uncaught Error: xxxxx
對于捕獲的錯誤需要上傳給服務(wù)器，通常可以通過 img 標簽的 src 發(fā)起一個請求。
監(jiān)控拿到報錯信息之后，接下來就需要將捕捉到的錯誤信息發(fā)送到信息收集平臺上，常用的發(fā)送形式主要有兩種:
實例 - 動態(tài)創(chuàng)建 img 標簽進行上報
function report(error) {var reportUrl = 'http://xxxx/report';new Image().src = reportUrl + 'error=' + error;}vue項目的異常處理
vue提供了一個全局配置 errorHandle,，用于收集Vue運行時發(fā)生的錯誤。
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對應(yīng)的實例之后，就可以獲取vue對應(yīng)的組件名稱，定位到是哪一個組件報錯；
性能監(jiān)控
性能監(jiān)控可以很好的幫助開發(fā)者了解在各種真實環(huán)境下，頁面的性能情況是如何的。
對于性能監(jiān)控來說，我們可以直接使用瀏覽器自帶的 Performance API 來實現(xiàn)這個功能。
對于性能監(jiān)控來說，其實我們只需要調(diào)用 performance.getEntriesByType('navigation') 這行代碼就行了。對，你沒看錯，一行代碼我們就可以獲得頁面中各種詳細的性能相關(guān)信息
[外鏈圖片轉(zhuǎn)存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(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)][外鏈圖片轉(zhuǎn)存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-O1GB6OZf-1597843082636)(C:\Users\29150\AppData\Roaming\Typora\typora-user-images\image-20200602084157858.png)]
我們可以發(fā)現(xiàn)這行代碼返回了一個數(shù)組，內(nèi)部包含了相當多的信息，從數(shù)據(jù)開始在網(wǎng)絡(luò)中傳輸?shù)巾撁婕虞d完成都提供了相應(yīng)的數(shù)據(jù)。
[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)
name: “https://www.gaosiedu.com/”
entryType: “navigation”
startTime: 0
duration: 5213.774999999998
proto: PerformanceNavigationTiming
length: 1
proto: Array(0)
[外鏈圖片轉(zhuǎn)存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(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、為什么要監(jiān)控性能？
| Google 延遲 400ms | 搜索量下降 0.59% |
| Bing 延遲 2s | 收入下降 4.3% |
| Yahoo 延遲 400ms | 流量下降 5-9% |
| Mozilla 頁面打開減少 2.2s | 下載量提升 15.4% |
| Netflix 開啟 Gzip | 性能提升 13.25% 帶寬減少50% |
根本原因還是在于性能影響了用戶體驗。加載的延遲、操作的卡頓等都會影響用戶的使用體驗。尤其是移動端，用戶對頁面響應(yīng)延遲和連接中斷的容忍度很低。我們需要一套性能監(jiān)控系統(tǒng)持續(xù)監(jiān)控、評估、預(yù)警頁面性能狀況、發(fā)現(xiàn)瓶頸，指導(dǎo)優(yōu)化工作的進行。
2、 有什么可用的工具？
Page Speed、webpagetest,是谷歌開發(fā)的分析和優(yōu)化網(wǎng)頁的工具，
為了持續(xù)監(jiān)控不同網(wǎng)絡(luò)環(huán)境下用戶訪問情況與頁面各功能可用狀況，我們選擇在頁面中植入 JS 來監(jiān)控線上真實用戶訪問性能，同時利用已有的分析工具作為輔助，形成一套完整多元的數(shù)據(jù)監(jiān)控體系，為產(chǎn)品線的評估與優(yōu)化提供可靠的數(shù)據(jù)。
3、 真實用戶性能監(jiān)控
關(guān)于不同監(jiān)控方式的簡單對比可以查看下表：
| 非侵入式 | 指標齊全、客戶端主動監(jiān)測、競品監(jiān)控 | 無法知道性能影響用戶數(shù)、采樣少容易失真、無法監(jiān)控復(fù)雜應(yīng)用與細分功能 | Pagespeed、PhantomJS、UAQ |
| 侵入式 | 真實海量用戶數(shù)據(jù)、能監(jiān)控復(fù)雜應(yīng)用與業(yè)務(wù)功能、用戶點擊與區(qū)域渲染 | 需插入腳本統(tǒng)計、網(wǎng)絡(luò)指標不全、無法監(jiān)控競品 | DP 、Google 統(tǒng)計 |
4、 如何采集性能數(shù)據(jù)？
線上監(jiān)控哪些指標呢？如何更好地反映用戶感知？
對于用戶來說他感覺到的為什么頁面打不開、為什么按鈕點擊不了、為什么圖片顯示這么慢。
而對于工程師來說，可能關(guān)注的是 DNS 查詢、TCP 連接、服務(wù)響應(yīng)等瀏覽器加載過程指標。
我們根據(jù)用戶的痛點，
將瀏覽器加載過程抽取出四個關(guān)鍵指標，即白屏?xí)r間、首屏?xí)r間、用戶可操作、總下載時間
這些指標是如何統(tǒng)計的呢？
確定統(tǒng)計起點
我們需要在用戶輸入 URL 或者點擊鏈接的時候就開始統(tǒng)計，因為這樣才能衡量用戶的等待時間。如果你的用戶高端瀏覽器占比很高，那么可以直接使用Navigation Timing接口來獲取統(tǒng)計起點以及加載過程中的各個階段耗時。另外也可以通過 cookie 記錄時間戳的方式來統(tǒng)計，需要注意的是 Cookie 方式只能統(tǒng)計到站內(nèi)跳轉(zhuǎn)的數(shù)據(jù)。
統(tǒng)計白屏?xí)r間
白屏?xí)r間是用戶首次看到內(nèi)容的時間，也叫做首次渲染時間，chrome 高版本有 firstPaintTime 接口來獲取這個耗時，但大部分瀏覽器并不支持，必須想其他辦法來監(jiān)測。仔細觀察 WebPagetest 視圖分析發(fā)現(xiàn)，白屏?xí)r間出現(xiàn)在頭部外鏈資源加載完附近，因為瀏覽器只有加載并解析完頭部資源才會真正渲染頁面。基于此我們可以通過獲取頭部資源加載完的時刻來近似統(tǒng)計白屏?xí)r間。盡管并不精確，但卻考慮了影響白屏的主要因素：首字節(jié)時間和頭部資源加載時間。
如何統(tǒng)計頭部資源加載呢？我們發(fā)現(xiàn)頭部內(nèi)嵌的 JS 通常需等待前面的 JS\CSS 加載完才會執(zhí)行，是不是可以在瀏覽器 head 內(nèi)底部加一句 JS 統(tǒng)計頭部資源加載結(jié)束點呢？可以通過一個簡單的示例進行測試：
<!DOCTYPE HTML> <html><head><meta charset="UTF-8"/><script>var start_time = +new Date; //測試時間起點，實際統(tǒng)計起點為 DNS 查詢</script><!-- 3s 后這個 js 才會返回 --><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 被模擬設(shè)置 3s 后返回，head 底部內(nèi)嵌 JS 等待前面 js 返回后才執(zhí)行</p><p>script.php 替換成一個執(zhí)行長時間循環(huán)的 js 效果也一樣</p> </body> </html>經(jīng)測試發(fā)現(xiàn)，統(tǒng)計的頭部加載時間正好跟頭部資源下載時間相近，而且換成一個執(zhí)行時間很長的 JS 也會等到 JS 執(zhí)行完才統(tǒng)計。說明此方法是可行的(具體原因可查看瀏覽器渲染原理及 JS 單線程相關(guān)介紹)。
統(tǒng)計首屏?xí)r間
首屏?xí)r間的統(tǒng)計比較復(fù)雜，因為涉及圖片等多種元素及異步渲染等方式。觀察加載視圖可發(fā)現(xiàn)，影響首屏的主要因素的圖片的加載。通過統(tǒng)計首屏內(nèi)圖片的加載時間便可以獲取首屏渲染完成的時間。統(tǒng)計流程如下：
首屏位置調(diào)用 API 開始統(tǒng)計 -> 綁定首屏內(nèi)所有圖片的 load 事件 -> 頁面加載完后判斷圖片是否在首屏內(nèi)，找出加載最慢的一張 -> 首屏?xí)r間這是同步加載情況下的簡單統(tǒng)計邏輯，另外需要注意的幾點：
- 頁面存在 iframe 的情況下也需要判斷加載時間
- gif 圖片在 IE 上可能重復(fù)觸發(fā) load 事件需排除
- 異步渲染的情況下應(yīng)在異步獲取數(shù)據(jù)插入之后再計算首屏
- css 重要背景圖片可以通過 JS 請求圖片 url 來統(tǒng)計(瀏覽器不會重復(fù)加載)
- 沒有圖片則以統(tǒng)計 JS 執(zhí)行時間為首屏，即認為文字出現(xiàn)時間
統(tǒng)計用戶可操作和總下載
用戶可操作默認可以統(tǒng)計domready時間，因為通常會在這時候綁定事件操作。對于使用了模塊化異步加載的 JS 可以在代碼中去主動標記重要 JS 的加載時間，這也是產(chǎn)品指標的統(tǒng)計方式。
總下載時間默認可以統(tǒng)計onload時間，這樣可以統(tǒng)計同步加載的資源全部加載完的耗時。如果頁面中存在很多異步渲染，可以將異步渲染全部完成的時間作為總下載時間。
網(wǎng)絡(luò)指標
網(wǎng)絡(luò)類型判斷
對于移動端來說，網(wǎng)絡(luò)是頁面加載速度最大的影響因素，需要根據(jù)不同的網(wǎng)絡(luò)來采取相應(yīng)的優(yōu)化措施，例如對于 2G 用戶采用簡版等。但 web 上沒有接口獲取用戶的網(wǎng)絡(luò)類型。為了獲取用戶網(wǎng)絡(luò)類型，可以通過測速的方式來判斷不同 IP 段對應(yīng)的網(wǎng)絡(luò)。測速例如比較經(jīng)典的有 facebook 的方案。經(jīng)過測速后的分析，用戶的加載速率有明顯的分布區(qū)間，如下圖所示：
各個分布區(qū)間正好對應(yīng)不同的網(wǎng)絡(luò)類型，經(jīng)過與客戶端的輔助測試，成功率可以在 95%以上。有了這個 IP 庫對應(yīng)的速率數(shù)據(jù)，就可以在分析用戶數(shù)據(jù)時根據(jù) IP 來判斷用戶網(wǎng)絡(luò)類型。
網(wǎng)絡(luò)耗時統(tǒng)計
網(wǎng)絡(luò)耗時數(shù)據(jù)可以借助前面提到 Navigation Timing 接口獲取，與之類似的還有Resource Timing,可以獲取頁面所有靜態(tài)資源的加載耗時。通過此接口可以輕松獲取 DNS、TCP、首字節(jié)、html 傳輸?shù)群臅r，Navigation Timing 的接口示意圖如下所示：
以上重點介紹了數(shù)據(jù)采集部分，這也是系統(tǒng)中最關(guān)鍵的一部分，只有保證數(shù)據(jù)能真實反映用戶感知，才能對癥下藥提升用戶體驗。數(shù)據(jù)采集完之后我們可以在頁面加載完之后統(tǒng)一上報，如示例：
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<=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 如何分析性能數(shù)據(jù)？
讓數(shù)據(jù)會說話
而數(shù)據(jù)分析過程，如前一篇文章所述，可以從多個維度去分析數(shù)據(jù)。大數(shù)據(jù)處理需要借助 hadoop、Hive 等方式，而對于普通站點則任意一種后端語言處理即可。
均值與分布
均值與分布是數(shù)據(jù)處理中最常見的兩種方式。因為它能直觀的表示指標的趨勢與分布狀況，方便進行評估、瓶頸發(fā)現(xiàn)與告警。處理過程中應(yīng)去除異常值，例如明顯超過閾值的臟數(shù)據(jù)等。
耗時的評估中，有很多這方面的研究數(shù)據(jù)。例如有人提出三個基本的時間范圍：
- 0.1秒 : 0.1 秒是用戶感知的最小粒度，在這個時間范圍內(nèi)完成的操作被認為是流暢沒有延遲的
- 1.0秒 : 1.0 秒內(nèi)完成的響應(yīng)認為不會干擾用戶的思維流。盡管用戶能感覺到延遲，但 0.1 秒 -1.0 秒內(nèi)完成的操作并不需要給出明顯 loading 提示
- 10秒 : 達到 10 秒用戶將無法保持注意力，很可能選擇離開做其他事情
我們根據(jù)業(yè)界的一些調(diào)研，結(jié)合不同指標的特點，制定了指標的分布評估區(qū)間。如下圖所示：
評估區(qū)間的制定方便我們了解當前性能狀況，同時對性能趨勢波動做出反應(yīng)。
多維分析
為了方便挖掘性能可能的瓶頸，需要從多維的角度對數(shù)據(jù)進行分析。例如移動端最重要的維度就是網(wǎng)絡(luò)，數(shù)據(jù)處理上除了總體數(shù)據(jù)，還需要根據(jù)網(wǎng)絡(luò)類型對數(shù)據(jù)進行分析。常見的維度還有系統(tǒng)、瀏覽器、地域運營商等。我們還可以根據(jù)自身產(chǎn)品的特點來確定一些維度，例如頁面長度分布、簡版炫版等。
需要注意的是維度并不是越多越好，需要根據(jù)產(chǎn)品的特點及終端來確定。維度是為了方便查找性能瓶頸。
小插曲 ：之前從微博中看到有人評價說想做監(jiān)控但是公司沒有日志服務(wù)器。并不需要單獨的日志服務(wù)器,只要能把統(tǒng)計的這個請求訪問日志保存下來即可。如果網(wǎng)站自己的獨立服務(wù)器都沒有還有解決辦法，在百度開發(fā)者中心新建一個應(yīng)用，寫一個簡單的 Web 服務(wù)將接收到的統(tǒng)計數(shù)據(jù)解析存到百度云免費的數(shù)據(jù)庫中，然后每天再用 Mysql 處理下當天的數(shù)據(jù)即可，對于普通站點的抽樣性能數(shù)據(jù)應(yīng)該沒問題。請叫我雷鋒。
5、如何利用監(jiān)控數(shù)據(jù)解決問題？
發(fā)現(xiàn)瓶頸，對癥下藥
對于圖表制作，比較出名的有Highcharts，百度開發(fā)的Echarts也很不錯。不管使用什么工具，最關(guān)鍵的一點就是讓報表能突出重點，直觀明了。
制作報表前多問幾個如何讓人直觀看到目前狀況和可能存在的問題，哪些地方可以加強，哪些可以去掉，使用是否習(xí)慣等。
有了能反映用戶感知的真實世界、并且細分到各個業(yè)務(wù)功能，有詳細的網(wǎng)絡(luò)等輔助數(shù)據(jù)，我們在解決前端性能上便更加得心應(yīng)手。監(jiān)控系統(tǒng)已經(jīng)對線上訪問狀況有了連續(xù)的反饋，根據(jù)現(xiàn)有評估與瓶頸選擇對應(yīng)方案進行優(yōu)化，最后根據(jù)反饋進行調(diào)整，相信性能優(yōu)化不再是個難題。
如何選擇優(yōu)化方案呢？這又是一個比較大的話題了，好在已經(jīng)有很多經(jīng)驗可以借鑒。附錄中就整理了部分性能的學(xué)習(xí)資料，可以根據(jù)需要閱讀學(xué)習(xí)。
6、 總結(jié)
通過以上“幾天”的努力，我們可以搭建一個小而美的前端性能監(jiān)控系統(tǒng)。但這僅僅是開始，前端數(shù)據(jù)有很多挖掘的價值。性能優(yōu)化也是一門需要認真學(xué)習(xí)的課程，為了打造流暢的使用體驗，為了讓用戶更加滿意，趕緊搭建起自己的前端數(shù)據(jù)平臺吧!
總結(jié)
以上是生活随笔為你收集整理的前端面试超全整理3（webpack性能优化及监控）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： MyChrome制作Chrome浏览器便
- 下一篇： 关于JavaStream的一些小练习