联接成功以后就可以开始传输数据了，传输数据须要将用户输入的URL封装成HTTPRequest恳求报文，发送到服务器，服务器收到恳求后会发出应答，即响应数据。
断掉TCP联接（4次挥手）
顾客端—>服务器端好了，我们断掉联接吧？
服务端—>顾客端好的，我在检测一哈有没有须要在发给你的信息？
服务端—>顾客端好了，我们可以断掉联接了
顾客端—>服务端好的
浏览器解析
浏览器通过解析HTML，生成DOM树，解析CSS，生成CSS规则树，之后通过DOM树和CSS规则树生成渲染树。
按照渲染树布局，估算CSS款式，即每位节点在页面中的大小和位置等几何信息。HTML默认是流式布局的，CSS和js会打破这些布局，改变DOM的外形款式以及大小和位置。这时就要提及两个重要概念：repaint(重画)和reflow(回流)。
repaint：屏幕的一部份重写，不影响整体布局，例如某个CSS的背景色变了，但元素的几何规格和位置不变。
reflow：意味着器件的几何规格变了，我们须要重新验证并估算渲染树。是渲染树的一部份或全部发生了变化。这就是Reflow，或是Layout。
性能优化工具LightHouse
LightHouse是Google开源的一个手动化工具，用于改进网路应用的质量。你可以将其作为一个Chrome扩充程序运行，或从命令行运行。当为Lighthouse提供一个要审查的网址，它将针对此页面运行一连串的测试，之后生成一个有关页面性能的报告。可以参考失败的测试，瞧瞧可以采取什么举措来改进应用。
——谷歌应用商店介绍
点击runaudits都会手动帮我们生成性能优化报告。
这儿推荐我们使用下一代图片低格的技术，缘由是JPEG2000、JPEGXR和WebP等图象格式一般比PNG或JPEG提供更好的压缩，这意味着更快的下载速率和更少的数据消耗。
网路部份DNSPrefetch优化
原理
当我们访问的时侯，首先就须要把域名转化为对应的IP地址，DNS本身的解析是一个十分历时的过程，打开DNSPrefetch以后，浏览器会在空闲时间提早将这种域名转化为对应的IP地址，这儿为了避免DNSPrefetch阻塞页面渲染影响用户体验，Chrome浏览器的引擎并没有使用它的网路堆栈去进行预解析，而是单独开了8个完全异步的Worker线程专门负责DNSPrefetch。
怎样使用
DNSPrefetch通过提早解析我们用到的一些常见域名，大大降低了实际访问时所耗费的时间，是一个十分好的解决方案，但是假如你所在的公司有国际化的业务，合理地运用DNSPrefetch相信可以带来不错的疗效。最后这儿要说明一点，DNSPrefetch的数目不是越多越好，大多数情况下我们设置3-5个常用的即可，多了反倒会适得其反，虽然DNSPrefetch也是会占用设备宽带。
Webpack性能优化完善速率优化
如今一个普通的后端项目中就有几百个包，加上每位包都有相关的依赖，可想而知工作量有多大。优化的办法也很简单，就是降低版本描述文件。
推荐使用天猫提供的npm库房
npm config set registry https://registry.npm.taobao.org
Webpack的打包流程
可以将其理解为一个函数，配置文件则是其参数，传入合理的参数后，运行函数能够得到我们想要的结果。
降低毋须要的编译，我们在使用loader处理文件的时侯，应当尽量把文件范围缩小，对于一些不须要处理的文件直接忽视。
module: {
rules: [
{
//处理后缀名为js的文件
test: /\.js$/,
//exclude去掉不需要转译的第三方包 && 或者这里使用include去声明哪些文件需要被处理
exclude: /(node_modules|bower_components)/,
//babel的常用配置项
use: {
loader: "babel-loader",
options: {
presets: ["@babel/preset-env"],
//缓存设置为开启
cacheDirectory: true,
},
},
},
];
}
这儿我们对于不须要处理的第三方包直接使用exclude属性排除在外，或则须要处理的文件使用include属性去包含，再者里面我们在options配置当中降低了cacheDirectory:true，这样对于转译结果就可以直接缓存到文件系统当中，在我们上次须要的时侯直接到缓存当中读取即可。
使用模块热替换(HMR)，传统的假如我们没有配置模块热替换，则须要每次刷新整个页面，效率很低。而使用模块热替换以后，我们只须要重新编译发生变化的模块，不须要编译所有模块，速率里面大大增强。具体配置方式如下：
module.exports = {
......
plugins: [
new webpack.HotModuleReplacementPlugin(), // 引入模块热替换插件
],
devServer: {
hot: true // 开启模块热替换模式
}
}
因为现今的项目就会引用大量的第三方包，这种包基本都是不会变的，我们完全把她们打包到单独的文件当中，这就涉及到了公共代码的提取,optimization.splitChunks插件
optimization: {
splitChunks: {
//设置那些代码用于分割
chunks: "all",
// 指定最小共享模块数(与CommonsChunkPlugin的minChunks类似)
minChunks: 1,
// 形成一个新代码块最小的体积
minSize: 0,
cacheGroups: {
framework: {
test: /lodash/,
name: "vendor",
enforce: true
}
}
}
}
打包文件质量优化
怎样使打包出的文件尽可能的小，这样我们在加载文件的时侯才会更快。
1.压缩JavaScript代码，在压缩JavaScript代码的时侯我们须要先将代码解析成AST句型树，这个过程估算量十分大，我们常用的插件是webpack-uglify-parallel。通过webpack-uglify-parallel我们可以将每位资源的压缩过程交给单独的进程，借此来提高整体的压缩效率。这个插件并不在Webpack内部，须要我们单独安装。配置方式也比较简单，如下：
const os = require("os");
const UglifyJsParallelPlugin = require("webpack-uglify-parallel");
new UglifyJsParallelPlugin({
//开启多进程
workers: os.cpus().length,
mangle: true,
compressor: {
//忽略警告
warnings: false,
//打开console
drop_console: true,
//打开debugger
drop_debugger: true,
},
});
2.压缩CSS代码，前面我们介绍了压缩JavaScript代码的方式，同样CSS代码同样也可以被压缩。WebPack4.x我们用MiniCssExtractPlugin和OptimizeCSSAssetsPlugin，具体配置如下：
const OptimizeCSSAssetsPlugin = require("optimize-css-assets-webpack-plugin");
const MiniCssExtractPlugin = require("mini-css-extract-plugin");
module.exports = {
module: {
rules: [
{
test: /\.css$/,
use: [
MiniCssExtractPlugin.loader, // 分离css代码
"css-loader",
],
},
],
},
plugins: [
new MiniCssExtractPlugin({
filename: "static/css/[name].[contenthash:8].css", //提取css存放目录
}),
new OptimizeCssAssetsPlugin(), // 使用OptimizeCssAssetsPlugin对CSS进行压缩
],
};
3.压缩图片，图片在通常项目当中都是最大的静态资源，所以图片的压缩就变得十分重要。图片压缩插件我们常用的是imagemin-webpack-plugin。配置较为简单，如下：
const ImageminPlugin = require("imagemin-webpack-plugin").default;
module.exports = {
plugins: [
new ImageminPlugin({
pngquant: {
//指定压缩后的图片质量
quality: "95-100",
},
}),
],
};
及时升级你的Webpack版本来获得更优的打包速率图片优化图片格式介绍
优化方式：
图片懒加载
图片懒加载是现今最常用的性能优化手段之一，对于首屏用不到的图片，我们完全可以使用懒加载在用户下拉到对应位置的时侯再进行加载，防止网页打开时一下子加载过多资源。
图片渐进显示
JPEG还可以细分为BaselineJPEG（标准型）、ProgressiveJPEG（渐进式）。
BaselineJPEG格式：
ProgressiveJPEG（渐进式）：使用了渐进显示
使用ProgressiveJPEG格式图片，直接使用Photoshop，之后在保存为JPEG格式的时侯，将连续这个选项勾选即可。
缓存优化CDN缓存
CDN的全称是ContentDeliveryNetwork，即内容分发网路，基本原理是避免互联网上有可能影响数据传输速率和稳定性的困局和环节，使内容才能传输的更快，愈发稳定。
**原理：**通过在各个地方布署相应的服务器，产生CDN集群，进而提升访问速率。
顾客端在获得IP地址以后，访问近来的边沿节点。边沿节点是最小的，规模也是最小的，不会缓存所有东西。若果没有找到对应资源都会去它的上一层区域节点去找寻，若果仍然没有则去中心节点找寻，假如中心节点也没有，最后再去原网站去访问。这一层一层向下找的过程我们称为回源。
优化方案：
本地缓存LocalStorage
优势
劣势
SessionStorage
SessionStorage只在当前会话下才能起作用，一旦我们关掉当前的Tab，SessionStorage也就失效了。因而，SessionStorage是一个有时效性的储存方案。
使用场景：因为SessionStorage具有时效性，常用的业务场景例如网站常见的旅客登陆，就可以储存在SessionStorage当中，还有网站的一些临时浏览记录都可以使用SessionStorage来进行记录。
Cookie
Cookie的大小最大只有4KB，并且它是纯文本的文件，我们每次发起HTTP恳求就会携带Cookie。
特点
IndexedDB
IndexedDB是非关系型数据库(类NOSQL)，虽然它和我们当下十分流行的MongoDB十分相像，我们直接使用JavaScript语言就可以直接进行相关的操作，不须要别的语言，大大增加了学习成本。
合理借助缓存是后端工程师的选修课