前言

笔者近半年始终在参加我的项目重构，在重构过程中大量利用性能优化和设计模式两方面的常识。性能优化和设计模式两方面的常识不论在工作还是面试时都是高频利用场景，趁着这次参加大规模我的项目重构的机会，笔者认真梳理出一些惯例且必用的性能优化倡议，同时联合日常开发教训整顿出笔者在网易四年来实际到的认为有用的所有性能优化倡议，与大家一起分享分享！(因为篇幅无限，那设计模式在前面再专门出一篇文章呗)

可能有些性能优化倡议已被大家熟知，不过也不影响这次分享，当然笔者也将一些平时可能不会留神的细节列举进去。

平时大家认为性能优化是一种无序的利用场景，但在笔者看来它是一种有序的利用场景且很多性能优化都是相互铺垫甚至一带一路。从过程趋势来看，性能优化可分为网络层面和渲染层面；从后果趋势来看，性能优化可分为工夫层面和体积层面。简略来说就是要在拜访网站时使其快准狠地立马出现在用户眼前。

所有的性能优化都围绕着两大层面两小层面实现，外围层面是网络层面和渲染层面，辅助层面是工夫层面和体积层面，而辅助层面则充斥在外围层面里。于是笔者通过本文整顿出对于前端性能优化的九大策略和六大指标。当然这些策略和指标都是笔者本人定义，不便通过某种形式为性能优化做一些标准。

因而在工作或面试时联合这些特色就能完满地诠释性能优化所延长进去的常识了。后方高能，不看也得珍藏，走起！！！

所有代码示例为了凸显主题，只展现外围配置代码，其余配置并未补上，请自行脑补

九大策略

网络层面

网络层面的性能优化，无疑是如何让资源体积更小加载更快，因而笔者从以下四方面做出倡议。

  • 构建策略：基于构建工具(Webpack/Rollup/Parcel/Esbuild/Vite/Gulp)
  • 图像策略：基于图像类型(JPG/PNG/SVG/WebP/Base64)
  • 散发策略：基于内容散发网络(CDN)
  • 缓存策略：基于浏览器缓存(强缓存/协商缓存)

上述四方面都是一步接着一步实现，充斥在整个我的项目流程里。构建策略和图像策略处于开发阶段，散发策略和缓存策略处于生产阶段，因而在每个阶段都可查看是否按程序接入上述策略。通过这种形式就能最大限度减少性能优化利用场景。

构建策略

该策略次要围绕webpack做相干解决，同时也是接入最广泛的性能优化策略。其余构建工具的解决也是大同小异，可能只是配置上不统一。说到webpack的性能优化，无疑是从工夫层面和体积层面动手。

笔者发现目前webpack v5整体兼容性还不是特地好，某些性能配合第三方工具可能呈现问题，故暂未降级到v5，持续应用v4作为生产工具，故以下配置均基于v4，但总体与v5的配置出入不大

笔者对两层面别离做出6个性能优化倡议总共12个性能优化倡议，为了不便记忆均应用四字词语概括，不便大家消化。⏱示意缩小打包工夫，示意缩小打包体积。

  • 缩小打包工夫：缩减范畴、缓存正本、定向搜寻、提前构建、并行构建、可视构造
  • 缩小打包体积：宰割代码、摇树优化、动静垫片、按需加载、作用晋升、压缩资源
⏱缩减范畴

配置include/exclude放大Loader对文件的搜寻范畴，益处是防止不必要的转译。node_modules目录的体积这么大，那得减少多少工夫老本去检索所有文件啊？

include/exclude通常在各大Loader里配置，src目录通常作为源码目录，可做如下解决。当然include/exclude可依据理论状况批改。

export default {    // ...    module: {        rules: [{            exclude: /node_modules/,            include: /src/,            test: /\.js$/,            use: "babel-loader"        }]    }};
⏱缓存正本

配置cache缓存Loader对文件的编译正本，益处是再次编译时只编译批改过的文件。未修改过的文件干嘛要随着批改过的文件从新编译呢？

大部分Loader/Plugin都会提供一个可应用编译缓存的选项，通常蕴含cache字眼。以babel-loader和eslint-webpack-plugin为例。

import EslintPlugin from "eslint-webpack-plugin";export default {    // ...    module: {        rules: [{            // ...            test: /\.js$/,            use: [{                loader: "babel-loader",                options: { cacheDirectory: true }            }]        }]    },    plugins: [        new EslintPlugin({ cache: true })    ]};
⏱定向搜寻

配置resolve进步文件的搜寻速度，益处是定向指定必须文件门路。若某些第三方库以惯例模式引入可能报错或心愿程序主动索引特定类型文件都可通过该形式解决。

alias映射模块门路，extensions表明文件后缀，noParse过滤无依赖文件。通常配置alias和extensions就足够。

export default {    // ...    resolve: {        alias: {            "#": AbsPath(""), // 根目录快捷方式            "@": AbsPath("src"), // src目录快捷方式            swiper: "swiper/js/swiper.min.js"        }, // 模块导入快捷方式        extensions: [".js", ".ts", ".jsx", ".tsx", ".json", ".vue"] // import门路时文件可省略后缀名    }};
⏱提前构建

配置DllPlugin将第三方依赖提前打包，益处是将DLL与业务代码齐全拆散且每次只构建业务代码。这是一个古老配置，在webpack v2时已存在，不过当初webpack v4+已不举荐应用该配置，因为其版本迭代带来的性能晋升足以疏忽DllPlugin所带来的效益。

DLL意为动态链接库，指一个蕴含可由多个程序同时应用的代码库。在前端畛域里可认为是另类缓存的存在，它把公共代码打包为DLL文件并存到硬盘里，再次打包时动静链接DLL文件就无需再次打包那些公共代码，从而晋升构建速度，缩小打包工夫。

配置DLL总体来说相比其余配置简单，配置流程可大抵分为三步。

首先告知构建脚本哪些依赖做成DLL并生成DLL文件和DLL映射表文件。

import { DefinePlugin, DllPlugin } from "webpack";export default {    // ...    entry: {        vendor: ["react", "react-dom", "react-router-dom"]    },    mode: "production",    optimization: {        splitChunks: {            cacheGroups: {                vendor: {                    chunks: "all",                    name: "vendor",                    test: /node_modules/                }            }        }    },    output: {        filename: "[name].dll.js", // 输入门路和文件名称        library: "[name]", // 全局变量名称：其余模块会从此变量上获取外面模块        path: AbsPath("dist/static") // 输入目录门路    },    plugins: [        new DefinePlugin({            "process.env.NODE_ENV": JSON.stringify("development") // DLL模式下笼罩生产环境成开发环境(启动第三方依赖调试模式)        }),        new DllPlugin({            name: "[name]", // 全局变量名称：减小搜寻范畴，与output.library联合应用            path: AbsPath("dist/static/[name]-manifest.json") // 输入目录门路        })    ]};

而后在package.json里配置执行脚本且每次构建前首先执行该脚本打包出DLL文件。

{    "scripts": {        "dll": "webpack --config webpack.dll.js"    }}

最初链接DLL文件并告知webpack可命中的DLL文件让其自行读取。应用html-webpack-tags-plugin在打包时主动插入DLL文件。

import { DllReferencePlugin } from "webpack";import HtmlTagsPlugin from "html-webpack-tags-plugin";export default {    // ...    plugins: [        // ...        new DllReferencePlugin({            manifest: AbsPath("dist/static/vendor-manifest.json") // manifest文件门路        }),        new HtmlTagsPlugin({            append: false, // 在生成资源后插入            publicPath: "/", // 应用公共门路            tags: ["static/vendor.dll.js"] // 资源门路        })    ]};

为了那几秒钟的工夫老本，笔者倡议配置上较好。当然也可应用autodll-webpack-plugin代替手动配置。

⏱并行构建

配置Thread将Loader单过程转换为多过程，益处是开释CPU多核并发的劣势。在应用webpack构建我的项目时会有大量文件需解析和解决，构建过程是计算密集型的操作，随着文件增多会使构建过程变得越慢。

运行在Node里的webpack是单线程模型，简略来说就是webpack待处理的工作需一件件解决，不能同一时刻解决多件工作。

文件读写与计算操作无奈防止，能不能让webpack同一时刻解决多个工作，施展多核CPU电脑的威力以晋升构建速度呢？thread-loader来帮你，依据CPU个数开启线程。

在此需注意一个问题，若我的项目文件不算多就不要应用该性能优化倡议，毕竟开启多个线程也会存在性能开销。

import Os from "os";export default {    // ...    module: {        rules: [{            // ...            test: /\.js$/,            use: [{                loader: "thread-loader",                options: { workers: Os.cpus().length }            }, {                loader: "babel-loader",                options: { cacheDirectory: true }            }]        }]    }};
⏱可视构造

配置BundleAnalyzer剖析打包文件构造，益处是找出导致体积过大的起因。从而通过剖析起因得出优化计划缩小构建工夫。BundleAnalyzer是webpack官网插件，可直观剖析打包文件的模块组成部分、模块体积占比、模块蕴含关系、模块依赖关系、文件是否反复、压缩体积比照等可视化数据。

可应用webpack-bundle-analyzer配置，有了它，咱们就能疾速找到相干问题。

import { BundleAnalyzerPlugin } from "webpack-bundle-analyzer";export default {    // ...    plugins: [        // ...        BundleAnalyzerPlugin()    ]};
宰割代码

宰割各个模块代码，提取雷同局部代码，益处是缩小反复代码的呈现频率。webpack v4应用splitChunks代替CommonsChunksPlugin实现代码宰割。

splitChunks配置较多，详情可参考官网，在此笔者贴上罕用配置。

export default {    // ...    optimization: {        runtimeChunk: { name: "manifest" }, // 抽离WebpackRuntime函数        splitChunks: {            cacheGroups: {                common: {                    minChunks: 2,                    name: "common",                    priority: 5,                    reuseExistingChunk: true, // 重用已存在代码块                    test: AbsPath("src")                },                vendor: {                    chunks: "initial", // 代码宰割类型                    name: "vendor", // 代码块名称                    priority: 10, // 优先级                    test: /node_modules/ // 校验文件正则表达式                }            }, // 缓存组            chunks: "all" // 代码宰割类型：all全副模块，async异步模块，initial入口模块        } // 代码块宰割    }};
摇树优化

删除我的项目中未被援用代码，益处是移除反复代码和未应用代码。摇树优化首次呈现于rollup，是rollup的外围概念，起初在webpack v2里借鉴过去应用。

摇树优化只对ESM标准失效，对其余模块标准生效。摇树优化针对动态构造剖析，只有import/export能力提供动态的导入/导出性能。因而在编写业务代码时必须应用ESM标准能力让摇树优化移除反复代码和未应用代码。

在webpack里只需将打包环境设置成生产环境就能让摇树优化失效，同时业务代码应用ESM标准编写，应用import导入模块，应用export导出模块。

export default {    // ...    mode: "production"};
动静垫片

通过垫片服务依据UA返回以后浏览器代码垫片，益处是无需将沉重的代码垫片打包进去。每次构建都配置@babel/preset-env和core-js依据某些需要将Polyfill打包进来，这无疑又为代码体积减少了奉献。

@babel/preset-env提供的useBuiltIns可按需导入Polyfill。

  • false：忽视target.browsers将所有Polyfill加载进来
  • entry：依据target.browsers将局部Polyfill加载进来(仅引入有浏览器不反对的Polyfill，需在入口文件import "core-js/stable")
  • usage：依据target.browsers和检测代码里ES6的应用状况将局部Polyfill加载进来(无需在入口文件import "core-js/stable")

在此举荐大家应用动静垫片。动静垫片可依据浏览器UserAgent返回以后浏览器Polyfill，其思路是依据浏览器的UserAgent从browserlist查找出以后浏览器哪些个性不足反对从而返回这些个性的Polyfill。对这方面感兴趣的同学可参考polyfill-library和polyfill-service的源码。

在此提供两个动静垫片服务，可在不同浏览器里点击以下链接看看输入不同的Polyfill。置信IExplore还是最多Polyfill的，它骄傲地说：我就是我，不一样的烟火。

  • 官网CDN服务：https://polyfill.io/v3/polyfill.min.js
  • 阿里CDN服务：https://polyfill.alicdn.com/polyfill.min.js

应用html-webpack-tags-plugin在打包时主动插入动静垫片。

import HtmlTagsPlugin from "html-webpack-tags-plugin";export default {    plugins: [        new HtmlTagsPlugin({            append: false, // 在生成资源后插入            publicPath: false, // 应用公共门路            tags: ["https://polyfill.alicdn.com/polyfill.min.js"] // 资源门路        })    ]};
按需加载

将路由页面/触发性功能独自打包为一个文件，应用时才加载，益处是加重首屏渲染的累赘。因为我的项目性能越多其打包体积越大，导致首屏渲染速度越慢。

首屏渲染时只需对应JS代码而无需其余JS代码，所以可应用按需加载。webpack v4提供模块按需切割加载性能，配合import()可做到首屏渲染减包的成果，从而放慢首屏渲染速度。只有当触发某些性能时才会加载以后性能的JS代码。

webpack v4提供魔术注解命名切割模块，若无注解则切割进去的模块无奈分辨出属于哪个业务模块，所以个别都是一个业务模块共用一个切割模块的注解名称。

const Login = () => import( /* webpackChunkName: "login" */ "../../views/login");const Logon = () => import( /* webpackChunkName: "logon" */ "../../views/logon");

运行起来控制台可能会报错，在package.json的babel相干配置里接入@babel/plugin-syntax-dynamic-import即可。

{    // ...    "babel": {        // ...        "plugins": [            // ...            "@babel/plugin-syntax-dynamic-import"        ]    }}
作用晋升

剖析模块间依赖关系，把打包好的模块合并到一个函数中，益处是缩小函数申明和内存花销。作用晋升首次呈现于rollup，是rollup的外围概念，起初在webpack v3里借鉴过去应用。

在未开启作用晋升前，构建后的代码会存在大量函数闭包。因为模块依赖，通过webpack打包后会转换成IIFE，大量函数闭包包裹代码会导致打包体积增大(模块越多越显著)。在运行代码时创立的函数作用域变多，从而导致更大的内存开销。

在开启作用晋升后，构建后的代码会依照引入程序放到一个函数作用域里，通过适当重命名某些变量以避免变量名抵触，从而缩小函数申明和内存花销。

在webpack里只需将打包环境设置成生产环境就能让作用晋升失效，或显式设置concatenateModules。

export default {    // ...    mode: "production"};// 显式设置export default {    // ...    optimization: {        // ...        concatenateModules: true    }};
压缩资源

压缩HTML/CSS/JS代码，压缩字体/图像/音频/视频，益处是更无效缩小打包体积。极致地优化代码都有可能不迭优化一个资源文件的体积更无效。

针对HTML代码，应用html-webpack-plugin开启压缩性能。

import HtmlPlugin from "html-webpack-plugin";export default {    // ...    plugins: [        // ...        HtmlPlugin({            // ...            minify: {                collapseWhitespace: true,                removeComments: true            } // 压缩HTML        })    ]};

针对CSS/JS代码，别离应用以下插件开启压缩性能。其中OptimizeCss基于cssnano封装，Uglifyjs和Terser都是webpack官网插件，同时需注意压缩JS代码需辨别ES5和ES6。

  • optimize-css-assets-webpack-plugin：压缩CSS代码
  • uglifyjs-webpack-plugin：压缩ES5版本的JS代码
  • terser-webpack-plugin：压缩ES6版本的JS代码
import OptimizeCssAssetsPlugin from "optimize-css-assets-webpack-plugin";import TerserPlugin from "terser-webpack-plugin";import UglifyjsPlugin from "uglifyjs-webpack-plugin";const compressOpts = type => ({    cache: true, // 缓存文件    parallel: true, // 并行处理    [`${type}Options`]: {        beautify: false,        compress: { drop_console: true }    } // 压缩配置});const compressCss = new OptimizeCssAssetsPlugin({    cssProcessorOptions: {        autoprefixer: { remove: false }, // 设置autoprefixer保留过期款式        safe: true // 防止cssnano从新计算z-index    }});const compressJs = USE_ES6    ? new TerserPlugin(compressOpts("terser"))    : new UglifyjsPlugin(compressOpts("uglify"));export default {    // ...    optimization: {        // ...        minimizer: [compressCss, compressJs] // 代码压缩    }};

针对字体/音频/视频文件，还真没相干Plugin供咱们应用，就只能托付大家在公布我的项目到生产服前应用对应的压缩工具解决了。针对图像文件，大部分Loader/Plugin封装时均应用了某些图像处理工具，而这些工具的某些性能又托管在国外服务器里，所以导致常常装置失败。具体解决形式可回看笔者已经公布的《聊聊NPM镜像那些险象环生的坑》一文寻求答案。

鉴于此，笔者花了一点小技巧开发了一个Plugin用于配合webpack压缩图像，详情请参考tinyimg-webpack-plugin。

import TinyimgPlugin from "tinyimg-webpack-plugin";export default {    // ...    plugins: [        // ...        TinyimgPlugin()    ]};

上述构建策略都集成到笔者开源的bruce-cli里，它是一个React/Vue利用自动化构建脚手架，其零配置开箱即用的长处非常适合入门级、初中级、疾速开发我的项目的前端同学应用，还可通过创立brucerc.js文件笼罩其默认配置，只需专一业务代码的编写无需关注构建代码的编写，让我的项目构造更简洁。详情请戳这里，应用时记得查看文档，反对一个Star哈！

图像策略

该策略次要围绕图像类型做相干解决，同时也是接入老本较低的性能优化策略。只需做到以下两点即可。

  • 图像选型：理解所有图像类型的特点及其何种利用场景最合适
  • 图像压缩：在部署到生产环境前应用工具或脚本对其压缩解决

图像选型肯定要晓得每种图像类型的体积/品质/兼容/申请/压缩/通明/场景等参数相对值，这样能力迅速做出判断在何种场景应用何种类型的图像。

类型体积品质兼容申请压缩通明场景
JPG小中高是有损不反对背景图、轮播图、色调丰盛图
PNG大高高是无损反对图标、透明图
SVG小高高是无损反对图标、矢量图
WebP小中低是兼备反对看兼容状况
Base64看状况中高否无损反对图标

图像压缩可在上述构建策略-压缩资源里实现，也可自行应用工具实现。因为当初大部分webpack图像压缩工具不是装置失败就是各种环境问题(你懂的)，所以笔者还是举荐在公布我的项目到生产服前应用图像压缩工具解决，这样运行稳固也不会减少打包工夫。

好用的图像压缩工具无非就是以下几个，若有更好用的工具麻烦在评论里补充喔！

工具开源免费API收费体验
QuickPicture✖️✔️✖️可压缩类型较多，压缩质感较好，有体积限度，有数量限度
ShrinkMe✖️✖️✖️可压缩类型较多，压缩质感个别，无数量限度，有体积限度
Squoosh✔️✖️✔️可压缩类型较少，压缩质感个别，无数量限度，有体积限度
TinyJpg✖️✔️✔️可压缩类型较少，压缩质感很好，有数量限度，有体积限度
TinyPng✖️✔️✔️可压缩类型较少，压缩质感很好，有数量限度，有体积限度
Zhitu✖️✖️✖️可压缩类型个别，压缩质感个别，有数量限度，有体积限度

若不想在网站里来回拖动图像文件，可应用笔者开源的图像批处理工具img-master代替，不仅有压缩性能，还有分组性能、标记性能和变换性能。目前笔者负责的全副我的项目都应用该工具解决，始终用一爽快！

图像策略兴许解决一张图像就能完爆所有构建策略，因而是一种很便宜但极无效的性能优化策略。

散发策略

该策略次要围绕内容散发网络做相干解决，同时也是接入老本较高的性能优化策略，需足够资金反对。

尽管接入老本较高，但大部分企业都会购买一些CDN服务器，所以在部署的事件上就不必过分担心，只管应用就好。该策略尽量遵循以下两点就能施展CDN最大作用。

  • 所有动态资源走CDN：开发阶段确定哪些文件属于动态资源
  • 把动态资源与主页面置于不同域名下：防止申请带上Cookie

内容散发网络简称CDN，指一组散布在各地存储数据正本并可依据就近准则满足数据申请的服务器。其外围特色是缓存和回源，缓存是把资源复制到CDN服务器里，回源是资源过期/不存在就向下层服务器申请并复制到CDN服务器里。

应用CDN可升高网络拥塞，进步用户拜访响应速度和命中率。构建在现有网络根底上的智能虚构网络，依附部署在各地服务器，通过核心平台的调度、负载平衡、内容散发等功能模块，使用户就近获取所需资源，这就是CDN的终极使命。

基于CDN的就近准则所带来的长处，可将网站所有动态资源全副部署到CDN服务器里。那动态资源包含哪些文件？通常来说就是无需服务器产生计算就能失去的资源，例如不常变动的款式文件、脚本文件和多媒体文件(字体/图像/音频/视频)等。

若需独自配置CDN服务器，可思考阿里云OSS、网易树帆NOS和七牛云Kodo，当然配置起来还需购买该产品对应的CDN服务。因为篇幅问题，这些配置在购买后会有相干教程，可自行领会，在此就不再叙述了。

笔者举荐大家首选网易树帆NOS，毕竟对自家产品还是挺有信念的，不小心给自家产品打了个小广告了，哈哈！

缓存策略

该策略次要围绕浏览器缓存做相干解决，同时也使接入老本最低的性能优化策略。其显著缩小网络传输所带来的损耗，晋升网页访问速度，是一种很值得应用的性能优化策略。

通过下图可知，为了让浏览器缓存施展最大作用，该策略尽量遵循以下五点就能施展浏览器缓存最大作用。

  • 思考回绝所有缓存策略：Cache-Control:no-store
  • 思考资源是否每次向服务器申请：Cache-Control:no-cache
  • 思考资源是否被代理服务器缓存：Cache-Control:public/private
  • 思考资源过期工夫：Expires:t/Cache-Control:max-age=t,s-maxage=t
  • 思考协商缓存：Last-Modified/Etag

同时浏览器缓存也是高频面试题之一，笔者感觉上述波及到的名词在不同语序串联下也能齐全了解能力真正弄懂浏览器缓存在性能优化里起到的作用。

缓存策略通过设置HTTP报文实现，在模式上分为强缓存/强制缓存和协商缓存/比照缓存。为了不便比照，笔者将某些细节应用图例展现，置信你有更好的了解。

整个缓存策略机制很明了，先走强缓存，若命中失败才走协商缓存。若命中强缓存，间接应用强缓存；若未命中强缓存，发送申请到服务器查看是否命中协商缓存；若命中协商缓存，服务器返回304告诉浏览器应用本地缓存，否则返回最新资源。

有两种较罕用的利用场景值得应用缓存策略一试，当然更多利用场景都可依据我的项目需要制订。

  • 频繁变动资源：设置Cache-Control:no-cache，使浏览器每次都发送申请到服务器，配合Last-Modified/ETag验证资源是否无效
  • 不常变动资源：设置Cache-Control:max-age=31536000，对文件名哈希解决，当代码批改后生成新的文件名，当HTML文件引入文件名产生扭转才会下载最新文件

渲染层面

渲染层面的性能优化，无疑是如何让代码解析更好执行更快。因而笔者从以下五方面做出倡议。

  • CSS策略：基于CSS规定
  • DOM策略：基于DOM操作
  • 阻塞策略：基于脚本加载
  • 回流重绘策略：基于回流重绘
  • 异步更新策略：基于异步更新

上述五方面都是编写代码时实现，充斥在整个我的项目流程的开发阶段里。因而在开发阶段需时刻留神以下波及到的每一点，养成良好的开发习惯，性能优化也自然而然被应用上了。

渲染层面的性能优化更多体现在编码细节上，而并非实体代码。简略来说就是遵循某些编码规定，能力将渲染层面的性能优化施展到最大作用。

回流重绘策略在渲染层面的性能优化里占比拟重，也是最惯例的性能优化之一。上年笔者公布的掘金小册《玩转CSS的艺术之美》应用一整章解说回流重绘，本章已开明试读，更多细节请戳这里。

CSS策略
  • 避免出现超过三层的嵌套规定
  • 防止为ID选择器增加多余选择器
  • 防止应用标签选择器代替类选择器
  • 防止应用通配选择器，只对指标节点申明规定
  • 防止反复匹配反复定义，关注可继承属性
DOM策略
  • 缓存DOM计算属性
  • 防止过多DOM操作
  • 应用DOMFragment缓存批量化DOM操作
阻塞策略
  • 脚本与DOM/其它脚本的依赖关系很强：对<script>设置defer
  • 脚本与DOM/其它脚本的依赖关系不强：对<script>设置async
回流重绘策略
  • 缓存DOM计算属性
  • 应用类合并款式，防止逐条扭转款式
  • 应用display管制DOM显隐，将DOM离线化
异步更新策略
  • 在异步工作中批改DOM时把其包装成微工作

六大指标

笔者依据性能优化的重要性和实际性划分出九大策略和六大指标，其实它们都是一条条活生生的性能优化倡议。有些性能优化倡议接不接入影响都不大，因而笔者将九大策略定位高于六大指标。针对九大策略还是倡议在开发阶段和生产阶段接入，在我的项目复盘时可将六大指标的条条框框依据理论利用场景接入。

六大指标根本囊括大部分性能优化细节，可作为九大策略的补充。笔者依据每条性能优化倡议的特色将指标划分为以下六方面。

  • 加载优化：资源在加载时可做的性能优化
  • 执行优化：资源在执行时可做的性能优化
  • 渲染优化：资源在渲染时可做的性能优化
  • 款式优化：款式在编码时可做的性能优化
  • 脚本优化：脚本在编码时可做的性能优化
  • V8引擎优化：针对V8引擎特色可做的性能优化
加载优化

执行优化

渲染优化

款式优化

脚本优化

V8引擎优化

总结

性能优化作为陈词滥调的常识，必然会在工作或面试时遇上。很多时候不是想到某条性能优化倡议就去做或答，而是要对这方面有一个整体认知，晓得为何这样设计，这样设计的目标能达到什么成果。

性能优化不是通过一篇文章就能全副讲完，若具体去讲可能要写两本书的篇幅能力讲完。本文能到给大家的就是一个方向一种态度，学以致用呗，心愿浏览完本文会对你有所帮忙。

最初，笔者将本文所有内容整顿成一张高清脑图，因为体积太大无奈上传，可关注笔者集体公众号IQ前端并回复性能优化获取口袋常识图谱吧！