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

标签: 前端 html css javascript 性能优化 | 发表时间:2021-07-14 08:00 | 作者:JowayYoung
出处:https://segmentfault.com/blogs

前言

笔者近半年一直在参与项目重构,在重构过程中大量应用 性能优化设计模式两方面的知识。 性能优化设计模式两方面的知识不管在工作还是面试时都是高频应用场景,趁着这次参与大规模项目重构的机会,笔者认真梳理出一些常规且必用的 性能优化建议,同时结合日常开发经验整理出笔者在网易四年来实践到的认为有用的所有 性能优化建议,与大家一起分享分享!(由于篇幅有限,那 设计模式在后面再专门出一篇文章呗)

可能有些 性能优化建议已被大家熟知,不过也不影响这次分享,当然笔者也将一些平时可能不会注意的细节罗列出来。

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

性能优化.png

所有的 性能优化都围绕着 两大层面两小层面实现,核心层面是 网络层面渲染层面,辅助层面是 时间层面体积层面,而辅助层面则充满在核心层面里。于是笔者通过本文整理出关于前端 性能优化九大策略六大指标。当然这些 策略指标都是笔者自己定义,方便通过某种方式为性能优化做一些规范。

因此在工作或面试时结合这些特征就能完美地诠释 性能优化所延伸出来的知识了。 前方高能,不看也得收藏,走起!!!

  所有代码示例为了凸显主题,只展示核心配置代码,其他配置并未补上,请自行脑补

九大策略

网络层面

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

  • 构建策略:基于构建工具( 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-loadereslint-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过滤无依赖文件。通常配置 aliasextensions就足够。

  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分析打包文件结构,好处是 找出导致体积过大的原因。从而通过分析原因得出优化方案减少构建时间。 BundleAnalyzerwebpack官方插件,可直观分析 打包文件的模块组成部分、模块体积占比、模块包含关系、模块依赖关系、文件是否重复、压缩体积对比等可视化数据。

可使用 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-envcore-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,其思路是根据浏览器的 UserAgentbrowserlist查找出当前浏览器哪些特性缺乏支持从而返回这些特性的 Polyfill。对这方面感兴趣的同学可参考 polyfill-librarypolyfill-service的源码。

在此提供两个 动态垫片服务,可在不同浏览器里点击以下链接看看输出不同的 Polyfill。相信 IExplore还是最多 Polyfill的,它自豪地说: 我就是我,不一样的烟火

使用 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.jsonbabel相关配置里接入 @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封装, UglifyjsTerser都是 webpack官方插件,同时需注意压缩 JS代码需区分 ES5ES6

  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报文实现,在形式上分为 强缓存/强制缓存协商缓存/对比缓存。为了方便对比,笔者将某些细节使用图例展示,相信你有更好的理解。

强缓存.png

协商缓存.png

整个 缓存策略机制很明了, 先走强缓存,若命中失败才走协商缓存。若命中 强缓存,直接使用 强缓存;若未命中 强缓存,发送请求到服务器检查是否命中 协商缓存;若命中 协商缓存,服务器返回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引擎特征可做的性能优化
加载优化

六大指标-加载优化.png

执行优化

六大指标-执行优化.png

渲染优化

六大指标-渲染优化.png

样式优化

六大指标-样式优化.png

脚本优化

六大指标-脚本优化.png

V8引擎优化

六大指标-V8引擎优化.png

总结

性能优化作为老生常谈的知识,必然会在工作或面试时遇上。很多时候不是想到某条 性能优化建议就去做或答,而是要对这方面有一个整体认知,知道为何这样设计,这样设计的目的能达到什么效果。

性能优化不是通过一篇文章就能全部讲完,若详细去讲可能要写两本书的篇幅才能讲完。本文能到给大家的就是一个方向一种态度,学以致用呗,希望阅读完本文会对你有所帮助。

最后,笔者将本文所有内容整理成一张高清脑图,由于体积太大无法上传,可关注笔者个人公众号 IQ前端并回复 性能优化获取口袋知识图谱吧!

相关 [前端 性能优化 策略] 推荐:

ElasticSearch性能优化策略

- - 数据库 - ITeye博客
ElasticSearch性能优化主要分为4个方面的优化. 1、增加1-2台服务器,用于负载均衡节点. elasticSearch的配置文件中有2个参数:node.master和node.data. 数搭配使用时,能够帮助提供服务器性能.         该node服务器只作为一个数据节点,只用于存储索引数据.

前端性能优化

- - JavaScript - Web前端 - ITeye博客
  在浏览器(客户端)和服务器发生通信时,就已经消耗了大量的时间,尤其是在网络情况比较糟糕的时候,这个问题尤其的突出.   一个正常HTTP请求的流程简述:如在浏览器中输入" www.xxxxxx.com"并按下回车,浏览器再与这个URL指向的服务器建立连接,然后浏览器才能向服务器发送请求信息,服务器在接受到请求的信息后再返回相应的信息,浏览器接收到来自服务器的应答信息后,对这些数据解释执行.

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

- - SegmentFault 最新的文章
笔者近半年一直在参与项目重构,在重构过程中大量应用 性能优化和 设计模式两方面的知识. 性能优化和 设计模式两方面的知识不管在工作还是面试时都是高频应用场景,趁着这次参与大规模项目重构的机会,笔者认真梳理出一些常规且必用的 性能优化建议,同时结合日常开发经验整理出笔者在网易四年来实践到的认为有用的所有 性能优化建议,与大家一起分享分享.

前端工程与性能优化

- - FEX 百度 Web 前端研发部
每个参与过开发企业级 web 应用的前端工程师或许都曾思考过前端性能优化方面的问题. 我们有雅虎 14 条性能优化原则,还有两本很经典的性能优化指导书:《高性能网站建设指南》、《高性能网站建设进阶指南》. 经验丰富的工程师对于前端性能优化方法耳濡目染,基本都能一一列举出来. 这些性能优化原则大概是在 7 年前提出的,对于 web 性能优化至今都有非常重要的指导意义.

web前端性能优化进阶路

- - 阿里巴巴(中国站)用户体验设计部博客
Web前端性能优化WPO,相信大多数前端同学都不会陌生,在各自所负责的站点页面中,也都会或多或少的有过一定的技术实践. 可以说,这个领域并不缺乏成熟技术理论和技术牛人:例如Yahoo的web站点性能优化 黄金法则,以及大名鼎鼎的优化大师 Steve Souders. 本文并非一篇讨论性能优化技术方法的文章,而更多的是对中文站 搜索List页面持续两年多的前端性能优化实践的 思路总结.

前端性能优化最佳实践

- - Web前端 - ITeye博客
如今浏览器能够实现的特性越来越多,并且网络逐渐向移动设备转移,使我们的前端代码更加紧凑,如何优化,就变得越来越重要了. 开发人员普遍会将他们的代码习惯优先于用户体验. 但是很多很小的改变可以让用户体验有个飞跃提升,所以任何一点儿小小的优化都会提升你网站的性能. 前端给力的地方是可以有许多种简单的策略和代码习惯让我们可以保证最理想的前端性能.

前端性能优化指南

- - SegmentFault 最新的文章
XMLHttpRequest时,而URL长度不到. GET类型请求只需要发送一个. CSS等静态文件放在静态资源服务器上并配置单独域名,客户端请求静态文件的时候,减少. COOKIE反复传输时对主域名的影响. cloneNode在外部更新节点然后再通过. replace与原始节点互换. >多个节点插入操作,即使在外面设置节点的元素和风格再插入,由于多个节点还是会引发多次reflow.

前端性能优化小纪 -

- - IT瘾-geek
天下武功,无坚不破,唯快不破. 对前端而言,快意味着要求资源体量更小、数量更精简、内容更早呈现、交互更加人性化. 当项目做到一定程度,就应该考虑性能的问题,前端的性能优化有诸多有迹可循的理论和方法,比如 Yahoo. 性能军规、Google PageSpeed Insights Rules. 我们团队一个比较老的项目首屏加载大概需要20多秒,这严重影响了用户体验,于是进行了一次首屏加载的性能优化.

hibernate复习(1)性能优化之抓取策略

- - CSDN博客互联网推荐文章
抓取策略(fetching strategy) 是指:当应用程序需要在(Hibernate实体对象图的)关联关系间进行导航的时候, Hibernate如何获取关联对象的策略. 抓取策略可以在O/R映射的元数据中声明,也可以在特定的HQL 或条件查询(Criteria Query)中重载声明. 通过配置抓取策略可以直接影响Session的get()和load()方法的查询效率.

前端重构实践(一) —— 性能优化

- - 搜索研发部官方博客
       最近一直在做性能优化和模块化改造的工作,并完成了一次前端重构. 在这里总结出一些经验和得失来帮助大家思考. 共两篇文章,第一篇讨论性能优化,第二篇讨论模块化框架. 而之所以把这两个话题放到一起,是因为这两项工作都涉及到对前端代码进行不同程度的重构,而且模块化改造其实是我们在对性能优化做到一定程度之后发现必须要做的一件事情.