download:Vue3+Nuxt3 打造 SSR 网站利用，0 到 1 实现服务端渲染

一、网络层面

1. DNS 预解析
   概念
   DNS-prefetch 是一种 DNS 预解析技术。它会在请求跨域资源之前，事后解析并进行 DNS 缓存，以缩小真正请求时 DNS 解析导致的请求提早。对于打开蕴含有许多第三方连接的网站，成果显著。
   实操
   增加 ref 属性为“dns-prefetch”的 link 标签。一般放在在 html 的 head 中。
   复制代码
   href 的值就是要预解析的域名，对应前面要加载的资源或用户有可能打开链接的域名。
   备注
   同理，也有“TCP/IP 预连接”，叫 preconnect。参考资料中有完整的描述。
2. 利用阅读器缓存
   概念
   阅读器缓存是阅读器存放在本地磁盘或者内存中的请求后果的备份。当有雷同请求进来时，间接响应本地备份，而无需每次都从原始服务器获取。这样不只晋升了客户端的响应效率，同时还能缓解服务器的拜访压力。
   其间，约定何时、如何使用缓存的规定，被称为缓存策略。分为强缓存和协商缓存。
   整个缓存执行的过程大抵如下：
   ①. 请求发动，阅读器判断本地缓存，如果有且未到期，则命中强缓存。阅读器响应本地备份，状态码为 200。控制台 Network 中 size 那一项浮现 disk cache;
   ②. 如果没有缓存或者缓存已过期，则请求原始服务器询问文件是否有变动。服务器根据请求头中的相干字段，判断目标文件新鲜度；
   ③. 如果目标文件没变更，则命中协商缓存，服务器设置新的过期工夫，阅读器响应本地备份，状态码为 304；
   ④. 如果目标文件有变动，则服务器响应新文件，状态码为 200。阅读器更新本地备份。
   上述过程有几个关键点

如何判断缓存是否过期？
阅读器读取缓存的请求后果中响应头的 Expires 和 Cache-Control，与以后工夫进行比较。
其中，Expires 是 HTTP 1.0 的字段，值是一个是相对工夫。
Expires: Tue, 18 Jan 2022 09:53:23 GMT
复制代码
比较相对工夫，有一个弊病，它依赖计算机时钟被正确设置。
为理解决这个问题，HTTP1.1 新增了 Cache-Control 字段，它的值是一个是绝对工夫。
Cache-Control: max-age=60 // 单位是秒
复制代码

如何判断文件是否变动？
首先可能通过比较 最初修改工夫。
// 缓存后果的 响应头
Last-Modified: Mon, 10 Jan 2022 09:06:14 GMT
// 新请求的 请求头
If-Modified-Since: Mon, 10 Jan 2022 09:06:14 GMT
复制代码
阅读器取出缓存后果中 Last-Modified 的值，通过 If-Modified-Since 上送到服务端。与服务器中目标文件的最初修改工夫做比较。
再者可能通过比较 Etag。

Etag 实体标签是附加到文档上的任意标签(引用字符串)。它们可能蕴含了文档的序列号或版本名，或者是文档内容的校验和及其他指纹信息。当发布者对文档进行修改时，会修改文档的实体标签来说明这是个新的版本。

从响应头的 ETag 取值，通过请求头的 If-None-Match 上送，与服务器目标文件的 Etag 标签比对。
// 缓存的 响应头
ETag: “61dbf706-142”
// 上送的 请求头
If-None-Match: “61dbf706-142”
复制代码
和下面一样，新增的字段也是为理解决前一种打算的某些缺点：

有些文档可能会被周期性地重写 (比如，从一个后盾过程中写入)，但实际蕴含的数据经常是一样的。尽管内容没有变动，但修改日期会发生变动。
有些文档可能被修改了，但所做修改并不重要，不需要让世界范畴内的缓存都重装数据 (比如对拼写或正文的修改)。
有些服务器无奈准确地判定其页面的最初修改日期。
有些服务器提供的文档会在亚秒间隙发生变动(比如，实时监视器)，对这些服务器来说，以一秒为粒度的修改日期可能就不够用了。

如果两个版本的字段同时存在，怎么办？
出于阅读器兼容方面的考虑，一般两组字段会被同时使用。他们没有优先级一说，取并集。
同时出现时，只有当两个条件都满足，才会命中相应缓存。

实操
缓存是 web 服务器和阅读器的核心能力，支流的 web 服务框架 nginx、koa-static 等都内置有上述缓存策略的实现。开箱即用，无需额定编程或配置。
以 Nginx 举例。强缓存的配置字段是 expires，它接受一个数字，单位是秒。
server {
listen 8080;
location / {
root /Users/zhp/demo/cache-koa/static;
index index.html;

# 注意 try_files 会导致缓存配置不失效

try_files $uri $uri/ /index.html;

expires 60;
}
}
复制代码
实际工作中确实配置一下就好了，但这体现不出什么学识点。为了加深印象，我这用 koa 简陋的模拟了一下，算是对下面那些学识点的考据。
上面是一个极简的动态资源服务，不带缓存的。
app.use(async (ctx) => {
// 1. 根据拜访路径读取指定文件
const content = fs.readFileSync(./static${ctx.path}, “utf-8”);
// 2. 设置响应
ctx.body = content;
});
复制代码
这种情况，无论拜访几次都是不进缓存的。
现在，在响应头加上强缓存所需的 Exprise 和 Cache-Control 字段
app.use(async (ctx) => {
// 1. 根据拜访路径读取指定文件
const content = fs.readFileSync(./static${ctx.path}, “utf-8”);
// 2. 设置缓存
ctx.response.set(“Cache-Control”, “max-age=60”);
ctx.response.set(‘Exprise’, new Date(new Date().getTime()+60*1000));
// 3. 设置响应
ctx.body = content;
});
复制代码
查看 Network，响应头会多出上面两个字段，且间隔 60 秒内的请求会走缓存，符合预期。
Expires: Tue, 18 Jan 2022 10:05:09 GMT
Cache-Control: max-age=60
复制代码
备注
抱着引用一手权威资料的想法，扒了《HTTP 权威指南》，但读感着实差强人意。老手倡导《图解 HTTP》起手，要敌对很多。
参考资料

《HTTP 权威指南》
HTTP 缓存机制
Nginx 中文文档

3. 动态资源 CDN
   概念

CDN 的全称是 Content Delivery Network，即内容散发网络。CDN 是构建在现有网络基础之上的智能虚构网络，依靠部署在各地的边缘服务器，通过核心平台的负载平衡、内容散发、调度等功能模块，运用户就近获取所需内容，升高网络拥塞，提高用户拜访响应速度和命中率。

核心功效总结起来就两点：
①. 通过负载平衡技术，为用户的请求抉择最佳的服务节点；
②. 通过内容缓存服务，提高用户拜访响应速度。
实操
一般玩家：抉择一个 CDN 服务商，看它提供的使用文档。通过配置域名和源站，代理到自己的动态资源服务器。
高级玩家：自建 CDN 服务器，balabal……
参考资料

阿里云 CDN 疾速入门

4. 开启 Gzip
   概念

gzip 是 GNUzip 的缩写，最早用于 UNIX 零碎的文件压缩。HTTP 协定上的 gzip 编码是一种用来改进 web 应用程序性能的技术，web 服务器和客户端（阅读器）必须独特反对 gzip。gzip 压缩比率在 3 到 10 倍左右，可能大大俭约服务器的网络带宽。

实操
实际操作过程中分为动静压缩和动态压缩。

动静压缩。指当收到请求后，服务器实时压缩而后输入数据流。服务器存放的是 css/js 文件。
Nginx 的 httpGzip 模块，反对该功能。次要配置如下：

开启或者敞开 gzip 模块

gzip on;

设置容许压缩的页面最小字节数。倡导设置成大于 1k 的字节数，小于 1k 可能会越压越大。

gzip_min_length 1024;

匹配 MIME 类型进行压缩，（无论是否指定）”text/html” 类型总是会被压缩的。

gzip_types text/plain application/x-javascript text/css text/html application/xml;
复制代码

动态压缩。服务器一开始存放的就是已经压缩好的文件，当接受请求后间接响应压缩资源，而不是收到请求后才压缩。
使用 Webpack + Nginx 的实现：
①. 安装并利用 compression-webpack-plugin 压缩插件
// ## 安装 ##
// 注意高版本会报错 Cannot read property ‘tapPromise’ of undefined
npm i –save-dev compression-webpack-plugin@5.0.1
// ## webpack 配置 ##
// vue.config.js
const CompressionPlugin = require(“compression-webpack-plugin”);
module.exports = {

 configureWebpack:{
   plugins: [new CompressionPlugin()
   ]
 }

}
复制代码
②. 执行构建 npm run build
打包实现后，在 dist 目录下会多出.gz 结尾的压缩文件
③. Nginx 配置开启 gzip_static
http{

gzip_static on;
server {
    listen       8082;
    location / {root   /Users/zhp/demo/demo-externals/dist;}
}

}
复制代码

后果考据
在 Response Header 中看到有 Content-Encoding: gzip，说明服务器配置失效；
在 Network 的 Size 列看数据比服务器上源文件要小，说明阅读器反对，Gzip 失效。

备注
gzip_static 的优先级高于 gzip。当 gzip 和 gzip_static 都开启时，nginx 会优先匹配.gz 文件，而后才走动静压缩。
参考资料：

你真的了解 gzip 吗？
www.npmjs.com/package/com…

5. 使用高版本的 HTTP 协定
   概念
   从 1.0 到 1.1 再到平常的 2.0，HTTP 协定在继续迭代中，变的更快更强。
   其间的变更内容多且硬核，这里出于解释高版本劣势的目标，简略的列举一二，HTTP/1.1 的持久连接和管道化技术、2.0 的多路复用和首部压缩。

持久连接

HTTP 协定的初始版本中，每进行一次 HTTP 通信就要断开一次 TCP 连接。为了缩小了 TCP 连接的重复建立和断开所造成的额外开支。HTTP/1.1 和一部分的 HTTP/1.0 想出了 持久连接（HTTP Persistent Connections，也称为 HTTP keep-alive 或 HTTP connection reuse）的方法。持久连接的个性是，只需任意一端 没有明确提出断开连接，则保持 TCP 连接状态。