性能优化分为网络优化和渲染优化

从输入 URL 到页面加载完成，发生了什么？
首先我们需要通过 DNS（域名解析系统）将 URL 解析为对应的 IP 地址，然后与这个 IP 地址确定的那台服务器建立起 TCP 网络连接，随后我们向服务端抛出我们的 HTTP 请求，服务端处理完我们的请求之后，把目标数据放在 HTTP 响应里返回给客户端，拿到响应数据的浏览器就可以开始走一个渲染的流程。渲染完毕，页面便呈现给了用户，并时刻等待响应用户的操作
各个优化
DNS 解析花时间，能不能尽量减少解析次数或者把解析前置？能——浏览器 DNS 缓存和 DNS prefetch
TCP 每次的三次握手都急死人，有没有解决方案？有——长连接、预连接、接入 SPDY 协议
这两个过程的优化往往需要我们和团队的服务端工程师协作完成，
HTTP 请求 减少请求次数和减小请求体积方面

浏览器端的性能优化——这部分涉及资源加载优化、服务端渲染、浏览器缓存机制的利用、DOM 树的构建、网页排版和渲染过程、回流与重绘的考量、DOM 操作的合理规避等等

先说网络优化

从输入 URL 到显示页面这个过程中，涉及到网络层面的，有三个主要过程：

• DNS 解析

• TCP 连接

• HTTP 请求/响应

对于 DNS 解析和 TCP 连接两个步骤，我们前端可以做的努力非常有限。相比之下，HTTP 连接这一层面的优化才是我们网络优化的核心
HTTP 优化有两个大的方向：

• 减少请求次数

• 减少单次请求所花费的时间

指向了我们日常开发中非常常见的操作——资源的压缩与合并
这就是我们用构建工具在做的事情

webpack 的性能瓶颈

webpack 的优化瓶颈，主要是两个方面：

• webpack 的构建过程太花时间

• webpack 打包的结果体积太大

webpack 优化方案

构建过程提速策略

不要让 loader 做太多事情——以 babbabel-loader 无疑是强大的，但它也是慢的。

babel-loader 无疑是强大的，但它也是慢的。

最常见的优化方式是，用 include 或 exclude 来帮我们避免不必要的转译，比如 webpack 官方在介绍 babel-loader 时给出的示例

module: {rules: [{test: /\.js$/,exclude: /(node_modules|bower_components)/,use: {loader: 'babel-loader',options: {presets: ['@babel/preset-env']}}}]
}

这段代码帮我们规避了对庞大的 node_modules 文件夹或者 bower_components 文件夹的处理。但通过限定文件范围带来的性能提升是有限的。除此之外，如果我们选择开启缓存将转译结果缓存至文件系统，则至少可以将 babel-loader 的工作效率提升两倍。要做到这点，我们只需要为 loader 增加相应的参数设定：

loader: 'babel-loader?cacheDirectory=true'

这个规则仅作用于这个 loader，像一些类似 UglifyJsPlugin 的 webpack 插件在工作时依然会被这些庞大的第三方库拖累，webpack 构建速度依然会因此大打折扣。

第三方库的处理

处理第三方库的姿势有很多，其中，Externals 不够聪明，一些情况下会引发重复打包的问题；而 CommonsChunkPlugin 每次构建时都会重新构建一次 vendor；出于对效率的考虑，我们这里为大家推荐 DllPlugin。
DllPlugin 是基于 Windows 动态链接库（dll）的思想被创作出来的。这个插件会把第三方库单独打包到一个文件中，这个文件就是一个单纯的依赖库。这个依赖库不会跟着你的业务代码一起被重新打包，只有当依赖自身发生版本变化时才会重新打包。

用 DllPlugin 处理文件，要分两步走：

• 基于 dll 专属的配置文件，打包 dll 库

• 基于 webpack.config.js 文件，打包业务代码
  以一个基于 React 的简单项目为例，我们的 dll 的配置文件可以编写如下：

const path = require('path')
const webpack = require('webpack')module.exports = {entry: {// 依赖的库数组vendor: ['prop-types','babel-polyfill','react','react-dom','react-router-dom',]},output: {path: path.join(__dirname, 'dist'),filename: '[name].js',library: '[name]_[hash]',},plugins: [new webpack.DllPlugin({// DllPlugin的name属性需要和libary保持一致name: '[name]_[hash]',path: path.join(__dirname, 'dist', '[name]-manifest.json'),// context需要和webpack.config.js保持一致context: __dirname,}),],
}

编写完成之后，运行这个配置文件，我们的 dist 文件夹里会出现这样两个文件：

vendor-manifest.json
vendor.js

vendor.js 不必解释，是我们第三方库打包的结果。这个多出来的 vendor-manifest.json，则用于描述每个第三方库对应的具体路径，我这里截取一部分给大家看下：

{"name": "vendor_397f9e25e49947b8675d","content": {"./node_modules/core-js/modules/_export.js": {"id": 0,"buildMeta": {"providedExports": true}},"./node_modules/prop-types/index.js": {"id": 1,"buildMeta": {"providedExports": true}},...}
}  

随后，我们只需在 webpack.config.js 里针对 dll 稍作配置：

const path = require('path');
const webpack = require('webpack')
module.exports = {mode: 'production',// 编译入口entry: {main: './src/index.js'},// 目标文件output: {path: path.join(__dirname, 'dist/'),filename: '[name].js'},// dll相关配置plugins: [new webpack.DllReferencePlugin({context: __dirname,// manifest就是我们第一步中打包出来的json文件manifest: require('./dist/vendor-manifest.json'),})]
}

以上也可用有些繁琐也可用AutoDllPlugin替代

 npm install --save-dev autodll-webpack-plugin

使用

const AutoDllPlugin = require('autodll-webpack-plugin');plugins: [new AutoDllPlugin({inject: true, // will inject the DLL bundles to htmlcontext: path.join(__dirname, '..'),filename: '[name]_[hash].dll.js',path: 'res/js',plugins: mode === 'online' ? [new UglifyJsPlugin({uglifyOptions: {compress: {warnings: false}},sourceMap: config.build.productionSourceMap,parallel: true})] : [],entry: {vendor: ['vue/dist/vue.esm.js', 'vuex', 'axios', 'vue-router', 'babel-polyfill', 'lodash']}})
]

一次基于 dll 的 webpack 构建过程优化，便大功告成了！

Happypack——将 loader 由单进程转为多进程

大家知道，webpack 是单线程的，就算此刻存在多个任务，你也只能排队一个接一个地等待处理。这是 webpack 的缺点，好在我们的 CPU 是多核的，Happypack 会充分释放 CPU 在多核并发方面的优势，帮我们把任务分解给多个子进程去并发执行，大大提升打包效率。

HappyPack 的使用方法也非常简单，只需要我们把对 loader 的配置转移到 HappyPack 中去就好，我们可以手动告诉 HappyPack 我们需要多少个并发的进程

const HappyPack = require('happypack')
// 手动创建进程池
const happyThreadPool =  HappyPack.ThreadPool({ size: os.cpus().length })module.exports = {module: {rules: [...{test: /\.js$/,// 问号后面的查询参数指定了处理这类文件的HappyPack实例的名字loader: 'happypack/loader?id=happyBabel',...},],},plugins: [...new HappyPack({// 这个HappyPack的“名字”就叫做happyBabel，和楼上的查询参数遥相呼应id: 'happyBabel',// 指定进程池threadPool: happyThreadPool,loaders: ['babel-loader?cacheDirectory']})],
}

构建结果体积压缩

文件结构可视化，找出导致体积过大的原因

这里为大家介绍一个非常好用的包组成可视化工具——webpack-bundle-analyzer，配置方法和普通的 plugin 无异，它会以矩形树图的形式将包内各个模块的大小和依赖关系呈现出来，格局如官方所提供这张图所示：

!––
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-B94UIKHw-1606275910452)(/img/bVcKrrf)]
在使用时，我们只需要将其以插件的形式引入

const BundleAnalyzerPlugin = require('webpack-bundle-analyzer').BundleAnalyzerPlugin;module.exports = {plugins: [new BundleAnalyzerPlugin()]
}

拆分资源

这点仍然围绕 DllPlugin 展开

删除冗余代码

一个比较典型的应用，就是 Tree-Shaking
基于 import/export 语法，Tree-Shaking 可以在编译的过程中获悉哪些模块并没有真正被使用，这些没用的代码，在最后打包的时候会被去除。
适合用来处理模块级别的冗余代码。至于粒度更细的冗余代码的去除，往往会被整合进 JS 或 CSS 的压缩或分离过程中。
这里我们以当下接受度较高的 UglifyJsPlugin 为例，看一下如何在压缩过程中对碎片化的冗余代码（如 console 语句、注释等）进行自动化删除：

const UglifyJsPlugin = require('uglifyjs-webpack-plugin');
module.exports = {plugins: [new UglifyJsPlugin({// 允许并发parallel: true,// 开启缓存cache: true,compress: {// 删除所有的console语句    drop_console: true,// 把使用多次的静态值自动定义为变量reduce_vars: true,},output: {// 不保留注释comment: false,// 使输出的代码尽可能紧凑beautify: false}})]
}

webpack4 中，我们是通过配置 optimization.minimize 与 optimization.minimizer 来自定义压缩相关的操作的。

按需加载

• 一次不加载完所有的文件内容，只加载此刻需要用到的那部分（会提前做拆分）

• 当需要更多内容时，再对用到的内容进行即时加载
  当我们不需要按需加载的时候，我们的代码是这样的：

import BugComponent from '../pages/BugComponent'
...
<Route path="/bug" component={BugComponent}>

为了开启按需加载，我们要稍作改动。
首先 webpack 的配置文件要走起来：

output: {path: path.join(__dirname, '/../dist'),filename: 'app.js',publicPath: defaultSettings.publicPath,// 指定 chunkFilenamechunkFilename: '[name].[chunkhash:5].chunk.js',
},

路由处的代码也要做一下配合；

const getComponent => (location, cb) {require.ensure([], (require) => {cb(null, require('../pages/BugComponent').default)}, 'bug')
},<Route path="/bug" getComponent={getComponent}>

核心就是这个方法：

require.ensure(dependencies, callback, chunkName)

这是一个异步的方法，webpack 在打包时，BugComponent 会被单独打成一个文件，只有在我们跳转 bug 这个路由的时候，这个异步方法的回调才会生效，才会真正地去获取 BugComponent 的内容。这就是按需加载。

按需加载的粒度，还可以继续细化，细化到更小的组件、细化到某个功能点，都是 ok 的。

Gzip 压缩原理

**开启 Gzip。 **
具体的做法非常简单，只需要你在你的 request headers 中加上这么一句：

accept-encoding:gzip

我们前端关系更密切的话题：HTTP 压缩。

HTTP 压缩是一种内置到网页服务器和网页客户端中以改进传输速度和带宽利用率的方式。在使用 HTTP 压缩的情况下，HTTP 数据在从服务器发送前就已压缩：兼容的浏览器将在下载所需的格式前宣告支持何种方法给服务器；不支持压缩方法的浏览器将下载未经压缩的数据。最常见的压缩方案包括 Gzip 和 Deflate。

HTTP 压缩就是以缩小体积为目的，对 HTTP 内容进行重新编码的过程
Gzip 的内核就是 Deflate，目前我们压缩文件用得最多的就是 Gzip。可以说，Gzip 就是 HTTP 压缩的经典例题。

该不该用 Gzip

压缩 Gzip，服务端要花时间；解压 Gzip，浏览器要花时间。中间节省出来的传输时间，真的那么可观吗？
我们处理的都是具备一定规模的项目文件。实践证明，这种情况下压缩和解压带来的时间开销相对于传输过程中节省下的时间开销来说，可以说是微不足道的。

Gzip 是万能的吗

首先要承认 Gzip 是高效的，压缩后通常能帮我们减少响应 70% 左右的大小。

但它并非万能。Gzip 并不保证针对每一个文件的压缩都会使其变小。

Gzip 压缩背后的原理，是在一个文本文件中找出一些重复出现的字符串、临时替换它们，从而使整个文件变小。根据这个原理，文件中代码的重复率越高，那么压缩的效率就越高，使用 Gzip 的收益也就越大。反之亦然。

webpack 的 Gzip 和服务端的 Gzip

一般来说，Gzip 压缩是服务器的活儿：服务器了解到我们这边有一个 Gzip 压缩的需求，它会启动自己的 CPU 去为我们完成这个任务。而压缩文件这个过程本身是需要耗费时间的，大家可以理解为我们以服务器压缩的时间开销和 CPU 开销（以及浏览器解析压缩文件的开销）为代价，省下了一些传输过程中的时间开销。

既然存在着这样的交换，那么就要求我们学会权衡。服务器的 CPU 性能不是无限的，如果存在大量的压缩需求，服务器也扛不住的。服务器一旦因此慢下来了，用户还是要等。Webpack 中 Gzip 压缩操作的存在，事实上就是为了在构建过程中去做一部分服务器的工作，为服务器分压。

因此，这两个地方的 Gzip 压缩，谁也不能替代谁。它们必须和平共处，好好合作。作为开发者，我们也应该结合业务压力的实际强度情况，去做好这其中的权衡。

图片优化——质量与性能的博弈

图片是电商平台的重要资源，甚至有人说“做电商就是做图片”。

就图片这块来说，与其说我们是在做“优化”，不如说我们是在做“权衡”。因为我们要做的事情，就是去压缩图片的体积（或者一开始就选取体积较小的图片格式）。但这个优化操作，是以牺牲一部分成像质量为代价的。因此我们的主要任务，是尽可能地去寻求一个质量与性能之间的平衡点。
时下应用较为广泛的 Web 图片格式有 JPEG/JPG、PNG、WebP、Base64、SVG 等
不谈业务场景的选型都是耍流氓

在计算机中，像素用二进制数来表示。不同的图片格式中像素与二进制位数之间的对应关系是不同的。一个像素对应的二进制位数越多，它可以表示的颜色种类就越多，成像效果也就越细腻，文件体积相应也会越大。
一个二进制位表示两种颜色（0|1 对应黑|白），如果一种图片格式对应的二进制位数有 n 个，那么它就可以呈现 2^n 种颜色。

JPEG/JPG

关键字：有损压缩、体积小、加载快、不支持透明

JPG 的优点

JPG 最大的特点是有损压缩
。这种高效的压缩算法使它成为了一种非常轻巧的图片格式。另一方面，即使被称为“有损”压缩，JPG的压缩方式仍然是一种高质量的压缩方式：当我们把图片体积压缩至原有体积的 50% 以下时，JPG 仍然可以保持住 60% 的品质。此外，JPG 格式以 24 位存储单个图，可以呈现多达 1600 万种颜色，足以应对大多数场景下对色彩的要求，这一点决定了它压缩前后的质量损耗并不容易被我们人类的肉眼所察觉
JPG 适用于呈现色彩丰富的图片，在我们日常开发中，JPG 图片经常作为大的背景图、轮播图或 Banner 图出现。

JPG 的缺陷

有损压缩在上文所展示的轮播图上确实很难露出马脚，但当它处理矢量图形和 Logo 等线条感较强、颜色对比强烈的图像时，人为压缩导致的图片模糊会相当明显。

此外，JPEG 图像不支持透明度处理，透明图片需要召唤 PNG 来呈现。

PNG-8 与 PNG-24

关键字：无损压缩、质量高、体积大、支持透明

PNG 的优点

PNG（可移植网络图形格式）是一种无损压缩的高保真的图片格式。8 和 24，这里都是二进制数的位数。按照我们前置知识里提到的对应关系，8 位的 PNG 最多支持 256 种颜色，而 24 位的可以呈现约 1600 万种颜色。
PNG 图片具有比 JPG 更强的色彩表现力，对线条的处理更加细腻，对透明度有良好的支持。它弥补了上文我们提到的 JPG 的局限性，唯一的 BUG 就是体积太大。
前面我们提到，复杂的、色彩层次丰富的图片，用 PNG 来处理的话，成本会比较高，我们一般会交给 JPG 去存储。

考虑到 PNG 在处理线条和颜色对比度方面的优势，我们主要用它来呈现小的 Logo、颜色简单且对比强烈的图片或背景等。

SVG

文本文件、体积小、不失真、兼容性好

SVG（可缩放矢量图形）是一种基于 XML 语法的图像格式。它和本文提及的其它图片种类有着本质的不同：SVG 对图像的处理不是基于像素点，而是是基于对图像的形状描述。

和性能关系最密切的一点就是：SVG 与 PNG 和 JPG 相比，文件体积更小，可压缩性更强。

当然，作为矢量图，它最显著的优势还是在于图片可无限放大而不失真这一点上。这使得 SVG 即使是被放到视网膜屏幕上，也可以一如既往地展现出较好的成像品质——1 张 SVG 足以适配 n 种分辨率。

此外，SVG 是文本文件。我们既可以像写代码一样定义 SVG，把它写在 HTML 里、成为 DOM 的一部分，也可以把对图形的描述写入以 .svg 为后缀的独立文件（SVG 文件在使用上与普通图片文件无异）。这使得 SVG 文件可以被非常多的工具读取和修改，具有较强的灵活性。

SVG 的局限性主要有两个方面，一方面是它的渲染成本比较高，这点对性能来说是很不利的。另一方面，SVG 存在着其它图片格式所没有的学习成本（它是可编程的）

SVG 的使用方式与应用场景

SVG 是文本文件，我们既可以像写代码一样定义 SVG，把它写在 HTML 里、成为 DOM 的一部分，也可以把对图形的描述写入以 .svg 为后缀的独立文件（SVG 文件在使用上与普通图片文件无异）。

• 将 SVG 写入 HTML：

<!DOCTYPE html>
<html lang="en">
<head><meta charset="UTF-8"><title></title>
</head>
<body><svg xmlns="http://www.w3.org/2000/svg"   width="200" height="200"><circle cx="50" cy="50" r="50" /></svg>
</body>
</html>

将 SVG 写入独立文件后引入 HTML:

<img src="文件名.svg" alt="">

在实际开发中，我们更多用到的是后者。很多情况下设计师会给到我们 SVG 文件，就算没有设计师，我们还有非常好用的 在线矢量图形库。对于矢量图，我们无须深究过多，只需要对其核心特性有所掌握、日后在应用时做到有迹可循即可。

最经典的小图标解决方案——雪碧图（CSS Sprites）

一种将小图标和背景图像合并到一张图片上，然后利用 CSS 的背景定位来显示其中的每一部分的技术。

被运用于众多使用大量小图标的网页应用之上。它可取图像的一部分来使用，使得使用一个图像文件替代多个小文件成为可能。相较于一个小图标一个图像文件，单独一张图片所需的 HTTP 请求更少，对内存和带宽更加友好。

Base64

不难看出，每次加载图片，都是需要单独向服务器请求这个图片对应的资源的——这也就意味着一次 HTTP 请求的开销。
Base64 是一种用于传输 8Bit 字节码的编码方式，通过对图片进行 Base64 编码，我们可以直接将编码结果写入 HTML 或者写入 CSS，从而减少 HTTP 请求的次数

按照一贯的思路，我们加载图片需要把图片链接写入 img 标签：

<img src="https://user-gold-cdn.xitu.io/2018/9/15/165db7e94699824b?w=22&h=22&f=png&s=3680">

浏览器就会针对我们的图片链接去发起一个资源请求.

但是如果我们对这个图片进行 Base64 编码，我们会得到一个这样的字符串：

data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABYAAAAWCAYAAADEtGw7AAAMJGlDQ1BJQ0MgUHJvZmlsZQAASImVlwdUU8kagOeWJCQktEAEpITeBCnSpdfQpQo2QhJIKDEkBBU7uqjgWlARwYquitjWAshiw14Wwd4fiKgo62LBhsqbFNDV89477z9n7v3yzz9/mcydMwOAehxbJMpFNQDIExaI48MCmeNT05ikR4AECIAKRgEamyMRBcTFRQEoQ+9/yrubAJG9r9nLfP3c/19Fk8uTcABA4iBncCWcPMiHAMDdOCJxAQCEXqg3m1YggkyEWQJtMUwQsrmMsxTsIeMMBUfJbRLjgyCnA6BCZbPFWQCoyfJiFnKyoB+1pZAdhVyB

字符串比较长，我们可以直接用这个字符串替换掉上文中的链接地址。你会发现浏览器原来是可以理解这个字符串的，它自动就将这个字符串解码为了一个图片，而不需再去发送 HTTP 请求

Base64 的应用场景

上面这个实例，其实源自我们 掘金 网站 Header 部分的搜索栏 Logo：
Base64 编码后，图片大小会膨胀为原文件的 4/3（这是由 Base64 的编码原理决定的）。如果我们把大图也编码到 HTML 或 CSS 文件中，后者的体积会明显增加，即便我们减少了 HTTP 请求，也无法弥补这庞大的体积带来的性能开销，得不偿失。

在传输非常小的图片的时候，Base64 带来的文件体积膨胀、以及浏览器解析 Base64 的时间开销，与它节省掉的 HTTP 请求开销相比，可以忽略不计，这时候才能真正体现出它在性能方面的优势。

因此，Base64 并非万全之策，我们往往在一张图片满足以下条件时会对它应用 Base64 编码：

• 图片的实际尺寸很小（大家可以观察一下掘金页面的 Base64 图，几乎没有超过 2kb 的）

• 图片无法以雪碧图的形式与其它小图结合（合成雪碧图仍是主要的减少 HTTP 请求的途径，Base64 是雪碧图的补充）

• 图片的更新频率非常低（不需我们重复编码和修改文件内容，维护成本较低）

Base64 编码工具推荐

这里最推荐的是利用 webpack 来进行 Base64 的编码——webpack 的 url-loader 非常聪明，它除了具备基本的 Base64 转码能力，还可以结合文件大小，帮我们判断图片是否有必要进行 Base64 编码。

除此之外，市面上免费的 Base64 编解码工具种类是非常多样化的，有很多网站都提供在线编解码的服务，大家选取自己认为顺手的工具就好。

WebP

WebP 像 JPEG 一样对细节丰富的图片信手拈来，像 PNG 一样支持透明，像 GIF 一样可以显示动态图片——它集多种图片文件格式的优点于一身。

与 PNG 相比，WebP 无损图像的尺寸缩小了 26％。在等效的 SSIM 质量指数下，WebP 有损图像比同类 JPEG 图像小 25-34％。

无损 WebP 支持透明度（也称为 alpha 通道），仅需 22％ 的额外字节。对于有损 RGB 压缩可接受的情况，有损 WebP 也支持透明度，与 PNG 相比，通常提供 3 倍的文件大小。
WebP 纵有千般好 都逃不开兼容性的大坑

此外，WebP 还会增加服务器的负担——和编码 JPG 文件相比，编码同样质量的 WebP 文件会占用更多的计算资源。

WebP 的应用场景

现在限制我们使用 WebP 的最大问题不是“这个图片是否适合用 WebP 呈现”的问题，而是“浏览器是否允许 WebP”的问题，即我们上文谈到的兼容性问题。具体来说，一旦我们选择了 WebP，就要考虑在 Safari 等浏览器下它无法显示的问题，也就是说我们需要准备 PlanB，准备降级方案。

目前真正把 WebP 格式落地到网页中的网站并不是很多，这其中淘宝首页对 WebP 兼容性问题的处理方式就非常有趣。我们可以打开 Chrome 的开发者工具搜索其源码里的 WebP 关键字

<img src="//img.alicdn.com/tps/i4/TB1CKSgIpXXXXccXXXX07tlTXXX-200-200.png_60x60.jpg_.webp" alt="手机app - 聚划算" class="app-icon">

.webp 前面，还跟了一个 .jpg 后缀！
这个图片应该至少存在 jpg 和 webp 两种格式，程序会根据浏览器的型号、以及该型号是否支持 WebP 这些信息来决定当前浏览器显示的是 .webp 后缀还是 .jpg 后缀。带着这个预判，我们打开并不支持 WebP 格式的 Safari 来进入同样的页面，再次搜索 WebP 关键字：
Safari 提示我们找不到，这也是情理之中。我们定位到刚刚示例的 WebP 图片所在的元素，查看一下它在 Safari 里的图片链接

<img src="//img.alicdn.com/tps/i4/TB1CKSgIpXXXXccXXXX07tlTXXX-200-200.png_60x60.jpg" alt="手机app - 聚划算" class="app-icon">

在 Safari 中的后缀从 .webp 变成了 .jpg！
站点确实是先进行了兼容性的预判，在浏览器环境支持 WebP 的情况下，优先使用 WebP 格式，否则就把图片降级为 JPG 格式（本质是对图片的链接地址作简单的字符串切割）。
此外，还有另一个维护性更强、更加灵活的方案——把判断工作交给后端，由服务器根据 HTTP 请求头部的 Accept 字段来决定返回什么格式的图片。当 Accept 字段包含 image/webp 时，就返回 WebP 格式的图片，否则返回原图。这种做法的好处是，当浏览器对 WebP 格式图片的兼容支持发生改变时，我们也不用再去更新自己的兼容判定代码，只需要服务端像往常一样对 Accept 字段进行检查即可。

由此也可以看出，我们 WebP 格式的局限性确实比较明显，如果决定使用 WebP，兼容性处理是必不可少的

浏览器缓存机制与缓存策略

缓存可以提高网络IO消耗 提高访问速度
通过网络获取内容既速度缓慢又开销巨大。较大的响应需要在客户端与服务器之间进行多次往返通信，这会延迟浏览器获得和处理内容的时间，还会增加访问者的流量费用。因此，缓存并重复利用之前获取的资源的能力成为性能优化的一个关键方面。
浏览器缓存机制有四个方面，它们按照获取资源时请求的优先级依次排列如下

1. Memory Cache

2. Service Worker Cache

3. HTTP Cache

4. Push Cache

HTTP 缓存机制

分为强缓存和协商缓存。优先级较高的是强缓存，在命中强缓存失败的情况下，才会走协商缓存。

强缓存是利用 http 头中的 Expires 和 Cache-Control 两个字段来控制的。强缓存中，当请求再次发出时，浏览器会根据其中的 expires 和 cache-control 判断目标资源是否“命中”强缓存，若命中则直接从缓存中获取资源，不会再与服务端发生通信。

命中强缓存的情况下，返回的 HTTP 状态码为 200

强缓存的实现：从 expires 到 cache-control

实现强缓存，过去我们一直用 expires。
当服务器返回响应时，在 Response Headers 中将过期时间写入 expires 字段。像这样：

expires: Wed, 11 Sep 2019 16:12:18 GMT

expires 是一个时间戳，接下来如果我们试图再次向服务器请求资源，浏览器就会先对比本地时间和 expires 的时间戳，如果本地时间小于 expires 设定的过期时间，那么就直接去缓存中取这个资源。

expires 是有问题的，它最大的问题在于对“本地时间”的依赖。如果服务端和客户端的时间设置可能不同，或者我直接手动去把客户端的时间改掉，那么 expires 将无法达到我们的预期。
考虑到 expires 的局限性，HTTP1.1 新增了 Cache-Control 字段来完成 expires 的任务。

expires 能做的事情，Cache-Control 都能做；expires 完成不了的事情，Cache-Control 也能做。因此，Cache-Control 可以视作是 expires 的完全替代方案。在当下的前端实践里，我们继续使用 expires 的唯一目的就是向下兼容。

现在我们给 Cache-Control 字段一个特写：

cache-control: max-age=31536000

通过 max-age 来控制资源的有效期。max-age 不是一个时间戳，而是一个时间长度。在本例中，max-age 是 31536000 秒，它意味着该资源在 31536000 秒以内都是有效的，完美地规避了时间戳带来的潜在问题。
Cache-Control 相对于 expires 更加准确，它的优先级也更高。当 Cache-Control 与 expires 同时出现时，我们以 Cache-Control 为准。
Cache-Control 的神通，可不止于这一个小小的 max-age。如下的用法也非常常见

cache-control: max-age=3600, s-maxage=31536000

s-maxage 优先级高于 max-age，两者同时出现时，优先考虑 s-maxage。如果 s-maxage 未过期，则向代理服务器请求其缓存内容。
在项目不是特别大的场景下，max-age 足够用了。但在依赖各种代理的大型架构中，我们不得不考虑代理服务器的缓存问题。s-maxage 就是用于表示 cache 服务器上（比如 cache CDN）的缓存的有效时间的，并只对 public 缓存有效。
那么什么是 public 缓存呢

public 与 private

public 与 private 是针对资源是否能够被代理服务缓存而存在的一组对立概念。
如果我们为资源设置了 public，那么它既可以被浏览器缓存，也可以被代理服务器缓存；如果我们设置了 private，则该资源只能被浏览器缓存。private 为默认值。但多数情况下，public 并不需要我们手动设置，比如有很多线上网站的 cache-control 是这样的：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Vcse6zdp-1606275910453)(/img/bVcKJEg)]
设置了 s-maxage，没设置 public，那么 CDN 还可以缓存这个资源吗？答案是肯定的。因为明确的缓存信息（例如“max-age”）已表示响应是可以缓存的。

no-store与no-cache

no-cache 绕开了浏览器：我们为资源设置了 no-cache 后，每一次发起请求都不会再去询问浏览器的缓存情况，而是直接向服务端去确认该资源是否过期

no-store 比较绝情，顾名思义就是不使用任何缓存策略。在 no-cache 的基础上，它连服务端的缓存确认也绕开了，只允许你直接向服务端发送请求、并下载完整的响应。

协商缓存：浏览器与服务器合作之下的缓存策略

协商缓存依赖于服务端与浏览器之间的通信。
协商缓存机制下，浏览器需要向服务器去询问缓存的相关信息，进而判断是重新发起请求、下载完整的响应，还是从本地获取缓存的资源。
如果服务端提示缓存资源未改动（Not Modified），资源会被重定向到浏览器缓存，这种情况下网络请求对应的状态码是 304（如下图）
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-JLx5YAfz-1606275910455)(/img/bVcKJEW)]

协商缓存的实现：从 Last-Modified 到 Etag

Last-Modified 是一个时间戳，如果我们启用了协商缓存，它会在首次请求时随着 Response Headers 返回：

Last-Modified: Fri, 27 Oct 2017 06:35:57 GMT

随后我们每次请求时，会带上一个叫 If-Modified-Since 的时间戳字段，它的值正是上一次 response 返回给它的 last-modified 值：

If-Modified-Since: Fri, 27 Oct 2017 06:35:57 GMT

服务器接收到这个时间戳后，会比对该时间戳和资源在服务器上的最后修改时间是否一致，从而判断资源是否发生了变化。如果发生了变化，就会返回一个完整的响应内容，并在 Response Headers 中添加新的 Last-Modified 值；否则，返回如上图的 304 响应，Response Headers 不会再添加 Last-Modified 字段。
使用 Last-Modified 存在一些弊端，这其中最常见的就是这样两个场景：
1 我们编辑了文件，但文件的内容没有改变。服务端并不清楚我们是否真正改变了文件，它仍然通过最后编辑时间进行判断。因此这个资源在再次被请求时，会被当做新资源，进而引发一次完整的响应——不该重新请求的时候，也会重新请求。
2 当我们修改文件的速度过快时（比如花了 100ms 完成了改动），由于 If-Modified-Since 只能检查到以秒为最小计量单位的时间差，所以它是感知不到这个改动的——该重新请求的时候，反而没有重新请求了。

这两个场景其实指向了同一个 bug——服务器并没有正确感知文件的变化。为了解决这样的问题，Etag 作为 Last-Modified 的补充出现了。

Etag 是由服务器为每个资源生成的唯一的标识字符串，这个标识字符串是基于文件内容编码的，只要文件内容不同，它们对应的 Etag 就是不同的，反之亦然。因此 Etag 能够精准地感知文件的变化
Etag 和 Last-Modified 类似，当首次请求时，我们会在响应头里获取到一个最初的标识符字符串，举个🌰，它可以是这样的：

ETag: W/"2a3b-1602480f459"

那么下一次请求时，请求头里就会带上一个值相同的、名为 if-None-Match 的字符串供服务端比对了：

If-None-Match: W/"2a3b-1602480f459"

Etag 的生成过程需要服务器额外付出开销，会影响服务端的性能，这是它的弊端。因此启用 Etag 需要我们审时度势。正如我们刚刚所提到的——Etag 并不能替代 Last-Modified，它只能作为 Last-Modified 的补充和强化存在。
Etag 在感知文件变化上比 Last-Modified 更加准确，优先级也更高。当 Etag 和 Last-Modified 同时存在时，以 Etag 为准。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Rt5xljpj-1606275910457)(/img/bVcKJMM)]
解读一下这张流程图
当我们的资源内容不可复用时，直接为 Cache-Control 设置 no-store，拒绝一切形式的缓存；否则考虑是否每次都需要向服务器进行缓存有效确认，如果需要，那么设 Cache-Control 的值为 no-cache；否则考虑该资源是否可以被代理服务器缓存，根据其结果决定是设置为 private 还是 public；然后考虑该资源的过期时间，设置对应的 max-age 和 s-maxage 值；最后，配置协商缓存需要用到的 Etag、Last-Modified 等参数。

MemoryCache

MemoryCache，是指存在内存中的缓存。从优先级上来说，它是浏览器最先尝试去命中的一种缓存。从效率上来说，它是响应速度最快的一种缓存。
内存缓存是快的，也是“短命”的。它和渲染进程“生死相依”，当进程结束后，也就是 tab 关闭以后，内存里的数据也将不复存在。

资源存不存内存，浏览器秉承的是“节约原则”。我们发现，Base64 格式的图片，几乎永远可以被塞进 memory cache，这可以视作浏览器为节省渲染开销的“自保行为”；此外，体积不大的 JS、CSS 文件，也有较大地被写入内存的几率——相比之下，较大的 JS、CSS 文件就没有这个待遇了，内存资源是有限的，它们往往被直接甩进磁盘

Service Worker Cache

Service Worker 是一种独立于主线程之外的 Javascript 线程。它脱离于浏览器窗体，因此无法直接访问 DOM。
这样独立的个性使得 Service Worker 的“个人行为”无法干扰页面的性能，这个“幕后工作者”可以帮我们实现离线缓存、消息推送和网络代理等功能。
我们借助 Service worker 实现的离线缓存就称为 Service Worker Cache
Service Worker 的生命周期包括 install、active、working 三个阶段。一旦 Service Worker 被 install，它将始终存在，只会在 active 与 working 之间切换，除非我们主动终止它。这是它可以用来实现离线存储的重要先决条件。
Service Worker 如何为我们实现离线缓存（注意看注释）：入口文件中插入这样一段 JS 代码，用以判断和引入 Service Worker:

window.navigator.serviceWorker.register('/test.js').then(()=>{
console.log('注册成功')
}).catch((error)=>{console.log('注册失败')
})

在 test.js 中，我们进行缓存的处理。假设我们需要缓存的文件分别是 test.html,test.css 和 test.js：

 self.addEventListener('install',event=>{event.waitUntill(// 考虑到缓存也需要更新， open内传入的参数为缓存的版本号caches.open('test-v1').then(cache=>{return cache.addAll([//此处传入指定的需缓存的文件名'/test.html','/test.css','test.js'])}))})//Service Worker会监听所有的网络请求，网络请求的产生触发的是fetch事件，我们可以在其对应的监听函数中实现对请求的拦截//进而判断是否对应到该请求的缓存 实现从Service Worker中取缓存的目的self.addEventListener('fetch',event=>{event.respondWith(//尝试匹配该请求对应的缓存值caches.match(event.request).then(res=>{//如果匹配到了，调用Server Worker缓存if(res){return res}//如果没有匹配到  向服务器发起这个资源请求return fetch(event.request).then(response=>{if(!response||response.status!==200){return response}//请求成功的话，将请求缓存起来caches.open('test-v1').then((cache)=>{cache.put(event.request,response)})return response.clone()})}))})

Server Worker 对协议是有要求的，必须以 https 协议为前提。

Push Cache

https://jakearchibald.com/2017/h2-push-tougher-than-i-thought/

Push Cache 是指 HTTP2 在 server push 阶段存在的缓存。这块的知识比较新，应用也还处于萌芽阶段，
但应用范围有限不代表不重要——HTTP2 是趋势、是未来。

*Push Cache 是缓存的最后一道防线。浏览器只有在 Memory Cache、HTTP Cache 和 Service Worker Cache 均未命中的情况下才会去询问 Push Cache。

*Push Cache 是一种存在于会话阶段的缓存，当 session 终止时，缓存也随之释放。
*不同的页面只要共享了同一个 HTTP2 连接，那么它们就可以共享同一个 Push Cache。

本地存储——从 Cookie 到 Web Storage、IndexDB

从 Cookie 说起

HTTP 协议是一个无状态协议，服务器接收客户端的请求，返回一个响应 服务器并没有记录下关于客户端的任何信息。
Cookie 说白了就是一个存储在浏览器里的一个小小的文本文件，它附着在 HTTP 请求上，在浏览器和服务器之间“飞来飞去”。它可以携带用户信息，当服务器检查 Cookie 的时候，便可以获取到客户端的状态。

Cookie的性能劣势

Cookie 不够大

Cookie 是有体积上限的，它最大只能有 4KB。当 Cookie 超过 4KB 时，它将面临被裁切的命运。这样看来，Cookie 只能用来存取少量的信息。

过量的 Cookie 会带来巨大的性能浪费

Cookie 是紧跟域名的。我们通过响应头里的 Set-Cookie 指定要存储的 Cookie 值。默认情况下，domain 被设置为设置 Cookie 页面的主机名，我们也可以手动设置 domain 的值：

Set-Cookie: name=xiuyan; domain=xiuyan.me

同一个域名下的所有请求，都会携带 Cookie

请求一张图片或者一个 CSS 文件，我们也要携带一个 Cookie 跑来跑去（关键是 Cookie 里存储的信息我现在并不需要），这是一件多么劳民伤财的事情。Cookie 虽然小，请求却可以有很多，随着请求的叠加，这样的不必要的 Cookie 带来的开销将是无法想象的。

Web Storage

Web Storage 是 HTML5 专门为浏览器存储而提供的数据存储机制。它又分为 Local Storage 与 Session Storage。
两者的区别在于生命周期与作用域的不同。

• 生命周期：Local Storage 是持久化的本地存储，存储在其中的数据是永远不会过期的，使其消失的唯一办法是手动删除；而 Session Storage 是临时性的本地存储，它是会话级别的存储，当会话结束（页面被关闭）时，存储内容也随之被释放。

• 作用域：Local Storage、Session Storage 和 Cookie 都遵循同源策略。但 Session Storage 特别的一点在于，即便是相同域名下的两个页面，只要它们不在同一个浏览器窗口中打开，那么它们的 Session Storage 内容便无法共享。

Web Storage 的特性

• 存储容量大： Web Storage 根据浏览器的不同，存储容量可以达到 5-10M 之间。

• 仅位于浏览器端，不与服务端发生通信。

• Web Storage 核心 API 使用示例

Web Storage 保存的数据内容和 Cookie 一样，是文本内容，以键值对的形式存在。Local Storage 与 Session Storage 在 API 方面无异，这里我们以 localStorage 为例：

• 存储数据：setItem()

localStorage.setItem('user_name', 'xiuyan')

• 读取数据： getItem()

localStorage.getItem('user_name')

• 删除某一键名对应的数据： removeItem()

localStorage.removeItem('user_name')

• 清空数据记录：clear()

localStorage.clear()

应用场景

倾向于用它来存储一些内容稳定的资源。比如图片内容丰富的电商网站会用它来存储 Base64 格式的图片字符串：
有的网站还会用它存储一些不经常更新的 CSS、JS 等静态资源。

Session Storage

Session Storage 更适合用来存储生命周期和它同步的会话级别的信息。这些信息只适用于当前会话，当你开启新的会话时，它也需要相应的更新或释放。比如微博的 Session Storage 就主要是存储你本次会话的浏览足迹：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-VQpGbLAv-1606275910460)(/img/bVcKKaw)]
lasturl 对应的就是你上一次访问的 URL 地址，这个地址是即时的。当你切换 URL 时，它随之更新，当你关闭页面时，留着它也确实没有什么意义了，干脆释放吧。这样的数据用 Session Storage 来处理再合适不过
Web Storage 是一个从定义到使用都非常简单的东西。它使用键值对的形式进行存储，这种模式有点类似于对象，却甚至连对象都不是——它只能存储字符串，要想得到对象，我们还需要先对字符串进行一轮解析。

说到底，Web Storage 是对 Cookie 的拓展，它只能用于存储少量的简单数据。当遇到大规模的、结构复杂的数据时，Web Storage 也爱莫能助了。这时候我们就要清楚我们的终极大 boss——IndexDB！

终极形态：IndexDB

IndexDB 是一个运行在浏览器上的非关系型数据库。既然是数据库了，那就不是 5M、10M 这样小打小闹级别了。理论上来说，IndexDB 是没有存储上限的（一般来说不会小于 250M）。它不仅可以存储字符串，还可以存储二进制数据。

遵循 MDN 推荐的操作模式 操作一个基本的 IndexDB 使用流程
1 打开/创建一个 IndexDB 数据库（当该数据库不存在时，open 方法会直接创建一个名为 xiaoceDB 新数据库）。

   //后面的回调中  我们可以通过event.target.result拿到数据库实例let db//参数1位数据库名  参数2为版本号const request = window.indexedDB.open('xiaoceDB',1)//使用IndexDB失败时的监听函数request.onerror = function(event){console.log('无法使用IndexDB');}//成功request.onsuccess = function(event){//此处就可以获取到db实例db = event.target.resultconsole.log('您打开了IndexDB');}

2 创建一个object store(object store对标到数据库中的表单位)

 //onupgradeneeded事件会在初始化数据库/版本发生更新时调用，我们在它的监听函数中创建object storerequest.onupgradeneeded = function(event){let objectStore//如果同名表未被创建过 则新建test表if(!db.objectStoreNames.contains('test')){objectStore = db.createObjectStore('test',{keyPath:'id'})}}

3 构建一个事务来执行一些数据库操作，像增加或提取数据等。

 //创建事务  指定表格名称和读写功能const transaction = db.transaction(["test"],"readwrite")//  拿到Object Store对象const objectStore = transaction.objectStore("test")//向表格写入数据objectStore.add({id:1,name:'xiuyan'})

4 通过监听正确类型的事件以等待操作完成。

 // 操作完成时的监听函数transaction.oncomplete = function(event){console.log('操作完成')}// 操作失败时的监听函数transaction.onerror = function(event){console.log('这里有一个error')}

IndexDB 的应用场景

在 IndexDB 中，我们可以创建多个数据库，一个数据库中创建多张表，一张表中存储多条数据——这足以 hold 住复杂的结构性数据。IndexDB 可以看做是 LocalStorage 的一个升级，当数据的复杂度和规模上升到了 LocalStorage 无法解决的程度，我们毫无疑问可以请出 IndexDB 来帮忙。

浏览器缓存/存储技术的出现和发展，为我们的前端应用带来了无限的转机。近年来基于缓存/存储技术的第三方库层出不绝，此外还衍生出了 PWA 这样优秀的 Web 应用模型。可以说，现代前端应用，尤其是移动端应用，之所以可以发展到在体验上叫板 Native 的地步，主要就是仰仗缓存/存储立下的汗马功劳

CDN 的缓存与回源机制解析

CDN （Content Delivery Network，即内容分发网络）指的是一组分布在各个地区的服务器。这些服务器存储着数据的副本，因此服务器可以根据哪些服务器与用户距离最近，来满足数据的请求。 CDN 提供快速服务，较少受高流量影响

缓存、本地存储带来的性能提升，是不是只能在“获取到资源并把它们存起来”这件事情发生之后？也就是说，首次请求资源的时候，这些招数都是救不了我们的。要提升首次请求的响应能力，我们还需要借助 CDN 的能力

CDN 如何工作

假设我的根服务器在杭州
此时有一位北京的用户向我请求资源。在网络带宽小、用户访问量大的情况下，杭州的这一台服务器或许不那么给力，不能给用户非常快的响应速度。于是我灵机一动，把这批资源 copy 了一批放在北京的机房里。当用户请求资源时，就近请求北京的服务器，北京这台服务器低头一看，这个资源我存了，离得这么近，响应速度肯定噌噌的！那如果北京这台服务器没有 copy 这批资源呢？它会再向杭州的根服务器去要这个资源。在这个过程中，北京这台服务器就扮演着 CDN 的角色。

CDN的核心功能特写

CDN 的核心点有两个，一个是缓存，一个是回源。

“缓存”就是说我们把资源 copy 一份到 CDN 服务器上这个过程，“回源”就是说 CDN 发现自己没有这个资源（一般是缓存的数据过期了），转头向根服务器（或者它的上层服务器）去要这个资源的过程。

CDN 与前端性能优化

CDN 往往被用来存放静态资源。上文中我们举例所提到的“根服务器”本质上是业务服务器，它的核心任务在于生成动态页面或返回非纯静态页面，这两种过程都是需要计算的。业务服务器仿佛一个车间，车间里运转的机器轰鸣着为我们产出所需的资源；相比之下，CDN 服务器则像一个仓库，它只充当资源的“栖息地”和“搬运工”。
所谓“静态资源”，就是像 JS、CSS、图片等不需要业务服务器进行计算即得的资源。而“动态资源”，顾名思义是需要后端实时动态生成的资源，较为常见的就是 JSP、ASP 或者依赖服务端渲染得到的 HTML 页面。
什么是“非纯静态资源”呢？它是指需要服务器在页面之外作额外计算的 HTML 页面。具体来说，当我打开某一网站之前，该网站需要通过权限认证等一系列手段确认我的身份、进而决定是否要把 HTML 页面呈现给我。这种情况下 HTML 确实是静态的，但它和业务服务器的操作耦合，我们把它丢到CDN 上显然是不合适的。

CDN 的实际应用

静态资源本身具有访问频率高、承接流量大的特点，因此静态资源加载速度始终是前端性能的一个非常关键的指标。CDN 是静态资源提速的重要手段，在许多一线的互联网公司，“静态资源走 CDN”并不是一个建议，而是一个规定。
比如以淘宝为代表的阿里系产品，就遵循着这个“规定”。

打开淘宝首页，我们可以在 Network 面板中看到，“非纯静态”的 HTML 页面，是向业务服务器请求来的：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-OF1JiEnr-1606275910461)(https://segmentfault.com/img/bVcKLoU “image.png”)]
我们点击 preview，可以看到业务服务器确实是返回给了我们一个尚未被静态资源加持过的简单 HTML 页面，所有的图片内容都是先以一个 div 占位：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-8N2JjnJV-1606275910462)(https://segmentfault.com/img/bVcKLo4 “image.png”)]

相应地，我们随便点开一个静态资源，可以看到它都是从 CDN 服务器上请求来的。

比如说图片：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-qUVRifNB-1606275910463)(https://segmentfault.com/img/bVcKLpt “image.png”)]

再比如 JS、CSS 文件：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-NWPoDRhH-1606275910463)(https://segmentfault.com/img/bVcKLpv “image.png”)]

CDN 优化细节

如何让 CDN 的效用最大化？这又是需要前后端程序员一起思考的庞大命题。它涉及到 CDN 服务器本身的性能优化、CDN 节点的地址选取等。谈离前端最近的这部分细节：CDN 的域名选取。
淘宝首页的例子，我们注意到业务服务器的域名是这个：

www.taobao.com

而 CDN 服务器的域名是这个

g.alicdn.com

我们讲到 Cookie 的时候，为了凸显 Local Storage 的优越性，曾经提到过
同一个域名下的请求会不分青红皂白地携带 Cookie，而静态资源往往并不需要 Cookie 携带什么认证信息。把静态资源和主页面置于不同的域名下，完美地避免了不必要的 Cookie 的出现！
看起来是一个不起眼的小细节，但带来的效用却是惊人的。以电商网站静态资源的流量之庞大，如果没把这个多余的 Cookie 拿下来，不仅用户体验会大打折扣，每年因性能浪费带来的经济开销也将是一个非常恐怖的数字。

如此看来，性能优化还真是要步步为营！

服务端渲染的探索与实践、

服务端渲染的运行机制

客户端渲染

客户端渲染模式下，服务端会把渲染需要的静态文件发送给客户端，客户端加载过来之后，自己在浏览器里跑一遍 JS，根据 JS 的运行结果，生成相应的 DOM。这种特性使得客户端渲染的源代码总是特别简洁，

<!doctype html>
<html><head><title>我是客户端渲染的页面</title></head><body><div id='root'></div><script src='index.js'></script></body>
</html>

根节点下到底是什么内容呢？你不知道，我不知道，只有浏览器把 index.js 跑过一遍后才知道，这就是典型的客户端渲染。

页面上呈现的内容，你在 html 源文件里里找不到——这正是它的特点。

服务端渲染

服务端渲染的模式下，当用户第一次请求页面时，由服务器把需要的组件或页面渲染成 HTML 字符串，然后把它返回给客户端。客户端拿到手的，是可以直接渲染然后呈现给用户的 HTML 内容，不需要为了生成 DOM 内容自己再去跑一遍 JS 代码。
使用服务端渲染的网站，可以说是“所见即所得”，页面上呈现的内容，我们在 html 源文件里也能找到。

比如知乎就是典型的服务端渲染案例：

服务端渲染解决了什么性能问题

事实上，很多网站是出于效益的考虑才启用服务端渲染，性能倒是在其次。
假设 A 网站页面中有一个关键字叫“前端性能优化”，这个关键字是 JS 代码跑过一遍后添加到 HTML 页面中的。那么客户端渲染模式下，我们在搜索引擎搜索这个关键字，是找不到 A 网站的——搜索引擎只会查找现成的内容，不会帮你跑 JS 代码。A 网站的运营方见此情形，感到很头大：搜索引擎搜不出来，用户找不到我们，谁还会用我的网站呢？为了把“现成的内容”拿给搜索引擎看，A 网站不得不启用服务端渲染。

但性能在其次，不代表性能不重要。服务端渲染解决了一个非常关键的性能问题——首屏加载速度过慢。在客户端渲染模式下，我们除了加载 HTML，还要等渲染所需的这部分 JS 加载完，之后还得把这部分 JS 在浏览器上再跑一遍。这一切都是发生在用户点击了我们的链接之后的事情，在这个过程结束之前，用户始终见不到我们网页的庐山真面目，也就是说用户一直在等！相比之下，服务端渲染模式下，服务器给到客户端的已经是一个直接可以拿来呈现给用户的网页，中间环节早在服务端就帮我们做掉了，用户岂不“美滋滋”？

服务端渲染的应用实例

先来看一下在一个 React 项目里，服务端渲染是怎么实现的。本例中，我们使用 Express 搭建后端服务。

项目中有一个叫做 VDom 的 React 组件，它的内容如下。

VDom.js:

 import React from 'react'const VDom = ()=>{return <div>我是一个被渲染为真是DOM的虚拟DOM</div>}export default VDom

在服务端的入口文件中，我引入这个组件，对它进行渲染：

 import express from 'express'import React from 'react'import {renderToString} from 'react-dom/server'import VDom from './VDom'// 创建一个express应用const app = express()//renderToString 是把虚拟DOM转化为真实DOM内容const Page = `<html><head><title>test</title></head><body><span>服务端渲染出了真实DOM:</span>${RDom}</body></html>`//配置HTML内容对应的路由app.get('/index',function(req,res){res.send(Page)})// 配置端口号const server = app.listen(8000)

根据我们的路由配置，当我访问 http://localhost:8000/index 时，就可以呈现出服务端渲染的结果了：

我们可以看到，VDom 组件已经被 renderToString 转化为了一个内容为<div data-reactroot="">我是一个被渲染为真实DOM的虚拟DOM</div>的字符串，这个字符串被插入 HTML 代码，成为了真实 DOM 树的一部分。
那么 Vue 是如何实现服务端渲染的呢？
该示例直接将 Vue 实例整合进了服务端的入口文件中：

const Vue  = require('vue')// 创建一个express应用const server = require('express')()//提取出renderer实例const renderer = require('vue-server-renderer').createRenderer()server.get('*',(req,res)=>{// 编写Vue实例(虚拟DOM节点)const app = new Vue({data:{url:req.url},// 编写模板HTML的内容template:`<div>访问的URL是：{{url}}</div>`})// renderToString是把Vue实例转换为真实DOM的关键方法renderer.renderToString(app,(err,html)=>{if(err){res.status(500).end("Internal Server Error")return}// 把渲染出来的真实DOM字符串插入HTML模板中res.end(`<!DOCTYPE HTML><html><head><title>hello</title></head><body>${html}</body></html>`)})})server.listen(8080)

实际项目比这些复杂很多，但万变不离其宗。强调的只有两点：一是这个 renderToString() 方法；二是把转化结果“塞”进模板里的这一步。这两个操作是服务端渲染的灵魂操作。在虚拟 DOM“横行”的当下，服务端渲染不再是早年 JSP 里简单粗暴的字符串拼接过程，它还要求这一端要具备将虚拟 DOM 转化为真实 DOM 的能力。与其说是“把 JS 在服务器上先跑一遍”，不如说是“把 Vue、React 等框架代码先在 Node 上跑一遍”。

服务端渲染的应用场景

服务端渲染本质上是本该浏览器做的事情，分担给服务器去做。这样当资源抵达浏览器时，它呈现的速度就快了。乍一看好像很合理：浏览器性能毕竟有限，服务器多牛逼！能者多劳，就该让服务器多干点活！

但仔细想想，在这个网民遍地的时代，几乎有多少个用户就有多少台浏览器。用户拥有的浏览器总量多到数不清，那么一个公司的服务器又有多少台呢？我们把这么多台浏览器的渲染压力集中起来，分散给相比之下数量并不多的服务器，服务器肯定是承受不住的。服务端渲染也并非万全之策。
在实践中，建议大家先忘记服务端渲染这个事情——服务器稀少而宝贵，但首屏渲染体验和 SEO 的优化方案却很多——我们最好先把能用的低成本“大招”都用完。除非网页对性能要求太高了，以至于所有的招式都用完了，性能表现还是不尽人意，这时候我们就可以考虑向老板多申请几台服务器，把服务端渲染搞起来了~