扛得住的MySQL数据库架构
免费分享，需要的自行获取哈
地址：网盘链接形式
Web前端性能优化自查清单
前言
一份简约、地道的Web前端性能优化清单。每个优化点都包含有概念、实操和参考材料。面试、实战两相宜。
这是一个大工程。在正式开端之前，先统一下言语，廓清每一局部的目的和请求，避免跑偏。
概念：把官话翻译成能看懂、能记住的人话，准绳上易读性 > 专业性
实操：本人操作一遍，不做云玩家；记载中心完成，便当CV
参考材料：信息来源选用一手材料，以便保证信息的完好性、精确性和时效性。除非看一手的了解不了……
一、网络层面
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/ /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 吗？
zxit666.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 衔接状态。
