乐趣区

关于前端:写给中高级前端关于性能优化的9大策略和6大指标-网易四年实践

jiezi

前言

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

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

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

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

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

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

九大策略

网络层面

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

  • 构建策略：基于构建工具(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 前端 并回复 性能优化 获取口袋常识图谱吧！

退出移动版